DNS 解析全链路：从输入到响应

你在浏览器里输入 chatgo.fun，到页面真正出现，中间发生了什么？大多数人知道有个叫 DNS 的东西在做「域名转 IP」的工作，但这个过程的细节，往往决定了你的网站是快还是慢、是稳定还是偶尔抽风。

这篇文章从头到尾走一遍 DNS 解析的完整链路，不跳过任何关键环节。

DNS 是什么：互联网的电话簿

计算机之间通信靠 IP 地址，但 IP 地址是一串数字，人类记不住。DNS（Domain Name System）做的事就是维护一张「域名 → IP」的映射表，让你只需要记住 chatgo.fun，不需要记住它背后的 IP。

这张表不是存在一个地方的，而是分布在全球数以万计的 DNS 服务器上，通过一套层级结构协同工作。理解这个层级，是理解整个解析过程的关键。

本地缓存查询

浏览器先查自己的 DNS 缓存，再查操作系统缓存（hosts 文件也在这里）。命中则直接返回，耗时接近 0。

递归解析器

缓存未命中，请求发给你的递归解析器（通常是运营商的 DNS，或 8.8.8.8、1.1.1.1）。它负责代你完成后续所有查询。

根域名服务器

解析器先问根服务器（全球 13 组）：「.fun 的域名服务器在哪？」根服务器返回 .fun 顶级域的服务器地址。

顶级域服务器（TLD）

解析器再问 .fun 的 TLD 服务器：「chatgo.fun 的权威 DNS 在哪？」返回 Cloudflare 的 NS 地址。

权威域名服务器

解析器最后问 Cloudflare 的权威 DNS：「chatgo.fun 的 IP 是多少？」这里存着你真正配置的 DNS 记录。

返回结果 + 缓存

权威服务器返回 IP，解析器缓存结果（按 TTL 时长），再把 IP 告诉你的浏览器。

TCP 连接 + TLS 握手

拿到 IP，浏览器发起 TCP 连接，HTTPS 还需要 TLS 握手，之后才是真正的 HTTP 请求。

「完整的 DNS 解析在首次访问时可能需要 100ms 以上；有缓存时则接近瞬间。这就是 TTL 设置如此重要的原因。」

· 关键概念 ·

TTL（Time To Live）是 DNS 记录的缓存时间，单位是秒。设置为 300，意味着全球各地的 DNS 缓存最多 5 分钟后才会更新。

TTL 的设置是一个权衡：TTL 越长，解析越快（命中缓存），但改动生效越慢；TTL 越短，改动快，但解析压力大、速度略降。日常运营时建议 300~3600 秒；计划切换服务器前，提前把 TTL 降到 60 秒，等缓存过期后再切，停机时间可以压到最短。

当你在 Cloudflare 开启某条 DNS 记录的橙云代理后，返回给用户的 IP 不再是你的源站 IP，而是 Cloudflare 的 Anycast IP。用户的请求先到 Cloudflare 最近的节点，再由 Cloudflare 转发到你的源站。

这带来三个好处：隐藏源站 IP（DDoS 防护）、CDN 缓存加速、以及 SSL 在 Cloudflare 侧终结（源站可以用 HTTP）。代价是增加了一跳，但 Cloudflare 节点遍布全球，这一跳通常比直连源站更快。

某些网络环境下，DNS 查询会被中间节点拦截，返回错误的 IP——这就是 DNS 污染。症状是域名解析到一个奇怪的地址，或者干脆解析失败。解法是使用加密 DNS（DoH 或 DoT），让查询过程无法被中间人篡改。Cloudflare 的 1.1.1.1 同时支持这两种协议。

理解了 DNS 的工作原理，很多「网站打不开」的问题就不再神秘了。大多数时候，在 DNS 层面动几下，比换服务器有效得多。