Mihomo DNS泄漏怎么检测？在线测试与本地交叉验证步骤
简答：先用 BrowserLeaks 和 DNS Leak Test 分别运行标准或扩展测试，再关闭 Mihomo、开启系统代理、开启 TUN 做三组对照。若开启 TUN 后仍出现本地运营商、路由器或公司网络 DNS，继续检查 dns.enable、dns-hijack、strict-route、浏览器 Secure DNS、Android Private DNS 和 IPv6；单个网页显示多个 DNS 服务器，不一定就等于泄漏。
定义：Mihomo DNS泄漏，是指应用的域名解析请求没有按预期进入 Mihomo DNS 或指定的加密解析链路，而是被系统、浏览器、局域网、IPv6 或其他应用单独发出。
先看结论：3组测试就能判断大多数情况
本文为第三方使用指南，Mihomo 客户端的菜单名称会因发行版、系统和版本不同而变化，以下以当前运行配置和实际日志为准。
| 阶段 | 操作 | 主要用途 | 如何解读 |
|---|---|---|---|
| 1. 基线 | 完全退出 Mihomo，关闭系统代理和 TUN | 记录当前网络本来的 DNS | 通常会看到路由器、运营商、公司网络或系统配置的解析器 |
| 2. 系统代理 | 只开启 Mihomo 的系统代理，不开启 TUN | 确认浏览器是否通过代理访问，以及浏览器解析路径是否改变 | 网页流量可能改变，但不代表所有应用的 DNS 都已被接管 |
| 3. TUN 接管 | 开启 Mihomo DNS、TUN 和 DNS 劫持后复测 | 检查系统级流量和传统 53 端口查询是否进入 Mihomo | 仍出现异常解析器时，重点检查浏览器 DoH、Android Private DNS、IPv6、UDP/TCP 53 和局域网 DNS |
最快做法是：先打开 BrowserLeaks DNS 测试，再打开 DNS Leak Test 的标准/扩展测试说明，记录每次测试显示的 DNS 服务器名称、IP、组织和位置。BrowserLeaks 说明其测试会让浏览器解析随机域名，其中包含 IPv4-only 和 IPv6-only 域名，因此可以帮助发现 IPv6 路径是否与 IPv4 不一致。
关键判断：结果出现多个 DNS 服务器并不自动等于泄漏。先判断这些服务器是否属于你预期使用的解析服务、公司网络或客户端上游；只有在预期路径之外出现本地运营商、家庭路由器、公司网关或未知解析器，并且在重复测试中稳定出现，才应进入旁路排查。
按顺序完成在线检测：关闭、系统代理、TUN
- 固定测试条件。使用同一浏览器、同一网络、同一测试页面；记录是否使用 Wi-Fi、网线、手机热点，是否启用 IPv6，以及浏览器是否开启 Secure DNS。不要在测试中途切换网络或清理配置。
- 做基线测试。退出 Mihomo 主程序，关闭系统代理和 TUN，分别运行两个 DNS 测试站。把结果保存下来，重点记录 DNS 服务器的 IP、组织名称和位置。基线结果只是当前网络的参照，不代表 Mihomo 已经泄漏。
- 只开系统代理。启动 Mihomo，开启系统代理，但暂时关闭 TUN。再次运行两个测试站。如果浏览器访问已经经过代理，但 DNS 结果没有改变，不要直接下结论；这通常说明浏览器或系统解析仍可能走独立路径。
- 开启 TUN 后复测。先确认配置文件已经加载，再开启 TUN。Mihomo 文档说明，TUN 的
dns-hijack用于把匹配到的 DNS 连接转入内部 DNS 模块；Windows 和 macOS 对发往局域网的 DNS 请求不能自动全部劫持，Android 开启 Private DNS 时也不能自动劫持这些请求。 - 做 IPv4/IPv6 对照。如果测试页面显示 IPv4 解析器符合预期，但 IPv6 解析器来自本地网络，优先暂时关闭 IPv6 或检查 TUN 的 IPv6 路由，再重新测试。关闭 IPv6 只是定位手段，确认原因后应根据实际网络和客户端能力决定是否恢复。
测试页面只能观察浏览器最终使用或触发到的解析结果，不能覆盖每一个应用。Chrome 的 Secure DNS 会让 Chrome 使用自己的安全 DNS 解析路径；Google 文档也说明，Chrome 的 Secure DNS 与 Android Private DNS 是不同设置，因此浏览器测试异常时需要分别检查。
检查 Mihomo 配置：重点看 7 个字段
打开实际运行的 Mihomo 配置，不要只看订阅原文。Mihomo 官方 DNS 文档列出了以下字段的作用：
dns.enable：设为false时会使用系统 DNS；因此检测时首先确认它是否确实启用。dns.nameserver：默认域名解析服务器。检查是否为空、是否写入了不认识的地址，或是否被其他配置覆盖。dns.fallback：备用解析服务器。出现多个结果时，先确认它们是否来自配置的备用服务器，不要仅凭数量判断泄漏。dns.default-nameserver：用于解析 DNS 服务器域名，官方文档要求这里填写 IP 地址；不要把普通域名直接当作该字段值。dns.direct-nameserver：用于直连出口的域名解析。如果配置为system，直连域名可能使用系统解析；这不一定是泄漏，但必须符合你的分流设计。tun.dns-hijack：用于把匹配到的 DNS 连接转给 Mihomo 内部 DNS 模块。常见写法包括any:53或明确的 UDP/TCP 53 目标，但应以当前版本文档和发行版支持情况为准。tun.strict-route：官方文档说明，Windows 下它会增加防止系统多宿主 DNS 解析造成泄漏的防火墙规则；Linux 下可帮助强制连接进入 TUN，但也可能影响虚拟机或局域网访问。
配置修改后，先保存并重载配置，再按“关闭 TUN→退出客户端→重新启动→开启 TUN”的顺序复测。不要只刷新网页，因为旧的浏览器连接、缓存或 DoH 会让结果看起来没有变化。
需要注意：fake-ip 不是“自动保证不泄漏”的开关。它改变的是 Mihomo 对域名解析结果的处理方式；浏览器自带 DoH、Android Private DNS、独立 VPN、容器或其他应用自建解析器，仍可能绕过普通的 53 端口劫持。
本地交叉验证：不要只相信网页结果
在线测试发现异常后，使用本地命令确认系统当前看到的 DNS 和查询路径。命令显示的服务器只是操作系统或工具所使用的解析器，不一定能直接证明所有应用都走同一条路径，因此要和在线测试、Mihomo 日志一起判断。
Windows 10/11
在命令提示符运行：
ipconfig /all
nslookup -debug example.com
nslookup -type=A+AAAA -nosearch -recurse example.comMicrosoft 文档将 nslookup 定义为用于诊断 DNS 基础设施的命令，并支持通过 -debug 查看更详细的查询信息。重点看输出中的 Server、Address 以及 A/AAAA 查询是否都成功。如果服务器显示家庭路由器或公司 DNS，而 TUN 与 DNS 劫持本应接管系统查询，应回到 dns.enable、dns-hijack 和 strict-route 检查。
macOS
先查看网络硬件接口：
networksetup -listallhardwareports再查看系统解析配置：
scutil --dns如果需要确认是否有传统 DNS 流量经过物理接口，可先用 Apple 文档所述的 networksetup -listallhardwareports 找到实际接口，再谨慎使用抓包工具观察 UDP/TCP 53。不要把抓不到明文 53 直接等同于“没有泄漏”，因为 DoH、DoT 或应用自带解析可能使用其他端口。
Linux
使用 systemd-resolved 的系统可运行：
resolvectl status
resolvectl query example.com
resolvectl query --type=AAAA example.comresolvectl status 用于查看全局和每个网络接口的 DNS 设置，resolvectl query 用于发起解析查询。若系统没有启用 systemd-resolved，可查看 /etc/resolv.conf，或使用已安装的 dig：
dig example.com A
dig example.com AAAA如果需要观察明文 DNS 连接，可在确认接口名称后使用：
sudo tcpdump -ni any 'port 53'查询期间完全没有 53 流量，不代表没有 DNS；加密 DNS 通常不会以明文 UDP/TCP 53 出现。
Android
打开系统设置中的“网络和互联网→私人 DNS”，记录当前状态；不同厂商菜单名称可能不同。再检查 Chrome 的“设置→隐私和安全→使用安全 DNS”。Android 官方资料说明，Android 9 及更高版本支持 Private DNS，而 Chrome Secure DNS 又是浏览器自己的解析设置。若 Mihomo TUN 已开启但 Private DNS 仍处于严格模式，先暂时切换为自动或关闭进行对照测试，然后重新运行两个在线测试站。
根据结果定位：一张排查清单
| 现象 | 优先检查 | 下一步 |
|---|---|---|
| 关闭 Mihomo 和开启 Mihomo 的结果完全相同 | 系统代理是否真的生效、浏览器 Secure DNS、应用是否自带 DNS | 用同一浏览器关闭 Secure DNS 后复测，再看 Mihomo 日志是否出现域名查询 |
| 系统代理有效，但 TUN 后仍有本地 DNS | tun.dns-hijack、strict-route、Windows/macOS 局域网 DNS 限制 | 检查是否劫持 UDP/TCP 53，并按客户端文档重新启用 TUN；不要直接修改系统 DNS 后忘记恢复 |
| IPv4 正常，IPv6 显示本地或未知解析器 | TUN IPv6 路由、系统 IPv6、浏览器 IPv6 查询 | 暂时关闭 IPv6 做对照；若结果改变，再针对 IPv6 路由和 DNS 劫持处理 |
| 在线测试显示多个同组织 DNS | nameserver、fallback、负载均衡或并发查询 | 与实际配置逐个比对；多个预期上游不等于泄漏 |
| Mihomo 日志没有域名查询记录 | 查询可能被浏览器 DoH、Android Private DNS 或其他网络组件处理 | 关闭独立解析功能后重新加载页面，并用系统命令和在线测试交叉验证 |
如果确认存在旁路，修复顺序应保持“先轻后重”：先关闭浏览器独立 DoH 或 Android Private DNS 做对照，再确认 Mihomo DNS 模块启用，然后检查 TUN 的 DNS 劫持和严格路由，最后才考虑系统网络栈重置。每次只改一个变量，并记录修改前后的测试结果。
恢复步骤：测试结束后关闭 TUN，关闭系统代理，退出 Mihomo；如果手动修改过系统 DNS，将网络接口恢复为自动获取；macOS、Windows 和 Linux 不要留下临时的静态 DNS 或防火墙规则。Android 则恢复原来的 Private DNS 设置。恢复后再打开网页，确认普通网络连接和局域网设备访问没有被影响。
常见问题
Mihomo DNS测试出现多个服务器，就是DNS泄漏吗？
不一定。nameserver、fallback、并发查询或公司网络都可能让测试显示多个服务器。先把结果中的IP和组织与实际Mihomo配置、网络环境逐项比对；只有出现预期链路之外的本地或未知解析器，并在重复测试中稳定出现，才应按泄漏排查。
只开系统代理，为什么DNS检测结果没有变化？
系统代理主要影响遵循系统代理设置的应用，不能自动接管所有应用的DNS。浏览器Secure DNS、Android Private DNS、IPv6或应用自带解析器都可能使用独立路径。可以关闭这些独立解析功能做一次对照，再开启TUN和DNS劫持复测。
Mihomo开启TUN后还需要检查dns-hijack吗？
需要。TUN是否启用与DNS请求是否被转入Mihomo DNS模块是两个相关但不同的检查点。官方文档将dns-hijack用于把匹配到的DNS连接转入内部DNS模块；Windows和macOS对发往局域网的DNS请求存在自动劫持限制，Android Private DNS也可能阻止自动劫持。
如何判断是IPv6导致的DNS泄漏？
先保持其他设置不变，分别进行IPv4-only和IPv6-only查询或测试。如果IPv4结果符合预期、IPv6结果稳定显示本地或未知解析器，可暂时关闭系统IPv6再复测。若结果恢复，再检查TUN IPv6路由、DNS劫持和浏览器的IPv6解析路径。
修改Mihomo DNS配置后，为什么检测结果还是旧的？
可能是配置没有真正加载、客户端没有重启TUN、浏览器缓存了连接，或浏览器仍使用独立DoH。建议保存配置后重载或重启客户端，关闭并重新打开浏览器，再按关闭Mihomo、系统代理、TUN三阶段测试。每次只修改一个变量。
相关阅读
- 先了解 Mihomo Party TUN 模式的开启、验证与回滚
- 如果连接变慢，继续区分节点、DNS 与 TUN 问题
- Linux 用户查看安装、curl 测试与 systemd 配置
- Android 用户查看客户端选择与订阅导入步骤
- 进入连接问题排查总清单
参考资料
- Mihomo 官方文档：DNS configuration
- Mihomo 官方文档：TUN
- Microsoft Learn：nslookup
- Apple Developer Documentation：Recording a Packet Trace
- Linux man-pages：resolvectl（man7.org）
- Android Developers：Insecure DNS Setup
- Google Chrome Help：Manage Chrome safety and security
- BrowserLeaks：DNS Leak Test（browserleaks.com）
- DNS Leak Test：Standard vs Extended test（dnsleaktest.com）