客户端指南

DNS 泄漏是什么意思？检测页显示多个 DNS 就一定有问题吗

DNS 泄漏通常指本应走受控解析路径的查询被其他解析器看到。检测页只能观察它收到的测试查询，多个服务器也可能是转发、负载均衡或浏览器 DoH。

发布于 2026/8/8 · 更新于 2026/8/8 · 5 项可核验来源

先看重点DNS 泄漏不是“DNS 数量多”，而是查询离开了你预期的解析边界。例如你要求全部 DNS 进入代理内核，却仍由本地网络解析器处理。检测页只能证明测试域名最终从哪些递归解析器到达，不能证明所有 App、所有时间都相同，也不能仅凭运营商名称断定泄漏。

DNS 查询会暴露“哪个域名需要被解析”以及时间关系。RFC 7626 对这种隐私风险有专门分析。但“泄漏”不是看到一个陌生 DNS 名称就成立，它必须相对于你的预期边界判断。

如果你只是正常使用家庭路由器 DNS，那么请求被运营商或公共递归解析器处理是当前设计，不叫绕过。只有你已要求浏览器、系统或 TUN 把查询交给指定解析路径，而部分查询仍去了路径之外，才符合常说的 DNS 泄漏。

先写清楚你预期谁来解析

常见目标有三种：

使用本地网络 DNS，代理只处理应用流量；
所有被接管应用的 DNS 都进入 Mihomo，再由指定 nameserver 解析；
浏览器单独使用某个 DoH，其他程序仍走系统 DNS。

这三种设计都可能正常，却会在检测页看到不同结果。没有先定义目标，就无法用“通过/失败”判断。

检测页实际能看到什么

DNS 检测站通常生成一组唯一子域名，并观察哪些递归解析器替你查询它们。它能证明这次浏览器测试触发的查询到达了某些出口，但存在边界：

解析服务可能使用多个出口或 Anycast 地址；
路由器、企业网关和上游解析器可能逐级转发；
浏览器 DoH 可能与系统 DNS 使用不同路径；
缓存命中时，某些查询根本不会再次到达测试站；
结果不覆盖后台 App、命令行和稍后的网络切换。

所以“出现两个 DNS”不是自动失败，“只出现一个”也不是整机零泄漏证明。

用日志和单变量对照确认

先关闭浏览器的安全 DNS/DoH，只保留系统或 Mihomo 一条路径，重新打开浏览器并测试；再单独开启浏览器 DoH 做第二次。与此同时查看客户端 DNS 和连接日志。

如果开启浏览器 DoH 后结果变成你选择的公共解析商，这更像浏览器按设置直连 DoH，而不是机场节点偷偷泄漏。具体处理见浏览器安全 DNS 与代理路径。

使用 TUN 时还要确认 dns-hijack 是否接住目标查询。Mihomo 文档明确指出，macOS/Windows 不能自动劫持发往局域网的 DNS，请求在 Android 开启私人 DNS 时也不能被普通 DNS 劫持自动接住；strict-route 在 Windows 可针对普通多宿主 DNS 行为增加约束，但也可能影响虚拟机等软件。

DoH 解决的是加密，不自动等于走代理

RFC 8484 定义了通过 HTTPS 发送 DNS 查询。它能减少本地网络直接看到明文 DNS 的机会，但查询最终仍由选定的 DoH 服务处理。若浏览器直接连接该服务，代理客户端未必能在自己的 DNS 模块里看到域名。

因此要分别问：

查询在本地链路上是否加密；
查询发给了哪个解析器；
到解析器的 HTTPS 连接是否由代理接管；
解析结果对应的业务连接走了哪条出口。

四个问题不能用一张检测截图代替。

什么结果才值得修复

明确要求所有查询进入 TUN，但抓到系统 DNS 在物理网卡直连；
关闭浏览器 DoH 后仍有应用绕过预期解析器；
切换网络后，旧网卡 DNS 继续被使用；
DNS 结果与路由规则长期不一致，造成错误直连或定位异常。

修复应落在真正绕过的一层：浏览器 DoH、Android 私人 DNS、TUN 路由、系统多网卡或某个 App 自带解析。不要为了让检测页只显示一个名字，随意关闭安全功能或填写来历不明的 DNS。

资料来源

以下来源于 2026/8/8 复核。版本、支持平台和发布状态以后续官方页面为准。

持续更新

收到新教程，也欢迎纠错

想收到新文章，可以关注 TG 频道；发现下载失效、套餐变化或步骤不一致，请附上页面链接和可公开的截图。不要发送订阅链接、密码或完整账户信息。

关注 TG 频道 Telegram 纠错邮件纠错

读者互动

这篇内容对你有帮助吗？

— 次访问— 累计日独立访问— 条评论

直接说出你的问题