VPN安⁠全吗？DNS与WebRTC泄漏自查及防护指⁠南

VPN安全吗，不能只用“已经连接”或客户端里的锁形图标来回答。VPN通常会在用户设备与远端服务器之间建立加密通道，但浏览器、操作系统、应用和网络环境仍可能通过DNS请求、WebRTC接口、IPv6路径、系统代理设置或连接中断后的短暂直连暴露部分信息。更准确的判断方式，是把“隧道是否建立”“哪些流量进入隧道”“哪些身份信息仍可能泄漏”分开检查。

本文重点讨论两类最容易被忽略的风险：DNS泄漏与WebRTC泄漏，同时覆盖公共WiFi、免费VPN和Kill Switch（网络锁）等场景。检测时不要只看一次网页结果，而应在连接前、连接后、切换线路后分别观察，并结合客户端模式、浏览器权限和系统网络设置判断原因。

VPN能保护什么，不能自动解决什么

VPN的核心作用是把符合规则的网络流量送入加密隧道，再由远端出口访问目标服务。这样可以降低本地网络运营者直接查看传输内容的机会，也能避免在公共WiFi中把未加密的应用请求直接暴露给同一局域网中的其他设备。但“加密隧道”不等于“所有隐私问题都消失”，因为隧道两端仍然存在设备、客户端、DNS解析器和远端服务等多个环节。

首先要确认客户端采用的是哪种工作模式。系统代理模式通常只接管遵守系统代理设置的浏览器和应用；命令行工具、部分游戏、更新程序或使用自定义网络栈的应用，可能继续直连。虚拟网卡或系统VPN模式通常能够覆盖更多流量，但仍要留意分流规则、局域网例外、IPv6和应用自身的网络策略。Clash Verge、sing-box、Shadowrocket等兼容客户端，还可能同时存在规则模式、全局模式和直连模式，切换模式后检测结果也会变化。

其次，VPN服务商本身属于信任边界的一部分。服务商可能看见连接时间、流量用量、账户信息或出口请求的元数据，具体范围取决于其技术架构、日志政策和运营方式。因此，判断“安全”不能只看协议名称，还要看服务商是否公开基本隐私政策、客户端来源是否可信、订阅信息是否会被安全保存，以及出现异常时是否有明确的更新和客服渠道。

• ✅ 先确认客户端确实处于连接状态，再检查系统代理或虚拟网卡是否启用。
• ✅ 测试浏览器、常用应用和需要保护的设备，而不是只测试一个网页标签。
• ✅ 了解规则模式下哪些域名或应用被设置为直连。
• ❌ 不要把“节点列表能显示”当成所有流量已经进入VPN。
• ❌ 不要把加密隧道等同于匿名，登录账号和浏览器指纹仍可能识别用户。

DNS泄漏的原理与自查步骤

DNS负责把域名转换为IP地址。当浏览器访问某个网站时，设备通常要先查询对应域名。若VPN只接管后续的网页连接，却没有接管DNS请求，查询可能仍由本地运营商、路由器或公共网络提供的解析器完成。此时目标网站未必能直接看到本地DNS，但DNS服务提供方可能知道设备请求过哪些域名，且解析地区与VPN出口地区不一致时，也会造成区域判断或隐私暴露。

DNS泄漏不一定意味着VPN完全失效。常见情况是网页连接经过远端出口，但DNS仍走本地网络；也可能是浏览器启用了自己的加密DNS，绕过了系统代理；还可能是IPv6使用了另一套解析路径。Windows、macOS、Android和iOS的DNS设置入口不同，浏览器的“安全DNS”选项也可能覆盖系统设置，所以排查时必须同时看客户端、系统和浏览器三层。

1. 建立未连接基线。断开VPN，打开可信的DNS检测页面，记录检测到的解析器、国家或地区信息。不要只记录截图，也要记下当时使用的网络和浏览器。
2. 连接VPN并等待状态稳定。确认客户端已经完成连接，不要在连接动画期间进行判断。若客户端有DNS设置，优先选择由隧道接管或随配置下发的方式。
3. 重复完整检测。观察解析器是否从本地网络提供方变为预期的远端解析路径。如果结果仍显示本地解析器，说明DNS可能没有进入隧道。
4. 检查浏览器独立设置。暂时关闭浏览器的自定义安全DNS，或将其调整为与客户端兼容的方式，再重新测试。部分浏览器的加密DNS可能绕开系统代理。
5. 复核IPv6与分流规则。如果IPv4检查正常而IPv6结果异常，可暂时关闭IPv6进行对照，或者在客户端中确认IPv6是否被正确接管。不要在不了解影响的情况下长期修改系统网络参数。

WebRTC泄漏为什么常被误判

WebRTC是浏览器用于实时音视频、点对点通信和网络连通性探测的一组技术。为了建立连接，浏览器可能通过ICE机制收集候选地址，包括本地网络地址、局域网接口信息以及由STUN服务发现的公网地址。VPN连接后，如果浏览器或客户端没有正确处理WebRTC，检测页面可能仍显示部分地址，从而暴露网络环境线索。

WebRTC泄漏与DNS泄漏不是同一问题。DNS泄漏关注域名解析请求走哪条路径，WebRTC泄漏关注浏览器为实时通信收集到哪些网络候选地址。关闭浏览器的WebRTC能力可能影响视频会议、语音通话或网页协作功能；更稳妥的做法是了解浏览器的权限策略、客户端是否支持相关防护，并在需要实时通信时重新评估可用性。

自查时，先关闭VPN记录一次结果，再连接VPN进行对照。测试页面显示的地址不一定全部等价：有些是本地私有地址，有些是公网候选地址，还有些是经过中继后的地址。不要仅凭页面列出一个地址就断定发生严重泄漏，应结合该地址是否属于当前网络、是否与预期出口相符，以及关闭WebRTC后结果是否变化。

• ✅ 使用常用浏览器分别测试，不要把一个浏览器的结果套用到所有设备。
• ✅ 检查浏览器是否允许网站访问摄像头、麦克风和本地网络相关能力。
• ✅ 需要视频会议时，先确认关闭WebRTC是否会影响业务，再选择限制、询问或允许策略。
• ✅ 规则模式和全局模式都进行一次对照，排除分流造成的差异。
• ❌ 不要把WebRTC显示的所有本地地址都当成公网IP泄漏，也不要忽视真正出现的公网地址。

公共WiFi与免费VPN的额外风险

公共WiFi的风险不只在于网络速度不稳定。热点可能要求通过门户页面登录，也可能存在错误配置、恶意接入点、弱加密或同网段设备互相可见等问题。VPN可以帮助保护进入隧道后的传输，但连接热点、打开门户页面、访问不支持加密的应用以及VPN尚未建立的阶段，仍可能暴露设备和请求信息。

连接公共WiFi时，应先确认热点名称和登录页面来源，避免在门户页面输入不必要的敏感信息。完成网络认证后，再启动VPN并检查连接状态。不要因为VPN已连接就忽略HTTPS证书警告、系统更新提示或应用的异常登录提醒。对于银行、支付和账号恢复等操作，还应依赖服务本身的多因素认证，而不是只依赖网络隧道。

免费VPN则需要从商业模式和权限范围判断。维护服务器、带宽和客户端都需要成本，免费服务可能通过广告、数据分析、流量限制或升级销售维持运营。风险并非所有免费产品都相同，但如果应用要求与功能无关的通讯录、短信、辅助功能或设备管理权限，或者无法说明数据如何处理，就不适合直接用于敏感场景。

选择服务时，可以检查官方网站、客户端签名、隐私政策、协议支持范围和更新渠道。Shadowsocks、VMess、Trojan、Hysteria2、WireGuard等名称只说明协议或实现方式，不能单独证明服务商值得信任。协议负责解决连接和传输问题，日志政策、软件供应链、账户保护与运营透明度仍然需要单独评估。

Kill Switch与日常防护配置

Kill Switch通常称为网络锁、断网保护或始终开启VPN。它的目标是在VPN连接中断、切换线路或客户端退出时，阻止受保护流量回落到普通网络，从而减少短暂直连的机会。不同客户端实现方式差异很大：有的只阻止系统代理流量，有的通过防火墙规则限制更多连接，还有的只在特定模式下生效。

启用网络锁后，应先了解它会不会影响局域网打印、家庭设备访问、系统更新和门户认证。公共WiFi经常需要先访问认证页面，如果网络锁在VPN建立前就完全阻断网络，可能需要按照客户端提供的临时放行或启动流程操作。不要为了恢复网络而随意关闭防护，应该先查看客户端日志，判断是VPN未连接、DNS不可用还是规则阻止了必要请求。

在Windows和macOS上，重点检查客户端是否获得网络扩展、系统代理或防火墙相关权限；在Android和iOS上，检查系统VPN配置、始终开启VPN和阻止无VPN连接等选项是否与客户端功能重复。使用Clash Verge或sing-box时，还要确认系统代理、TUN模式、DNS模式和规则集没有互相冲突；使用Shadowrocket时，要检查全局、配置规则和按需连接状态。

1. 先关闭其他代理。只保留一个主要客户端，避免两个虚拟网卡、系统代理或防火墙规则同时工作。
2. 选择明确的接管模式。需要保护全部设备流量时，确认系统VPN或TUN模式的范围；只想保护浏览器时，确认其他应用不会被误认为已受保护。
3. 启用网络锁并观察断线行为。手动断开线路，检查受保护应用是否停止连接，而不是悄悄改走直连。测试完成后再恢复网络。
4. 切换网络环境。从移动网络切换到WiFi，或从WiFi切换到移动网络，观察客户端是否自动重连，以及重连期间是否有流量外泄。
5. 重新检查DNS和WebRTC。网络切换后不要沿用之前的检测结果，重新加载检测页面并确认规则仍然生效。

一份可执行的安全自检清单

如果你想判断当前VPN是否达到自己的使用要求，可以按下面顺序完成一次完整检查。每一步都应记录客户端名称、运行模式、浏览器、当前网络和线路类型。这样以后出现DNS异常、网页地区错误或应用突然直连时，可以通过对照记录快速定位变化来源。

• ✅ 只从官方渠道获取客户端，确认安装包和更新来源可信。
• ✅ 注册和订阅信息不发布到公开聊天、截图或在线转换网站。
• ✅ 连接后分别检查出口地址、DNS解析路径与WebRTC候选地址。
• ✅ 对比系统代理、虚拟网卡、规则模式和全局模式的实际覆盖范围。
• ✅ 启用适合自己的Kill Switch，并测试断线时应用是否停止连接。
• ✅ 公共WiFi中先完成必要的网络认证，再建立VPN并重新验证。
• ✅ 定期检查客户端权限、隐私政策和协议配置是否发生变化。
• ❌ 不使用两个代理客户端同时接管同一设备。
• ❌ 不把一次检测结果当成永久结论，尤其是在切换网络、浏览器或线路后。

最终，VPN安全性应当被看成“服务商信任、客户端实现、系统配置和使用习惯”的共同结果。DNS泄漏说明解析路径可能没有按预期接管，WebRTC泄漏说明浏览器可能暴露网络候选地址，Kill Switch则用于降低连接中断时的直连风险。逐项检查这些环节，比只看宣传中的协议名称或连接动画更接近真实使用情况。