开启 3 天免费试用
注册即可免费体验全部高级功能。
*仅限新用户；每位用户只能获得一次试用。
什么是 DNS 泄露？逐项检测、解释结果并修复查询路径
Ryan Foster
2026年10月5日· 7 分钟阅读
DNS 泄露是域名查询走了你原本希望保护范围之外的路径。判断 DNS 泄露，要把预期策略与观察到的请求对照；仅凭解析器名称或国家不同，不能证明查询绕过 VPN。
关键要点：
- 解析器身份、查询路径、DNS 加密是三个不同问题。
- 用同一设备和浏览器比较断开与连接后的结果。
- 浏览器安全 DNS 可以使用另一个解析器，同时仍经隧道传送。
- 每次只改一个设置，失败就恢复，并重测 DNS 和正常浏览。
DNS 泄露说明了哪条查询路径？
DNS 把域名转换为应用建立连接所需的信息。系统可能向路由器、网络提供的解析器或手动指定服务发请求，浏览器也可能自己选择解析器。关键是这些请求相对于你想执行的策略，实际走哪条路径。
VPN 出口地址表明某次连接从哪里到达网站，却不能识别设备上的每个 DNS 请求。双栈路由和其它接口可能提供绕过隧道的路径，因此网页能打开，不足以证明完整覆盖。［1］
图中把经 VPN 的查询与直接经接入网络的查询分开。这是通用路由模型，不是某家服务的抓包，也不证明你的设备正在使用其中任一路径。应对照有效配置和实际观察，再判断模型是否适用。
| 问题 | 有用证据 | 单凭它不能证明什么 |
|---|---|---|
| 谁回答了查询？ | 解析器运营方或观察到的服务器地址 | 设备端查询实际经过的路由 |
| 查询去了哪里？ | 获准的路由检查或抓包 | 解析器是否保存日志 |
| DNS 是否加密？ | 已说明的 DoH 或其它安全 DNS 配置 | 流量一定使用 VPN |
| 网页是否连接成功？ | 出口地址和请求完成 | 所有查询、应用都受覆盖 |
做 DNS 泄露检测前需要准备什么？
写出你希望的策略，例如本次浏览全部经 VPN；企业受管理环境也可能有意让内部域名走另一套解析。记录设备、系统、VPN 应用版本、浏览器版本、活动网卡和浏览器安全 DNS 设置。主动设置的例外需要评估，但不能直接叫作意外泄露。
只修改你有权管理的网络或设备。工作设备先问管理员内部域名和解析器要求；换掉企业 DNS 可能破坏访问而没有提升隐私。先关闭敏感任务，保存原始设置，再开始排查。
选能够解释测量对象、能产生新查询名的诊断工具。缓存可能让新查询根本不发生，干扰对照。普通检测通常观察到联系其权威服务器的递归解析器，不是从笔记本发出的完整查询路径抓包。
怎样比较 VPN 连接与 DNS 结果？
- 保存基线。 在可信网络断开 VPN，用同一浏览器记录安全 DNS 模式及检测的解析器结果。查看当前出口地址，记录时间和网络。分享记录时不要公开完整地址。
- 建立连接后对照。 用 AethoVPN 做对照时，在应用里选择当前可用位置，连接并再次核对出口，再重复 DNS 观察。这只建立网页请求的 VPN 连接参考，不能证明所有 DNS 查询经过同一路径。iPhone、iPad、Mac 的配置需要 Pro 或 Premium。［3］需要建立此对照时，可用邮箱开始 3 天 Pro 试用，每位用户仅一次。［3］
- 重复新查询。 保持网络和浏览器不变，使用同一个检测工具建立新的测试会话。保存解析器运营方、地址、时间和不确定提示。工具报错时重试，不能把空列表算通过。
- 对照浏览器与系统配置。 查浏览器是否设置安全 DNS、系统是否手动指定解析器，以及是否存在其它活动网卡或代理。先记录差异再修改。浏览器可以不用系统解析器，但其 HTTPS DNS 连接仍可能经隧道。［2］
- 验证可疑路径。 结果与预期不符时，查 VPN 文档或向支持咨询。在自己的设备做获准的路由检查或抓包可增强证据；解析器国家标签不能替代它。不要抓取他人流量，也不要公开原始日志。
- 窄修复并重测。 按文档恢复非预期的手动设置，或使浏览器 DNS 符合实际需要的策略。文档要求时重启相应应用，重复原来的观察。内部资源失效或原因仍不清楚，就恢复原值并升级求助。
需要扩大到整体连接健康度时，使用完整 VPN 检测流程。它可以补充 DNS 专项对照，却不能把解析器列表变成所有路径都正常的证明。
DNS 泄露检测结果应该怎样解释？
预期由 VPN 控制解析，却仍看到接入运营商解析器，尤其是连接后新查询继续用它，值得调查，但不能单独定案。服务可能主动采用外部解析器，浏览器也可能有独立安全 DNS 端点。对照说明和实际路由证据。
大型公共 DNS 服务不是天然安全或危险；同一运营方可能经隧道抵达，也可能直连。多个解析器地址可能是负载均衡，也可能是不同路径。没有上下文，不能给出确定原因。
| 观察 | 可能解释 | 后续动作 |
|---|---|---|
| 前后同一解析器 | 主动外部解析、浏览器 DNS 或旁路 | 核对策略并检查实际路由 |
| 连接后换了解析器 | 配置变化或采用 VPN 解析 | 确认路径，不能推断整个设备覆盖 |
| 解析器国家不同 | 基础设施位置或地理数据库 | 关注运营方和策略，不看国旗下结论 |
| 没返回解析器 | 工具报错、缓存、过滤或没有新查询 | 重新生成查询，并验证正常浏览 |
| 浏览器与其它应用不同 | 独立 DNS 设置或应用路径 | 分开测实际需要的应用 |
DNS 泄露检测是诊断输入，不是二元隐私认证。可记录“路径已确认”“策略不符”或“路径不确定”，同时写明证据。对一种主动策略可接受的结果，对另一种策略可能不合适。
怎样修复 DNS 泄露而不破坏网络？
先从可以解释的配置开始。查旧手动解析器、残留 VPN 网卡设置、第二个活动 VPN，以及浏览器覆盖项。按当前系统文档操作，不要照抄会清空路由或全面覆盖网卡配置的命令。
“改用公共 DNS”不是通用修复，它改变查询接收方，却未必改变传输路径。DoH 用 HTTPS 传送 DNS；连接加密不能证明它经过 VPN，解析器仍处理查询，外层 VPN 连接的可见性也是另一问题。［2］可参阅加密 DNS 能隐藏哪些信息。
可疑旁路涉及另一个地址族时，继续检查 IPv6 覆盖。原始公网地址出现在浏览器媒体诊断，而非解析器观察时，使用WebRTC 候选地址指南。混淆症状，可能一直改 DNS，却没有处理真正原因。
不要一开始就禁用 IPv6、删除所有网卡或装陌生扩展。它们会引入新故障、遮蔽原始观察。找不到受支持的修复方法时，停止变更，保存基线和连接后记录，向管理员或提供方确认预期 DNS 路径。
什么样的重测才算完整？
按文档修复后，复现原始条件。检查新 DNS 查询、普通网页和必需内部资源；恢复正常浏览方式，再经过一次常规重连重测，避免只拿暂时成功的一次作证据。
简要记录修改项、原值、新值、观察解析器、路径证据和恢复结果。仍不确定时如实标注，不能拿出口 IP 改变替代。购买前把结论放进试用验收表，再决定。
受管理设备应恢复到获准配置，不是个人偏好。修改后网页打不开，先还原，再考虑其它方案。路由与隐私的整体关系可参考VPN 基础解释。
总结
- 先确定配置应该执行哪条 DNS 路径。
- 保持变量不变，对照断开与连接后的新查询。
- 分开理解运营方、国家、加密和路由证据。
- 一次只做受支持的修复，确认恢复并保留不确定结果。
常见问题
运营商解析器一定代表 DNS 泄露吗？
不一定，它可能不符合预期策略，但需要配置说明和路径证据，才能确认查询绕过隧道，不能只凭运营方名称判断。
安全 DNS 仍然可以经过 VPN 吗？
可以，浏览器到 DoH 解析器的 HTTPS 连接仍可能经 VPN 路由，即使使用的解析器与系统不同。
解析器在外国就证明泄露吗？
不能，国家标签可能反映基础设施或地理资料。应核对运营方和预期路径，而不是只根据国旗判断。
是否应该立刻换公共 DNS？
不能当成通用修复。它改变由谁解析，但没有检查路由，就还不知道查询实际经哪里传送。
为什么检测没有返回 DNS 服务器？
可能是工具失败、缓存或过滤。先用新的查询重测，确认工具确实生成请求，再把结果视为有用证据。
DNS 检测能发现 WebRTC 地址暴露吗？
不能可靠替代专项检查。解析器观察和浏览器媒体候选是不同机制，应使用 WebRTC 对照判断原始公网地址暴露。
修复后工作资源打不开怎么办？
恢复之前记录的设置，停止继续调整，向管理员确认内部解析器要求，不要自行替换受管理的配置。
免责声明： 此流程仅适用于你有权管理的设备和网络。观察只描述已记录的配置，不构成匿名性证明。
来源
- RFC 7359 — Layer 3 Virtual Private Network Tunnel Traffic Leakages in Dual-Stack Hosts/Networks
- RFC 8484 — DNS Queries over HTTPS
- AethoVPN — Official website
Sources checked 2026 年 10 月 5 日。
