IP 检测台

开了代理仍有 DNS 泄露？按这四步排查

首页的谷歌一栏已经显示代理出口，DNS 检测却列出了你没打算使用的解析服务器。先别急着换节点：网页连接和域名解析可能走了不同的路。下面以 Mihomo 为例，先辨认结果，再检查浏览器、TUN 和上游 DNS，每次只改一个地方。

更新于

第一步：确认检测到了什么

先打开分流检测，记录国内、海外和谷歌三栏的出口及失败提示，再打开 DNS 泄露检测。两页测量的对象不同：前者观察网页请求的出口，后者让浏览器访问随机测试域名，观察最后来询问测试域名权威服务器的解析服务器。DNS 列表里的 IP 不要求等于节点 IP。

例如，网页出口是 203.0.113.10，解析服务器是 198.51.100.53，两个地址不同本身不能证明泄露。这里使用的是文档示例地址，不是真实检测结果。中间如果还有转发服务器，测试也不能仅凭最终的解析服务器还原整条链路。

先写清自己的预期：你是只要求需要代理的网站由指定上游解析，还是希望这个浏览器的所有查询都交给同一条受控路径？国内域名有意交给本地解析，与本应经过代理的域名意外交给本地解析，是两种情况。判断泄露要和这个预期对照。

DNS 检测结果应怎样继续确认
看到的结果目前能说明什么下一步
出现意外的运营商解析服务器测试域名的解析链路需要核查对照浏览器、客户端和上游配置
只有境外解析服务器本次观察到了这些服务器继续确认连接上游时是否按预期走代理
归属未知或地理位置缺失无法据此确认归属保留 IP 和时间，不当成安全结果
空列表、超时或请求失败没有得到有效检测结果先排除测试请求或网络失败

解析服务器的地区也不是传输路径证明。即使最终服务器在境外，设备仍可能直连这台服务器；反过来，地区标签不能单独证明整条链路由谁处理。需要把检测结果和客户端日志放在一起看。

第二步：检查浏览器的加密 DNS

如果同一台电脑上两个浏览器的结果不同，先记录各自的加密 DNS 设置。DNS over HTTPS，简称 DoH，是通过 HTTPS 传输 DNS 查询；它保护这一段传输，但接收查询的解析服务仍然需要处理域名。开启加密不等于请求已经经过你的代理节点。

以 Firefox 为例，进入设置中的“隐私与安全”，找到“基于 HTTPS 的 DNS”相关选项，记录所选服务、保护级别与当前状态。具体中文名称可能随版本变化。默认保护在某些条件下会退回系统解析，因此只看到开关开启，还不能确认这一次实际用了哪条路径。

做一次对照：保持同一网络、节点、规则和 TUN 状态，把浏览器 DNS 临时改为使用系统解析，再重新检测；随后恢复原设置复测。如果列表随之变化，这说明浏览器设置参与了结果，接下来应确认它与客户端 DNS 策略是否一致，而不是直接认定其中一组结果正确。

这一步用于定位，不是要求永久关闭加密 DNS。若你的目标是让客户端统一管理解析，就检查浏览器有没有另选上游；若保留浏览器 DoH，就核查连接该上游的流量是否也按预期处理。其他浏览器同样先记录自己的安全 DNS 设置，不必照搬 Firefox 的菜单。

第三步：确认 DNS 进入了客户端

再看客户端究竟接管了什么。系统代理是应用选择代理的一种方式；应用可以有自己的代理设置或绕过项。以 Chromium 的 SOCKS5 代理为例，交给代理的目标连接使用代理侧解析，但这不能推导出设备上所有程序的 DNS 都被接管。

需要 TUN 时，先确认客户端实际启用成功，再查运行配置里的 DNS 接管项。以下仅展示 Mihomo 中需要对照的字段，是合并到现有配置的片段，不是一份可直接替换订阅的完整配置：

tun:
  enable: true
  auto-route: true
  dns-hijack:
    - any:53          # 匹配 UDP 53 端口 DNS
    - tcp://any:53    # 匹配 TCP 53 端口 DNS

dns-hijack 把匹配连接交给内置 DNS 模块；它不意味着所有加密 DNS 都被拦截。Mihomo 文档还列出了发往局域网的 DNS、Android 私人 DNS 等限制。系统、内核版本及客户端生成的配置都可能影响行为，应检查最终运行配置，不能只看图形界面的开关。

在 Windows 上，如果同时使用多块网卡，可进一步核对 strict-route。Mihomo 文档说明它在启用 auto-route 时通过防火墙规则处理一类多网卡 DNS 泄露问题，也提示可能影响部分应用。先保存配置再做对照，不把它当成每台设备都必须打开的通用修复。

第四步：检查客户端上游和分流

当查询已进入 Mihomo，还要核对“交给谁解析”和“连接上游走哪里”。在当前生效配置中检查 nameserver、nameserver-policy 与 proxy-server-nameserver：它们分别涉及默认上游、按域名指定上游和代理节点域名解析，作用不同。不要把用于节点自身解析的设置，误当成全部网站的解析策略。

若使用 respect-rules 让 DNS 连接遵守路由规则，官方要求同时配置 proxy-server-nameserver。修改前先弄清启动代理所依赖的解析路径，避免形成“要先连上代理才能解析代理地址”的循环。本文不提供一组万能上游地址，沿用你已核实可用且符合预期的服务。

再检查规则列表。需要目标 IP 的规则可能触发域名解析；相关规则上的 no-resolve 用于避免由该条规则发起解析，不会撤回之前已经发生的查询，也不会禁止其他解析来源。规则顺序和字段示例见GEOSITE 和 GEOIP 有什么不同。

不要只为让测试列表变成某个国家，就给全部域名套同一份 DNS 设置。先定位是哪类域名、哪一个上游或哪条规则不符合预期，再改对应项；否则即使测试显示变了，也难以知道是否影响了国内网站、局域网名称或节点连接。

改完后怎样复测

  1. 记录修改前的网络、节点、浏览器 DNS、TUN 状态和检测时间。只改一个变量，重新加载配置后确认它确实生效。
  2. 重新运行 DNS 检测，记录解析服务器列表及失败提示；再从客户端日志核对对应时间的查询与上游连接。没有日志证据的环节，保留为未确认。
  3. 回到首页复测三条线路，确认国内访问、海外访问及谷歌访问符合原定分流目标；随后检查原本需要使用的网站能否正常打开。
  4. 浏览器结果稳定后，再单独检查其他应用。这个浏览器的一次结果不能代表整台设备；WebRTC 仍需到 WebRTC 检测另外确认。

如果列表显示 ECS，也应单独看待。EDNS Client Subnet 可以携带发起查询网络的地址前缀；它与解析服务器 IP 是不同信息。出现前缀值得核对，没显示前缀也不能证明整条 DNS 链路没有暴露其他信息。

最后保留一份能恢复的原配置。若改动后域名无法解析、国内访问异常或节点连接失败，先恢复本轮改动，再带着前后记录继续排查。目标是确认解析符合你的策略，并且正常访问没有被破坏，而不只是让某次检测出现一条理想提示。

相关文章