糖果云 Mihomo DNS 泄漏怎么排查？
简答：如果 DNS 泄漏测试显示本地运营商、路由器或未预期的解析器，先不要直接改一整份配置：关闭糖果云或 Mihomo 测一次作为基线，再开启 Mihomo 与 TUN 复测。随后检查最终生效配置中的 <code>dns.enable</code>、<code>tun.enable</code>、<code>dns-hijack</code>、Fake-IP 和浏览器或系统自己的安全 DNS。本文只处理已导入订阅后的 Mihomo DNS 泄漏定位，不覆盖订阅购买、服务状态和从零部署。
定义：DNS 泄漏是指应用或系统的域名查询没有按预期进入 Mihomo 的 DNS 处理路径，而是由本地网络、系统解析器、浏览器 DoH、IPv6 或其他 DNS 通道完成。
先看速查表：不同结果对应什么方向
DNS 泄漏检测页面出现多个解析器，不一定就等于泄漏。重点是比较关闭 Mihomo、仅开启系统代理、开启 TUN，以及关闭浏览器或系统独立 DNS 后的结果是否发生变化。Mihomo 官方文档明确区分了内置 DNS、Fake-IP、nameserver-policy、proxy-server-nameserver 和 TUN 的 dns-hijack 等配置项，可先从最终生效配置核对，而不是只看订阅原文。
| 现象 | 可能的排查方向 | 先做什么 |
|---|---|---|
| 关闭 Mihomo 与开启 Mihomo 显示相同解析器 | 当前流量可能没有经过 TUN，或测试页面由浏览器独立解析 | 确认 TUN 是否真正启动，再临时关闭浏览器安全 DNS |
| 开启 TUN 后仍显示本地网络解析器 | dns-hijack 未生效、系统 DNS 未被接管，或存在 IPv6 旁路 | 核对 tun.enable、dns.enable、dns-hijack 和 IPv6 设置 |
| 只在 Chrome 中出现异常 | Chrome 可能使用自己的 Secure DNS | 在 Chrome 的隐私与安全设置中检查 Use secure DNS |
| DNS 查询能返回结果，但网页打不开 | 可能是 Fake-IP、规则、路由或节点连接问题，不等于 DNS 泄漏 | 查看 Mihomo 日志和规则命中，不要只根据测试页面下结论 |
| Android 开启 Mihomo 后结果与桌面不同 | Android Private DNS、其他 VPN 或应用自身解析可能改变路径 | 检查系统 Private DNS，并确认没有同时运行其他 VPN |
停止条件：如果关闭 Mihomo 和开启 Mihomo 的检测结果完全一致，先不要继续添加 fallback 或更换大量 DNS 服务器，应优先确认当前测试流量是否经过 Mihomo。
第一步：建立关闭与开启的 DNS 基线
- 记录测试条件。记下设备系统、网络类型、Mihomo 前端名称、内核版本，以及检测页面显示的解析器名称。不要把一次测试结果当作长期可用性或绝对隐私结论。
- 关闭 Mihomo。退出代理或关闭 TUN，保持同一网络、同一浏览器和同一测试页面，完成一次标准测试。这个结果只代表当前网络下的基线。
- 开启 Mihomo 但先不改配置。确认订阅配置已激活，再开启系统代理或 TUN，重新测试。Mihomo 官方文档中，
dns.enable: false时会使用系统 DNS；因此不能只看客户端显示“已连接”，还要确认 DNS 模块是否启用。 - 进行第二站交叉测试。两个检测页面结果不完全一致并不自动证明泄漏。应重点比较解析器所属网络、是否出现本地运营商解析器，以及开启或关闭 Mihomo 后是否稳定变化。
验证边界：检测页面只能观察某次网页访问产生的解析结果，不能证明所有应用、所有域名和所有网络都使用同一 DNS 路径。修复后仍需重启客户端、清理缓存并在另一个网络复测。
可参考 Mihomo 官方 DNS 配置说明，其中列出了 enable、enhanced-mode、fake-ip-filter、nameserver-policy 和多类 nameserver 字段的作用。
第二步：在 Mihomo 最终配置中核对 6 个字段
糖果云订阅通常只是输入来源，前端的覆写配置、当前激活配置和 Mihomo 内核最终读取的配置可能不是同一份。请优先查看客户端提供的“配置编辑”“覆写”“当前配置”或类似入口；不同前端菜单名称可能不同，未核实的菜单不要照抄。
dns.enable：应确认是否为启用状态。官方文档说明，关闭时使用系统 DNS。tun.enable：如果你依赖 TUN 接管未设置系统代理的应用，应确认 TUN 已启动，而不是只看到代理端口正在监听。dns-hijack：这是 TUN 配置中的 DNS 劫持入口。常见配置会包含any:53，有些配置还会处理 TCP 53；是否适合你的系统，要以当前前端和内核支持情况为准。enhanced-mode：确认使用的是fake-ip还是redir-host。Fake-IP 返回特殊地址并不等于 DNS 泄漏，需要结合 Mihomo 日志和网页访问结果判断。fake-ip-filter：局域网、内网域名或特殊应用可能需要排除 Fake-IP。不要为了“看起来更干净”直接删除全部过滤项。nameserver-policy、proxy-server-nameserver、direct-nameserver：这些字段可能让不同域名或不同连接阶段使用不同解析路径。只改其中一个字段，然后重载配置并复测。
建议先复制保存当前配置，再只做一项变更。Mihomo 官方 DNS 示例同时展示了 nameserver、fallback、proxy-server-nameserver 和 direct-nameserver，这些字段不是同义项，不能简单合并或互换。
停止条件：如果修改后 Mihomo 启动失败、DNS 超时或所有网页都打不开，立即恢复备份配置。不要在没有日志证据时继续叠加 Fake-IP、策略组和自定义规则。
第三步：排除 TUN、IPv6 和应用自带 DNS 旁路
Mihomo 官方 TUN 文档将 auto-route、auto-redirect、auto-detect-interface、dns-mode 和 dns-hijack 分开列出。也就是说，TUN 已创建、代理端口可访问，并不自动等于所有 DNS 查询都已被接管。
- 确认 TUN 状态。在客户端界面查看 TUN 是否为运行状态，并观察日志中是否有启动失败、权限不足、网卡创建失败或路由设置失败。没有日志证据时，不要把“开关已打开”当作“接管已生效”。
- 检查 IPv6。如果 IPv4 通过 Mihomo，而 IPv6 仍由系统或路由器处理，测试结果可能出现分叉。可以先记录当前 IPv6 状态，在同一设备上临时关闭 IPv6 做对照；这是定位变量，不是对所有网络的长期建议。
- 检查浏览器 DoH。Chrome 官方说明，Secure DNS 开启后，Chrome 会加密 DNS 查询，并允许用户选择服务商。进入 Chrome 的设置、隐私和安全、安全设置，检查“使用安全 DNS”。排查阶段可暂时关闭，复测后再决定是否恢复。
- 检查 Android Private DNS。Android 系统设置中的 Private DNS 可能影响应用的 DNS 路径。Google 的 Android 帮助页给出的入口是“设置→网络和互联网→Private DNS”；如果找不到，可直接在系统设置搜索。不要同时运行多个 VPN 或网络过滤工具，否则结果难以归因。
如果关闭浏览器 Secure DNS 后结果改变，问题可能是浏览器自己的解析通道；如果关闭 IPv6 后结果改变，IPv6 路径应作为重点排查方向。上述现象只能说明路径发生变化，不能单凭一次结果认定服务商或节点存在问题。
第四步：用日志和系统查询确认“谁在回答 DNS”
在 Windows 上，可以使用 Microsoft 文档中的 nslookup 检查默认解析器或指定解析器。例如：
nslookup example.com
命令输出中的 Server、Address、超时或 No response 信息，可帮助确认系统当前调用的解析器。Microsoft 对 nslookup 的说明指出，省略第二个参数时会使用默认 DNS 服务器；因此它适合做系统层面的对照，但不等于直接证明浏览器或 Mihomo 内部使用的上游。
在 Mihomo 日志中，重点观察以下可核对信息：
- DNS 模块是否启动，是否出现配置解析失败；
- 查询是否命中 Fake-IP 或过滤规则；
- 上游解析请求是否超时、被拒绝或反复重试；
- TUN、路由和 DNS 劫持是否出现启动或恢复失败。
如果系统查询显示本地路由器，而 Mihomo 日志能看到对应域名查询，可能是检测工具、浏览器或系统缓存造成的差异；如果系统查询、浏览器测试和 Mihomo 日志都没有出现 DNS 请求，则应先确认流量是否真正经过该客户端。
验证边界：端口监听只能说明某个进程在监听端口，不能证明请求经过正确的规则；网页能打开也不能证明没有 DNS 旁路。诊断时要把“进程在运行”“DNS 有响应”“网页可用”分别记录。
Windows 的 nslookup 官方说明提供了默认服务器、指定服务器和调试输出的用法；可用于补充客户端日志，而不是替代日志。
第五步：清缓存、回滚并完成复测
- 保存结果。记录关闭 Mihomo、开启 Mihomo、关闭浏览器 Secure DNS、临时关闭 IPv6 四组结果，避免凭记忆判断。
- 清理缓存。重启 Mihomo，关闭并重新打开浏览器；必要时按系统提供的方式刷新 DNS 缓存。不要因为缓存未更新就重复修改配置。
- 恢复最小配置。如果问题来自多层覆写，先保留订阅和最少的 DNS/TUN 设置，再逐项恢复
nameserver-policy、Fake-IP 过滤和自定义规则。 - 复测多个应用。至少分别测试浏览器和一个不依赖浏览器代理设置的应用；若只浏览器正常而其他应用异常，应继续检查 TUN 和系统路由。
- 更换网络复测。在另一 Wi-Fi 或移动网络下重复测试。不同网络可能提供不同的系统 DNS、IPv6 和路由条件。
最终结论应写成“在某设备、某网络、某客户端设置下，测试结果显示……”，不要写成永久无泄漏、所有应用都已接管或节点一定可用。若只改变浏览器设置就恢复，优先保留浏览器旁路作为定位结果；若只有开启 TUN 后恢复，重点记录 TUN 和 dns-hijack 的最终配置。
与糖果云订阅相关的核验边界
本文是使用指南，不是 Candytally（糖果云）官方页面，也不提供其官网入口、价格、节点状态或当前可用性判断。对于订阅内容、客户端版本和前端菜单，以当前服务页面和客户端实际显示为准；无法从公开资料核实的品牌能力，本文不作结论。
如果 DNS 泄漏测试异常，但 Mihomo 日志、系统查询和浏览器测试结果互相矛盾，优先把问题拆成三个层次：订阅或节点连接、Mihomo 内核 DNS、操作系统或应用自身 DNS。不要把 DNS 解析器归属直接等同于节点质量，也不要用单次测试推断长期性能。
常见问题
DNS 泄漏测试显示多个 DNS，就一定是泄漏吗？
不一定。多个解析器可能来自备用 DNS、不同网络路径或检测页面的多次请求。应先比较关闭 Mihomo和开启 Mihomo后的结果，再结合解析器归属、Mihomo日志、浏览器 Secure DNS、IPv6和系统 Private DNS判断。
Mihomo 已经开启 TUN，为什么还会显示本地 DNS？
可能是 TUN 没有真正启动、dns-hijack未生效、IPv6绕过，或浏览器和系统使用了独立的加密 DNS。先查看客户端日志和最终配置，不要只看 TUN 开关状态。
Fake-IP 返回 198.18.0.0/16 是不是 DNS 泄漏？
不能单独这样判断。Fake-IP 是 Mihomo 的一种增强 DNS 模式，特殊地址需要结合 Fake-IP 映射、日志、规则命中和实际连接结果判断。若网页访问正常但测试页面显示特殊地址，不应直接把它判定为泄漏。
Windows 上用 nslookup 能直接证明 Mihomo 没有 DNS 泄漏吗？
不能。nslookup主要反映系统层面的默认或指定解析器，浏览器 DoH、应用自带 DNS 和 Mihomo 内部解析可能不同。它适合做对照，应与客户端日志和浏览器测试一起使用。
排查时可以直接把 fallback、nameserver 和 Fake-IP 全部改掉吗？
不建议。一次改多个变量会失去对照。先备份当前配置，只修改一个字段，重载后观察日志和测试结果；如果启动失败或网页全部打不开，立即恢复备份。