DNS 是什么
一句话总结
DNS（域名系统）把人类可读的域名（
getgrowth.app）翻译成机器可读的 IP 地址（104.236.24.124），在 Growth App 中使用 Cloudflare 管理所有*.getgrowth.app域名的解析。
🤔 为什么会有它 / 解决了什么问题
互联网通信靠 IP 地址，但人记不住一串数字。DNS 做了域名到 IP 的电话簿映射，让用户访问 demo1.getgrowth.app 而不是 45.55.93.224。
🔍 具体原理 / 运作逻辑
浏览器先查本地缓存，没命中则向上游 DNS 服务器层层递归查询，最终从权威 DNS 服务器（我们的 Cloudflare）获取 IP 地址。Growth App 开启 CF 橙色云朵（代理模式），CF 返回的是 CDN 边缘节点 IP 而非真实服务器 IP。
更硬核的技术细节（点击展开）
DNS 记录有 A（IPv4）、AAAA（IPv6）、CNAME（别名）、MX（邮件）、TXT（文本验证）等类型。Press 的
*.getgrowth.app通配符记录让所有子域名自动解析，无需为每个新站点单独加记录。
🧭 什么情况下会用到 / 什么场景会遇到它
- 浏览器访问
press.getgrowth.app时——DNS 解析→CF 边缘→n1 nginx→Press 容器 - 新站点（如
demo2.getgrowth.app）创建后——通配符*记录自动生效，Press 无需额外 DNS 操作 dig getgrowth.app或nslookup排查解析问题
🛠️ 怎么上手 / 在哪操作
在 Cloudflare Dashboard 的 DNS 面板管理所有记录；通配符 * 记录已配好，日常不需要手动添加新子域名。
⚖️ 副作用 / 代价 / 取舍
- DNS 缓存生效有延迟（TTL 决定，最长 24 小时），修改记录后不是立即生效
- CF 橙色云朵模式下 CF 是代理而非纯 DNS——CF 出问题则全站不可访问，即使源站正常
- 通配符 DNS 不能用于根域名（
getgrowth.app本身需要单独的 A 记录）
🕰️ 来历
- 谁提出/创造的：Paul Mockapetris（1983 年 IETF 标准）
- 什么时候出现的：1983 年（RFC 882 和 RFC 883），1987 年更新为 RFC 1034/1035（沿用至今）
🔗 关联 / 经常一起出现的概念
- CDN：DNS 将域名解析到 CF 边缘节点，CDN 加速内容分发，两者在 CF 橙色云朵模式下合为一体
- SSL：DNS 解析完成后浏览器发起 HTTPS 连接，CF 的边缘 TLS 证书必须覆盖对应域名
⚠️ 注意事项 / 常见误区
dig 的结果可能来自 CF 代理 IP（橙色云）而非源站 IP。要查源站用 dig +short getgrowth.app @8.8.8.8 绕过 CF 或关掉橙色云朵。
📎 记忆锚点
电话簿——你知道人名（域名），翻电话簿（DNS）找到号码（IP），但号码可能是前台总机（CF 代理）而非本人的工位电话。
📝 更新日志
| 日期 | 改动 | 原因 |
|---|---|---|
| 2026-07-13 | 首次创建 | - |