DNS 泄漏并不等于 VPN 一定失效，但它说明域名查询可能没有按照预期经过加密隧道。你访问的具体网页内容也许仍然通过 VPN 出口传输，可是设备向哪个 DNS 服务器询问了域名、查询了哪些站点，可能被本地网络、公共 WiFi 管理者或互联网服务商观察到。对于重视隐私、经常切换网络，或需要让不同应用保持一致出口的用户来说，这是一项值得单独检查的配置。
排查 DNS 泄漏不能只看客户端是否显示“已连接”。VPN 连接通常包含本地虚拟网卡、系统路由、DNS 服务器、分流规则和应用自身代理设置多个部分。任何一层配置不一致，都可能出现网页能打开但 DNS 仍走本地网络的情况。本文会从检测结果的含义开始，介绍 Windows、Android、iPhone 与常见兼容客户端的排查方法，并说明 Kill Switch、公共 WiFi 和免费 VPN 场景下应该怎样降低风险。
DNS 泄漏是什么，为什么会发生
DNS 可以理解为互联网的“目录查询”机制：浏览器输入域名后，设备先向 DNS 解析器询问对应的 IP 地址，再尝试建立连接。传统 DNS 请求通常没有像 HTTPS 网页内容那样由应用层加密保护，因此，负责转发查询的网络设备可能看到域名。VPN 的理想状态是让相关 DNS 查询与后续连接使用一致的隧道路由，避免查询从本地网络单独发出。
最常见的泄漏原因是 VPN 只改变了默认路由，却没有完整接管 DNS。Windows 可能仍保留物理网卡上的 DNS 优先级；手机系统可能在网络切换后恢复运营商解析器；浏览器的安全 DNS 可能绕过系统设置；而分应用代理则可能让浏览器、即时通信软件和其他应用采用不同的解析路径。此时用户看到的现象往往不是“完全无法连接”，而是地区判断异常、部分网站打不开、同一域名在不同应用中返回不同结果。
IPv6 也是经常被忽略的因素。如果 VPN 客户端只为 IPv4 设置隧道路由，而当前网络同时提供 IPv6，系统可能通过原始网络发送 IPv6 相关请求。某些旧客户端还会在网络切换、休眠唤醒或 VPN 重连后短暂恢复原来的 DNS 配置。由于这种问题具有间歇性，单次检测正常并不能完全证明长期没有泄漏。
DNS
域名解析层
IPv4
常见路由路径
IPv6
容易忽略的路径
Kill Switch
断线保护机制
如何检测 DNS 泄漏并正确理解结果
检测前先关闭浏览器中不必要的代理扩展，连接 VPN 后等待客户端完成握手，再打开可信的 DNS 泄漏检测页面。建议至少进行两轮：第一轮使用标准检测，第二轮执行更完整的扩展检测。检测过程中不要同时切换节点、修改 DNS 或刷新订阅，否则结果无法说明是哪项配置产生了变化。
检测页面通常会列出一组 DNS 服务器的 IP、所属网络或大致地区。不要只依据服务器名称判断是否泄漏，因为 VPN 服务可能使用第三方 DNS、云服务地址或与出口地区不同的解析集群。更有价值的比较方式是：断开 VPN 记录一次结果，连接 VPN 后再记录一次，然后检查连接后是否仍大量出现本地宽带或移动运营商的解析器。
| 检测结果 | 可能含义 | 下一步排查 |
|---|---|---|
| 只出现 VPN 或远程解析器 | 系统 DNS 大体跟随隧道路由 | 在切换网络、重连和休眠后复测 |
| 出现本地运营商解析器 | 查询可能绕过 VPN，或存在并行解析 | 检查客户端 DNS、系统优先级和分流模式 |
| 只在 IPv6 网络出现异常 | IPv6 路由或 IPv6 DNS 未被隧道接管 | 更新客户端，检查 IPv6 防护选项 |
| 不同浏览器结果不同 | 浏览器自带安全 DNS 或扩展改变了路径 | 核对浏览器的安全 DNS 与代理设置 |
| 断线后仍能解析并访问 | 可能缺少断线阻断，存在短暂暴露窗口 | 启用 Kill Switch 并测试断线行为 |
一次检测出现本地解析器并不一定代表所有请求都已暴露，也可能是系统并行发送查询、浏览器单独使用安全 DNS，或检测站点把缓存结果误认为实时请求。因此，排查时应把检测页面、系统命令、客户端日志和实际断线行为结合起来观察，不要仅凭一个“安全”或“危险”的页面结论做判断。
Windows 端排查与修复步骤
Windows 上的 DNS 路径可能同时受到物理网卡、虚拟网卡、系统服务、浏览器和第三方客户端影响。开始前先关闭其他代理工具，尤其不要同时运行两个会修改系统路由的 VPN 或代理客户端。多层代理并不会自动增加隐私，反而可能让 DNS 优先级和默认网关难以判断。
- 确认客户端模式。优先使用官方客户端或经过验证的兼容客户端，确认已经开启系统代理、虚拟网卡或全局隧道中与你需求对应的模式。仅设置浏览器代理时，其他应用和系统 DNS 可能仍走本地网络。
- 查看系统 DNS。在命令提示符中执行
ipconfig /all，分别查看物理网卡和 VPN 虚拟网卡的 DNS 服务器。不要只看当前 WiFi 网卡，断开 VPN 后再比较一次，观察连接状态变化时 DNS 是否随之调整。 - 清理旧缓存。修改客户端或 DNS 设置后，可以执行
ipconfig /flushdns清理本地缓存，再重新打开检测页面。缓存中的旧记录不会直接证明当前查询仍在泄漏，但会让排查结果混乱。 - 检查浏览器单独设置。Chrome、Edge、Firefox 等浏览器可能启用安全 DNS 或自定义解析器。若浏览器结果与系统命令、其他应用不同，应暂时关闭浏览器自定义 DNS 进行对照，或确认它支持通过当前代理路径发送查询。
- 测试断线保护。连接 VPN 后暂时断开客户端，观察新打开的网页、命令行解析和已有连接是否被阻止。若客户端显示断开后系统仍能直接访问外网，说明需要检查 Kill Switch 或“阻止无 VPN 流量”选项。
- 检查 IPv6。如果检测工具只在 IPv6 网络下报告异常，不要只反复更换 DNS 地址。应先确认客户端是否支持 IPv6 隧道与泄漏防护，必要时更新客户端版本并重新测试。
- ✅ 连接 VPN 后同时检查物理网卡与虚拟网卡的 DNS 信息。
- ✅ 修改设置后清理 DNS 缓存，并在浏览器与其他应用中分别验证。
- ✅ 测试断开 VPN 后是否立即阻止新的外网连接。
- ✅ 使用订阅导入配置时，确认远程 DNS、Fake-IP 或规则模式是否符合客户端实现。
- ❌ 不要把手动填写一个公共 DNS 地址当作完整的防泄漏方案。
- ❌ 不要在排查过程中同时运行多个系统级代理客户端。
Android 与 iPhone 的手机端排查
手机端的特殊之处在于系统会频繁处理 WiFi、移动数据、休眠和后台权限。VPN 连接在 WiFi 与移动数据之间切换时，系统可能重新建立网络接口；如果客户端没有及时重新写入路由，短时间内就可能出现查询走原始网络的情况。测试时应分别在 WiFi 和移动数据下连接，并在锁屏后重新打开应用确认状态。
Android 检查重点
Android 用户可以先查看系统的“私人 DNS”设置。私人 DNS 与 VPN 客户端的远程 DNS 并不是同一层功能，启用固定主机名后，系统可能按照自己的策略处理查询。不要简单认为私人 DNS 与 VPN 叠加后一定更安全，应根据客户端说明确认二者是否兼容。随后检查 VPN 应用中的始终开启 VPN、阻止无 VPN 连接等选项，并通过系统 VPN 设置确认当前只有预期的客户端处于活动状态。
如果使用 Clash Verge 的移动兼容版本、sing-box 或其他支持订阅导入的客户端，应重点核对 DNS 模式、Fake-IP、分流规则和 IPv6 处理方式。不同实现对“直连域名”“代理域名”和系统 DNS 的处理并不相同。开启 Fake-IP 后，部分本地应用、银行应用或局域网设备可能需要额外的绕过规则；出现故障时应先查看日志中实际采用的 DNS 出口，而不是盲目关闭全部防护。
iPhone 与 iPad 检查重点
iOS 通常通过系统 VPN 配置接管流量，用户能调整的选项取决于客户端使用的网络扩展类型。连接后先在系统设置中确认 VPN 状态，再检查客户端是否提供 DNS 防泄漏、按需连接、断线阻止或局域网绕过选项。若同时安装了内容过滤器、企业配置或其他网络安全应用，它们也可能改变 DNS 路径。
iOS 上不要只在 Safari 中测试。可以先连接 VPN，访问检测页面，再切换到移动数据、锁定屏幕、重新解锁并测试一次。如果 VPN 在后台被系统暂停，检测结果可能暂时恢复为移动运营商的解析器。对于 Shadowrocket 等兼容客户端，应确认订阅规则、DNS 服务器和代理模式已生效；仅导入节点而没有正确启用配置，不代表系统流量已经经过隧道。
Kill Switch、公共 WiFi 与免费 VPN 的防护
Kill Switch 的作用不是让 DNS 本身变得更安全，而是在 VPN 隧道中断、重连或配置失效时阻止流量回落到普通网络。它尤其适合经常使用公共 WiFi、移动热点或不稳定网络的场景。启用后，本地打印机、局域网网页和部分智能设备可能无法访问，这是阻断范围带来的正常影响。需要局域网功能时，应使用明确的局域网绕过选项，并再次确认需要保护的应用没有被一起绕过。
公共 WiFi 中的风险不只来自 DNS。热点可能要求门户认证、强制跳转或限制 UDP，VPN 客户端因此需要先完成网络登录再建立隧道。连接成功后仍要重新检查 DNS，因为系统从认证页切换到正常网络时可能改变网关和解析器。不要在未验证隧道的情况下处理敏感账号，也不要把“WiFi 显示已连接”误认为 VPN 保护已经生效。
免费 VPN 的主要问题通常是运营模式、日志政策、广告注入、流量限制和客户端权限，而不只是速度。某些免费工具只提供浏览器扩展，保护范围可能局限于浏览器；另一些工具只修改代理而不接管系统 DNS。选择服务时应查看是否说明 DNS 处理方式、是否支持 Kill Switch、是否维护 Windows、macOS、Android、iOS 与 Linux 客户端，以及发生故障时是否有可核对的文档。不要把“免费”直接等同于匿名或无记录。
| 使用场景 | 建议设置 | 验证重点 |
|---|---|---|
| 家庭 WiFi | 远程 DNS、自动重连、必要时启用 Kill Switch | 路由器 IPv6 与本机 DNS 是否同时存在 |
| 公共 WiFi | 先完成门户认证，再连接 VPN | 断线后是否阻止新连接，切网后是否自动恢复 |
| 移动热点 | 开启按需连接或始终开启 VPN | 移动数据切换后 DNS 是否仍符合预期 |
| 免费 VPN | 核对隐私政策、DNS 方案与客户端权限 | 浏览器扩展是否只保护单一应用 |
常见问题解答
使用公共 DNS 就不会泄漏吗？
不会。把 DNS 改成公共解析器，只是更换了查询对象，并没有保证查询一定通过 VPN 隧道。若系统仍从本地网络直接访问该解析器，查询路径依然可能与 VPN 流量不一致。应先确认客户端的隧道和 DNS 接管方式，再考虑是否使用自定义解析器。
检测结果显示本地 DNS，一定需要更换 VPN 吗？
不一定。先排除浏览器安全 DNS、缓存、分应用代理、IPv6 和系统并行查询等因素。连接 VPN 后，若所有检测都稳定显示本地运营商解析器，并且客户端没有可用的远程 DNS 或阻断选项，再评估更换客户端或服务。
只在浏览器中使用 VPN，其他应用需要检查吗？
需要。浏览器扩展通常只覆盖浏览器标签页，系统更新、即时通信、游戏启动器和其他应用仍可能使用本地网络。若目标是保护整台设备，应使用支持系统级隧道的官方客户端或兼容客户端，并检查其分流范围。
修复后多久需要复查？
每次更新客户端、导入新订阅、更换网络、启用浏览器安全 DNS 或调整 IPv6 设置后，都建议重新检测。特别是公共 WiFi 和移动数据环境，连接建立与网络切换后的路径可能不同。保留一份不含账号、订阅链接和设备识别信息的配置记录，有助于之后比较变化。
DNS 防护的关键不是寻找一个“万能 DNS 地址”，而是让域名查询、实际连接、分流规则和断线行为彼此匹配。先用检测工具确认现象，再按 Windows、Android 或 iPhone 的系统路径逐层排查；最后通过切网、重连、锁屏和 Kill Switch 测试验证修复是否持续有效。这样得到的结果，比单纯看到客户端显示已连接更可靠。