Mihomo DNS 泄漏怎么检查和修复

更新于 2026-11-05 · nexitally.top

简答：先不要只改 nameserver：依次检查浏览器 Secure DNS、系统 Private DNS、Mihomo 当前运行配置和 TUN 的 DNS 接管状态。最小闭环是开启 TUN、确认 dns.enable 与 dns-hijack 生效、关闭额外 DNS 通道，再用两个检测站和系统命令复测；如果仍异常，按 IPv6、UDP/TCP 53、DoH/DoT 和平台限制分流。

定义：Mihomo DNS 泄漏，是指设备的域名查询绕过 Mihomo 的 DNS 模块或预期出站路径，直接交给本地运营商、路由器、系统解析器或浏览器自己的加密 DNS。

先做三步判断：到底是泄漏、解析异常，还是检测结果误读

本文是第三方使用指南，不代表任何客户端、服务或节点的官方结论。DNS 检测站看到的解析器身份，只能说明测试域名最终由哪些解析器查询，不能单独证明所有应用、所有网络协议都走了同一条路径。

先在同一设备、同一网络、同一浏览器中打开 BrowserLeaks DNS Leak Test 和 DNS Leak Test。运行标准测试后记录解析器名称、网络归属和 IPv4/IPv6 结果，再重复一次深度或完整测试。测试工具本身只能观察它发起的测试查询，因此不要仅凭一次结果推断整个设备没有泄漏。

Mihomo 配置中，哪些字段真正影响 DNS 路径

Mihomo 文档将 DNS 模块、TUN 接管和代理节点域名解析分成不同职责。只修改 nameserver，并不等于系统所有 DNS 请求都会进入 Mihomo。

• dns.enable：控制 Mihomo DNS 模块是否启用；关闭时会使用系统 DNS。
• dns.enhanced-mode：可选 fake-ip 或 redir-host。前者为域名建立虚拟地址映射，后者保留真实解析地址，二者对局域网、NAS、游戏和部分应用的兼容性不同。
• tun.dns-hijack：把匹配的 DNS 连接导入 Mihomo DNS 模块。文档说明 Windows 和 macOS 不能自动劫持发往本地网络的 DNS 请求。
• tun.dns-mode：native 只设置 TUN 地址为系统 DNS，hijack 还会接管其他接口发往 53 端口的流量。
• strict-route：Windows 下可通过防火墙规则减少多宿主 DNS 泄漏；Linux 下有助于让连接走 TUN，但可能影响部分虚拟化或局域网软件。
• proxy-server-nameserver：只用于解析代理节点域名，不能理解为“所有网站 DNS 都经代理”。
• nameserver-policy：按域名或规则集选择解析器，优先级和分流逻辑需要结合当前配置核对。

以上字段的定义和平台限制以 Mihomo DNS 配置文档 与 Mihomo TUN 配置文档 为准。不要直接复制别人的完整 YAML；先备份当前配置，并只修改一个变量。

最小修复配置：先备份，再确认 TUN 和 DNS 接管

以下是排查思路，不是跨平台通用成品配置。将原 YAML 复制为测试副本，启动测试副本后确认界面显示的运行配置确实来自该文件。

tun:
  enable: true
  auto-route: true
  dns-hijack:
    - any:53
    - tcp://any:53
  strict-route: true

dns:
  enable: true
  enhanced-mode: fake-ip
  ipv6: false
  nameserver:
    - https://dns.example.invalid/dns-query

上面使用了保留的示例域名，不能直接作为可用 DNS 地址。请把 dns.example.invalid 替换为你实际选择且能从当前网络访问的解析器；如果不清楚上游是否可达，先保留原有 nameserver，只验证接管链路。

1. 关闭 Mihomo，备份当前 YAML、订阅生成配置和客户端运行配置。
2. 只在测试副本中确认 dns.enable: true、TUN 已开启，并为 dns-hijack 同时观察 UDP 53 和 TCP 53。
3. Windows 再测试 strict-route: true；Linux 只有在 TUN 自动路由与 auto-redirect 条件满足时，才考虑自动重定向。
4. 启动后查看日志，查询一个新域名；预期结果是日志出现 Mihomo DNS 查询，而不是只有系统网络设置发生变化。
5. 如果网页、局域网或虚拟机异常，先关闭测试副本并恢复备份，不要长期关闭系统安全功能。

如果打开 respect-rules 让 DNS 查询遵守规则，Mihomo 文档要求同时考虑 proxy-server-nameserver，否则解析代理节点时可能形成循环依赖或失败。

按系统排查：Windows、macOS、Linux、Android 的最短路径

Windows

1. 确认 TUN 已启动，检查 dns-mode 是否为 hijack，并确认 strict-route 是否在当前运行配置中生效。
2. 打开命令提示符执行 nslookup example.com。它使用当前系统默认 DNS；再执行 nslookup example.com 1.1.1.1 对比指定服务器查询。命令行为可参考 Microsoft nslookup 文档。
3. 如果浏览器检测结果异常而 Mihomo 日志没有对应查询，检查浏览器的 Secure DNS；关闭后重启浏览器并复测。
4. 如果同一台电脑存在 Wi-Fi、网线、虚拟网卡或虚拟机，优先测试 strict-route；若虚拟机联网受影响，记录该结果并回滚，而不是盲目保留。

macOS

1. 打开“系统设置—网络—当前网络服务—详细信息—DNS”，核对系统 DNS 列表；Apple 的路径说明见 Apple DNS 设置文档。
2. 终端执行 scutil --dns，观察当前解析器、接口和搜索域；也可用 dig example.com 做辅助查询。
3. Mihomo 文档明确说明 macOS 不能自动劫持发往本地网络的 DNS，因此 TUN 开启不等于所有局域网 DNS 都会被接管。
4. 如果系统解析器没有出现在 Mihomo 日志中，先检查 macOS 的 DNS 服务顺序和浏览器 Secure DNS，再决定是否切换 fake-ip 或 redir-host。

Linux

1. 确认 TUN 的 auto-route 与 DNS 模式已生效；需要透明重定向时，再核对 auto-redirect、iptables 或 nftables 是否存在。
2. 执行 resolvectl status 查看 systemd-resolved 的接口与 DNS 状态；该命令用途见 freedesktop.org resolvectl 文档。
3. 若 /etc/resolv.conf 是静态文件，系统解析器可能与 TUN 配置不一致；先记录文件状态，避免直接删除或覆盖。
4. 防火墙开启时，检查是否允许 Mihomo 或 TUN 接口出站；修改规则前保存现有规则，测试失败立即恢复。

Android

1. 检查系统“私人 DNS”。Mihomo 文档说明，Android 开启 Private DNS 时，DNS 请求不能被自动劫持。
2. 如果使用 TUN，确认应用没有被排除，且 strict-route 与当前 Android 客户端实现兼容。
3. 先关闭 Private DNS 做一次对照测试，记录结果；不要把“关闭后有效”当作永久安全建议，企业网络或局域网可能有自己的 DNS 要求。
4. 若只有某个应用异常，检查应用分流、排除包名和局域网域名的 fake-ip-filter，不要直接把所有域名加入过滤列表。

fake-ip、redir-host 和 fake-ip-filter 怎么选

建议从默认或当前可用模式开始，只为一个已知异常域名增加过滤项，然后复测局域网、网页、节点连接和日志。不要因为检测站显示某个公共解析器，就把它加入所有字段；先明确它属于普通域名解析、代理节点解析还是规则分流。

复测闭环：至少验证 DNS、网页、日志和 IPv6 四层

1. DNS 检测：在两个检测站各运行标准测试和一次深度测试，记录解析器归属、IPv4 与 IPv6 结果。两次结果不一致时，先视为路径不稳定，不要直接下结论。
2. 网页加载：访问一个此前未打开过的域名，观察网页是否能加载；DNS 有返回不代表代理连接、TLS 或页面加载一定成功。
3. Mihomo 日志：查询测试域名时，确认日志能看到 DNS 模块处理或对应连接；没有日志只能说明当前观察点没有捕获到该请求。
4. 系统状态：Windows 用 nslookup，macOS 用 scutil --dns 和 dig，Linux 用 resolvectl status。这些命令用于观察系统路径，不能替代检测站。
5. IPv6 对照：若设备和网络有 IPv6，单独检查 AAAA 查询和 IPv6 页面访问。dns.ipv6: false 只影响 Mihomo 的 AAAA 返回，不等于系统所有 IPv6 流量都会被关闭或接管。

复测时固定设备、系统、网络、浏览器、配置副本和测试时间；每次只改一个变量。若修复后局域网异常，先回滚最后一项变更，再重新定位是 fake-ip、路由、DNS 劫持还是应用排除造成的。

常见失败原因与回滚方法

• 只修改了未加载的 YAML：客户端可能使用订阅生成配置或运行时合并配置。以客户端当前显示的运行配置、日志和 TUN 状态为准。
• 浏览器 DoH 绕过 Mihomo：关闭浏览器 Secure DNS 做对照；如果关闭后恢复，说明浏览器存在独立解析路径。
• Android Private DNS 未关闭：先记录原设置，再做一次关闭后的对照测试。
• TCP 53 未处理：只配置 UDP 53 可能遗漏部分请求，因此应按当前文档核对 dns-hijack 写法。
• 局域网设备无法访问：优先检查 fake-ip-filter、局域网路由和排除规则，不要直接把系统 DNS 或安全防护长期关闭。
• 节点域名无法解析：单独检查 proxy-server-nameserver，不要误把它当成普通网站 DNS 的总开关。

回滚顺序建议是：停止 Mihomo测试配置、恢复原 YAML、恢复系统 DNS 或 Private DNS 原值、重启受影响应用，最后再用相同检测步骤确认回滚成功。

结论：什么时候可以认为问题已基本定位

可以认为“当前测试场景下已基本定位”，至少要同时满足：检测站连续两轮没有出现不在预期范围内的解析器；Mihomo 日志能观察到测试域名的 DNS 处理；Windows、macOS、Linux 或 Android 的系统状态与配置方向一致；IPv4、IPv6、浏览器和实际网页加载没有互相矛盾的结果。

如果只有检测站结果改善、但 Mihomo 日志仍没有请求，或只有浏览器正常而其他应用异常，应继续按应用、协议和平台分流。不要把一次检测、一个节点或一个网络环境的结果扩大为整体稳定性结论。

常见问题

Mihomo 开启 TUN 后，为什么还会出现 DNS 泄漏？

TUN 只代表系统流量有机会进入虚拟网卡，不代表浏览器 DoH、Android Private DNS、局域网 DNS 或 IPv6 路径一定被接管。应同时检查 dns-mode、dns-hijack、strict-route、浏览器设置和系统 DNS。

DNS 检测站显示 Cloudflare 或 Google，算不算泄漏？

不能仅凭名称判断。关键是这些解析器是否属于你的预期配置、是否由 Mihomo 发起查询，以及是否在不同测试中稳定出现。公共解析器可能是配置结果，也可能是浏览器或系统独立 DoH 的结果。

dns.ipv6: false 能不能彻底解决 IPv6 泄漏？

不能。它主要影响 Mihomo DNS 对 AAAA 记录的返回，不等于系统 IPv6 路由、浏览器 IPv6 连接或其他应用的 IPv6 流量都会被关闭。必须单独检查 IPv6 页面访问和 TUN 路由。

fake-ip 和 redir-host 应该选哪个？

没有适合所有设备的固定答案。fake-ip 更强调域名映射和规则统一，redir-host 更接近真实地址解析。先保留当前可用模式，只针对具体局域网或应用问题做单变量对照。

为什么 proxy-server-nameserver 修好了节点，但普通网站仍可能泄漏？

该字段主要负责代理节点服务器域名解析，解决节点域名尚未解析的问题；普通网站是否使用 Mihomo DNS，还要看 dns.enable、TUN 接管、浏览器 DoH、系统 Private DNS 和分流规则。

修复后局域网、NAS 或虚拟机不能用了怎么办？

立即停止测试配置并恢复备份，然后逐项检查 fake-ip-filter、route-exclude-address、strict-route 和应用排除。不要直接长期关闭防火墙或系统安全设置。

相关阅读

• 连接不上网络时的代理、内核、节点与 TUN 排查
• 按日志定位 DNS、TUN 与节点问题
• 连接问题排查总览

参考资料

1. Mihomo DNS 配置文档
2. Mihomo TUN 配置文档
3. BrowserLeaks DNS Leak Test（browserleaks.com）
4. DNS Leak Test（dnsleak.dev）
5. Microsoft Learn：nslookup 命令
6. Apple 支持：在 Mac 上更改 DNS 设置
7. freedesktop.org：resolvectl（freedesktop.org）