Mihomo DNS 泄漏怎么检查和解决？

更新于 2026-11-01 · xn--mesv7f5toqlp.shop

简答：先不要直接复制复杂 YAML。关闭 Mihomo 做一次基线，再分别测试系统代理和 TUN；只有在开启 TUN 后仍出现预期外的系统、路由器或运营商解析器，并且能排除浏览器 DoH、Android Private DNS 和 IPv6 独立解析，才可判断为 DNS 路径未被 Mihomo 接管。修复顺序是：确认当前生效配置、检查 TUN 的 DNS 接管状态、排除应用自带加密 DNS，最后一次只改一个变量并保留回滚副本。

定义：Mihomo DNS 泄漏，是 DNS 请求没有按预期进入 Mihomo 的 DNS 模块或指定上游，而是被系统、浏览器、Android Private DNS、IPv6 或其他网络路径直接解析。

先看判断表：什么结果才算 DNS 泄漏

本文是第三方使用指南站，页面不代表任何客户端或订阅服务的官方立场。DNS 检测页显示多个解析器，并不自动等于泄漏；关键是检测结果是否符合你当前的接管设计，以及查询是否由同一条路径发出。

判断标准应是“查询发起者和路径是否符合预期”，而不是“检测页上是否只有一个 DNS”。Mihomo 官方文档说明，dns.enable 控制是否启用内部 DNS，dns.listen 定义 DNS 服务监听地址，enhanced-mode 可使用 fake-ip 或 redir-host；这些字段都应以当前内核实际生效配置为准。查看 Mihomo DNS 配置文档

最短复现流程：先做基线，再逐层打开

1. 固定测试条件。使用同一设备、同一网络、同一浏览器和同一测试域名。记录是否启用 IPv6、浏览器 Secure DNS、Android Private DNS，以及 Mihomo 当前模式。
2. 关闭 Mihomo。打开一个命令行查询域名，记录返回的 Server、Address 或系统 DNS 信息；不要把这次结果当成泄漏结论，它只是基线。
3. 只开启系统代理。再次查询并打开浏览器检测页。如果网页变化但命令行或其他应用不变，说明系统代理没有覆盖所有 DNS 发起者。
4. 开启 TUN。确认前端显示 TUN 已运行，再重复相同查询。不要同时修改 DNS、规则、IPv6 和 fake-ip，否则无法知道是哪项改变了结果。
5. 检查 Mihomo 日志或面板。查询测试域名时，观察是否出现 DNS 请求记录。没有记录但检测结果变化，可能是浏览器或系统组件绕过 Mihomo；有记录但仍出现预期外解析器，则要检查 Mihomo 的上游配置和规则。
6. 清理缓存后复测。Windows 可执行 ipconfig /flushdns；浏览器也要重新打开页面或清理其 DNS 缓存。一次成功不代表所有应用都走同一路径。

Windows 的 nslookup 可以使用默认 DNS，也可以指定服务器，例如 nslookup example.com 192.0.2.1。微软文档说明，省略第二个参数时会使用默认 DNS；指定服务器只能验证该服务器是否能回答，不能单独证明普通应用的所有查询都经过 Mihomo。查看 Microsoft nslookup 文档

Windows：命令、预期结果与异常分流

先在命令提示符中执行 nslookup example.com，记录输出中的 Server 和 Address。然后在 Mihomo 关闭、仅系统代理、TUN 开启三种状态下分别执行，保持域名不变。

• 预期结果：TUN 开启后，查询结果应与 Mihomo 的 DNS 接管设计一致，并且测试时能在 Mihomo 日志中看到对应查询。
• 仅默认查询显示本地 DNS：这可能只是系统 DNS 配置或 TUN 未接管，不足以证明泄漏；先确认 TUN 是否运行、系统代理是否只是浏览器级代理。
• 日志没有查询，浏览器却能解析：检查 Chrome Secure DNS、Firefox DoH、其他安全软件或应用自身代理。Chrome 的 Secure DNS 可在“设置—隐私和安全—安全”中开关；官方说明显示，启用后 Chrome 会加密 DNS 查询，自动模式遇到问题时还可能回退到未加密查询。查看 Chrome Secure DNS 设置说明
• 开启 TUN 后断网：先关闭 TUN并恢复备份，不要继续叠加字段；确认基础代理可用后，再只恢复 DNS 接管相关设置。

nslookup 是验证工具，不是完整的流量审计工具。它使用配置的 DNS 服务器进行查询，不能覆盖浏览器、应用内 DoH 或 IPv6 旁路，因此必须与 Mihomo 日志、浏览器设置和系统网络状态交叉判断。

macOS：不要只看网络设置，要结合实际查询

macOS 可在“系统设置—网络—当前网络—详细信息—DNS”查看系统配置的 DNS 服务器。Apple 官方说明，这里显示的是网络服务使用的 DNS 服务器列表；它不能单独证明查询已经被 Mihomo 接管。查看 Apple DNS 设置说明

1. 关闭 Mihomo，在终端执行 dig example.com，记录 SERVER、返回时间以及 A/AAAA 结果。
2. 只开启系统代理，再执行相同命令。若命令行结果和 Mihomo 日志没有变化，不要认为系统 DNS已走代理。
3. 开启 TUN后重复查询，并同时观察 Mihomo 日志。若 dig 有结果但 Mihomo 无对应记录，优先排查 macOS 本地 DNS、浏览器 DoH 或 IPv6。
4. 检查浏览器独立 DNS。Firefox 的 DoH 保护等级可以在“设置—隐私与安全—DNS over HTTPS”中查看；Mozilla 文档明确区分了关闭、默认、增强和最大保护等模式。查看 Firefox DoH 设置说明

macOS 和 Windows 对本地网络 DNS 的自动劫持存在限制。Mihomo TUN 文档明确提示，在 macOS 和 Windows 上，Mihomo 不能自动劫持发送到本地网络的 DNS 请求；因此局域网 DNS、企业内网域名和普通公网域名可能需要分别验证。查看 Mihomo TUN 文档

Android：重点排除 Private DNS 与应用自带解析

Android 系统的“私人 DNS”是独立的 DNS 处理层。Google 官方说明，私人 DNS 只保护 DNS 问答，不会保护其他网络流量；入口通常是“设置—网络和互联网—私人 DNS”，不同厂商名称可能略有差异。查看 Android 私人 DNS 设置说明

1. 记录私人 DNS 当前是“关闭”“自动”还是“私人 DNS 提供商主机名”。
2. 启动 Mihomo TUN，确认 VPN 图标出现后，使用同一个应用和域名重复测试。
3. 若 Android 私人 DNS 处于启用状态，而 Mihomo 日志没有对应 DNS 查询，先把私人 DNS 临时改为“自动”进行对照测试；只为定位问题，不建议在不了解网络策略时长期关闭安全功能。
4. 检查浏览器的 Secure DNS。Android 上的 Chrome 可能使用自己的 DNS 解析路径；如果只在 Chrome 出现不同结果，先在 Chrome 的“设置—隐私和安全—使用安全 DNS”中查看。
5. 若 Android TUN 开启后仍有本地 DNS，检查 IPv6、分应用路由和 fake-ip 过滤规则。Mihomo 文档指出，Android 开启 Private DNS 时，DNS 请求不能被自动劫持；strict-route 还会影响 DNS 劫持和路由行为。

Mihomo 配置怎么改：只核对字段，不盲抄整份 YAML

当前官方文档将 dns-mode 和 dns-hijack列在顶层 tun 配置下，而 enable、listen、nameserver、fallback 等属于顶层 dns 配置。TUN 字段位置与DNS 字段位置请以当前版本文档和前端生成的实际配置为准。

建议按以下顺序操作：

1. 在前端导出或复制当前配置，另存为备份文件，并记录当前内核版本和运行平台。
2. 先只确认 dns.enable 是否启用、DNS 服务是否有监听地址，以及 TUN 是否启用；不要同时改上游、规则和 fake-ip。
3. 再确认 tun.dns-mode 的实际值。官方文档中，native、hijack 和 disabled 的作用不同；Windows 使用 hijack 时还涉及 strict-route，不能脱离平台直接套用。
4. 如果需要核对 dns-hijack，只把它当作当前版本的结构字段检查，不要直接复制一整段示例。尤其要确认前端是否覆盖该字段、系统权限是否允许 TUN 接管。
5. 保存后只重启 Mihomo，复用同一测试步骤。如果网页打不开、局域网设备失效或日志出现解析错误，立即恢复备份。

结构示例，不可直接复制：应分别核对“顶层 dns 是否启用”和“顶层 tun 是否启用及其 DNS 接管模式”；具体上游地址、监听端口、规则集、fake-ip 过滤项和 IPv6 设置必须由你的前端与当前内核文档确认。

常见异常：fake-ip、IPv6、局域网和浏览器 DoH

• fake-ip 后 NAS、打印机或企业内网打不开：这不一定是 DNS 泄漏，可能是内网域名或地址不适合 fake-ip。先保留备份，针对内网后缀或局域网地址核对 fake-ip-filter，不要全局关闭所有 DNS 接管。
• 只出现 IPv6 解析异常：分别测试 A 和 AAAA 记录。如果 IPv4 走 Mihomo、IPv6 走系统网络，问题更像 IPv6 路由或接管范围不一致，应先临时对照 IPv6，再决定是否调整。
• 浏览器检测正常，某个应用仍显示本地 DNS：应用可能使用独立 DoH、DoT 或自带解析库。检查应用网络设置和系统日志，不要仅凭浏览器结果判断全机无泄漏。
• 看到多个解析器：若它们全部来自你明确配置的 nameserver、fallback 或规则策略，并且日志能对应到查询，不一定是泄漏；若出现未配置的本地、路由器或网络提供方解析器，则继续查旁路。

修复完成后的验收与回滚清单

1. 保留关闭 Mihomo 的基线结果。
2. 在开启 TUN 后分别测试浏览器、命令行和至少一个非浏览器应用。
3. 检查 Mihomo 日志是否出现测试域名的查询记录。
4. 分别确认 Chrome/Firefox 的 Secure DNS 或 DoH 状态，以及 Android Private DNS 状态。
5. 重复测试 IPv4 和 IPv6，记录 A/AAAA 是否走同一预期路径。
6. 验证局域网域名、NAS、打印机或企业内网是否仍能访问。
7. 若改动后断网，关闭 TUN，恢复备份配置，重新启动客户端；不要在未恢复前继续叠加字段。

满足“测试请求有 Mihomo 记录、结果没有未配置的旁路解析器、浏览器和系统设置不存在独立绕过、IPv4/IPv6 结果符合设计”时，才可以说当前测试场景下已排除明显 DNS 泄漏。它不等于所有应用、所有网络和长期运行都永久不会改变。

常见问题

DNS 检测页出现两个或多个解析器，是不是一定泄漏？

不是。多个解析器可能来自 Mihomo 的 nameserver、fallback 或规则策略。只有出现未配置的本地或网络提供方解析器，并且能通过日志、命令或设置排除其他发起者时，才应判定为疑似泄漏。

开了系统代理，为什么 DNS 还显示本地解析器？

系统代理通常只影响支持代理的应用连接，不代表所有系统 DNS 请求都进入 Mihomo。请用关闭、系统代理、TUN三种状态对照，并检查浏览器 DoH、Android Private DNS 和 IPv6。

Windows 的 nslookup 显示某个 DNS，能证明全机都泄漏吗？

不能。它主要反映该命令使用的默认 DNS 路径。还要结合 Mihomo DNS 日志、浏览器设置、应用独立 DNS 和 TUN 状态判断。

为什么 TUN 开启后局域网设备反而打不开？

可能是 fake-ip、路由排除、局域网 DNS 或 strict-route 与当前应用的兼容问题。先恢复备份，再只验证局域网域名和地址，不要把局域网异常直接当作公网 DNS 泄漏。

要不要直接复制网上的 dns-hijack 配置？

不建议。字段位置和可用行为取决于当前 Mihomo 内核、前端、操作系统和权限。先备份，再按官方 schema 核对最小字段，一次只改一个变量。

修复后还要不要继续使用浏览器 DoH？

取决于你的目标。如果希望浏览器查询由 Mihomo 统一记录和接管，就要检查并按需调整浏览器 DoH；如果希望浏览器使用独立加密 DNS，则它可能不会出现在 Mihomo DNS 日志中，这属于不同的解析设计，而不是自动等于泄漏。

常见问题

DNS 检测页出现多个解析器，是不是一定泄漏？

不是。多个解析器可能来自 Mihomo 已配置的 nameserver、fallback 或规则策略。只有出现未配置的本地或网络提供方解析器，并且能排除浏览器 DoH、Android Private DNS、IPv6 等独立路径时，才是疑似泄漏。

开了系统代理，为什么 DNS 仍然显示本地解析器？

系统代理不等于全机 DNS 接管。请关闭 Mihomo做基线，再比较仅系统代理和 TUN 开启后的结果，并查看 Mihomo 日志是否收到同一测试域名的查询。

Windows 的 nslookup 能单独证明 DNS 泄漏吗？

不能。nslookup 主要验证命令使用的默认 DNS 路径；还需要结合 Mihomo 日志、浏览器 Secure DNS、应用设置、IPv6 和 TUN 状态判断。

TUN 开启后局域网设备打不开怎么办？

先关闭 TUN并恢复备份，确认基础代理可用后，再单独检查 fake-ip、局域网排除地址、内网 DNS 和 strict-route。局域网异常不等于公网 DNS 泄漏。

相关阅读

• Mihomo IPv6 设置后无法联网怎么排查
• Mihomo 规则不生效时如何定位
• Mihomo 节点测速与延迟结果怎么看
• 连接问题排查总入口

参考资料

1. Mihomo DNS configuration
2. Mihomo TUN configuration
3. Google Chrome Secure DNS settings
4. Mozilla Firefox DNS over HTTPS settings
5. Android Private DNS settings
6. Microsoft nslookup command
7. Apple macOS DNS settings