DNS lookup failed：域名解析失败的原因和解决顺序

DNS-001DNS lookup failed严重程度 High

一句话结论

域名没有得到任何可用的解析结果，连接在第一步就停住了。最可能是当前 DNS 服务器不可达或该域名在当前网络被拦截；第一步是换一个网络对同一域名重新解析并对比结果。

适用环境WindowsmacOSLinuxAndroidiOS

适用客户端通用客户端

最后验证：2026-07-28规则版本：v1内容更新：2026-07-28

结论

DNS 是每次连接的第一步：把域名换成 IP。这一步失败，后面的 TCP、TLS 根本没有机会开始，所以 DNS 故障的表现往往是"什么都连不上"而不是"连得慢"。诊断的好消息是：DNS 层的证据最容易收集，用一条命令就能看到解析在哪个环节、以什么方式失败。

适用环境

• 全部桌面与移动平台
• 浏览器、代理客户端、命令行工具等一切依赖域名的场景

一分钟快速判断

1. 换域名：解析一个你确定存在的常用域名。同样失败 → DNS 服务器或网络问题；只有目标域名失败 → 域名本身或针对性拦截；
2. 换网络：手机热点下解析目标域名。成功 → 原网络的 DNS 有问题或有拦截；仍失败 → 域名本身可能真的有问题（过期、配置错误）；
3. 查拼写：connproof dns 报 NXDOMAIN（域名不存在）时，第一嫌疑永远是拼写——多一个字母、少一个点、.com 打成 .con 都会得到这个结果。

这条错误代表什么

一次"解析失败"背后有几种不同的底层事件，ConnProof 会把它们区分开：

• NXDOMAIN / ENOTFOUND：DNS 系统明确回答"这个域名不存在"。指向拼写错误、域名过期或子域未配置——另见 getaddrinfo ENOTFOUND；
• 超时：查询发出去没有任何回应。指向 DNS 服务器不可达或查询被丢弃；
• SERVFAIL 等服务器错误：DNS 服务器自己出了问题；
• 权威解析失败但系统 lookup 成功：hosts 文件或本地缓存在"兜底"，真实解析其实是坏的——这种不一致值得警惕，可能是残留的手工 hosts 条目在掩盖问题。

ConnProof 如何判断

connproof dns 目标域名

一次运行同时执行三种查询并对比：

• A 记录（IPv4）与 AAAA 记录（IPv6）：直接问 DNS 服务器；
• 系统级 lookup：走操作系统完整解析路径（包含 hosts 文件与缓存）。

三者的一致性就是证据：全部超时 → 服务器不可达；A/AAAA 失败而 lookup 成功 → 本地 hosts/缓存介入；只有 AAAA 有结果 → IPv6-only 域名，连接问题可能出在 IPv6 可达性。

最常见原因

1. 当前网络的 DNS 服务器故障或不可达：路由器 DHCP 下发的 DNS 挂了，整个局域网一起遭殃；
2. 针对性拦截或污染：特定域名在当前网络被丢弃查询或返回错误结果，换网络立即恢复；
3. 域名本身的问题：过期、注册商暂停、子域没有配置记录；
4. 本地配置残留：手工改过的 DNS 服务器地址已失效，或 hosts 文件里有过期条目；
5. DNS 缓存陈旧：域名刚迁移过，本地还缓存着旧的失败结果。

Windows 排查步骤

1. connproof dns <域名> 拿到失败类型（NXDOMAIN / 超时 / 服务器错误）；
2. 超时类：connproof doctor 看 DNS 服务器配置；管理员命令行执行 ipconfig /flushdns 清缓存后复测；
3. 检查 C:\Windows\System32\drivers\etc\hosts 是否有目标域名的手工条目；
4. 临时把网卡 DNS 改为公共 DNS（如运营商备用或其他可信服务器）复测——恢复则原 DNS 服务器故障；
5. 记得把测试性修改改回去，避免留下新的配置残留。

macOS 排查步骤

1. 同样先 connproof dns 分类失败；
2. 清缓存：sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder；
3. 检查 /etc/hosts；
4. 系统设置 → 网络 → 详细信息 → DNS 中查看和临时更换 DNS 服务器复测。

手机端排查步骤

• 开关飞行模式（等效于清一次网络状态）后重试；
• Android 检查"私人 DNS"设置：填了失效的 DoT 服务器会让所有解析失败，改回"自动"复测；
• iOS 在 Wi-Fi 详情里检查是否配置过手动 DNS；
• 蜂窝与 Wi-Fi 对比，定位问题网络。

代理环境下的 DNS：本地解析还是远程解析

使用代理客户端时，DNS 有两条可能的路径，排查前必须先弄清自己走的是哪条：

• 本地解析：你的设备直接向本地网络的 DNS 服务器查询，拿到 IP 后再决定是否走代理。这条路径受本地网络的污染和拦截影响——即使代理是好的，被污染的解析结果也会把连接引向错误的地址；
• 远程解析：域名原样交给代理节点，由节点在它那一侧解析。本地 DNS 完全不参与，本地污染因此失效，但节点侧的 DNS 故障会换一种方式呈现（参见 client connected but no internet）。

判断方法：在客户端关闭的状态下运行 connproof dns <域名>，测的是纯本地路径；客户端开启后浏览器却打不开同一域名，而本地检测正常，则问题大概率在远程解析或分流规则。两条路径的故障互不掩盖，混着排查只会得出自相矛盾的结论——先固定一条路径，测完再换另一条。

如何区分本地问题和节点问题

证据	更可能是
所有域名都解析失败	本地 DNS 配置或 DNS 服务器
只有特定域名失败、换网络恢复	当前网络对该域名的拦截
所有网络下都 NXDOMAIN	域名本身（过期/配置/拼写）
权威失败而 lookup 成功	本地 hosts/缓存残留

仍未解决时收集什么信息

• ConnProof 错误码（DNS-001）与脱敏报告；
• 失败类型（NXDOMAIN / 超时 / 服务器错误）；
• 两个网络下的对比结果；
• 操作系统版本与问题开始时间。

禁止提交：完整订阅链接、密码、验证码、私钥、Token。

重新运行检测

connproof dns 目标域名 --format markdown --output dns-report.md

修复后 A 或 AAAA 至少一项应返回地址，系统 lookup 与权威解析结果一致。

相关文档

相关文档

• getaddrinfo ENOTFOUND：找不到目标主机
• IPv6 resolved but unreachable：IPv6 解析成功但不可达
• subscription update failed：订阅更新失败
• 网络基础：DNS 解析全流程

更新记录

• 2026-07-28：规则 v1 发布，确立三查询一致性对比方法。