VPN安⁠全吗？DNS泄漏检测与修复自查方法

连接 VPN 并不等于所有网络信息都会自动隐藏。VPN 主要负责在设备与远端服务器之间建立加密隧道，但域名解析、浏览器的 WebRTC 通信、系统自带的 IPv6 通道，以及应用绕过系统代理的行为，都可能让部分网络请求走另一条路径。于是，网页内容看似通过 VPN 加载，DNS 查询却仍由本地网络提供商处理；或者浏览器在建立音视频连接时暴露了真实的局域网地址和部分公网网络信息。

DNS 泄漏不是“VPN 完全失效”的同义词，而是需要单独定位的配置问题。不同系统、客户端和协议的处理方式并不相同：Windows、macOS、Android、iOS 与 Linux 的 DNS 管理机制不同，原生客户端、Clash Verge、sing-box、Shadowrocket 等兼容客户端的规则能力也有差异。本文按照“理解风险—执行检测—修复配置—再次验证”的顺序，整理一套适合日常自查的方法。

DNS 泄漏到底暴露了什么

DNS 是把域名转换为 IP 地址的服务。当你访问一个网站时，设备通常需要先询问 DNS 服务器，才能知道应该连接哪个地址。如果 VPN 隧道只承载网页连接，却没有接管 DNS 请求，那么本地路由器、公共 WiFi 网关、互联网服务提供商或系统预设的 DNS 服务，仍可能看到你查询过的域名。

DNS 查询通常不直接包含网页正文、账户密码或支付内容，因此不能简单地说“泄漏 DNS 就等于全部数据明文传输”。但域名本身能够反映访问目标、软件更新、工作系统、视频平台或其他服务类别。对于使用公共 WiFi、共享网络或不熟悉的路由器环境，解析请求外泄会增加隐私暴露面，也可能让本地网络对域名访问进行拦截、重定向或错误缓存。

还要区分 DNS 泄漏与 IP 泄漏。前者关注“谁在回答域名查询”，后者关注“外部服务看到的连接出口”。如果 DNS 测试显示的是 VPN 提供的解析服务器，但目标网站仍看到本地公网 IP，问题就不止是 DNS；如果公网 IP 已切换，DNS 却仍显示本地网络服务商，也不能因此认为配置完全安全。

这些服务规格不能替代隐私检测。节点数量多，不代表每条线路都以相同方式处理 DNS；客户端支持多个协议，也不代表当前配置已经启用防泄漏选项。真正有意义的判断，是在计划使用的设备、浏览器、网络和线路组合下进行复查。

常见的外泄来源与表现

最常见的来源是系统 DNS 与 VPN DNS 没有正确切换。部分客户端建立了隧道，却只修改了默认路由，没有修改系统解析器；另一部分客户端在连接断开后没有及时恢复原设置，导致重连期间出现短暂的解析异常。Windows 的网络适配器、macOS 的网络服务顺序、Android 的私人 DNS、iOS 的网络扩展以及 Linux 的 systemd-resolved，都可能影响最终结果。

第二类来源是 IPv6。若 VPN 仅处理 IPv4，而本地网络仍提供 IPv6 连接，浏览器或应用可能优先使用 IPv6 访问目标。此时 IPv4 测试看起来正常，IPv6 流量却从本地网络直接出去。关闭 IPv6 不是所有设备上的最佳方案，但在客户端明确不支持 IPv6 隧道时，它可以作为排查步骤；修改前应记录原配置，并确认不会影响公司内网、家庭设备或其他必要服务。

第三类来源是浏览器 WebRTC。WebRTC 用于网页音视频、屏幕共享和实时通信，可能建立与普通网页请求不同的连接。现代浏览器通常会减少可见地址，但具体结果仍受浏览器版本、权限、网络接口和客户端配置影响。WebRTC 暴露的可能是局域网地址、虚拟网卡地址或公网候选地址，不能把某一次浏览器测试结果扩展成所有应用的结论。

此外，分流规则也会带来误判。规则模式下，某些域名可能被设为直连，某些 DNS 请求则由本地解析以便判断规则。这样的设计未必是漏洞，但如果目标是尽量减少本地网络可见信息，就需要检查 DNS 模式、Fake-IP 或真实 IP 模式、域名嗅探、远程解析和直连例外是否符合预期。

• ✅ 记录连接前后的公网 IP、DNS 服务商和 IPv6 状态。
• ✅ 分别检查浏览器访问与独立应用，不把一个测试结果套用到全部流量。
• ✅ 检查系统 DNS、客户端 DNS、规则模式和分流例外是否互相冲突。
• ❌ 不要只看客户端界面的“已连接”状态，就认定 DNS 已进入隧道。
• ❌ 不要同时开启两个 VPN、代理或网络过滤应用，避免虚拟网卡互相抢占。

动手检测：按顺序确认 DNS 与地址

检测前先关闭浏览器中的无关标签页，暂停其他代理软件，并记下当前连接的网络类型。公共 WiFi、手机热点和家庭宽带应分别测试，因为它们可能下发不同的 DNS、IPv6 和代理设置。检测时最好先在未连接 VPN 的状态记录一次，再连接同一条线路重新测试。

第一步：查看公网出口

打开可信的 IP 检测页面，分别观察 IPv4 与 IPv6 是否存在。如果连接 VPN 后 IPv4 仍显示本地网络出口，说明隧道没有接管该类流量，或当前应用采用了不经过系统 VPN 的连接方式。若页面显示多个地址，先不要急于下结论，需要结合客户端日志、浏览器网络接口和线路协议进一步判断。

第二步：执行 DNS 泄漏测试

使用 DNS 泄漏检测页面时，建议先执行标准测试，再执行扩展测试。测试页面通常会列出多个解析服务器的 IP、组织或地理信息。重点不是服务器数量越少越好，而是观察列表中是否出现本地宽带运营商、公共 WiFi 所属网络或不应出现的家庭路由器上游。VPN 服务商使用第三方 DNS 并不必然是问题，关键在于来源是否符合客户端说明和当前线路设置。

第三步：检查 WebRTC 与浏览器权限

在浏览器的 WebRTC 检测页面中，观察是否出现与本地网络相关的地址。测试期间不要授权网页访问摄像头或麦克风；WebRTC 地址检测与设备权限不是同一件事。若浏览器允许调整 WebRTC 防护选项，可以先使用默认防护，再用无痕窗口重复测试。无痕模式主要减少缓存和扩展影响，并不会自动替代 VPN 或修复 DNS。

第四步：用系统命令交叉确认

桌面系统可以通过命令查看当前解析器。Windows 可在命令提示符中使用 ipconfig /all，检查活动网卡下的 DNS Servers；macOS 可使用 scutil --dns 查看解析器；Linux 可根据发行版使用 resolvectl status 或查看 NetworkManager 状态。命令显示的是系统当前配置，不一定能证明每个应用都遵守它，但可以帮助发现明显的本地 DNS 残留。

Android 和 iOS 的系统限制更多，普通用户通常无法像桌面系统一样查看所有底层请求。此时应结合客户端连接日志、系统 VPN 图标、浏览器测试页面和切换网络后的重复结果判断。不要为了读取底层数据而安装来源不明的证书、描述文件或设备管理配置。

修复 DNS 泄漏的配置顺序

第一步是确认客户端使用了全局 VPN 模式还是规则分流模式。全局模式通常更容易排查，因为大部分流量都应进入隧道；规则模式更灵活，但需要理解直连规则、DNS 规则和应用排除项。Clash Verge、sing-box、Shadowrocket 等客户端的界面和字段名称可能不同，不能只照抄其他软件的截图。应优先查看当前客户端的 DNS、路由、IPv6、Tun 或系统代理选项。

第二步是启用客户端提供的远程 DNS、隧道内 DNS 或防止 DNS 泄漏选项，并重新连接。对于 sing-box 等配置型客户端，需要同时检查 DNS server、route、rule-set 与出站选择，避免 DNS 请求使用了与普通流量不同的 direct 出站。对于 Clash 类配置，要检查 DNS enhanced-mode、nameserver、fallback、proxy-server-nameserver 以及 fake-ip-filter 是否与目标网络兼容。字段存在不代表配置一定正确，最终仍应以实际测试为准。

第三步是清理系统缓存。Windows 可以在命令提示符中执行 ipconfig /flushdns；macOS 和 Linux 的缓存方式随系统服务不同，重启网络服务或设备通常比盲目复制命令更稳妥。Android 的私人 DNS、浏览器安全 DNS 和 VPN 客户端 DNS 可能同时生效；iOS 则要留意内容过滤器、描述文件和其他网络扩展。修改后应断开并重新连接 VPN，再进行测试。

如果 IPv6 仍然绕过隧道，先确认客户端是否明确支持 IPv6。支持时应让 IPv6 通过隧道并配置对应 DNS；不支持时，可在系统或路由器层面暂时关闭 IPv6，随后检查是否影响家庭网络设备。不要在不了解网络结构的情况下直接修改公司电脑、服务器或路由器的全局设置。

WebRTC 方面，可以关闭不需要的浏览器扩展，限制不必要的网站权限，并使用浏览器自身的隐私防护选项。若日常不使用网页音视频，限制 WebRTC 暴露面通常较容易；若依赖在线会议，则不应为了隐藏地址而盲目关闭全部实时通信功能，应在会议平台、浏览器和 VPN 客户端之间进行兼容性测试。

客户端与协议如何影响结果

原生客户端通常会集中处理登录、订阅更新、隧道路由和 DNS，适合希望减少手动配置的人。Windows、macOS、Android、iOS 和 Linux 的官方客户端一般会根据系统能力提供不同选项，但“连接成功”仍只说明隧道建立，不自动证明所有应用和所有地址族都经过隧道。

兼容客户端的优势是规则和协议选择更灵活。Shadowsocks、VMess、Trojan、Hysteria2 和 WireGuard 的连接模型、配置字段与系统接管方式不同，不能仅凭协议名称判断是否防止 DNS 泄漏。协议负责传输或建立连接，DNS 是否进入隧道还取决于客户端路由、解析器、系统接口和规则设置。使用订阅链接导入时，也要确认客户端正确识别订阅格式，并检查导入后的 DNS 与出站配置，而不是只看节点列表是否出现。

在桌面系统上，Tun 模式通常比单纯的系统代理能够接管更多应用流量，但它也可能与其他虚拟网卡、杀毒软件、企业安全客户端发生冲突。移动系统则受沙盒和系统 VPN 接口限制，某些应用可能使用自定义网络栈，测试时必须把“浏览器正常”与“所有应用正常”分开记录。

公共 WiFi、免费 VPN 与支付场景的自查清单

连接公共 WiFi 时，先确认网络名称与登录页面是否可信，不要在未完成 VPN 连接前进行敏感操作。公共网络管理员未必能看到加密隧道内的具体内容，但 DNS、连接时间、设备指纹和未加密的应用流量仍可能暴露。切换到公共 WiFi 后，应重新连接 VPN，并重新检查 DNS 与 IPv6，因为系统可能重新获取网络参数。

选择免费 VPN 时，不要只看“免费”二字。应查看服务方是否说明数据处理、日志、广告、第三方 SDK、流量限制和协议实现。免费服务可能通过广告或其他方式维持运营，也可能缺少可靠的客户端更新。无法解释权限用途、要求安装可疑证书、强制导入陌生配置或频繁弹出无法关闭的页面时，应停止使用。

进行日常支付时，VPN 不是支付安全的全部。应确认浏览器地址、网站证书、账户登录通知和设备安全状态；不要在公共设备上保存支付信息。某些银行或支付平台会因出口地区变化触发额外验证，频繁切换线路可能导致登录中断。遇到支付页面异常时，先停止重复提交，再检查订单状态和账户通知，避免把网络故障变成重复扣款风险。

• ✅ 公共 WiFi 下先完成 VPN 连接，再访问账户和支付页面。
• ✅ 支付前确认公网出口没有因断线而恢复到本地网络。
• ✅ 选择服务时查看客户端来源、权限说明、协议支持和隐私政策。
• ✅ 每次更换客户端或协议后重新检查 IPv4、IPv6、DNS 与 WebRTC。
• ❌ 不要把“节点数量多”当作隐私保护的直接证明。
• ❌ 不要在无法核验来源的应用中输入账户密码或导入长期订阅。

常见问题解答

VPN 显示已连接，为什么还会 DNS 泄漏？

“已连接”通常只表示隧道建立成功，不代表系统所有 DNS 请求都使用隧道内解析器。客户端可能没有接管 DNS、规则模式可能允许直连解析，IPv6 也可能绕过 IPv4 隧道。应分别检查系统 DNS、客户端 DNS、IPv6 和实际测试结果。

检测页面显示第三方 DNS，需要担心吗？

不一定。许多服务会使用公共 DNS、线路所在地区的解析器或自建解析服务。重点是确认它是否与当前 VPN 配置相符，以及是否出现本地运营商、家庭路由器或公共 WiFi 的解析器。来源无法解释时，再检查客户端说明和连接日志。

WebRTC 暴露地址，是否代表 VPN 完全无效？

不一定。WebRTC 使用的连接机制与普通网页请求不同，可能暴露局域网地址、虚拟网卡地址或候选公网地址。应分别查看网页请求的公网出口、DNS 测试和 WebRTC 测试，并根据浏览器隐私选项、网站权限和客户端路由进行修复。

修复后多久需要再次检测？

每次更换客户端、协议、DNS 模式、浏览器、网络环境或系统更新后，都建议重新检测。公共 WiFi、手机热点和家庭宽带应分别验证。保存检测日期、设备、网络、线路和配置摘要，比只记住“以前正常”更有助于后续排查。