VPN 是否安全,不能只看客户端界面上的“已连接”三个字。真正需要确认的是:设备访问域名时发出的 DNS 请求由谁处理,浏览器是否通过 WebRTC 暴露本地或公网地址,客户端是否正确接管了应用流量,以及连接所使用的协议和加密方式是否与当前场景匹配。只要其中一个环节没有经过预期的保护,IP 地址、访问目标或网络环境信息就可能被泄漏。

DNS 泄漏并不一定意味着 VPN 完全失效。更常见的情况是,隧道本身已经建立,但操作系统仍把域名解析请求交给本地运营商;或者浏览器、某个应用绕过了系统代理;也可能是切换网络、睡眠唤醒或更换客户端后,旧的 DNS 设置没有及时恢复。下面将从原理、检测、修复到日常防护逐步说明,帮助你建立一套可以重复执行的检查流程。

DNS 泄漏到底泄漏了什么

当你在浏览器中输入一个域名时,设备通常需要先把域名转换成 IP 地址。这个转换过程就是 DNS 查询。查询内容可能包含你正在访问的域名,DNS 服务商则可能看到请求来源、时间和查询记录。即使网页正文通过加密连接传输,DNS 请求也可能在连接建立前沿着本地网络发送。

正常情况下,VPN 客户端会通过隧道转发 DNS 请求,或者把系统解析器切换到由客户端指定的远端解析服务。若客户端只设置了浏览器或系统代理,却没有接管 DNS,系统仍可能使用路由器、运营商或公共网络提供的解析器。此时网页能够打开,IP 地址也可能已经变化,但 DNS 检测结果会显示本地网络相关的服务器。

DNS 泄漏通常有几种来源。第一种是系统代理模式的能力有限:遵循系统代理的浏览器可以通过代理访问网页,但部分应用仍直接访问网络。第二种是 TUN 或虚拟网卡模式配置不完整,流量被接管了,DNS 却被规则放行。第三种是 IPv6 环境没有同步处理,IPv4 请求经过隧道,IPv6 请求则从本地链路发出。第四种是客户端断开后遗留了自定义 DNS,导致后续结果与当前连接状态不一致。

IP

检查出口地址

DNS

检查解析服务器

WebRTC

检查浏览器地址

IPv6

检查额外路径

因此,DNS 泄漏检测不能只做一次,也不能只看“网页能否访问”。更可靠的做法是先断开 VPN 记录基线,再连接 VPN 重复测试,最后切换网络或客户端后再次确认。如果连接前后 DNS 服务器完全不变,或者仍出现明显属于本地网络的解析器,就应继续排查客户端的 DNS 接管和分流设置。

加密协议与安全边界怎么判断

VPN 的安全性由多个层面共同决定。加密协议负责保护设备与远端入口之间的传输内容,认证机制负责确认连接对象,路由和 DNS 设置则决定哪些请求真正进入隧道。协议名称本身不是绝对的安全评级,同一个协议在不同客户端核心、参数和配置下,实际表现也可能不同。

常见的 Shadowsocks 更接近加密代理,配置相对灵活,适合由兼容客户端进行节点管理;VMess 和 Trojan 通常依赖特定传输与认证配置,导入时不能只复制地址和端口;Hysteria2 针对高延迟或易丢包环境采用不同的传输设计,但需要客户端核心正确支持。WireGuard 则是现代 VPN 协议,结构较简洁、性能较好,通常以密钥和隧道路由为核心。无论选择哪一种,都应优先使用服务商官方提供的订阅或配置,不要手动猜测参数。

还要区分传输加密与匿名性。加密可以降低本地网络观察到具体内容的机会,但 VPN 服务端仍可能看到连接时间、出口请求和部分元数据;网站也可能通过账号、Cookie、浏览器指纹或主动提交的信息识别用户。VPN 不是隐身工具,DNS 防护也不会自动清除浏览器历史、账户活动或设备上的恶意软件。

检查层面 它主要保护什么 常见误区 应确认的内容
连接协议 设备与远端入口之间的传输 认为协议名称越多就一定越安全 客户端是否支持、参数是否完整、日志是否报错
DNS 处理 域名查询请求的转发路径 网页打开就认为 DNS 已受保护 解析器是否随 VPN 连接切换,IPv4 与 IPv6 是否一致
流量接管 哪些应用和请求进入隧道 只开启系统代理却期待所有程序都被接管 规则模式、TUN 模式、绕过列表和应用代理设置
浏览器接口 网页可获取的网络地址信息 只检测公网 IP,不检查 WebRTC 浏览器是否允许 WebRTC 暴露候选地址
安全判断:不要用“能连上”替代完整验证。协议、DNS、应用路由和浏览器行为必须分别检查,才能知道保护范围。

动手检测 IP、DNS 与 WebRTC

检测前先关闭 VPN,使用浏览器访问可信的 IP 和 DNS 检测页面,记录页面显示的公网地址、IPv4 或 IPv6 地址、DNS 服务商以及检测时间。这里的重点不是某个检测网站给出的分数,而是保存连接前后的对照结果。不要同时开启其他代理、加速器或浏览器扩展,否则很难判断到底是哪一层改变了网络路径。

  1. 退出其他会修改系统代理、DNS 或虚拟网卡的工具,确保当前只有一个主要客户端参与测试。
  2. 断开 VPN,打开 IP 检测页面,记录公网出口、DNS 服务器和页面显示的 WebRTC 地址。
  3. 启动 VPN,等待客户端显示连接成功,再刷新检测页面,不要只使用缓存结果。
  4. 比较连接前后的公网 IP。若出口没有变化,先检查系统代理、TUN 模式和规则是否真正启用。
  5. 查看 DNS 结果。如果仍然全部来自本地运营商、家庭路由器或公共 WiFi 的解析器,应检查 DNS 接管选项。
  6. 查看 WebRTC 检测结果,确认页面没有显示不应公开的本地地址或未预期的公网出口。
  7. 关闭 VPN 后重新检测,确认客户端没有把错误的 DNS、代理端口或路由规则遗留在系统中。

DNS 结果需要结合网络环境判断。检测页面显示的服务器所在地不一定等于 VPN 出口所在地,因为不同服务可能采用独立的 DNS 集群,也可能使用 Anycast 或集中式解析。真正值得关注的是:连接后是否仍暴露了本地运营商名称、家庭路由器地址或公司网络的内部解析域名。如果名称不明显,可以在断开和连接状态下重复测试,观察结果是否随隧道变化。

WebRTC 是浏览器提供实时通信能力的一组接口,视频通话、语音通话和点对点连接会通过它寻找候选网络地址。不同浏览器版本、权限设置和客户端模式会影响检测结果。看到内网地址不一定等于公网 IP 泄漏,但如果页面显示了当前网络的公网地址,或者连接状态变化后仍稳定暴露未预期的出口,就应检查浏览器的 WebRTC 防护设置以及 VPN 客户端是否支持相关处理。

在客户端中修复 DNS 泄漏

不同客户端的选项名称可能是“远程 DNS”“DNS 劫持”“DNS 通过代理”“增强模式”或“虚拟网卡 DNS”。名称不同并不代表功能完全相同。设置前应先确认客户端使用的是系统代理、TUN 模式还是单独的本地代理端口。系统代理主要影响遵循系统设置的应用,TUN 模式则通过虚拟网卡接管更广泛的网络流量,但也更容易与安全软件、虚拟机和其他网络工具冲突。

使用 Clash Verge、sing-box 或 Shadowrocket 等兼容客户端时,导入订阅后不要立即修改大量规则。先确认配置文件能够正常解析,再查看 DNS 模式、Fake-IP 或真实地址解析策略、IPv6 开关和绕过列表。某些规则会让国内域名、本地局域网或特定应用直连,这属于设计上的分流,不一定是泄漏;但如果你不清楚规则含义,就不应把“直连”误认为“已经保护”。

如果客户端支持 DNS 劫持或 TUN DNS 接管,可以先启用该功能,再重新测试。若仍有异常,逐项检查以下项目:系统网络适配器中是否存在旧的手动 DNS,客户端是否只对 IPv4 生效,浏览器是否启用了独立的安全 DNS,应用是否自带 DoH 或 DoT,分流规则是否把 DNS 请求发送到本地。浏览器自己的加密 DNS 可能绕过系统解析路径,因此它不一定会表现为传统意义上的运营商 DNS,但仍要确认请求通过的服务器是否符合你的使用预期。

特别检查 IPv6 与浏览器安全 DNS

IPv6 是最容易被忽略的额外路径之一。部分客户端只处理 IPv4,设备却仍通过 IPv6 访问检测页面或目标服务。此时可能出现“IPv4 已变化、IPv6 未变化”的结果。解决方式包括启用客户端对 IPv6 的完整支持、在确认需求后暂时关闭系统 IPv6,或按照服务商文档配置 IPv6 路由。不要在没有了解局域网结构的情况下随意修改路由器设置。

Chrome、Firefox、Edge 等浏览器可能提供“安全 DNS”或类似功能。它们会直接向指定解析服务发送加密查询,绕过传统的系统 DNS。加密传输可以减少本地网络窥探,但不代表这个解析服务天然值得信任,也不代表 VPN 的所有应用都使用同一解析路径。排查时应暂时记录浏览器设置,分别测试开启和关闭后的结果,避免把不同机制混在一起。

修复顺序:先确认流量接管方式,再处理 DNS 接管、IPv6 和浏览器安全 DNS;一次只改一个变量,最容易找到真正原因。

公共 WiFi 与日常使用中的防护

公共 WiFi 的主要风险不只是 DNS 泄漏,还包括假冒热点、弱加密、网关篡改、强制门户和同网段设备探测。连接 VPN 可以保护设备与远端入口之间的传输,但不能证明热点本身可信,也不能阻止你主动打开钓鱼页面或提交账号密码。第一次连接陌生 WiFi 时,应先确认网络名称,避免自动连接相似名称的热点。

在咖啡店、机场或酒店网络中,强制门户可能要求先打开一个网页完成认证。此时可以先关闭 VPN,完成必要的 WiFi 登录,再立即启动客户端并重新检测。若客户端连接后无法访问认证页面,不要反复切换多个节点;更稳妥的做法是断开网络、清除错误的代理状态,完成认证后再启用 VPN。离开公共场所后,应删除不再使用的网络配置,避免设备下次自动连接。

移动设备还需要关注后台切换。Android 和 iOS 在省电、网络切换和后台权限方面可能暂停客户端,导致从 WiFi 切换到移动网络时短暂直连。可在系统设置中检查 VPN 的始终开启、断开连接时阻止网络或类似选项,但这些名称和可用功能会因系统版本而不同。启用后仍应测试实际应用,因为某些应用可能使用自带网络栈或独立 DNS。

日常使用时,尽量保持客户端、浏览器和操作系统处于支持状态。订阅更新后检查新配置是否继承了 DNS 与路由设置;系统升级后重新确认虚拟网卡、网络权限和始终开启选项。对于银行、支付和工作账户,不要仅依赖 VPN,仍应使用 HTTPS、多因素认证、设备锁和独立的密码管理方式。

一套可重复的隐私自检清单

隐私防护不是连接一次 VPN 就结束,而是需要在网络环境变化后重复确认。尤其是更新客户端、切换协议、从家庭网络进入公共 WiFi、系统休眠唤醒,以及启用新的浏览器扩展后,都可能改变请求路径。可以把下列清单保存下来,作为每次出现异常时的排查顺序。

如果检测结果异常,建议先截图保存客户端状态和检测页面,但要遮盖订阅链接、用户名、内部地址和工单信息。随后恢复到最简单的配置:单个客户端、单条线路、默认规则、明确的 DNS 设置。确认基础连接正常后,再逐步加入分流、IPv6、浏览器安全 DNS 或其他高级选项。这样能避免多个变量同时变化,减少误判。

最终结论:VPN 的隐私保护效果取决于完整链路,而不是品牌宣传或单一开关。把 IP、DNS、WebRTC、IPv6 和应用路由分别验证,并在网络变化后重复检查,才是更可靠的安全习惯。

常见问题

DNS 泄漏是不是说明 VPN 完全没有加密?

不一定。DNS 泄漏说明部分域名查询可能没有沿着预期隧道传输,不能直接推断所有网页内容都未加密。你仍需要分别检查出口 IP、DNS 服务器、应用流量和 IPv6 路径,再决定是修复 DNS 设置还是更换接管模式。

检测到本地 DNS 服务器就一定是泄漏吗?

如果连接 VPN 后仍显示家庭路由器、运营商或公共 WiFi 的解析器,通常值得进一步排查。但检测页面的识别名称可能不准确,某些服务也会使用集中式 DNS。最稳妥的方法是记录断开与连接状态的结果,并结合客户端日志和系统网络设置判断。

开启浏览器安全 DNS 后还需要检查 VPN 的 DNS 吗?

需要。浏览器安全 DNS 只影响该浏览器的解析请求,其他应用仍可能使用系统 DNS。它也可能绕过客户端的 DNS 策略。开启后应分别测试浏览器和其他应用,并确认所使用的解析服务符合你的隐私和网络需求。

公共 WiFi 中连接 VPN 后就可以放心操作账户吗?

不能完全这样理解。VPN 可以减少本地网络直接观察传输内容的机会,但无法识别所有假冒热点,也不能防止钓鱼网站、恶意扩展或账户被盗。使用公共 WiFi 时仍应确认热点来源,优先使用 HTTPS,启用多因素认证,并避免在不必要的页面输入敏感信息。