Mihomo DNS泄漏怎么排查？按请求路径定位并复测

更新于 2026-11-10 · piaomiaoxu.online

简答：先不要直接改一整份配置：固定设备、网络、节点和浏览器后，分别确认“谁发起DNS请求、请求去了哪里、是否经过Mihomo”。重点检查实际生效配置中的 `dns.enable`、`dns.listen`、`dns.enhanced-mode`、TUN的 `dns-hijack`、`dns-mode` 与 `strict-route`；其中 `dns-mode` 属于TUN配置，不能和 `dns.enhanced-mode` 混为一谈。最后用系统命令、Mihomo日志和连续复测共同判断。

定义：DNS泄漏是指在你的网络设计目标下，本应由Mihomo处理或转发的域名查询，实际绕过预期路径而由系统、浏览器、私人DNS、局域网DNS或其他应用独立完成；单独看到某个解析器并不必然代表存在安全问题。

先看这张表：检测结果对应查什么

DNS检测站只能说明某次解析结果被哪些解析器观察到，不能单独证明请求一定绕过了Mihomo。先固定同一设备、同一网络、同一节点、同一浏览器和同一测试域名，再按下表定位。

这里的核心亮点是“现象—证据—处理—复测”四步，而不是直接套用一份可能与客户端封装不匹配的配置。

第一步：确认检查的是实际生效配置

不同客户端可能把订阅、覆写、当前Profile和运行时配置分开保存。先备份当前配置并记录原设置，确认当前选中的Profile确实已启用；不要只编辑订阅原文或一个未选中的文件。若客户端提供“运行配置”“当前配置”或配置检查页面，应以运行时内容为准。Mihomo官方文档说明，顶层TUN配置用于接管系统流量、DNS劫持和按应用路由；监听器形式的TUN属于另一种配置入口，不能把两者的字段位置混用。可查看Mihomo入站配置说明。

逐项核对以下字段，但不要把它们当成同一个开关：

• dns.enable：决定Mihomo DNS模块是否启用；关闭时会使用系统DNS。
• dns.listen：Mihomo本地DNS监听地址和端口，支持UDP和TCP。
• dns.enhanced-mode：Mihomo内部DNS处理模式，可为fake-ip或redir-host。
• dns.nameserver、nameserver-policy：处理普通域名查询及按域名匹配的上游。
• dns.proxy-server-nameserver：仅用于解析代理节点域名，不能简单当成所有DNS请求的唯一出口。
• tun.dns-hijack：把匹配到的连接导入内部DNS模块。
• tun.dns-mode：TUN如何配置系统DNS，可选值是disabled、native和hijack；它不是dns.enhanced-mode。
• tun.strict-route：严格路由行为，Windows下还涉及阻止普通多网卡DNS解析造成的旁路。

这些字段的定义和限制应以Mihomo DNS配置文档及Mihomo TUN配置文档为准。特别注意：官方文档明确写出，Windows和macOS不能自动劫持发往局域网的DNS请求；Android开启私人DNS时，也不能自动劫持DNS请求。这是内核限制，不能简单归因于某个客户端界面。

第二步：Windows上用命令和日志对照

1. 清除旧缓存并记录当前DNS：在命令提示符执行ipconfig /flushdns，再执行nslookup example.com。把example.com替换成你实际测试的域名，记录Server、Address和返回结果。
2. 确认系统解析路径：在PowerShell执行Resolve-DnsName example.com。如果结果中的服务器地址仍是路由器、局域网DNS或运营商DNS，而Mihomo日志没有同一时间的查询记录，说明系统请求可能没有进入Mihomo。
3. 检查本地监听：如果运行配置中的dns.listen是例如127.0.0.1:1053，可用nslookup example.com 127.0.0.1测试该监听；端口必须替换成你的实际值，不要照抄示例端口。
4. 对照Mihomo日志：先打开日志，再执行一次指定域名解析，记录精确时间。若日志出现该域名查询，同时系统命令返回正常，说明至少有一条请求进入Mihomo；若日志完全没有对应记录，优先检查配置是否生效、系统DNS是否指向本地监听，以及TUN是否真的运行。
5. 处理TUN旁路：确认dns-hijack、dns-mode和strict-route是否与当前客户端支持方式一致。修改前备份，改一个变量后重启客户端；若局域网、虚拟机或内网应用异常，恢复原配置再单独测试。

Windows的成功标准不是“某次检测站显示No leak”，而是连续几次查询均能在预期的Mihomo日志中出现，浏览器和目标应用也能正常解析。Mihomo文档还提示，严格路由可能影响某些应用，例如虚拟化软件，因此不要把它当成无条件的默认修复。

第三步：macOS用scutil、dig和Mihomo日志交叉验证

1. 查看系统当前解析器：打开终端执行scutil --dns。重点看当前活跃网络服务对应的 nameserver、resolver 顺序和作用域，不要只看系统设置页面。
2. 执行系统解析：运行dig example.com，记录SERVER、QUESTION SECTION和ANSWER SECTION。如果SERVER显示路由器或局域网地址，这只能说明这次查询由该解析器回答，仍需和Mihomo日志对照。
3. 直接测试Mihomo监听：如果运行配置显示Mihomo监听在本机某端口，可执行dig @127.0.0.1 -p 1053 example.com；将1053替换为实际监听端口。若直接查询失败，先处理Mihomo DNS监听或配置问题；若直接查询成功但普通dig仍走系统DNS，问题更可能在系统DNS接管或TUN实现。
4. 检查系统设置：Apple的网络设置路径是“系统设置→网络→当前网络服务→详细信息→DNS”，具体步骤可参考Apple的Mac DNS设置说明。把页面中的DNS服务器和scutil --dns输出一起记录。
5. 联合复测：先打开Mihomo日志，再执行一次dig example.com和一次浏览器访问。若浏览器能访问但日志无查询，可能存在浏览器独立DoH或应用自有解析路径；若系统和Mihomo都记录查询，检测站仍显示多个解析器，则需要继续考虑多上游、CDN或多出口，而不是立即判定为泄漏。

macOS上不要把“系统DNS页面没有显示Mihomo地址”直接等同于泄漏。TUN的dns-mode默认行为、客户端是否修改系统DNS，以及局域网DNS无法自动劫持，都会影响观察结果。

第四步：Android重点检查私人DNS、VPN状态和应用范围

1. 确认系统VPN状态：连接Mihomo后查看状态栏VPN图标或系统“设置→网络和互联网→VPN”中的活动连接。若没有活动VPN，Android应用通常不会经过该VPN接口。
2. 检查私人DNS：Android帮助页面提供的路径是“设置→网络和互联网→私人DNS”，选项包括关闭、自动和私人DNS提供商主机名；不同厂商菜单名称可能不同，可直接在设置中搜索“私人DNS”。Android官方说明指出，私人DNS只保护DNS问答，不会保护其他流量，且Mihomo文档明确说明开启私人DNS时无法自动劫持DNS。
3. 检查应用独立DNS：如果只有某个浏览器或应用异常，先查看该应用是否启用了安全DNS、专用DNS或独立网络设置。Android开发者文档说明，应用可以通过VPN接口配置自己的DNS服务器和路由，也可能被配置为绕过VPN，因此“系统VPN已连接”不代表所有应用路径完全相同。
4. 查看Mihomo日志：打开日志后，在同一应用中访问一个新域名，记录时间、域名和日志是否出现查询。如果应用有访问记录但Mihomo无对应DNS日志，优先检查应用排除列表、分应用路由和私人DNS。
5. 低风险复测：不要一开始关闭所有安全设置。只在定位阶段临时切换私人DNS模式，记录原值，测试后恢复原设置；如果切换后必须依赖某一模式才能联网，应把它视为兼容性现象，而不是直接认定为“泄漏已修复”。

Android系统设置会随版本和厂商变化。Google官方帮助建议在找不到“私人DNS”时使用设置搜索或咨询设备厂商，相关说明见Android高级网络设置。

第五步：浏览器DoH、IPv6和Fake-IP怎么分别判断

浏览器独立DoH：如果Windows或macOS的nslookup、dig与Mihomo日志一致，但浏览器检测结果不同，先检查浏览器的安全DNS或DoH设置。关闭后重新启动浏览器，再用同一域名复测。不要仅凭看到TCP 443或TCP 853就断定是DoH或DoT；需要结合浏览器设置、Mihomo日志和抓包中的目标地址与时间点。

IPv6旁路：分别测试A和AAAA记录，例如执行dig A example.com与dig AAAA example.com。如果只有AAAA路径异常，检查Mihomo的dns.ipv6、TUN是否配置IPv6，以及客户端是否把IPv6流量纳入路由。不要为了“看起来不泄漏”直接关闭IPv6；先确认目标网络和应用是否依赖IPv6，再记录原设置后调整。

Fake-IP不是自动防泄漏：Mihomo文档将fake-ip和redir-host定义为DNS处理模式；fake-ip-filter决定哪些域名不返回Fake-IP。NAS、打印机、局域网域名和部分游戏可能需要真实地址或局域网解析。出现局域网异常时，优先查看过滤规则和域名范围，逐项添加必要例外并复测，不要整段复制来源不明的过滤列表。

检测站结果还可能受缓存、CDN多解析器、多个上游DNS和不同出口影响。判断“是否泄漏”时至少满足三项：请求时间与Mihomo日志对应；系统或应用没有独立旁路；重启Mihomo和浏览器后连续测试仍保持相同路径。

一份可回滚的最短排查清单

1. 记录系统、客户端、内核版本和当前Profile；无法确认的版本不要按网上教程臆测。
2. 备份配置，固定设备、网络、节点、浏览器和测试域名。
3. 先查实际生效配置，不要只改订阅原文。
4. 分别核对dns.enable、dns.listen、dns.enhanced-mode、dns-hijack、dns-mode和strict-route。
5. 打开Mihomo日志，执行一次可复制的系统解析命令，并记录时间点。
6. 只改一个变量，重启客户端后重复同一测试。
7. 若局域网、NAS、打印机、虚拟机或应用异常，立即恢复原配置，再缩小变更范围。
8. 最后同时验证DNS日志、浏览器访问、目标应用和连续检测结果；不要只看一个检测站。

如果抓包工具显示UDP或TCP 53，最多说明存在相应端口流量；如果显示TCP 443或853，也不能单独证明使用了DoH或DoT。要确认协议，仍需结合配置、目标地址、TLS信息、日志和可重复的时间点。

常见问题

检测站显示了本地或运营商DNS，就一定是DNS泄漏吗？

不一定。是否属于泄漏取决于你的网络设计目标：有些配置本来就允许直连DNS、局域网DNS或按规则使用不同上游。先确认请求是否绕过了预期的Mihomo路径，再判断是否需要调整。

Fake-IP开启后还会DNS泄漏吗？

可能。Fake-IP只描述Mihomo的DNS处理方式，不负责自动接管浏览器独立DoH、Android私人DNS或未纳入TUN路由的应用。应结合日志和系统命令确认请求路径。

为什么Mihomo日志里有DNS请求，但检测站仍显示多个解析器？

可能是配置使用了多个上游、检测站分多次查询、CDN返回不同解析器，或设备存在多个网络出口。固定测试条件并连续复测；如果每次请求都进入预期日志，不能仅凭解析器数量下结论。

Windows和macOS为什么不能自动接管局域网DNS？

Mihomo官方TUN文档明确列出这一限制。它属于内核与系统网络路径的边界，不等同于客户端一定配置错误。局域网DNS场景需要结合系统设置、TUN状态、路由和实际日志验证。

Android应该关闭私人DNS吗？

不应把关闭私人DNS作为永久默认方案。Android官方建议保持私人DNS开启；排查时可以临时切换并记录原设置，用于判断它是否绕过了当前Mihomo的DNS劫持，测试完成后按安全需求恢复。

修改配置后无法上网，怎么恢复？

停止客户端，恢复修改前备份的Profile或覆写文件，确认当前选中的配置已切回原版本，再启动客户端。若问题只在TUN开启时出现，可先关闭TUN验证代理端口是否仍正常，再逐项恢复设置。

常见问题

检测站显示本地DNS，就一定是DNS泄漏吗？

不一定。先确认你的设计目标，再检查请求是否绕过了预期的Mihomo路径；解析器数量或归属本身不能单独定性。

Mihomo的dns-mode和enhanced-mode有什么区别？

dns-mode是TUN配置项，用于决定系统DNS配置方式；enhanced-mode是DNS模块的处理模式，可选fake-ip或redir-host，两者不应混写。

为什么Android连接VPN后仍可能出现DNS旁路？

Android的私人DNS、应用独立DNS、应用排除列表和客户端VPN实现都可能改变请求路径。Mihomo文档明确说明，开启私人DNS时无法自动劫持DNS。

如何判断浏览器DoH是否绕过Mihomo？

先让系统命令和Mihomo日志建立基线，再检查浏览器安全DNS设置；若只有浏览器结果不同，临时关闭独立DNS并重启浏览器复测。

Fake-IP是否等于不会DNS泄漏？

不是。Fake-IP是Mihomo的DNS处理模式，不能自动接管浏览器DoH、Android私人DNS或未纳入TUN路由的应用。

相关阅读

• Mihomo连接成功但无法上网的排查步骤
• 按现象整理的连接问题排查
• VPN配置问题的通用判断方法

参考资料

1. Mihomo DNS configuration
2. Mihomo TUN configuration
3. Mihomo inbound configuration
4. Google Android Help：Manage advanced network settings
5. Android Developers：VpnService.Builder
6. Apple Support：Change DNS settings on Mac