遇到域名解析异常时，先不要反复修改记录或重启服务器。建议按照“域名状态—权威 DNS—解析记录—本地缓存—网站服务”的顺序排查：先确认问题影响范围，再判断是记录配置错误、DNS 服务异常，还是域名已经解析到服务器但网站本身没有正常响应。

先判断是全部无法访问，还是部分网络异常

用手机流量、家庭宽带和其他网络分别打开域名，必要时再换一台设备测试。不同网络的结果有助于区分问题位置。

第一步：确认域名没有过期或被暂停

登录域名注册商后台，检查域名是否仍在有效期内，是否因为未完成实名认证、付款异常、争议处理或安全策略而被暂停。域名一旦处于过期、锁定、暂停解析等状态，即使 DNS 记录填写正确，也可能无法正常解析。

同时查看域名当前使用的权威 DNS 服务器。注册商后台显示的 NS 服务器，必须与实际管理解析记录的平台一致。例如，域名已经切换到新的 DNS 服务商，但记录仍添加在旧平台，查询到的结果就不会按照预期变化。

第二步：核对 NS、A、AAAA 和 CNAME 记录

解析异常最常见的原因不是服务器宕机，而是记录类型、主机记录或目标值填错。检查时应重点确认以下内容：

• A 记录：把域名指向 IPv4 地址，确认 IP 是当前服务器公网地址，没有多写、少写或填入内网地址。
• AAAA 记录：把域名指向 IPv6 地址。如果 IPv6 服务器不可用，但仍保留错误的 AAAA 记录，部分网络可能优先访问 IPv6，表现为打不开或访问超时。
• CNAME 记录：常用于把子域名指向另一个域名。目标应填写服务商提供的规范域名，不能把 CNAME 与同一主机名下的 A、AAAA 等记录随意并存。
• 主机记录：根域名、www、api、mail 等是不同名称，不能因为根域名配置正确，就默认所有子域名也能使用。
• 线路和地域设置：如果启用了分线路、分地区或权重解析，要确认每一条线路都有有效目标，且测试网络确实命中了预期线路。

如果使用 CDN、云防护或负载均衡，A 记录通常应指向服务商指定的接入地址，而不是直接指向源站；如果绕过 CDN 直接改成源站 IP，可能导致访问策略、证书或安全防护失效。

第三步：对比本地、公共 DNS 与权威 DNS 的结果

仅看浏览器报错不足以定位问题。可以在 Windows 命令提示符中使用 nslookup 查询，在 macOS 或 Linux 中使用 dig。将命令中的域名替换为实际域名。

• Windows 可查询：nslookup 你的域名
• 查询 NS 服务器：nslookup -type=ns 你的域名
• 查询 IPv4：nslookup -type=a 你的域名
• macOS 或 Linux 可查询：dig 你的域名 A
• 查看简洁结果：dig 你的域名 A +short

先记录本地网络返回的结果，再使用其他网络或可信的公共递归 DNS 进行对比。如果不同网络返回的 IP 不一致，可能是缓存、分线路配置或解析尚未完成；如果多个递归 DNS 都没有结果，则应继续检查权威 DNS 和记录本身。

查询结果中的错误也有参考价值：

• NXDOMAIN：当前查询方认为该域名不存在，常见原因是域名写错、记录不存在、域名委派错误或负缓存尚未过期。
• SERVFAIL：递归 DNS 没有得到有效答案，可能与权威 DNS 不可用、DNSSEC 校验失败或区域配置异常有关。
• 超时：可能是 DNS 服务器没有响应、网络拦截或权威服务器故障，不等同于“没有这条记录”。

第四步：清理本地缓存，排除设备和网络影响

如果后台记录已经修正，但只有自己的电脑仍然异常，可以先刷新本地 DNS 缓存。Windows 命令提示符中执行 ipconfig /flushdns；浏览器也可能保留独立的 DNS 缓存，关闭并重新打开浏览器后再测试。

路由器同样可能缓存旧结果。可以重启路由器，或临时使用其他网络进行对比。更换递归 DNS 只能用于定位问题，不能替代对权威解析记录的修复。如果所有网络都返回错误结果，单纯清理本地缓存不会解决根本问题。

修改解析后为什么还没有恢复

DNS 记录会按照 TTL 被递归 DNS 和终端缓存一段时间。修改权威 DNS 后，新的查询可能已经得到新值，但部分地区仍会暂时保留旧结果；删除记录后，NXDOMAIN 也可能因负缓存而继续存在。

尤其是更换 NS 服务器时，旧的委派信息和缓存不一定立即消失。此时不要频繁来回切换 DNS 服务商，也不要连续修改多个记录，否则难以判断当前生效的是哪一份配置。应保留修改时间、旧值和新值，间隔一段时间从多个网络复查。

如果 DNS 平台允许设置 TTL，修复前可以适当降低 TTL，但降低 TTL 只会影响后续缓存时间，无法立即清除已经形成的旧缓存。恢复稳定后，再根据访问量和变更频率设置合理值。

重点排查 DNSSEC 和自建 DNS 的特殊问题

如果域名启用了 DNSSEC，注册商处的 DS 记录必须与当前 DNS 服务商的签名信息匹配。更换 DNS 服务商、重新创建 DNSSEC 密钥或迁移解析区域后，如果旧 DS 记录仍然存在，部分递归 DNS 可能返回 SERVFAIL。

这类问题不要盲目删除安全配置。应先确认当前区域是否启用 DNSSEC、当前服务商提供的 DS 信息是否与注册商后台一致；如果确认已经停止 DNSSEC，再按服务商和注册商的流程清理过期 DS 记录。

如果使用自建权威 DNS，还要检查服务器是否能从公网通过 DNS 所需端口提供服务、主从区域是否同步、SOA 序列号是否更新，以及自定义 NS 服务器是否完成了正确的注册和胶水记录配置。自建 DNS 任一环节异常，都可能导致部分或全部查询失败。

解析正常但网站仍打不开怎么办

当查询已经稳定返回正确 IP，问题就不再是纯粹的域名解析异常。接下来应检查：

• 服务器公网 IP 是否发生变化，A 或 AAAA 记录是否仍指向旧地址；
• Web 服务是否运行，80 和 443 端口是否监听并允许访问；
• 云服务器安全组、防火墙、WAF 或 CDN 是否拦截了请求；
• 虚拟主机配置是否包含该域名，HTTPS 证书是否覆盖根域名和 www；
• 应用、数据库或反向代理是否发生故障。

如果浏览器提示的是连接超时、连接被拒绝、502、503 或证书错误，而 DNS 查询能返回正确地址，应转向服务器和 HTTPS 配置排查，不要继续重复添加解析记录。

域名解析异常的快速恢复顺序

1. 确认域名未过期、未暂停，记录实际使用的 NS 服务器。
2. 在正确的 DNS 服务商后台核对根域名、www 及其他业务子域名。
3. 检查 A、AAAA、CNAME 是否指向当前有效目标，删除明确错误的旧记录。
4. 使用多个网络和查询工具，对比解析结果是否一致。
5. 清理本地和路由器缓存，等待 TTL 和委派缓存自然更新。
6. 若出现 SERVFAIL，重点检查 DNSSEC、权威 DNS 可用性和区域配置。
7. 若已解析到正确 IP，再检查服务器、端口、CDN、证书和网站程序。

按照这条路径处理，通常可以快速判断故障究竟发生在域名注册状态、DNS 委派、解析记录、缓存，还是网站服务器本身，从而避免在错误环节反复修改。