DNS 污染怎么判断与修复：nslookup 对比、DoH 与客户端 DNS 设置

有一类「连不上」换多少个节点都没用：网站打开是空白页或证书错误，客户端日志里反复出现解析失败，甚至节点入口域名本身也连不上。这时问题不在节点，而在域名解析这一步就走错了方向。DNS 污染指的就是域名被解析到了错误的 IP。本文先教你用三种解析器对比来确认它，再从客户端 DNS 模式和系统设置两个层面修复。

DNS 污染的表现与判断逻辑

DNS 查询默认是明文 UDP，中间设备可以在真正的应答到达之前，抢先塞回一个错误的 IP。被污染的域名通常有以下表现：

表现	原因	与其他故障的区别	处理
网站打不开，换节点无效	解析到错误 IP，流量根本没发往正确的服务器	节点故障换节点会好，污染不会	客户端接管 DNS
证书错误、域名不匹配	错误 IP 上的服务返回了其他证书	时间问题会影响所有站点，污染只影响部分	对比解析结果
节点入口域名无法连接	入口域名被污染	入口 IP 直连可以通	用 DoH 解析入口
流媒体提示代理或地区错误	DNS 解析地区与代理出口地区不一致	换同地区节点仍提示	解析交给代理侧
只在某个网络下出问题	该网络的运营商 DNS 被干预	换手机热点恢复	换上游 DNS

判断的核心逻辑只有一条：同一个域名，不同解析路径给出的答案应该一致。本地运营商 DNS、公共 DNS、通过代理的加密查询，三者结果不同且本地给出的 IP 无法正常建立 TLS 连接，就可以确认污染。DNS 的基础概念可以先读机场用户需要了解的 DNS 基础。

用 nslookup 做三路对比

Windows PowerShell：

# 1. 本地默认 DNS
nslookup 目标域名

# 2. 指定公共 DNS 明文查询
nslookup 目标域名 1.1.1.1

# 3. 通过 DoH 查询（curl 直接请求 DoH 接口）
curl.exe -s -H "accept: application/dns-json" "https://1.1.1.1/dns-query?name=目标域名&type=A"

macOS / Linux：

nslookup 目标域名
nslookup 目标域名 1.1.1.1
curl -s -H "accept: application/dns-json" "https://1.1.1.1/dns-query?name=目标域名&type=A"

读结果时注意三点：

1. 第 1 步和第 2 步结果不同，第 2 步与第 3 步相同：本地 DNS 被干预。
2. 第 1、2 步相同但与第 3 步不同：明文查询在途中被改写，即使换公共 DNS 也没用，只有加密查询可信。
3. 三者都相同但仍然打不开：不是 DNS 问题，转向握手超时与 TLS 错误的排查。

拿到可疑 IP 后，还可以用 curl 的 --resolve 参数把域名强制指向这个 IP 再访问一次，验证它能否完成 TLS 握手。握手失败或证书域名不对，污染就坐实了。

修复第一层：让客户端接管解析

根本解法是不让系统的明文 DNS 参与代理流量的解析。Clash / Mihomo 系列客户端提供两种模式：

模式	工作方式	优点	适合场景
fake-ip	客户端对域名返回一个假 IP，真实解析在代理侧完成	本地完全不做真实解析，污染无从发生；连接建立快	绝大多数日常使用
redir-host	客户端用配置的上游 DNS 真实解析，再按规则分流	应用能拿到真实 IP，兼容某些需要真实 IP 的软件	游戏、局域网服务、特定客户端

fake-ip 下，走代理的域名由节点那一端解析，本地根本不查询，污染自然失效；需要直连的国内域名则通过 fake-ip-filter 和 nameserver 正常解析。redir-host 则依赖你配置的上游 DNS 本身不被污染，因此必须配 DoH。一份可以直接放进覆写配置的示例：

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "+.msftconnecttest.com"
  default-nameserver:        # 只用于解析下面 DoH 域名本身
    - 223.5.5.5
    - 119.29.29.29
  nameserver:                # 国内域名走这里
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:                  # 境外域名走加密查询
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

两种模式的更多细节、与 TUN 的配合以及常见坑，见 Clash / Mihomo DNS 设置详解。v2rayN、sing-box、Shadowrocket 的 DNS 设置位置不同，但思路一致：境外域名用 DoH 或交给代理侧解析，不要用系统默认 DNS。

修复第二层：关闭会绕过客户端的系统设置

客户端配置正确，仍然被污染，多半是某个设置绕过了客户端：

• Android 私人 DNS：「设置 → 网络 → 私人 DNS」如果填了某个域名，系统会直接用它查询，不经过客户端。改为「自动」或关闭。
• Windows / 浏览器的安全 DNS：Chrome、Edge 的「使用安全 DNS」会让浏览器自己做 DoH，绕过客户端的 fake-ip。开启 TUN 模式后一般不冲突，系统代理模式下建议关闭。
• macOS 的 DNS 描述文件：安装过加密 DNS 描述文件的设备，系统解析会优先走描述文件，需要移除。
• 路由器的 DNS 劫持：部分路由器会把所有 53 端口查询重定向到自身，客户端的 DNS 劫持与之冲突。开启 TUN 并启用客户端的 DNS 劫持可以绕开。

改完之后重新做一次三路对比，第 1 步的结果应该与第 3 步一致（fake-ip 模式下第 1 步会返回 198.18.x.x 的假 IP，这是正常的）。

逐步排查清单

1. 换手机热点测试，恢复即可确认是当前网络的 DNS 问题。
2. 用 nslookup 三路对比，确认污染并记下被污染的 IP。
3. 客户端启用 DNS 接管，fake-ip 模式，nameserver 与 fallback 使用 DoH。
4. 关闭系统私人 DNS、浏览器安全 DNS，移除 DNS 描述文件。
5. 重启客户端，清空浏览器 DNS 缓存，重新对比。
6. 仍然异常，检查是否存在 DNS 泄漏，方法见 DNS 泄漏的检测与修复。

预防建议

• 客户端 DNS 配置做成覆写规则保存，换订阅时自动套用，不要每次手改。
• 订阅节点优先使用 IP 入口或多个入口域名，入口域名被污染时还有退路。
• 选择机场时留意它是否提供多个入口域名和 IP 直连入口，这是稳定机场推荐里关于「入口冗余」的重要一项。
• 定期做一次三路对比，尤其是换了网络环境之后。

小结

DNS 污染的本质是域名被解析到错误的 IP，判断靠三路对比，修复靠客户端接管解析并使用 DoH，再关闭所有会绕过客户端的系统设置。做完这两层，换节点无效的那类「连不上」通常就消失了。更多 DNS 相关问题见 DNS 异常栏目。