直接答案：DNS_PROBE_FINISHED_NXDOMAIN 表示 DNS 查询已经完成，但解析器得到“该名称不存在”的结论。先不要改服务器端口或重启网站：直接向注册局链路和域名当前权威 NS 查询，确认委派是否正确、目标主机名是否真的有 A、AAAA 或 CNAME；权威答案正常后，再检查公共递归 DNS、负缓存、本机缓存、代理和浏览器。若权威服务器本身返回 NXDOMAIN，清理本机缓存不会解决根因。
本文针对域名或某个子域突然无法解析、浏览器出现 NXDOMAIN，而直接访问 IP 或其他子域仍可能正常的场景。若已经能解析到 IP，但连接超时、证书错误或返回 5xx，应转到网络、TLS 或应用层排查，不要继续把所有问题归因于 DNS。
本文按 2026 年 9 月可查的官方文档核对。示例命令以只读取证为主；凡涉及删除、覆盖、重启、权限、网络或数据库参数的动作，都应先确认操作对象、备份、维护窗口和带外恢复入口。不同发行版与软件版本的路径可能不同，必须先查询实际配置再改。
先用证据判断故障在哪一层
| 现象或检查点 | 它能说明什么 | 直接证据 | 不要误判为 |
|---|---|---|---|
| 权威 NS 也返回 NXDOMAIN | 记录未创建、名称写错或查询了错误区域 | 向每台权威 NS 查询同一类型 | 本机缓存故障 |
| 父区委派与控制台 NS 不同 | 注册商委派尚未更新或填错 | 注册局 NS 与域名 SOA | A 记录内容错误 |
| 权威正常、部分递归仍 NXDOMAIN | 负缓存或委派传播未结束 | 多个公共递归的回答与 TTL | 源站宕机 |
| SERVFAIL 而不是 NXDOMAIN | 可能是 DNSSEC、超时或权威故障 | 返回码、DNSSEC 验证链、权威可达性 | 名称不存在 |
| 仅一台电脑或一个浏览器失败 | 本地缓存、DoH、代理或 hosts 差异 | 同网其他设备与指定解析器查询 | 全网解析失败 |
这张表的用法不是“看到一个关键词就改一个参数”，而是把客户端、DNS或边缘、Web 代理、应用、数据层依次分开。至少保留故障时间、完整 URL、状态码、关键响应头、同一时刻的服务日志和一份正常样本。只有时间能够对齐，才能判断两个现象是否属于同一次故障。
六步排查与修复顺序
1. 固定名称、类型和时间
把出错的完整主机名写下来，区分根域、www、api 等子域，并分别查 A、AAAA、CNAME 和 NS。记录首次出现时间、使用的网络和解析器；同一个域名查询不同记录类型可能得到完全不同的结果。
2. 先查父区委派
从注册商和注册局视角确认当前委派到哪些 NS，再与 DNS 服务商控制台展示的 NS 对照。刚更换 DNS 托管时，旧权威和新权威可能同时被缓存；若某台权威缺少区域或序列号不同，会形成间歇性失败。
3. 逐台询问权威服务器
对每台权威 NS 直接查询目标记录和 SOA，不经过本地递归缓存。若只有一台返回 NXDOMAIN，要修复权威集群同步；若全部返回 NXDOMAIN，检查记录名称是否把完整域名重复拼接、记录是否被暂停，以及通配符是否覆盖预期层级。
4. 区分 NXDOMAIN、NODATA 与 SERVFAIL
NXDOMAIN 是名称不存在，NODATA 是名称存在但没有所问类型，SERVFAIL 常指验证或上游失败。尤其启用、关闭或迁移 DNSSEC 后，要核对父区 DS 与新权威 DNSKEY 是否匹配；不要通过反复新增 A 记录掩盖错误的签名链。
5. 再查递归和客户端缓存
权威正确后，分别查询 1.1.1.1、8.8.8.8 和本地运营商解析器，查看旧负缓存何时到期。本机可刷新缓存或临时指定解析器做对照，但不要让用户永久依赖某一家公共 DNS 来绕过仍未修好的权威问题。
6. 以外部请求完成验收
解析收敛后，从至少两个网络访问 HTTPS，核对证书主机名、HTTP 状态、正文和源站/CDN日志。连续观察一个旧 TTL 窗口；如果只验证 dig 有 IP，没有验证真实 HTTPS，请求链仍可能在下一层失败。
可复制的只读取证命令
以下命令中的域名、服务名、路径和时间范围要替换为自己的真实值。先执行查询命令并保存原始输出；不要把“命令能运行”误当成“业务已恢复”。
text
dig NS your-domain.tld +short
dig +trace your-domain.tld NS
dig @ns1.dns-provider.tld www.your-domain.tld A +noall +answer +authority
dig @1.1.1.1 www.your-domain.tld A +noall +answer +comments
dig your-domain.tld SOA +dnssec
dig NS your-domain.tld +short：查看当前递归解析器看到的权威服务器dig +trace your-domain.tld NS：从根区逐级检查委派链；输出较长，适合保存工单dig @ns1.dns-provider.tld www.your-domain.tld A +noall +answer +authority：直接询问指定权威服务器，绕过递归缓存dig @1.1.1.1 www.your-domain.tld A +noall +answer +comments：对比公共递归的返回码、答案和 TTLdig your-domain.tld SOA +dnssec：检查 SOA 与 DNSSEC 相关响应，SERVFAIL 时尤其有用
如命令输出包含公网 IP、用户名、Cookie、令牌、数据库连接串或客户数据，分享工单前先脱敏。对比时保留时间戳、时区和命令本身，否则后来无法复现同一观察条件。
五个最容易扩大故障的误区
- 只刷新浏览器缓存：若权威 NS 返回 NXDOMAIN，本地刷新只会重复得到同一错误。
- 同时改 NS、A 记录和 CDN：多变量一起变化后无法判断是哪一层恢复，也让回滚变得不确定。
- 把 SERVFAIL 写成 NXDOMAIN：两者根因不同；前者常与 DNSSEC、权威不可达或验证失败相关。
- 忽略 AAAA 和子域：IPv6 记录、
www与根域是独立名称，不能用一个成功结果代表全部。 - 看到一个公共 DNS 正常就关闭工单：递归缓存分散，必须跨解析器、跨网络并覆盖旧 TTL 窗口。
变更、回滚与数据边界
DNS 变更前导出完整区域记录并记录当前 NS、SOA 序列号和 TTL。若新权威缺记录或 DNSSEC 链错误，优先恢复上一组已验证的委派/DS 组合，不要只把 A 记录复制到错误的权威。回滚后旧缓存仍需到期，因此新旧权威在过渡期都应提供一致答案；任何一台权威返回不同数据都不能算完成。
如果只能先恢复服务、还不能确认根因，应把措施标记为“临时缓解”，例如限流、摘除单节点、切回上一配置或临时绕过一层代理。恢复后仍要在受控环境复现原因，并验证同类故障不会在下一次重启、发布或高峰重新出现。
统一验收清单
- [ ] 父区委派与控制台 NS 一致
- [ ] 每台权威对目标记录回答一致
- [ ] 返回码已区分 NXDOMAIN、NODATA 和 SERVFAIL
- [ ] DNSSEC 链无验证错误
- [ ] 至少三个递归解析器结果收敛
- [ ] IPv4 与 IPv6 记录均按预期
- [ ] 两个外部网络的 HTTPS 请求成功
- [ ] 观察期覆盖旧 TTL 且无间歇失败
验收必须同时覆盖机器内部和真实外部路径。首页返回 200 不能证明上传、长连接、登录、数据库写入或移动端都正常；同样，控制台显示“运行中”也不能证明应用已能处理请求。至少选一个正常请求、一个边界请求和一个失败请求，记录预期与实际结果。
相关内容与隔离测试入口
建议先阅读域名解析多久生效、服务器正常但网站打不开、云服务器端口不通，把本问题放回完整请求链路。若生产环境不适合直接试验，可查看美国轻量云的当前规格与库存，搭建与生产隔离的复现环境；测试机不能替代生产备份，价格、库存和可选配置以实时产品页为准。
常见问题
直接用 IP 能打开，为什么域名还是 NXDOMAIN？
IP 访问绕过了 DNS，只证明某个网络地址上的服务可能存在。域名是否被正确委派、是否有目标记录仍需独立验证。
新加记录后多久生效？
取决于旧的正缓存或负缓存 TTL、委派缓存和递归实现。以权威答案与多个递归的实际 TTL 判断，不承诺固定分钟数。
换成 8.8.8.8 就正常，能算修好吗？
不能。这说明解析器之间结果不同，是定位证据；站点仍要让主流递归都得到正确权威答案。
根域正常但 www 报 NXDOMAIN 是什么原因？
根域和 www 是两个名称。需要为 www 单独配置 A、AAAA 或 CNAME，并检查是否在正确区域中。
NXDOMAIN 会影响搜索收录吗？
持续 NXDOMAIN 会让爬虫无法找到主机名，影响抓取与现有 URL 可用性。恢复后应先确认真实页面 200 和 sitemap，再在站长平台观察抓取，不把提交成功等同收录。