VPN DNS 泄漏怎么检查和修复?
简答:VPN DNS 泄漏不能只看一次在线测试。先关闭 VPN 记录 DNS 解析器和 IPv4/IPv6 结果,再连接同一节点复测;若仍出现原网络运营商的 DNS,优先检查客户端的 DNS 防泄漏、全局/分流模式、浏览器 DoH、系统手动 DNS 和 IPv6 路由,修改后重启客户端并再次对比。
定义:VPN DNS 泄漏是指设备的域名解析请求没有按预期进入 VPN 隧道,而是继续交给本地网络、运营商、浏览器自带 DoH 或其他解析器处理。
先做基线对比:不要把“看到第三方 DNS”直接判定为泄漏
本文是第三方使用指南,不是相关品牌的官方页面。以 2026 年 10 月 30 日为核验日期,最可靠的判断方式是比较同一设备、同一网络、同一测试网站在 VPN 关闭和开启时的结果,而不是只看某个 DNS 名称是否熟悉。
先试这一步:关闭 VPN,打开一个 DNS 泄漏检测页面,记录解析器名称、所属组织或网络、所在地区以及是否出现 IPv6;然后保持 Wi-Fi 或移动网络不变,连接 VPN 的同一地区节点,再重新测试。两次测试应尽量使用同一个浏览器和同一网络。
| 现象 | 更合理的判断 | 下一步 |
|---|---|---|
| VPN 开启后只显示 VPN 网络或其合作解析器 | 不能仅凭“不是熟悉品牌”判定泄漏 | 对照 VPN 关闭时的运营商或家庭网络结果,并检查客户端模式 |
| VPN 开启后仍出现关闭 VPN 时的本地运营商 DNS | 存在 DNS 未进入隧道的可能 | 检查 DNS 防泄漏、系统 DNS、浏览器 DoH 和分流规则 |
| 浏览器测试正常,但命令行或另一浏览器结果不同 | 可能是浏览器 DoH、代理扩展或系统解析路径不同 | 分别关闭或固定其中一层,再重复测试 |
| IPv4 结果正常,但出现本地 IPv6 地址或 IPv6 解析路径 | 可能存在 IPv6 未被 VPN 接管 | 检查客户端 IPv6 防泄漏或暂时关闭系统 IPv6 后复测 |
| VPN 断开后网页仍能打开 | 这不能单独证明 DNS 泄漏 | 检查 Kill Switch;它主要用于阻止断线后的流量回落,不是 DNS 修复开关 |
DNS 解析器可能属于 VPN 基础设施、公共 DNS、企业网络或其他第三方服务。真正要观察的是:VPN 开启后,解析请求是否仍由原本的本地网络处理。Mozilla 也说明,浏览器启用 DNS over HTTPS(DoH)后,DNS 请求可能直接发送给浏览器选择的 DoH 解析器,并不一定使用操作系统 DNS。Mozilla 关于 Firefox DNS over HTTPS 的说明
按顺序检查客户端、系统 DNS、浏览器和 IPv6
- 确认 VPN 客户端模式。如果客户端只有系统代理或浏览器代理,其他应用的 DNS 请求可能仍由系统或应用自己的解析器处理。优先选择客户端明确提供的全局隧道、TUN、DNS 防泄漏或类似选项;如果使用分流模式,先临时切换为全局或完整隧道进行对比。修改前导出或记录原配置,出现无法联网时关闭改动并恢复原模式。
- 检查客户端 DNS 选项。查找“DNS leak protection”“防 DNS 泄漏”“远程 DNS”“通过代理解析”“Fake-IP”“TUN DNS”等字段。不同客户端命名和实现可能不同,不能仅凭字段名称推断所有流量都会进入 VPN;打开后必须重新测试。若启用后网页打不开,先恢复到原模式,再检查远程 DNS 地址、规则和本地网络是否允许相应连接。
- 检查系统手动 DNS。如果设备网卡、Wi-Fi 配置或路由器中写入了固定 DNS,客户端可能需要覆盖它才能接管解析。Windows 网络排查文档建议检查当前 DNS 服务器,并提供清理 DNS 客户端缓存的方法。Microsoft Windows 网络连接排查文档
- 检查浏览器 Secure DNS 或 DoH。Firefox 的“默认保护”可能在特定网络、VPN、企业策略或检测条件下改变行为;“严格”或“自定义”模式则可能持续使用指定的 DoH 解析器。排查时可以先临时关闭浏览器 Secure DNS,使用系统解析完成一次复测;如果结果恢复一致,再决定是否重新开启并让客户端或网络明确支持该路径。Mozilla Firefox DoH 设置说明
- 检查 IPv6。DNS 结果正常不代表 IPv6 一定被 VPN 接管。若 VPN 客户端没有 IPv6 支持,可暂时关闭系统 IPv6,重启客户端后进行对比;这只是定位手段,不应在不了解企业网络、局域网设备或办公系统依赖关系时长期修改。Apple 的网络扩展文档说明,VPN 可以配置包含或排除的流量,因此不同客户端的全局隧道和分流行为可能不同。Apple VPN 流量路由文档
- 检查 Kill Switch 的边界。Kill Switch 的主要作用是 VPN 断开时阻止流量回落到普通网络;它不能替代 DNS 路由、浏览器 DoH、IPv6 和分流设置。开启前确认客户端是否提供应用级或系统级选项,并记录如何关闭,避免网络故障时无法恢复。
在 Android 上,系统“私人 DNS”只保护 DNS 问题和答案,并不保护其他流量;因此开启私人 DNS 不等于整个设备已经通过 VPN,也不等于一定消除了 VPN 客户端的 DNS 路由问题。Google 的官方说明给出了“关闭、自动、私人 DNS 提供商主机名”三种选项。Google Android 高级网络设置
在 macOS 中,可通过“系统设置—网络—选择网络服务—详细信息—DNS”查看和移除手动 DNS。Apple 的说明确认该位置用于管理 DNS 服务器和搜索域。Apple macOS DNS 设置
iPhone 和 iPad 的可用入口取决于 VPN 客户端、配置描述文件和系统能力。Apple 的 Network Extension 文档说明,VPN 应用可以使用系统 VPN、数据包隧道或 DNS 配置,但不同能力存在平台和权限限制;普通用户应优先使用客户端内置的 DNS 防泄漏或全隧道选项,不要把 Wi-Fi 页面里的手动 DNS 当成完整 VPN 修复方案。Apple Network Extension 文档
Windows、macOS 与手机的可复现验证方法
Windows:先用 nslookup 看当前默认解析器
打开命令提示符,分别在 VPN 关闭和开启时运行:
nslookup example.com
ipconfig /all | findstr /c:"DNS Servers"第一条用于查看查询结果和使用的 DNS 服务器,第二条用于查看 Windows 当前列出的 DNS 服务器。Microsoft 文档说明,nslookup 未指定服务器时会使用默认 DNS;也可以显式指定服务器进行对照,例如:
nslookup example.com 1.1.1.1这类命令只能说明某次解析使用了哪个服务器,不能单独证明全部应用流量都经过 VPN。若修改设置后出现解析异常,可在管理员命令提示符运行:
ipconfig /flushdns然后重启 VPN 客户端和浏览器,再完成在线测试。Microsoft 官方文档列出了 ipconfig /flushdns 以及 Winsock、TCP/IP 重置步骤;不要一开始就全部执行,先从清理 DNS 缓存开始,以免扩大改动范围。Microsoft DNS 客户端排查文档
macOS:查看 DNS 列表,再做关闭与开启对比
进入“系统设置—网络”,选择当前 Wi-Fi 或有线服务,打开“详细信息—DNS”。记录 DNS 服务器列表,不要直接删除企业网络、办公域名或路由器下发的条目。先退出 VPN 截图或记录一次,再连接 VPN 查看列表是否变化,并用同一浏览器进行复测。若客户端通过系统扩展接管 DNS,系统列表不一定完整反映隧道内部解析,因此仍需结合在线测试和命令行结果。
Android:区分私人 DNS 与 VPN 客户端 DNS
进入“设置—网络和互联网—私人 DNS”。先记录原选项,再根据 VPN 客户端文档进行对比。排查时不要同时更改私人 DNS、Wi-Fi 固定 DNS 和 VPN 客户端 DNS,否则无法判断是哪一层生效。Google 明确提示,私人 DNS 只处理 DNS 问题和答案,不能保护其他网络流量。Google Android 官方说明
iPhone/iPad:优先核对 VPN 应用的系统级接管状态
iOS/iPadOS 不适合用“手动改 Wi-Fi DNS”作为唯一判断方法。先确认 VPN 应用显示已连接,再查看是否有“全局、按应用、分流、DNS 保护、断线保护”等选项;如果只有浏览器扩展或应用内代理,它可能只影响该应用。Apple 文档说明,VPN 路由可以包含或排除不同流量,因此必须以客户端实际提供的模式和复测结果为准。Apple VPN 路由说明
修复后如何确认:一次测试不够,按闭环复测
- 恢复到固定网络:不要在复测过程中同时切换 Wi-Fi、移动网络和热点。
- 关闭浏览器额外代理扩展,或固定使用一个浏览器,避免浏览器 DoH 与系统 DNS 同时变化。
- 连接 VPN 的同一节点或同一地区,等待客户端显示稳定连接。
- 重复在线 DNS 测试,并保存 DNS 解析器、组织、地区、IPv4 和 IPv6 结果。
- Windows 使用
nslookup,macOS 可使用系统网络工具或dig,对比命令行与浏览器测试是否一致。 - 关闭 VPN 后再测一次,确认结果能回到原网络状态;如果关闭后仍保持异常,检查浏览器 DoH、代理扩展、系统 DNS 或路由器设置。
- 切换另一种网络,例如从 Wi-Fi 改为移动热点,再重复一次。若只在某个网络出现问题,重点检查该网络的 DHCP、路由器 DNS、企业网关或 IPv6。
如果在线测试显示的是 VPN 基础设施或公共解析器,不应仅凭名称判断为泄漏;如果不同浏览器结果不同,优先检查 DoH;如果只有 IPv6 结果暴露本地网络,优先检查 VPN 的 IPv6 支持和路由;如果 VPN 一断开就能继续访问,重点检查 Kill Switch,而不是反复更换公共 DNS。
对于使用 sing-box、Mihomo、Clash Verge Rev、Shadowrocket 或 v2rayN 等客户端的用户,字段名称、TUN 实现、规则模式和 DNS 行为可能随客户端版本与配置而变化。本文不把某个字段名称当作完整安全证明;应以客户端当前版本的帮助文档、日志和上述基线复测结果为准。
常见问题
VPN DNS 泄漏会让运营商看到哪些信息?
如果 DNS 请求仍交给本地网络或运营商,网络路径上的解析服务可能获得域名查询记录。它不等于对网页正文、账号密码或所有应用流量的完整判断;具体可见范围取决于 DNS、HTTPS、应用连接方式和 VPN 路由。先通过关闭与开启 VPN 的对比确认解析路径,再处理客户端和浏览器设置。
检测结果出现公共 DNS,算不算 DNS 泄漏?
不一定。VPN 可能使用合作解析器或公共解析器,名称不一定显示为 VPN 品牌。判断重点是 VPN 开启后是否仍出现原网络运营商的解析器,以及不同测试方式是否一致。若无法确认,使用同一网络做关闭、开启、关闭三次对比。
开启 Kill Switch 后还需要检查 DNS 吗?
需要。Kill Switch 主要防止 VPN 断线后流量回落,并不自动修复浏览器 DoH、手动 DNS、IPv6 或分流规则。应分别检查 DNS、IPv6 和断线保护,并在每次修改后复测。
浏览器 DNS 测试正常,但游戏或桌面应用仍可能泄漏吗?
可能。浏览器可能使用自己的 DoH 或代理扩展,而桌面应用可能使用系统 DNS、内置解析器或独立网络栈。应在客户端开启系统级或全局隧道后,再用系统命令和应用实际连接情况交叉验证;不要把浏览器一次测试当成所有应用的证明。
要不要直接换成公共 DNS 来修复泄漏?
不建议把更换公共 DNS 当作第一步。公共 DNS 只能改变解析器,不能保证 DNS 请求进入 VPN,也不能解决 IPv6、浏览器 DoH 或分流问题。先恢复清晰的基线,检查客户端是否接管 DNS,再决定是否使用手动 DNS,并记录回滚方式。
常见问题
VPN DNS 泄漏会让运营商看到哪些信息?
如果 DNS 请求仍交给本地网络或运营商,解析服务可能获得域名查询记录。具体可见范围取决于 DNS、HTTPS、应用连接方式和 VPN 路由,不能仅凭一次测试推断全部流量。
检测结果出现公共 DNS,算不算 DNS 泄漏?
不一定。VPN 可能使用合作解析器或公共解析器。应重点比较 VPN 关闭和开启时是否仍出现原网络运营商的解析器,并用浏览器和命令行交叉复核。
开启 Kill Switch 后还需要检查 DNS 吗?
需要。Kill Switch 主要防止 VPN 断线后的流量回落,不能自动处理浏览器 DoH、手动 DNS、IPv6 或分流规则。
浏览器检测正常,桌面应用还可能泄漏吗?
可能。浏览器可能使用独立 DoH 或代理扩展,而其他应用可能使用系统 DNS、内置解析器或不同网络路径。应使用系统级隧道和命令行复核。
要不要直接换成公共 DNS?
不建议把换公共 DNS 当作第一步。它只能改变解析器,不能保证请求进入 VPN,也不能解决 IPv6、DoH 或分流问题。
相关阅读
- 继续看 Mihomo DNS 设置、Fake-IP 与解析失败排查
- 如果 VPN 已连接但网页打不开,按 DNS、代理和节点分层排查
- DNS 修复后仍然变慢,再检查节点、协议、MTU 与丢包
- 使用 sing-box 时,可继续查看日志、配置和网络排查步骤
- 查看更多连接问题的通用排查流程