DNS 泄漏怎么排查和修复？从预期路径到复测

修复 DNS 问题的第一步，是确认哪一项结果不符合实际需求。运营商解析、公共 DNS、不同国家标签或多个出口，都不是统一故障标准。先保留原配置，再用范围明确的对照测试找到负责解析的应用和服务，避免同时修改多个开关后无法解释结果。

一、写清目标并保留回滚信息

写下希望采用的解析服务、测试应用和网络通道。例如，公司内部域名应交给企业解析器，公开域名允许采用经批准的加密 DNS；这与要求所有应用使用同一个远程解析服务，是两种不同设计。没有明确目标，就不能只凭测试地址不同决定修改。

记录系统 DNS、浏览器安全 DNS、代理或 VPN 配置名称及软件版本。导出配置前检查凭证，截图也应遮盖无关信息。受管理设备遵循管理员要求。路由器变更会影响其他设备，选择合适时间，准备恢复原设置，并在重要业务使用前先做小范围对照。

二、先确定是谁负责解析

同一台设备可能存在系统解析器、浏览器 DoH、应用自定义 DNS 和远程环境的解析器。先在发生问题的应用中观察，不要用本机浏览器代表远程服务器。浏览器正常而终端异常时，比较两者执行位置和代理范围，记录是否采用相同目标域名。

本站检测展示测试服务观察到的解析出口。把结果与系统设置、浏览器设置和客户端日志对应起来。显示的地址可能属于上游转发服务，因此设置页写 A、结果显示 B，并不直接证明绕过；必要时查供应商说明或询问管理员。

三、检查客户端接管与规则

系统代理通常影响遵循该设置的应用；TUN 或 VPN 可以影响更广的流量，但具体范围仍由权限、路由、例外规则和地址族决定。开启 TUN 后，还需确认查询进入客户端后交给哪个解析服务，以及访问该解析服务采用哪个出站。

使用 Clash 系、Surge 或 sing-box 时，确认准确产品名称、内核版本和系统，再查看相应版本的 DNS、路由与 TUN 官方文档。名字相似的开关不保证相同行为，旧版配置也不一定适用于新版。内部域名还要检查搜索域和分流 DNS，避免被公共解析覆盖。

四、单独核对浏览器的加密 DNS

DoH 将 DNS 查询装在 HTTPS 请求中发送。它可能独立于系统默认解析器，但是否绕过网络通道取决于该 HTTPS 连接的实际路径。不要把开启 DoH 直接当作泄漏原因，也不要为了让国家标签一致而更换服务。

组织要求浏览器统一使用系统解析时，可以在批准范围内临时调整浏览器设置，重新打开标签页后对照。如果允许独立 DoH，则核对服务来源、连接路径和失败时的回退行为。测试完成后保留符合需求的配置，避免把有用的加密解析长期关闭。[Firefox DoH 说明]

五、检查双栈与 SOCKS5 的范围

设备同时具备 IPv4 和 IPv6 时，检查客户端与规则是否覆盖需要管理的地址族。IPv6 本身不表示不安全，IPv4 正常也不能说明 IPv6 正确。临时限制某个地址族有助于定位，但应在可恢复的测试中进行，确认后修复具体配置。

SOCKS5 可以接收已解析的 IP，也可以接收域名，由代理完成解析。以 curl 为例，socks5h://用于让代理解析目标主机名。它只影响该次请求的目标名称；代理服务器自身的域名、其他应用和后台请求仍可能另行解析，不能据此承诺本机完全没有 DNS 请求。[curl 官方说明]

六、按现象选择下一项检查

• 运营商出口：先确认运营商是否就是预期服务；如果不是，检查浏览器独立设置、客户端规则和回退路径。
• 多个服务：核对负载分配、转发、双栈和多个并行应用，记录集合与条件，避免按地址数量判断故障。
• 修改后不变：确认设置作用于实际测试的应用，检查缓存、受管理策略和保存状态。
• 超时或无结果：检查扩展、网络拦截和探测服务，区分测试失败与业务域名解析失败。
• 仅内部域名异常：优先查看企业 DNS、搜索域和专用通道，不要反复向公共检测提交内部名称。

七、怎样证明修复有效

保持设备、应用、目标和网络一致，重新执行之前失败的操作，再运行同类 DNS 测试。记录预期服务是否出现、原错误是否消失、正常网站与内部资源是否仍可访问。国家相同或分数降低可以作为记录，不能取代功能验收。

假设浏览器误用了未经批准的解析服务。只调整浏览器设置后，测试采用了指定服务，内部域名也仍可打开，这才支持保留修改。如果只有表格变化，业务仍失败，就要继续检查连接、权限或服务状态。该情景是方法示例，不代表任何真实账号因此恢复。

最后保存有效配置和恢复步骤。网络切换或软件更新后，针对重要功能复测即可，不必为保持某种页面颜色反复更换线路。留档方法见检测基线教程；复杂结果可继续查阅DNS 结果组合排查。