代理 DNS 泄漏怎么检查和解决

更新于 2026-11-03 · xn--gwtw23etrg7yf.shop

简答：代理 DNS 泄漏的最快判断方法是：先分别记录代理关闭和开启时的出口 IP、默认 DNS 解析结果与 IPv4/IPv6 状态，再检查浏览器 DoH、客户端日志和 TUN 是否接管查询。注意：命令中指定 <code>@dns.google</code> 或 DNS 服务器地址，只能验证该服务器是否可达，不能证明系统或代理默认使用了它。真正的判断要依靠“不指定服务器的默认查询”、客户端日志、路由或抓包对照。

定义：DNS 泄漏是指域名查询本应由代理、VPN 或指定解析路径处理，却仍被系统、浏览器、路由器或其他未预期的解析器接收。

先试这一步：30 秒判定卡与最快修复顺序

本文是第三方使用指南，不代表任何客户端或服务的官方页面。若代理已经能打开网页但你担心 DNS 泄漏，先不要立刻改系统 DNS，按下面六项记录一次基线。

1. 关闭代理，运行系统默认解析测试并记录结果。
2. 开启代理，关闭浏览器后重新打开，再运行同一组测试。
3. 只改变一个设置：先检查客户端是否启用远程解析或 TUN，再检查浏览器 DoH。
4. 清理浏览器和客户端 DNS 缓存，断开并重新连接代理。
5. 重新测试 IPv4、IPv6 和 Wi-Fi/移动网络。

如果只看到 Cloudflare、Google 或其他公共 DNS，不能单独判定泄漏。解析器可能是客户端、浏览器、企业网络或路由器主动配置的，也可能受到 Anycast、转发和网络策略影响。只有当结果与预期路径不一致，并由日志、路由或抓包相互印证时，才应按泄漏处理。

先分清代理协议：你的 DNS 到底由谁解析

以 curl 的官方文档为例，socks5:// 与 socks5h:// 是不同的代理前缀，后者用于要求 SOCKS 代理解析主机名；这说明“使用 SOCKS5”本身不足以证明 DNS 已远程解析。参考 curl 官方代理参数说明。

如果客户端只启用了系统代理，未遵守系统代理的应用可能使用自己的连接方式。使用 VPN/TUN 时，仍要确认虚拟网卡、路由和 DNS 接管是否生效。mihomo 文档将 TUN 描述为可用于系统流量接管、DNS 劫持和按应用路由，但具体效果取决于当前配置与系统权限，不能只凭“已连接”判断。参考 mihomo 入站与 TUN 说明。

三类检测的证据边界：能证明什么，不能证明什么

Google 的官方诊断文档使用指定 DNS 服务器的命令来检查 Google Public DNS 的 UDP/TCP 连通性。例如 nslookup ... dns.google. 或 dig ... @dns.google. 能判断查询是否到达指定服务器；它们不是默认 DNS 泄漏证明。参考 Google Public DNS 官方诊断文档。

默认解析路径测试

Windows 可运行：

nslookup example.com

macOS 或 Linux 可运行：

dig example.com

这里故意不写 @服务器，目的是观察系统默认解析路径。记录输出中的 Server、Address、Status 和回答结果。若代理开启前后 Server 始终指向本地网关或企业 DNS，这不自动等于泄漏；还要结合客户端设计判断该路径是否符合预期。

指定服务器测试只做连通性验证

例如：

dig example.com @dns.google

这条命令只回答“当前设备能否向指定服务器查询并得到结果”。它不能回答“浏览器、系统或代理平时是否使用 dns.google”。不要把两类结论混在一起。

抓包的正确解读

Wireshark 可先用 dns 或 udp.port == 53 || tcp.port == 53 查看明文 DNS。若代理连接期间仍有请求发往不符合预期的本地网关或解析器，可继续定位系统、路由或客户端接管问题。若没有 53 端口，也不能证明没有泄漏，因为 DoH 会复用 HTTPS，DoT 使用加密连接。DoH 使用 HTTPS 端口传输 DNS 查询的基本特征可参考 MDN DNS over HTTPS 说明。

按层修复：客户端、系统、浏览器与 IPv6

1. 客户端与 TUN

先备份配置，只修改一个变量。检查“远程 DNS”“代理解析”“DNS 劫持”“TUN”“严格路由”等识别关键词。以 mihomo 为例，DNS 模块的 enable、nameserver、proxy-server-nameserver、direct-nameserver 和 enhanced-mode 分别影响 DNS 是否启用、普通解析、代理节点域名解析、直连解析和 fake-IP/redir-host 模式；字段含义以当前文档为准，不能复制一份配置就假定适合所有网络。参考 mihomo DNS 配置文档。

TUN 中的 dns-hijack 可将匹配到的 DNS 请求转入内部 DNS 模块，但官方文档明确写出：Windows 上相关行为依赖 strict-route，Linux 上可能需要 auto-redirect；macOS/Windows 对发往本地网络的 DNS 不能自动全部劫持，Android 开启 Private DNS 时也可能无法自动劫持。以上是特定实现的边界，不是所有客户端的普遍规律。参考 mihomo TUN 与 DNS 劫持文档。

2. 浏览器 DoH

Chrome 的 Secure DNS 默认可能处于自动模式；Google 说明，自动模式发生问题时可能回退到未加密解析，自定义服务商则不会默认回退到未加密模式。入口通常是“设置→隐私和安全→安全→使用安全 DNS”，菜单名称以当前版本为准。若只有 Chrome 结果异常，先临时关闭 Secure DNS 或统一到客户端预期路径，再复测。参考 Chrome 官方 Secure DNS 说明。

Firefox 也有独立的 DNS over HTTPS 设置。若命令行与 Firefox 结果不一致，先检查 Firefox 的 DoH 模式，再与其他浏览器比较，不要直接改系统 DNS。参考 Firefox 官方 DNS over HTTPS 说明。

3. Windows、macOS 与 Linux

• Windows：用 ipconfig /all 记录网卡 DNS；用 nslookup example.com 观察默认解析；检查客户端 TUN、DNS 劫持和严格路由，再复测 IPv4/IPv6。
• macOS：用 scutil --dns 查看解析器；用 dig example.com 做默认查询；检查系统代理、虚拟网卡和浏览器 DoH。
• Linux：用 resolvectl status 查看当前解析服务，用 dig example.com 和 ip route 对照；若存在本地 DNS 服务与 TUN 冲突，先记录配置再逐项停用或恢复。

4. Android 与 iOS

• Android：在设置中搜索“Private DNS”或“私人 DNS”，记录当前是关闭、自动还是指定主机名。若使用支持 TUN 的客户端，可临时切换为“自动”做对照，再按客户端文档恢复。mihomo 文档对 Android Private DNS 与自动 DNS 劫持的关系有明确限制说明。Wi-Fi 和移动网络必须分别测试。
• iOS：进入“设置→Wi-Fi→当前网络的信息按钮”，检查 DNS 和 HTTP Proxy；Apple 官方说明该页面可以配置 DNS、HTTP Proxy 等网络设置。VPN 配置、网络描述文件和应用自己的加密 DNS 可能改变结果，因此要分别在 Wi-Fi 和蜂窝网络复测。参考 Apple iPhone Wi-Fi 设置说明。

复测、回滚与误判边界

1. 清缓存：关闭并重新打开浏览器，按客户端提供的入口清理 DNS 缓存。
2. 重新连接：断开并重新连接代理；必要时重启网络适配器或设备。
3. 重复对照：分别测试代理关闭、代理开启、Wi-Fi、移动网络、IPv4 和 IPv6。
4. 记录证据：保存默认 nslookup/dig 输出、客户端日志摘要和抓包时间，不要上传订阅、令牌、证书或私钥。
5. 失败回滚：若出现无法解析、内网域名失效或全部断网，恢复修改前的 DNS、代理、DoH、Private DNS 和 IPv6 设置，再一次只改一个选项。

DNS 泄漏、真实 IP 泄漏、WebRTC 地址暴露、DNS 污染和 DNS 劫持不是同一个问题。本文步骤主要验证 DNS 查询路径；通过 DNS 检测不能自动证明真实 IP 或 WebRTC 已安全。

常见问题

代理 DNS 泄漏怎么检查最快？

先用不指定 DNS 服务器的 nslookup 或 dig 比较代理关闭和开启的默认解析路径，再检查浏览器 DoH、客户端日志、TUN 和 IPv6。指定 @dns.google 的命令只做指定服务器连通性测试。

SOCKS5 和 SOCKS5H 有什么区别？

不能把两者视为同一条 DNS 路径。以 curl 官方参数为例，socks5h:// 明确要求代理端解析主机名，而 socks5:// 不能据此证明域名一定由代理端解析。还要确认实际客户端是否保留了该协议设置。

看到 Google 或 Cloudflare DNS 就是泄漏吗？

不是。公共 DNS 可能由系统、浏览器、客户端或企业网络主动配置，Anycast 和转发也会造成地区差异。只有当结果与预期路径不一致，并被日志、路由或抓包印证时，才应判定为具体故障。

指定 DNS 服务器的 dig 命令能证明没有泄漏吗？

不能。dig example.com @dns.google 只证明设备能向 dns.google 查询并获得响应。要观察默认路径，应省略 @服务器；要判断浏览器路径，还要单独检查浏览器 DoH。

TUN 模式能自动防止 DNS 泄漏吗？

不能保证。TUN、DNS 劫持、严格路由、IPv6、分流规则和系统权限需要配合；Android Private DNS、浏览器 DoH 和应用自带解析也可能形成独立路径。

Android Private DNS 要不要关闭？

不能一概而论。可先记录原状态，再临时切换为“自动”做对照测试；如果结果改变，说明 Private DNS 与客户端 DNS 接管存在交互。修复后按当前客户端文档决定是否恢复。

iOS 只检查 Wi-Fi DNS 就够了吗？

不够。Wi-Fi DNS 和 HTTP Proxy 只是一个入口，VPN 配置、网络描述文件、蜂窝网络以及应用自带加密 DNS 都可能改变路径。至少要分别测试 Wi-Fi 和蜂窝网络。

关闭 IPv6 后检测正常，下一步怎么做？

把它当作定位结果，检查 IPv6 路由、AAAA 查询和客户端是否接管 IPv6。修复后恢复 IPv6，再重复代理关闭、开启、浏览器和不同网络的完整测试。

修改 DNS 后无法上网怎么恢复？

恢复修改前备份的 DNS、代理、DoH、Private DNS 和 IPv6 设置，断开并重新连接网络。每次只改一个变量，避免同时启用多个 DNS 接管组件。

常见问题

代理 DNS 泄漏怎么检查最快？

先用不指定 DNS 服务器的 nslookup 或 dig 比较代理关闭和开启的默认解析路径，再检查浏览器 DoH、客户端日志、TUN 和 IPv6。指定 @dns.google 的命令只做指定服务器连通性测试。

SOCKS5 和 SOCKS5H 有什么区别？

以 curl 官方参数为例，socks5h://明确要求代理端解析主机名，而 socks5://不能据此证明域名一定由代理端解析。还要确认实际客户端是否保留该协议设置。

看到 Google 或 Cloudflare DNS 就是泄漏吗？

不是。公共 DNS 可能由系统、浏览器、客户端或企业网络主动配置，Anycast 和转发也会造成地区差异。应结合预期路径、日志、路由或抓包判断。

指定 DNS 服务器的 dig 命令能证明没有泄漏吗？

不能。dig example.com @dns.google 只证明设备能向指定服务器查询并获得响应。观察默认路径时应省略 @服务器，并单独检查浏览器 DoH。

TUN 模式能自动防止 DNS 泄漏吗？

不能保证。TUN、DNS 劫持、严格路由、IPv6、分流规则、系统权限、Private DNS 和浏览器 DoH 需要一起核对。

相关阅读

• 检查 TUN 模式是否真正接管系统流量
• 查看连接问题的分层排查方法
• 按设备查看 DNS、代理与网络设置
• 继续排查延迟、丢包与速度问题
• 查看客户端导入与连接排查步骤

参考资料

1. curl 官方代理参数说明（curl.se）
2. mihomo 入站与 TUN 说明
3. mihomo TUN 与 DNS 劫持文档
4. mihomo DNS 配置文档
5. Google Public DNS 官方诊断文档
6. MDN DNS over HTTPS 说明
7. Chrome 官方 Secure DNS 说明
8. Firefox 官方 DNS over HTTPS 说明
9. Apple iPhone Wi-Fi 设置说明