Mihomo DNS泄漏怎么处理？按路径定位并复测
简答：如果 DNS 检测显示了本地运营商、路由器或非预期解析器，先确认 Mihomo 当前是系统代理还是 TUN 模式，再检查 dns.enable、tun.dns-hijack、enhanced-mode 和浏览器或系统的加密 DNS。最稳妥的处理顺序是：备份配置→只开启一条 DNS 接管路径→重启 Mihomo 与应用→复测解析器和实际查询路径。
定义：Mihomo DNS 泄漏，是指域名查询没有按预期进入 Mihomo 的 DNS 模块或指定上游，而是被系统、浏览器、应用、IPv6 或局域网 DNS 直接处理。
先试这一步：确认你到底在用哪条 DNS 路径
不要一开始就同时修改 Fake-IP、DNS 上游、TUN、IPv6 和浏览器设置。先打开 Mihomo 当前配置或客户端状态页，记录三项：是否开启 tun.enable、是否有 dns.enable: true、当前使用的是系统代理还是 TUN。Mihomo 官方文档将 fake-ip 与 redir-host列为两种 DNS 增强模式，并说明 TUN 可用于自动路由和 DNS 劫持。查看 Mihomo DNS 配置说明 查看 Mihomo TUN 配置说明
| 检测或现象 | 优先怀疑 | 先做什么 |
|---|---|---|
| 代理网页能打开，但检测显示本地解析器 | 浏览器 Secure DNS、系统 DNS 或应用内 DoH 绕过 Mihomo | 临时关闭浏览器自定义 Secure DNS，重启浏览器后复测 |
| 系统代理模式正常，TUN 模式才出现异常 | dns-hijack、strict-route 或 TUN 权限没有生效 | 先回到系统代理验证，再单独启用 TUN 和 DNS 劫持 |
| Windows 或 macOS 仍显示局域网 DNS | 系统发往局域网的 DNS 请求未被自动劫持 | 查看 Mihomo 日志；不要把端口监听误认为已经接管系统 DNS |
| Android 开启 TUN 后仍有旁路 | Private DNS、应用内 DNS 或 IPv6 路径 | 暂时将 Private DNS 设为 Automatic 或按场景关闭，再重启应用复测 |
| 改成 Fake-IP 后个别局域网应用失效 | 需要真实地址的域名没有加入过滤列表 | 只为具体域名增加 fake-ip-filter，不要使用过大的通配符 |
在线检测页面显示的解析器只能说明某次查询结果，不等于所有应用、IPv4、IPv6 和浏览器请求都走了同一条路径。验收时至少要分别检查：域名能否打开、Mihomo 日志是否出现查询、检测结果中的 resolver 是否符合预期。
最小改动排查顺序：备份、单变量、回滚
- 备份：复制当前 YAML 或导出客户端配置，保留原文件名和时间。不要直接覆盖唯一配置。
- 建立基线：先关闭 TUN，仅保留系统代理，测试一个普通域名和一个原本显示泄漏的域名。
- 检查内置 DNS：确认
dns.enable没有被设为false。官方说明指出，关闭该字段后会使用系统 DNS。Mihomo DNS 官方字段说明 - 检查接管入口：启用 TUN 时，确认配置中有适合当前系统的
dns-hijack，并检查权限、auto-route和必要时的strict-route。 - 一次只改一个变量：先改浏览器 Secure DNS，仍异常再改 TUN；不要同时更换上游、Fake-IP 和 IPv6，否则无法判断是哪项变化起作用。
- 重载并重启：重载配置后，完全退出并重新打开浏览器或应用，清理该应用的 DNS 缓存，再进行同一条件下的复测。
如果改动后无法联网，立即恢复备份配置，关闭 TUN，回到系统代理模式。恢复连通后，再逐项开启功能。不要把“端口能监听”或“网页能打开”单独当作 DNS 已经接管的证明。
Mihomo 基础 DNS 配置：先用可核对的字段
下面是用于字段核对的基础示例，不是适用于所有网络的完整成品配置。上游地址、分流策略、代理组名称和局域网需求应按你的环境替换；如果你的客户端不支持某字段，应以该客户端内置 Mihomo 版本对应的文档为准。
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
fake-ip-range: 198.18.0.1/16
fake-ip-filter-mode: blacklist
fake-ip-filter:
- '*.lan'
- '*.local'
- 'time.windows.com'
- 'stun.l.google.com'
nameserver:
- https://doh.pub/dns-query
fallback:
- tls://1.1.1.1
proxy-server-nameserver:
- https://doh.pub/dns-query官方文档说明，fake-ip-filter支持域名通配和域名集合；但排障时建议先写具体域名，避免把大范围规则误当成修复方案。局域网域名是否需要真实解析，应根据实际使用情况逐条添加。fake-ip-range是 Fake-IP 地址段，不是远端节点地址，也不能据此判断 DNS 查询已经通过代理。
如果你不需要 Fake-IP，或者某个应用与 Fake-IP 不兼容，可以只把 enhanced-mode 改为 redir-host 做对照测试。切换后要重启相关应用并清理缓存；如果问题随模式切换消失，说明故障可能与应用对虚拟地址的处理有关，而不能直接归因于“DNS 上游泄漏”。
TUN 模式下重点检查 dns-hijack 与 strict-route
启用 TUN 后，重点不是盲目增加 DNS 地址，而是确认 DNS 请求是否真正进入 Mihomo。官方文档将 dns-mode区分为 disabled、native 和 hijack；其中 hijack会进一步拦截发往其他接口 53 端口的请求，但文档也明确提示：Windows 和 macOS 无法自动劫持发往局域网的 DNS 请求，Android 开启 Private DNS 时也无法自动劫持。TUN 的 DNS 劫持限制
tun:
enable: true
auto-route: true
auto-detect-interface: true
strict-route: true
dns-hijack:
- any:53
- tcp://any:53这段配置只表示要尝试接管 53 端口，不代表所有应用的 DNS 都会被拦截。Windows 上的 strict-route可用于减少系统多网卡 DNS 旁路，但官方同时提示它可能影响部分虚拟机或特殊网络软件，因此启用后应立即验证办公 VPN、虚拟机和局域网访问，异常时恢复为原配置。
如果 macOS 或 Windows 的系统解析器仍绕过 Mihomo，先不要继续扩大 fake-ip-filter。可暂时关闭 TUN，使用系统代理验证 Mihomo 基础 DNS，再查看系统 DNS 设置、浏览器 Secure DNS 和客户端日志。macOS 的系统解析器行为还可能受系统版本和网络接口影响，无法仅凭 YAML 字段推导出必然结果。
浏览器、Windows 与 Android 的旁路检查
浏览器 Secure DNS 或应用内 DoH
Chrome 官方说明，Secure DNS 开启后会加密 DNS 查询；自定义提供商不会按普通模式自动回落到未加密查询。排查时进入 Chrome 设置中的“隐私和安全”→“安全”→“使用安全 DNS”，先暂时关闭或改回系统提供商，再完全重启 Chrome。Chrome 官方 Secure DNS 说明如果关闭后检测结果恢复正常，说明浏览器原先可能使用了独立 DNS 路径；这不等于 Mihomo 配置本身一定错误。
Windows DNS over HTTPS 与 IPv6
Windows 的网络设置可以为 DNS 指定加密或未加密方式，并提供是否允许失败后回落到明文的选项。排查时记录当前 DNS 服务器、DoH 状态和 IPv6 状态；一次只关闭其中一个变量，然后重启网络连接再测试。Microsoft Windows 网络设置说明
Android Private DNS
Android 官方帮助显示，Private DNS 位于“设置”→“网络和互联网”→“私人 DNS”，可选择关闭、自动或指定提供商主机名；该功能只保护 DNS 问答，不会覆盖其他网络流量。排查 Mihomo TUN 时，如果 Private DNS 与 Mihomo 同时接管，先记录原设置，再临时切换到“自动”进行对照测试，完成后根据需要恢复。Android 官方 Private DNS 说明
如何确认修复，而不是只看检测站变绿
- 固定条件：保持同一网络、同一节点、同一浏览器和同一域名，避免切换 Wi-Fi、移动网络或代理组。
- 看 Mihomo 日志：访问测试域名时，确认是否出现 DNS 查询或对应的连接记录；如果日志完全没有相关请求，优先检查应用是否绕过系统代理或使用独立 DoH。
- 检查系统命令：Windows 可用
nslookup example.com观察系统当前解析器；macOS 或 Linux 可用dig example.com。这些命令默认测试系统解析路径，不等于一定经过代理，因此只能作为旁证。 - 复测多个场景：分别测试浏览器、目标应用和一个局域网域名。浏览器正常不代表应用内 DNS 正常，外网域名正常也不代表局域网解析应当使用 Fake-IP。
- 检查 IPv6：如果关闭 IPv6 后异常消失，说明需要继续检查 IPv6 路由、TUN 接管和应用是否走独立 IPv6 DNS；不要仅凭这一现象断定是某个 DNS 地址导致泄漏。
更可靠的验收标准是三项同时满足：预期应用可以正常连接；Mihomo 日志或抓包能够证明查询进入预期路径；重复测试时解析器结果保持一致。若只满足其中一项，应标记为“部分修复”，继续定位旁路。
常见问题
1. DNSLeakTest 显示本地解析器，但网页访问正常，算不算泄漏？
从排查角度看，这表示至少有一次 DNS 查询使用了你未预期的解析器，但不能仅凭检测页面判断所有流量都泄漏。先关闭浏览器 Secure DNS，确认当前是系统代理还是 TUN，再查看 Mihomo 日志；网页能打开只能证明该次连接成功，不能证明 DNS 路径符合预期。
2. Fake-IP 能不能直接解决 Mihomo DNS 泄漏？
不能直接这样判断。Fake-IP 是 Mihomo 的 DNS 处理模式，不等于所有应用查询都会自动进入 Mihomo。若浏览器、应用或系统使用独立 DoH、Private DNS 或 IPv6 旁路，仍可能绕过。应先确认接管入口，再比较 fake-ip 与 redir-host。
3. 为什么开启 TUN 后反而不能联网？
常见原因包括 TUN 权限不足、strict-route影响特殊网络、DNS 劫持与系统 Private DNS 冲突，或配置中的接口和地址不适合当前系统。先关闭 TUN 恢复系统代理，确认基础连接，再只启用 TUN、重启并查看日志；不要同时改 DNS、MTU 和路由。
4. fake-ip-filter 应该写哪些域名？
先写确实需要真实地址的具体域名，例如局域网后缀或某个时间同步、连通性检测域名。不要直接添加过大的 stun.*.* 等泛化规则；每增加一条都要验证对应应用是否恢复，并保留删除该条的回滚方式。
5. 关闭 Android Private DNS 后一定能修好吗？
不一定。它只是排除一个可能的 DNS 接管者。若仍异常，还要检查 Mihomo 的 TUN 权限、dns-hijack、应用内 DNS 和 IPv6。修复后应在同一网络条件下重新启动 Mihomo 和目标应用，再重复检测。
本文是 96110.buzz 本地视觉备份整理的第三方使用指南，不代表任何客户端或品牌官方。配置字段和菜单会随客户端内置 Mihomo 版本变化，实际操作前请以对应版本文档和页面显示为准。
推荐：如果你已确认是线路或跨境办公连接问题，可了解边界云加速的相关办公网络方案，再根据自己的系统和客户端逐项核验。
常见问题
DNSLeakTest 显示本地解析器，但网页访问正常，算不算泄漏？
这说明至少有一次查询使用了未预期的解析器，但不能代表所有流量都如此。先检查浏览器 Secure DNS、应用内 DoH、系统代理与 TUN，再看 Mihomo 日志。
Fake-IP 能直接解决 Mihomo DNS 泄漏吗？
不能直接保证。Fake-IP 只是 DNS 处理模式，浏览器、应用、Private DNS 或 IPv6 仍可能绕过 Mihomo。
开启 TUN 后不能联网怎么办？
先关闭 TUN 恢复系统代理，确认基础连接，再单独启用 TUN、dns-hijack 和 strict-route，并逐项查看日志和权限。
fake-ip-filter 应该写哪些域名？
优先写具体局域网、时间同步或连通性检测域名，避免直接使用过大的通配符；每条规则都应可单独删除和复测。