DNS 泄漏怎么检查和修复？一套可复测的排查流程

更新于 2026-11-03 · flowercloud.site

简答：DNS 泄漏的核心判断不是“检测站显示了某个地区”，而是开启 VPN、WireGuard 或代理后，域名查询仍沿用不应使用的本地 DNS 路径。先关闭代理记录一次 DNS 基线，再开启连接进行在线检测和命令行复测；如果结果异常，只改一个设置，优先检查浏览器 DoH、系统代理与 VPN/TUN 接管、IPv6、私人 DNS，以及是否同时运行多个网络工具。

定义：DNS 泄漏是指设备访问域名时，DNS 查询没有按预期经过 VPN、WireGuard 或代理所要求的解析路径，而是由本地网络、路由器、运营商或其他未预期的解析器处理。

先试这 5 步：建立基线、检测、单变量修复、再复测

如果你只想先确认是否存在 DNS 泄漏，不要一开始就修改 DNS、MTU 或网络重置。按照下面顺序操作，能够保留对照结果，也方便在修复失败时恢复。

关闭 VPN、WireGuard、代理客户端和浏览器自定义安全 DNS。保持当前 Wi-Fi 或移动网络不变，打开一个 DNS 检测页面，记录显示的解析器名称、组织、地区和 IPv4/IPv6 情况。这只是本地网络基线，不是泄漏结论。
开启一个网络隧道或代理配置。不要同时打开第二个 VPN、系统代理、浏览器 DoH、私人 DNS 和其他网络过滤工具。先只启用一个变量。
重新进行普通检测和扩展检测。如果开启后仍显示与基线相同的本地解析器，或者客户端日志明确显示 DNS 请求没有进入隧道，才算有较强的泄漏证据。仅凭解析器地区与出口 IP 地区不同，不能单独确认泄漏，因为公共 Anycast DNS、企业 DNS、邻近地区节点和 IPv6 都可能造成地区差异。
用系统命令检查实际解析路径。Windows 可执行 nslookup example.com，观察使用的默认 DNS 服务器；如需指定服务器进行对照，可使用 nslookup example.com DNS服务器地址。微软文档说明，nslookup 可用于诊断 DNS 基础设施，省略第二个参数时会使用默认 DNS 服务器。Microsoft Learn：nslookup
每次只改一个设置后复测。验证标准应包括：浏览器检测结果、命令行解析结果、常用网页是否能打开、需要内网解析的域名是否仍可用。异常时先恢复上一个设置，不要连续改动多个系统层选项。

现象	更可能是什么	先验证什么	低风险回退
网页能打开，但检测显示本地 DNS	代理只接管了网页流量，DNS 仍由系统或浏览器单独处理	检查客户端是否有 DNS 接管、TUN 或全局路由；检查 Chrome/Firefox 的安全 DNS状态	恢复浏览器自动 DNS，重新连接客户端后复测
检测显示解析器地区与出口地区不同	可能是 Anycast、企业解析、邻近节点或 IPv6，不一定是泄漏	比较开启前后解析器组织、协议族和多次检测结果	不要仅因地区不同更换 DNS，先做基线对比
只有部分应用出现本地 DNS	分应用代理、系统代理盲区或应用自带 DNS	分别关闭应用自定义 DNS、检查是否走系统代理	先改回系统默认解析，单独测试该应用
开启安全 DNS 后网页报解析错误	DoH 服务不可达、网络策略冲突或自定义服务地址错误	临时切回自动/默认模式，确认问题是否消失	保留系统默认 DNS，待确认服务可达后再启用

Windows 的 DNS 客户端排障通常可以从 nslookup 和缓存检查开始；如果是缓存导致的旧结果，可使用 ipconfig /flushdns 清理 DNS 客户端缓存。该命令只清理本机 DNS 缓存，不会把普通 DNS 自动变成隧道 DNS。Microsoft Learn：排查 DNS 客户端 Microsoft Learn：ipconfig

先分清：DNS 泄漏、污染、劫持和其他泄漏不是一回事

DNS 泄漏关注的是“查询走了谁的解析路径”。例如你已经建立了 VPN 或 WireGuard 隧道，但系统仍把域名查询发送给本地路由器或运营商 DNS。

DNS 污染通常指返回结果被篡改、错误或不完整；它不等于查询一定泄漏。DNS 劫持则更强调查询被强制转发或被替换到另一个解析服务。解析失败只是没有得到可用结果，原因可能是 DNS 服务不可达、域名不存在、规则拦截或网络断开。

WebRTC 泄漏与 DNS 查询不是同一层问题，主要涉及浏览器实时通信接口暴露地址信息；真实 IP 泄漏也不能只靠 DNS 检测判断。DNS 检测页只能说明它观察到的查询路径，不能替代对浏览器、应用、IPv4、IPv6 和隧道路由的完整检查。

浏览器的安全 DNS 会改变浏览器自己的域名查询方式。Chrome 官方说明，开启安全 DNS 后会加密 DNS 查询；自动模式遇到问题时可能回退到未加密模式，而选择自定义服务时不会默认回退到未加密模式。Google Chrome 帮助：管理安全设置和安全 DNS

Firefox 也可能根据保护级别、VPN、企业策略或网络信号启用、停用或回退 DoH。Firefox 官方文档将“Active”“Not active”和“Off”区分开，因此看到 DoH 未激活时，应先检查状态和原因，而不是直接判断为系统 DNS 泄漏。Firefox Help：DNS over HTTPS 保护级别

按设备修复：Windows、macOS、Android、iPhone

Windows：先查默认 DNS，再排除浏览器和 IPv6

打开命令提示符，执行 ipconfig /all，记录当前网卡的 DNS 服务器、默认网关和 IPv6 配置。
执行 nslookup example.com，记录输出中的默认 Server 或 Address。
开启 VPN、WireGuard 或代理客户端后重复命令。如果默认 DNS 没变化，不要立即断定泄漏；先确认该客户端是否设计为接管系统 DNS，以及是否只代理浏览器流量。
在 Chrome 中进入“设置→隐私和安全→安全”，检查“使用安全 DNS”；在 Firefox 中进入“设置→隐私与安全→DNS over HTTPS”，记录保护级别。Chrome 的菜单和回退行为以官方帮助页为准，Firefox 则可能因网络、VPN 或组织策略改变状态。Chrome 安全 DNS说明 Firefox DoH说明
若只在 IPv6 网络下异常，先在客户端中确认是否同时接管 IPv6；不要直接修改 MTU。若客户端明确不支持 IPv6，可暂时关闭该客户端配置中的 IPv6 选项并复测，恢复时按原设置重新开启。
测试结束后可执行 ipconfig /flushdns，重新连接网络，再验证是否仍出现相同结果。

macOS：检查系统 DNS、浏览器 DoH 与多个网络工具

打开“系统设置→网络”，进入当前 Wi-Fi 或以太网服务的 DNS 配置，记录已有服务器，不要在没有记录原值的情况下直接删除。
分别测试浏览器和终端：浏览器用于观察网页路径，终端可使用 nslookup example.com 或系统自带的 DNS 查询工具观察默认解析器。
如果浏览器结果与终端结果不同，优先检查浏览器的安全 DNS；如果所有应用结果都异常，再检查 VPN、WireGuard、代理客户端是否启用了全局隧道、DNS 接管或分流。
若同时启用了 iCloud Private Relay 和其他 VPN、过滤软件或代理，先只保留一个网络隐私工具进行测试。Apple 说明，某些 VPN 或网络过滤软件可能与 Private Relay 的系统设置不兼容。Apple 支持：管理 iCloud Private Relay

Android：区分私人 DNS、Chrome 安全 DNS 和 VPN

在系统设置中搜索“私人 DNS”，通常可选择“关闭”“自动”或“私人 DNS 提供商主机名”；不同手机厂商和 Android 版本的菜单名称可能不同。Android 官方说明，私人 DNS 只保护 DNS 问答，不会保护其他网络流量。Android 帮助：管理高级网络设置
在 Chrome 中进入“设置→隐私和安全→使用安全 DNS”，先记录当前状态。不要同时把 Chrome 自定义 DoH、Android 私人 DNS 和 VPN 客户端 DNS 都改成不同服务。
只开启一个 VPN 或代理配置，测试系统浏览器和一个需要联网的应用。如果浏览器正常、应用异常，重点排查分应用代理和应用自带 DNS，而不是继续更换公共 DNS。
如需回退，把私人 DNS 恢复为“自动”，把 Chrome 安全 DNS恢复为自动或关闭，再断开并重新连接 VPN，完成一次复测。

iPhone：优先排除 Private Relay、VPN 配置和网络冲突

检查“设置→你的姓名→iCloud→Private Relay”是否开启；它主要保护 Safari 浏览和 DNS 请求，不等同于所有应用都经过同一条 VPN 隧道。Apple 说明，Private Relay 使用两个中继，并且主要针对 Safari 等网页浏览场景。Apple 支持：关于 iCloud Private Relay
检查“设置→通用→VPN 与设备管理”中是否存在多个 VPN、描述文件或网络过滤配置。不要在未确认来源的情况下删除企业或学校配置；如需处理，先记录配置名称并向管理员确认。
在当前 Wi-Fi 下检查“限制 IP 地址跟踪”或 Private Relay 相关选项。如果关闭后问题消失，说明可能是 Private Relay 与当前网络、VPN 或过滤软件存在兼容性问题，不足以证明发生了 DNS 泄漏。Apple 提供了按网络关闭和恢复该功能的操作路径。Apple 支持：按网络管理 Private Relay
如果问题只在 Safari 出现，先单独测试 Safari；如果所有应用都出现解析异常，再检查 VPN 配置、Wi-Fi 路由器 DNS 和 IPv6。iOS 的具体 DNS 菜单会因系统版本、管理策略和网络配置变化，找不到选项时应以“VPN”“Private Relay”“限制 IP 地址跟踪”和当前 Wi-Fi 配置为核验入口。

修复后怎么验收：不要只看一次在线检测

一次检测结果只能说明某个时间点、某个浏览器和某条网络路径的表现。建议按下面的清单验收：

同一网络对比：在关闭和开启隧道时分别检测，记录解析器组织、IPv4/IPv6 和结果变化。
至少两个应用：浏览器之外，再测试一个普通联网应用；如果只影响一个应用，优先判断为分应用代理或应用自带 DNS。
IPv4 与 IPv6 分开看：客户端只接管 IPv4 时，IPv6 可能仍走本地网络；必须确认客户端是否支持并接管两种协议族。
重连后复测：切换 Wi-Fi、移动网络、节点或客户端模式后，重新测试，因为 DNS、路由和浏览器 DoH 状态可能随网络变化。
保留回退点：记录原 DNS、浏览器原设置、VPN 配置和 Private Relay 状态。修复后出现内网域名无法解析、网页打不开或登录异常时，先恢复上一项改动。

如果检测结果始终矛盾，优先把问题改写为“解析路径未确认”，而不是直接宣布存在泄漏。可以暂时停用第二个 VPN、浏览器自定义 DoH 或私人 DNS，重新建立单一变量测试；对于企业网络、家庭路由器和受管理设备，还需要确认网络管理员是否有意配置了内部 DNS。Firefox 官方也提示，某些组织网络会要求使用本地解析策略，DoH 可能因此被停用或回退。Firefox Help：配置网络停用 DoH

常见问题：DNS 泄漏排查中的 5 个误区

1. 检测站显示本地运营商名称，就一定是 DNS 泄漏吗？

不一定。先看开启前后的基线变化、客户端的 DNS 接管说明、IPv4/IPv6 路径和检测站是否能观察到完整查询。解析器地区不同也不一定代表泄漏。

2. 把 DNS 改成公共 DNS，能解决 DNS 泄漏吗？

不能直接等同。更换解析器地址只改变“使用哪个 DNS”，不保证 DNS 请求进入 VPN、WireGuard 或代理隧道；如果客户端没有接管 DNS，公共 DNS 仍可能在隧道外发送。

3. 网页能打开，是否说明没有 DNS 泄漏？

不能。网页打开只说明当前浏览器完成了访问，不代表后台应用、IPv6、分应用代理或另一个浏览器的 DNS 也使用同一路径。

4. Chrome 的安全 DNS 应该一直开启吗？

要看你的网络和客户端组合。Chrome 官方说明，自动模式遇到问题时可能回退到未加密解析；自定义服务出现错误时，可能需要检查服务地址或暂时关闭安全 DNS。与 VPN 或代理客户端同时使用时，应以单变量复测结果为准。Chrome 官方说明

5. Android 私人 DNS 开启后，就不会发生 DNS 泄漏了吗？

不能这样保证。Android 官方明确说明，私人 DNS只保护 DNS 问答，不保护其他流量；它还可能与 VPN、Chrome 安全 DNS 或企业网络策略形成不同的解析路径。应在开启 VPN 后重新检测，并确认实际使用的是哪一层 DNS。

常见问题

DNS 泄漏怎么检查最快？

先关闭 VPN、WireGuard 或代理建立本地 DNS 基线，再开启单一网络配置进行在线检测；同时用 Windows 的 nslookup 或对应系统工具观察默认解析器。开启前后结果、客户端日志和 IPv4/IPv6 路径一致异常时，才有较强证据。

DNS 泄漏和 DNS 污染有什么区别？

DNS 泄漏关注查询由谁处理、是否走出预期隧道；DNS 污染关注返回结果是否被篡改或错误。两者可能同时出现，但不能用一个现象替代另一个结论。

DNS 泄漏怎么修复？

按单变量顺序检查浏览器 DoH、系统代理、VPN 或 WireGuard 的 DNS 接管、TUN/全局路由、IPv6、Android 私人 DNS、路由器 DNS 和多个 VPN 冲突。每次只改一项，修复后用浏览器、命令行和第二个应用复测。

为什么代理开着，DNS 检测仍显示本地网络？

常见原因是客户端只代理网页流量，没有接管系统 DNS；也可能是浏览器使用独立 DoH、IPv6 未纳入隧道、分应用代理生效，或同时运行了多个网络工具。需要按平台检查实际解析路径。

在线 DNS 检测显示的地区不一致是否一定是泄漏？

不一定。Anycast、企业解析、公共解析器、邻近节点和 IPv6 都可能导致解析器地区与出口地区不同。应优先比较开启前后结果，并结合客户端日志和命令行查询判断。