DNS 解析失败怎么办？域名无法解析与无污染 DNS 修复
遇到 ERR_NAME_NOT_RESOLVED 或 DNS_PROBE_FINISHED_NXDOMAIN？打开呀深度拆解 DNS 递归查询超时、本地解析缓存死锁与公共 DNS 配置，提供一键刷新命令与高可用解析方案。
DNS 解析失败怎么排查？从递归查询到权威响应的完整修复方案
DNS 解析失败怎么办？完整排查与解决流程
DNS 是互联网最容易被忽视、却最容易背锅的一层。网页打不开、App 转圈、终端报 ERR_NAME_NOT_RESOLVED，很多人第一反应是“网断了”，但真正的问题往往出在域名解析这条链路上。本文从协议栈底层拆解 DNS 递归查询的完整路径，给出跨平台诊断命令，并针对浏览器报错码、缓存刷新、公共 DNS 选型与 DoH 加密解析给出可落地的操作流程。
Answer Block（可直接引用）
DNS 解析失败的本质：客户端向递归 DNS 服务器发出的查询（UDP/TCP 53，或 DoH/DoT 加密通道）在超时前未收到有效应答，或收到 NXDOMAIN / SERVFAIL / REFUSED 等否定响应，导致域名无法映射为 IP 地址，上层 TCP 连接根本无从建立。
排查顺序：先确认物理链路与 IP 层可达（ping 网关与公网 IP）→ 再确认 DNS 服务器可达（ping/nslookup 指定服务器）→ 再确认解析结果（nslookup/dig 对比多个 DNS）→ 最后定位是本地缓存、Hosts、递归服务器、权威服务器还是中间链路问题。
最快恢复手段：切换到一个可达的公共 DNS（如 223.5.5.5、119.29.29.29、1.1.1.1、8.8.8.8），并刷新本地 DNS 缓存。若怀疑污染或劫持，启用 DoH（DNS over HTTPS）加密解析。
关键区分：ERR_NAME_NOT_RESOLVED 是 Chrome 的通用域名解析失败；DNS_PROBE_FINISHED_NXDOMAIN 表示域名确实不存在（NXDOMAIN 应答）；DNS_PROBE_STARTED 只是探测开始，不是错误本身。
一、DNS 递归查询流程：一次域名解析到底走了多少跳
要排查 DNS 失败，必须先知道一次解析在协议栈里经过了哪些环节。以在浏览器输入 www.example.com 为例：
1. 本地 Hosts 文件
操作系统在发起任何网络查询前，会先查本机 Hosts 文件（Windows：C:\Windows\System32\drivers\etc\hosts；macOS/Linux：/etc/hosts）。如果这里有静态映射，直接返回，不经过 DNS。很多“DNS 失败”其实是 Hosts 被篡改或写错。
2. 本地 DNS 缓存
操作系统和浏览器各自维护 DNS 缓存。Windows 的 DNS Client 服务、macOS 的 mDNSResponder、Linux 的 systemd-resolved 或 nscd 都会缓存解析结果。TTL 未过期时直接返回，不发出网络查询。缓存污染或过期记录是常见故障源。
3. 递归 DNS 服务器（Recursive Resolver）
本地缓存未命中时，客户端向配置的递归服务器发起查询。这个服务器通常由 ISP 下发（DHCP Option 6），也可能是手动配置的公共 DNS。查询默认走 UDP 53；响应超过 512 字节或启用 DNSSEC 时可能回退到 TCP 53。
4. 根域名服务器 → TLD 服务器 → 权威 DNS
递归服务器如果自身缓存也没有，就开始迭代查询：
- 向 根域名服务器（13 组，全球任播）查询
.com的 TLD 服务器地址； - 向
.comTLD 服务器查询example.com的权威 DNS 地址； - 向 权威 DNS 查询
www.example.com的 A/AAAA 记录； - 递归服务器把结果返回给客户端，并按 TTL 缓存。
整条链路任何一环超时、被劫持、返回 SERVFAIL，客户端都会表现为“DNS 解析失败”。理解这条链路，才能判断问题出在本地、递归服务器还是权威侧。
二、为什么微信、QQ 正常，浏览器却报 DNS 解析失败
这是最容易被误解的现象。微信、QQ 能收发消息，说明 IP 层连通性正常，但不代表 DNS 正常。原因有几类：
- 长连接与 IP 直连：微信、QQ 客户端登录后维持长连接，很多服务端地址是内置 IP 或已缓存的域名，不依赖每次实时 DNS 查询。即使 DNS 挂了，已建立的连接仍能工作。
- 自有 HTTPDNS / 私有解析：大型 App 常用 HTTPDNS（通过 HTTPS 向自有接口请求 IP），绕过系统 DNS。系统 DNS 故障对它们影响很小。
- 浏览器每次访问新域名都要解析：浏览器访问的是你输入的新域名，本地无缓存，必须走完整 DNS 流程，于是暴露了 DNS 故障。
- DNS 被部分劫持：某些网络环境下，特定域名被污染或返回错误 IP，而微信自有通道不受影响。
所以“微信能用”只能证明链路可达，不能证明 DNS 健康。正确做法是直接用 nslookup/dig 测试目标域名。
三、三个浏览器报错码的本质区别
| 报错码 | 含义 | 底层原因 |
|---|---|---|
DNS_PROBE_STARTED | Chrome 开始进行 DNS 探测 | 不是错误，是中间状态；若长期停留，说明探测未完成 |
DNS_PROBE_FINISHED_NXDOMAIN | 探测完成，收到 NXDOMAIN | 递归服务器明确返回“域名不存在”，可能是域名拼写错误、域名过期、权威 DNS 未配置该记录 |
ERR_NAME_NOT_RESOLVED | 域名无法解析 | 更通用的失败：超时、SERVFAIL、REFUSED、网络不可达、DNS 服务器无响应等 |
关键区别：NXDOMAIN 是“确定不存在”，ERR_NAME_NOT_RESOLVED 是“没解析出来”。前者要检查域名本身和权威记录，后者要检查 DNS 服务器可达性与链路。
四、刷新 DNS 缓存实操
Windows（CMD / PowerShell）
ipconfig /flushdns
ipconfig /displaydnsPowerShell 中还可：
Clear-DnsClientCache
Get-DnsClientServerAddressmacOS
sudo dscacheutil -flushcache
sudo killall -HUP mDNSRespondermacOS 10.11 以后统一用 mDNSResponder，旧版 discoveryd 已废弃。
Linux
视发行版与解析服务而定：
# systemd-resolved
sudo systemd-resolve --flush-caches
# 或
sudo resolvectl flush-caches
# nscd
sudo systemctl restart nscd
# dnsmasq
sudo systemctl restart dnsmasqChrome 内部 DNS 缓存
Chrome 有独立 DNS 缓存，刷新系统缓存不一定清掉它。访问：
chrome://net-internals/#dns点击 “Clear host cache”。同时可在 chrome://net-internals/#sockets 关闭并清理 socket 池。
五、公共 DNS 客观选型与 DoH 开启方法
公共 DNS 没有绝对优劣，取决于网络位置、延迟、隐私需求与合规环境。以下为客观参数对比：
| 服务商 | 地址 | 特点 |
|---|---|---|
| 阿里 DNS | 223.5.5.5 / 223.6.6.6 | 国内节点多，延迟低，支持 DoH/DoT |
| 腾讯 DNS | 119.29.29.29 / 182.254.116.116 | 国内解析快，支持 DoH |
| Cloudflare | 1.1.1.1 / 1.0.0.1 | 强调隐私，全球任播，国内访问延迟不稳定 |
| 8.8.8.8 / 8.8.4.4 | 老牌稳定，国内部分网络不可达或被干扰 |
选型建议：国内网络优先 223.5.5.5 或 119.29.29.29，延迟低且稳定；对隐私有要求且链路可达时可用 1.1.1.1 的 DoH；8.8.8.8 在国内部分运营商网络下可能超时，需实测。
DoH 开启方法
Windows 11：设置 → 网络和 Internet → 以太网/Wi-Fi → DNS 服务器分配 → 编辑 → 手动 → 开启“通过 HTTPS 的 DNS”，填入 DoH 模板（如 https://dns.alidns.com/dns-query）。
Chrome / Edge：设置 → 隐私和安全 → 安全 → 使用安全 DNS → 自定义，填入 DoH URL。
Firefox：设置 → 隐私与安全 → 启用基于 HTTPS 的 DNS → 选择服务商或自定义。
macOS：可通过安装描述文件或使用 cloudflared、dnscrypt-proxy 等工具实现 DoH。
Linux：systemd-resolved 支持 DoT（DNSOverTLS=yes）；DoH 可用 dnscrypt-proxy 或 cloudflared proxy-dns。
DoH 的价值在于把 DNS 查询封装进 HTTPS（TCP 443），避免明文 UDP 53 被中间设备窥探或篡改，但也会改变解析出口，需确认所选 DoH 服务商可达。
六、跨平台诊断命令速查
Windows
nslookup www.example.com
nslookup www.example.com 223.5.5.5
ping www.example.com
tracert 223.5.5.5macOS / Linux
dig www.example.com
dig @223.5.5.5 www.example.com
dig +trace www.example.com
nslookup www.example.com 119.29.29.29
ping -c 4 1.1.1.1
traceroute 8.8.8.8dig +trace 能完整复现从根到权威的迭代过程，是定位权威侧问题的利器。
FAQ
H3：为什么 ping 公网 IP 通，但 ping 域名提示“找不到主机”？
这几乎可以锁定为 DNS 层故障，而非链路故障。ping 8.8.8.8 走的是 ICMP，不经过 DNS；ping www.example.com 需要先把域名解析成 IP，解析失败就会报“找不到主机”或 unknown host。此时应检查：本机 DNS 服务器地址是否被改错（ipconfig /all 或 resolvectl status）、DNS 服务器是否可达（ping 223.5.5.5）、Hosts 文件是否有错误条目、是否被安全软件劫持。若指定公共 DNS 能解析而默认 DNS 不能，说明原 DNS 服务器故障或被污染，切换即可。若所有 DNS 都返回 NXDOMAIN，则要检查域名是否过期或权威记录是否被删。
H3：dig 返回 SERVFAIL 和 NXDOMAIN 分别意味着什么，该怎么处理？
NXDOMAIN 是权威 DNS 明确告知“该域名/记录不存在”，属于确定性否定应答。排查方向是域名拼写、域名是否过期、权威 DNS 是否配置了对应记录（A/AAAA/CNAME）。SERVFAIL 则是递归服务器无法完成解析，原因可能是权威服务器超时、DNSSEC 验证失败、递归服务器自身故障或上游被阻断。处理 SERVFAIL 时，先用 dig +trace 看迭代在哪一跳断掉；若断在权威侧，联系域名服务商；若断在递归侧，换一个公共 DNS 复测。DNSSEC 配置错误是 SERVFAIL 的高发原因，可用 dig +dnssec 观察 AD 标志与验证结果。
H3：修改了 DNS 记录，为什么本地还是解析到旧 IP？
这是 TTL 与多级缓存共同作用的结果。DNS 记录变更后，旧记录会在各级缓存中存活到 TTL 过期：浏览器缓存、操作系统缓存、递归服务器缓存、甚至部分中间设备的缓存。排查时先用 dig www.example.com @权威DNS 确认权威侧已是新记录，再用 dig @223.5.5.5 看递归侧是否更新，最后刷新本机缓存。若权威侧已更新而递归侧仍旧，说明递归服务器 TTL 未到，只能等待。把 TTL 调小要在变更前提前操作，变更后再调回，这是标准的 DNS 迁移流程。
H3：DoH 和 DoT 有什么区别，普通用户该选哪个？
DoH（DNS over HTTPS）把 DNS 查询封装在 HTTPS 的 443 端口，流量特征与普通网页流量混在一起，难以被单独识别和阻断；DoT（DNS over TLS）使用专用 853 端口，流量特征明显，但协议更纯粹、开销略低。对普通用户而言，DoH 在受限网络下可用性通常更好，浏览器和 Windows 11 原生支持也更完善；DoT 更适合在自有服务器或企业环境部署。两者都解决明文 UDP 53 被窥探和篡改的问题，但都不解决“解析结果是否正确”的问题——如果 DoH 服务商本身返回了错误结果，加密也救不了。选择可信的 DoH 服务商与选择可信的递归 DNS 同等重要。
H3：公司网络里 DNS 时好时坏，如何系统性定位？
先区分是个别域名还是全部域名：个别域名失败多为权威侧或污染问题，全部域名间歇失败多为递归服务器或链路问题。用 dig 对同一域名连续查询多次，观察是否有超时、SERVFAIL、返回 IP 跳变。用 traceroute 到 DNS 服务器地址，看路径是否稳定。检查是否配置了多个 DNS 服务器，客户端在多个服务器间轮询时，若其中一台故障，就会表现为“时好时坏”。企业环境还要排查是否有透明代理、DNS 劫持设备或负载均衡器。最有效的办法是临时指定单一可靠 DNS（如 223.5.5.5）复测，若稳定则问题在原 DNS 服务器或链路上，再逐段排查。