如何检查 DNS 泄漏
判断 DNS 解析是否与预期路径一致，并按场景给出验证与修复步骤。
DNS 泄漏并不总是“安全事故”，有时只是测试方法问题。 要判断是否有效，核心看的是：解析请求是否和你的安全路径一致。
你可以先在 IP 查询工具 获取当前公网结果，再继续做 DNS 侧核对。
先弄清三个层级
- 第一层：出口 IP 先确认是否已按预期走 VPN/代理。
- 第二层：解析器来源 看 DNS 请求是否仍打到运营商/本地解析器。
- 第三层：应用行为 看目标网站/服务是否仍按本地解析策略回退。
只有三层同步后，才说明“路径和解析”整体一致。
为什么它常被忽略
1）可见信号不对齐
很多人只看 IP，没看 DNS。 这就像只检查车牌号没看方向盘——你以为换车牌了，实际上方向盘仍在本地。
2）单次测试误导
缓存、CDN、网络抖动都会让一次样本不稳定。 第一次结果不变不等于失败，三次以上更能反映真实。
3）浏览器与系统路径不一致
系统 DNS 与浏览器 DoH/DoT 配置可能走不同路线，导致“部分泄漏”。
分步验证方法（推荐）
Step 1：建立固定基线
记录：
- 当前网络类型（Wi-Fi/移动/企业网）；
- 本地 DNS 服务器；
- VPN/代理模式（全局/分流）。
然后执行第一次查询并记录 IP 与 ASN。
Step 2：切换环境只改一个变量
每次只改一个配置：
- 只改 DNS；
- 或只改 VPN；
- 或只改测试网络。
避免一次改三样导致归因失败。
Step 3：复测并对照
用 DNS 泄漏测试页、系统命令、浏览器观察三种手段复测。 当三类结果都一致后再下结论。
Step 4：记录时序
至少间隔 15~30 分钟复测一次，确认是否持续、重现、可回放。
常见场景与判定
场景 A：企业网测试
企业网常有安全网关统一解析。 在有权限范围内，先确认是否为官方策略；如果不是异常，按企业说明处理而不是判泄漏。
场景 B：公共 Wi-Fi 与共享热点
很多手机热点和咖啡店网会有透明代理，解析器在网关侧完成。 此时常见“IP 已改、DNS 未改”现象，优先判定为场景差异后再决定是否继续。
场景 C：移动网络切换
移动网络切换引起 DNS 缓存和路径重建。 先清缓存再测，并保持应用不变，防止误判为泄漏。
场景 D：跨设备对比
同一网络下两台设备出现不同结果，通常是客户端配置差异。 把设置对齐后重测可减少误报。
避免误判的规则
- 只看一次样本会误伤；
- 没清缓存就下结论不可靠；
- 不区分系统 DNS 与应用 DNS 很容易错判；
- 缺少会话/登录上下文是典型误报根因。
处理优先级
- 本地 DNS 是否被强制覆盖？
- VPN 客户端是否有分流白名单？
- 浏览器/应用是否仍保留直接路径？
- 网关策略是否允许当前 DNS 路径？
按优先级自下而上修复，别只盯最后一条。
与 IP 地址判断的关联
DNS 是“你要找谁的地址”，IP 是“你从哪条路出去”。 两者同时不一致才是高风险信号，二者各自单独偏离未必说明泄漏。
FAQ 扩展
Q：有没有“一次性”工具可以完全确认？
A：没有。建议组合使用官方测试页 + 本机解析检测 + 两个时间点复测。
Q：看到本地 DNS 但页面也能访问，是不是一定有问题？
A：不一定，取决于策略是否有授权且是否涉及敏感会话。
Q：检测到泄漏应该先做什么？
A：先回滚到默认网络配置保存证据，再按步骤逐项修复并复测。
Q：清缓存后结果变正常说明什么？
A：可能是旧状态残留，缓存清理后更容易看见真实状态，先保持两次一致再确认。
Q：共享设备测试时如何避免影响他人？
A：尽量不用公共敏感配置，仅做只读检查并记录，不改底层网关关键设置。
相关阅读
常见问题
DNS 泄漏到底是什么意思？
DNS 请求在你以为走隧道的同时仍回到本地/未受控解析器时，说明有潜在泄漏。
为什么 IP 变了但 DNS 还像没变？
常见于 split tunnel、浏览器缓存、系统策略回退或网关代理未生效。
企业网络里能做这个测试吗？
可做，但要先确认策略许可。先对照公司网关文档再执行公开测试。
如何避免把一次波动判成泄漏？
固定变量、重复复测并结合会话上下文，不要以单次结果定论。
发现 DNS 泄漏后优先处理什么？
先校验本地 DNS 配置与客户端分流，再检查应用级设置和路由策略。