Windows
macOS
Android
iOS
遇到网站突然打不开时，先不要急着重启服务器或修改代码。域名解析异常排查应从“域名是否存在、记录是否正确、不同网络是否得到一致结果”三个问题开始。解析层出现故障时，浏览器可能提示“找不到服务器”，但源站本身仍然正常运行。
一、先判断是不是解析问题
打开网站后，记录浏览器的具体提示。若显示 DNS_PROBE_FINISHED_NXDOMAIN、SERVFAIL 或“服务器 IP 地址无法找到”，通常应优先检查 DNS；若能够进入网站但返回 403、404、502 或连接超时，则还要继续检查 Web 服务、防火墙、负载均衡和源站网络。
可以先用手机蜂窝网络和固定宽带分别访问。同一域名在两个网络中的结果不同，常见原因包括递归 DNS 缓存、运营商线路差异、区域解析策略或本地网络配置，而不一定是源站宕机。
二、域名解析异常排查清单
1. 检查域名状态与到期情况
- 在注册商后台确认域名仍处于正常状态，没有过期、暂停解析或被锁定。
- 确认域名使用的权威 DNS 服务器与当前管理解析记录的平台一致。
- 如果近期更换过 DNS 服务商，核对注册商处的 NS 记录是否已经更新。
域名注册商、DNS 托管商和网站服务器可能是三个不同对象。只在错误的平台修改 A 记录，通常不会产生实际效果。
2. 核对记录类型和目标值
| 记录类型 | 常见用途 | 重点检查 |
|---|---|---|
| A | 将主机名指向 IPv4 地址 | 地址是否属于当前服务器，是否误填旧地址 |
| AAAA | 将主机名指向 IPv6 地址 | IPv6 服务是否真正可用，避免只配置了失效地址 |
| CNAME | 将一个主机名指向另一个主机名 | 目标是否拼写正确，是否与其他记录冲突 |
| MX | 指定邮件接收服务器 | 优先级和邮件主机是否完整 |
根域名与 www 子域名也要分别确认。根域名常用 A 或 CNAME Flattening 等方式处理，www 则经常使用 CNAME；两者不能因为名称相近就默认结果相同。
3. 对比权威 DNS 与递归 DNS
在 Windows 中打开命令提示符，执行 nslookup example.com；在 macOS 或 Linux 中可使用 dig example.com。将 example.com 替换为实际域名即可。先观察返回的地址，再指定不同 DNS 服务器进行对比，例如使用网络默认 DNS 与已知公共递归 DNS。
- 查询域名的 A、AAAA、CNAME 和 MX 记录，确认返回内容是否符合后台配置。
- 查询域名的 NS 记录，确认请求是否到达预期的权威 DNS。
- 如果权威 DNS 返回正确，而本地递归 DNS 仍返回旧地址，优先考虑缓存和 TTL。
- 如果权威 DNS 本身返回错误，继续检查记录、DNSSEC 和托管商状态。
这一步是域名解析异常排查中区分“配置错误”和“传播未完成”的关键。不要只看浏览器一次访问结果。
三、重点处理缓存、TTL 与 DNSSEC
DNS 记录中的 TTL 表示缓存建议保留时间，常见设置可能从几分钟到数小时不等。修改记录后，旧结果不会在所有网络中同时消失；实际生效时间还受递归 DNS、浏览器和本地系统缓存影响，通常需要等待一段时间，复杂变更可能持续到约 24 至 48 小时。
排查时可依次清理本机 DNS 缓存、重启浏览器，并用另一条网络复查。Windows 可执行 ipconfig /flushdns；macOS 的缓存刷新方式会随系统版本变化，建议使用对应版本的系统命令或直接重启网络服务。
若启用了 DNSSEC，DS 记录、签名记录或密钥链不匹配可能导致 SERVFAIL。此时即使 A 记录看起来正确，部分递归 DNS 仍会拒绝返回结果。刚更换 DNS 托管商时，应确认旧 DS 记录是否需要删除或更新。
四、按风险选择修复方式
小范围记录错误
适合直接修正 A、AAAA、CNAME 或 MX 目标，并将 TTL 临时调整到较短范围。修正后保留变更记录，等待多个网络复查。不要同时修改大量无关记录，否则难以判断哪一项产生影响。
服务器正在迁移
更稳妥的做法是先让新旧源站同时运行，再修改 DNS 指向。确认新地址能够处理 HTTPS、静态资源、登录和邮件等关键功能后，再逐步下线旧源站。涉及 HTTPS 时，还要检查证书是否覆盖根域名和实际使用的子域名。
无法确认故障边界
保存 nslookup 或 dig 的完整输出、发生时间、所在网络和错误提示，再提交给 DNS 托管商或注册商。清晰的证据比单独描述“网站打不开”更容易定位问题。
五、预防再次发生
- 为域名、DNS 托管和服务器建立变更记录，注明修改人、时间、旧值和新值。
- 重要域名启用双人复核，尤其是 NS、DNSSEC、MX 和根域名记录。
- 为网站和邮件分别设置外部监测，避免只监测服务器端口。
- 变更前降低 TTL，稳定后再恢复到适合业务的范围，避免长期使用过短 TTL 增加查询压力。
常见问题
为什么只有部分地区打不开？
可能是不同递归 DNS 的缓存尚未统一，也可能存在区域线路、IPv6 或权威 DNS 节点异常。应比较多个网络的查询结果。
修改 A 记录后多久生效？
取决于原 TTL、缓存状态和 DNS 服务商，通常是数分钟到数小时，部分网络可能更久，不能仅凭本地一次查询判断完成。
能否直接修改 hosts 文件？
hosts 适合临时验证某个 IP 是否能正常提供网站，不会修复公网 DNS。验证结束后应恢复文件，避免影响后续访问。
解析正常但网站仍打不开怎么办？
继续检查服务器端口、防火墙、反向代理、证书和应用日志。域名解析异常排查只解决名称到地址的映射问题，不能替代源站故障诊断。
按照“现象确认—记录核对—权威查询—缓存等待—业务复查”的顺序执行，能减少反复改配置的风险，也能让域名解析异常排查更快收敛到具体原因。