先确认是不是 DNS 问题
浏览器通常会提示域名解析失败。在 Chrome 和 Edge 中，ERR_NAME_NOT_RESOLVED 或 DNS_PROBE_FINISHED_NXDOMAIN 这类错误指向 DNS。而 ERR_CONNECTION_TIMED_OUT、ERR_CONNECTION_REFUSED 或证书警告说明域名已经解析成功，问题出在后续环节：服务器、网络或 TLS。
在命令行中，curl 可以显示它实际连接的地址：
curl -v -o /dev/null https://example.com/如果 curl 报告 Could not resolve host，说明在你的系统上解析失败。如果它输出类似 Trying 203.0.113.10:443 的行，随后卡住或报错，说明 DNS 已经完成了它的工作，应该转而排查服务器或网络。
查询关键记录
使用 dig 或 nslookup 逐一查询浏览器所依赖的记录类型：
dig example.com A +short
dig example.com AAAA +short
dig www.example.com CNAME +short
dig example.com NS +short
nslookup -type=AAAA example.com- A / AAAA：返回 IPv4 和 IPv6 地址。确认它们指向当前的主机或 CDN。迁移后遗留的过期 AAAA 记录是“我这里正常、部分访客打不开”的典型原因，因为支持 IPv6 的客户端通常会优先使用它。
- CNAME：把一个名称设为另一个名称的别名。CNAME 不能与同名的其他记录共存，因此不允许出现在区域顶点（即
example.com本身）；许多 DNS 服务商为此提供 ALIAS、ANAME 或 CNAME 展平（flattening）等替代方案。 - NS：列出权威域名服务器。如果它们不是你编辑区域所在的服务器，你做的修改永远不会生效。
去掉 +short 后，dig 还会显示响应的 status、头部标志位以及接下来需要用到的 TTL。
对比公共解析器与权威服务器
每个解析器各自独立缓存，因此在一段时间内返回不同结果是正常的。先询问几个公共解析器，再询问“权威来源”（把 ns1.example.net 替换为 dig NS 返回的名称）：
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @ns1.example.net example.com A +norecurse
dig example.com A +trace权威服务器反映的是区域当前的实际内容；注意查看头部中的 aa（authoritative answer，权威应答）标志。dig +trace 从根服务器开始，沿着每一级委派一直查到你的区域，从而绕过递归缓存，并暴露委派问题，例如 TLD 仍指向旧的域名服务器。
如果权威服务器返回新值，而某个公共解析器返回旧值，那么并没有故障：该解析器只是仍在使用缓存副本。如果权威服务器返回的值本身就是错的，就需要修正区域配置。
读懂错误：NXDOMAIN、SERVFAIL 还是超时
- NXDOMAIN：该名称不存在。检查是否有拼写错误、缺少记录（常见的是
www）、域名已过期，或区域并没有委派到你以为的地方。 - NOERROR 但应答为空（通常称为 NODATA）：名称存在，但没有所请求类型的记录，例如对仅支持 IPv4 的主机查询 AAAA。
- SERVFAIL：解析器无法获得可用的应答。常见原因包括权威服务器宕机或未配置该区域（即“跛脚委派”，lame delegation），以及 DNSSEC 验证失败。如果只有加上
+cd（关闭验证检查）才能查询成功，请检查 DS 和 DNSKEY 记录。 - REFUSED：服务器拒绝回答，通常是向某台权威服务器查询了它并不托管的区域。
- 超时（
connection timed out; no servers could be reached）：完全没有回复。要么服务器不可达，要么防火墙拦截了 53 端口上的 DNS 流量；换一个解析器试试，就能判断是哪一种。
TTL、缓存与所谓的“传播”
每条 DNS 记录都有一个以秒为单位的 TTL（生存时间），由管理该区域的一方设置。获取到该记录的解析器最多可以将其缓存这么长时间。查询递归解析器时，dig 显示的 TTL 是该记录在其缓存中的剩余时间。
因此，DNS 变更并不是向外“扩散”的。区域一更新，权威服务器就会提供新值，而每个解析器会继续用缓存副本作答，直到副本过期。人们所说的“传播”，其实就是缓存过期。实际操作中：
- 在计划变更之前，至少提前一个旧 TTL 周期把 TTL 调低（例如 300 秒），变更完成后再调回去。
- 否定应答同样会被缓存。如果在你创建某个名称之前就有人查询过它，NXDOMAIN 可能会被缓存一段时间，时长由区域的 SOA 记录决定。
- 在注册商处更换域名服务器，修改的是父区域（TLD）中的 NS 记录，其 TTL 通常为一天或更长，且不受你控制。
- 操作系统和浏览器也各有自己的缓存。
排除本地原因
dig 和 nslookup 直接查询 DNS 服务器。而浏览器走的是操作系统解析器，它还会读取 hosts 文件和本地缓存。如果 dig 的结果正确，浏览器却仍然打不开，请检查：
- hosts 文件：macOS 和 Linux 上是
/etc/hosts，Windows 上是C:\Windows\System32\drivers\etc\hosts。一条遗忘的测试条目会完全覆盖 DNS。getent hosts example.com（Linux）或dscacheutil -q host -a name example.com（macOS）可以显示系统解析器返回的结果。 - VPN 与企业网络：VPN 可能下发自己的 DNS 服务器或分流 DNS 规则。在开启和关闭 VPN 的情况下分别对比
scutil --dns（macOS）、resolvectl status（Linux）或ipconfig /all（Windows）的输出。 - 浏览器的 DNS over HTTPS：Chrome、Edge 和 Firefox 可以使用各自的加密解析器，因此浏览器的结果可能与系统不一致。检查“安全 DNS”设置；在基于 Chromium 的浏览器中，可以在
chrome://net-internals/#dns清除主机缓存。 - 本地缓存：使用
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder（macOS）、ipconfig /flushdns（Windows）或resolvectl flush-caches（systemd-resolved）清空缓存。
快速检查清单
- 查看浏览器错误：是域名解析失败，还是 DNS 成功之后的连接或 TLS 错误？
- 分别查询顶点域名和
www的 A、AAAA 和 CNAME 记录。 - 确认 NS 记录指向你编辑区域所在的服务商。
- 对比
1.1.1.1、8.8.8.8以及使用+norecurse查询的权威服务器的结果。 - 记下响应状态：NXDOMAIN、NODATA、SERVFAIL、REFUSED 还是超时。
- 在断定变更“还没传播”之前，先查看剩余 TTL。
- 排除 hosts 文件、VPN、浏览器 DNS over HTTPS 和本地缓存的影响。
用 WebTraceCheck 检查
如果想从你自己的网络之外再看一次，WebTraceCheck 无需注册账号即可发起 DNS 或网站检查。其网站审计会检查 DNS、HTTP 响应、重定向和技术 SEO，并为每条观察结果注明来源和测量局限。如果要在真实浏览器中复现问题，同时避开本机的 hosts 文件、VPN 和本地缓存，可以使用 GitHub 登录并打开一个临时云浏览器，自行选择浏览器引擎、地区和设备模式。