域名解析异常，通常是域名没有被正确转换为服务器 IP，或不同解析环节返回了错误结果。解决时不要一开始就盲目修改 DNS，建议先确认故障范围，再依次检查域名状态、DNS 服务器委派、解析记录、DNSSEC 与缓存时间。只有权威 DNS 已返回正确记录，并且递归 DNS 缓存完成更新，域名才算真正恢复。

域名解析异常到底表现在哪里？

常见表现包括：浏览器提示“找不到服务器 IP 地址”、返回 NXDOMAIN、SERVFAIL 或 DNS_PROBE_FINISHED_NXDOMAIN；有的用户可以打开网站，另一些地区却无法访问；域名能解析到 IP，但打开的是旧服务器、错误站点或 CDN 默认页面。不同表现对应的故障位置并不相同。

因此，“域名解析异常”并不等于“本地 DNS 设置错了”。如果多个网络中的查询结果都不正确，单纯把电脑 DNS 改成其他公共 DNS，通常不能修复权威记录；更换递归 DNS 只能帮助判断某个解析服务是否存在缓存或查询故障。

确认了异常后，应该按什么顺序排查？

第一步：确认故障范围和实际报错

先分别用手机流量、家庭宽带和其他网络访问域名，记录是否所有环境都失败。再尝试访问同一域名的根域名、www 子域名和其他业务子域名。若只有一台设备异常，优先处理本地缓存；若所有网络都异常，就应直接检查域名注册与权威 DNS 配置。

同时记录浏览器报错文字。NXDOMAIN 通常表示查询结果明确说明域名或记录不存在；SERVFAIL 更常见于权威 DNS 无法正常响应、DNSSEC 校验失败或委派链路存在问题；超时则可能与 DNS 服务器不可达、网络策略或权威服务器故障有关。

第二步：检查域名是否正常注册和到期

登录域名注册商后台，确认域名没有到期、暂停、锁定或被设置为禁止解析的状态。部分域名在到期后会被注册商替换为停放页或直接停止原有 DNS 服务。还要确认当前使用的域名服务器名称，也就是 NS 记录，是否与实际管理解析记录的平台一致。

例如，解析记录是在云 DNS 平台维护，但注册商处的 NS 仍指向旧服务商，那么你在新平台中修改 A 记录不会生效。相反，如果刚把 NS 切换到新平台，却仍在旧平台改记录，也会造成“后台看起来正确、外部查询仍然错误”的情况。

第三步：检查 NS 委派和权威 DNS 是否一致

查询域名的 NS 记录，确认注册商公布的 NS 与权威 DNS 返回的结果没有明显冲突。随后分别查询权威 DNS 上的 A、AAAA、CNAME、MX 等记录。可以在 Windows 使用 nslookup 域名，在 macOS 或 Linux 使用 dig 域名 A、dig 域名 NS 进行初步检查。

如果普通查询失败，可以进一步指定某个权威 DNS 查询。若直接查询权威服务器已经返回正确 IP，而普通 DNS 仍返回旧结果，问题多半处于递归缓存和 TTL 阶段；如果权威服务器本身就返回错误结果，则应回到解析平台检查记录内容、记录类型和生效区域。

第四步：核对记录类型、主机记录和目标值

确认根域名使用的是正确的 A 或 AAAA 记录，www 是否需要使用 CNAME，子域名是否拼写正确。主机记录通常应填写主机部分，而不是重复填写完整域名，具体格式要以解析平台的输入说明为准。还要检查是否存在多条相互冲突的记录，例如同一主机名同时存在不应共存的 CNAME 与其他记录。

如果服务器只支持 IPv4，却配置了错误的 AAAA 记录，支持 IPv6 的网络可能优先访问这个错误地址，表现为部分用户无法打开。若使用 CDN 或反向代理，也要确认解析目标确实是平台要求的地址，而不是源站地址与 CDN 地址混用。

第五步：检查 DNSSEC、缓存与区域同步

启用 DNSSEC 后，如果 DS 记录与 DNSKEY 不匹配、密钥已更换但父级委派未同步，部分递归 DNS 会判定响应不可信并返回 SERVFAIL。若近期更换过 DNS 服务商、开启或关闭过 DNSSEC，应把这项变更列为重点检查对象。不了解 DNSSEC 配置时，不要重复开关，先核对注册商和 DNS 服务商两端的状态是否一致。

如果记录刚刚修改，查询结果不同并不一定意味着配置失败。递归 DNS、浏览器、操作系统和路由器都可能保留缓存，缓存时间通常受记录 TTL 影响，但不同节点的刷新时间不会完全相同。此时应保留正确记录，避免频繁反复修改导致缓存更新时间被重新拉长或问题更难判断。

为什么改完解析记录，网站仍然没有恢复？

最常见的原因是改动位置不对。修改的是非权威 DNS 平台，或者域名实际仍委派给旧 NS，外部查询自然不会变化。第二种情况是缓存尚未过期，尤其是此前设置了较长 TTL 时，部分用户仍可能获得旧 IP。

如果权威查询已经返回新 IP，但浏览器仍打不开，应暂时把问题从 DNS 分开处理：检查服务器是否监听 80 或 443 端口，安全组和防火墙是否放行，Web 服务是否启动，HTTPS 证书是否匹配域名，以及 CDN、负载均衡或源站是否正常。解析成功只表示“找到了目标地址”，并不保证目标服务一定能建立连接。

还要注意 CNAME、重定向和应用配置造成的假象。例如 www 已经解析到新服务器，但新服务器的虚拟主机没有配置该域名，访问时可能显示默认站点；又或者根域名与 www 指向不同服务，导致一个正常、另一个异常。这些属于解析后的服务配置问题，不能通过继续更换 DNS 解决。

怎样判断域名解析已经真正恢复？

满足以下条件后，通常可以认为解析故障已经恢复：第一，域名注册状态正常，当前 NS 指向正确的权威 DNS；第二，从至少两个不同网络或递归 DNS 查询，A、AAAA、CNAME 等结果与预期一致；第三，权威 DNS 和普通 DNS 的结果逐步统一，不再出现随机错误或持续返回旧地址；第四，使用解析到的目标 IP 访问时，服务器、CDN 或负载均衡能够正常响应。

如果只是本机仍显示旧结果，可以重启网络连接、清理操作系统和浏览器的 DNS 缓存，或暂时更换网络进行验证。但不要把“本机刷新后能打开”当作全网恢复的唯一标准。应同时从外部网络查询，确认其他地区的递归 DNS 也已完成更新。

哪些处理方式容易让问题变得更难判断？

• 反复修改多条记录：一次只调整一个明确的配置项，并记录修改时间、原值和新值，便于结合 TTL 判断结果。
• 只更换电脑 DNS：这可能绕开某个递归 DNS 的缓存，却无法修复域名到期、NS 委派错误或权威记录错误。
• 只看 DNS 平台后台：后台显示“已生效”不代表该平台就是当前域名使用的权威 DNS，必须用外部查询验证。
• 把访问失败都归因于解析：如果已经得到正确 IP，应继续检查端口、证书、服务器和 CDN，而不是继续改解析。
• 忽略 AAAA 或 DNSSEC：部分网络异常往往与错误 IPv6 记录或 DNSSEC 校验失败有关，不能只检查 A 记录。

总的来说，域名解析异常的排查顺序应是：先确认故障范围，再查域名状态和 NS 委派，接着核对权威记录，随后检查 DNSSEC 与缓存，最后区分网站服务本身的问题。只有找到实际返回错误的位置，才能决定是修复记录、恢复委派、等待缓存更新，还是转向服务器和网络服务排查。