VPN 安全不能只看客户端上是否显示“已连接”。连接建立后，网页请求、域名解析、浏览器实时通信和系统后台服务，可能采用不同的网络路径；其中任何一个环节配置不当，都可能让真实网络地址、访问过的域名或设备状态暴露给不应看到的一方。DNS 泄漏与 WebRTC 泄漏并不意味着所有隐私都已经失守，但它们确实是值得优先排查的信号。更可靠的做法是先理解泄漏发生在哪里，再使用多个角度重复检测，最后根据设备、浏览器和客户端的实际设置进行修复。
VPN 连接后，哪些信息仍可能暴露
VPN 通常会在设备与远端入口之间建立加密隧道，将符合规则的网络流量送入隧道，再由出口访问目标服务。加密隧道主要解决传输路径上的窃听和篡改问题，但它并不会自动替所有应用接管网络，也不会让网站无法通过账号、浏览器特征或主动授权识别用户。因此，“连接成功”与“所有请求都经过同一路径”是两件不同的事。
DNS 泄漏发生在域名解析环节。例如浏览器访问某个网站时，先要把域名解析成 IP 地址。如果 VPN 只代理后续的网页连接，却让系统继续向本地运营商、路由器或公共 WiFi 提供的 DNS 服务器发起查询，那么解析请求可能绕过隧道。查询内容未必直接包含网页正文，但域名记录可以反映用户正在访问哪些服务，也可能造成地区解析结果与代理出口不一致。
WebRTC 泄漏则与浏览器的实时通信能力有关。视频会议、语音通话、屏幕共享和部分网页应用会使用 WebRTC 建立点对点连接。为了完成连接协商，浏览器可能收集候选网络地址，包括本地网络接口地址、局域网地址或某些情况下可观察到的公网地址。现代浏览器已经逐步限制这类暴露，但具体行为仍受浏览器版本、权限、扩展和网站实现影响。
90+
国家覆盖
200+
线路数
14 天
退款保障
不限
同时在线设备
DNS 泄漏怎么自查
开始检测前，先关闭不必要的浏览器标签页、云盘同步和自动更新，再确认 VPN 客户端已经连接到计划使用的线路。测试期间不要频繁切换节点，因为不同线路可能使用不同的 DNS 策略。还要记下当前网络环境，例如家庭路由器、公司网络或公共 WiFi，这些信息有助于解释检测结果。
先建立直连与连接后的对照
- 断开 VPN，打开可信的 DNS 检测页面，记录检测到的解析服务商和服务器归属。不要只看页面顶部显示的公网地址。
- 关闭页面后连接 VPN，等待客户端显示连接稳定，再重新打开同一检测页面。
- 比较两次结果中的 DNS 服务商、服务器位置和网络归属，而不是只比较某一个地址。
- 关闭 VPN 后再次检测，确认结果会随连接状态发生合理变化，避免把浏览器缓存误认为新的解析结果。
如果连接 VPN 后仍然反复出现本地网络服务商的 DNS 服务器，或者结果同时混入本地和远端解析服务，就需要继续排查。常见原因包括客户端只启用了浏览器代理、系统的 IPv6 解析没有被接管、分流规则把 DNS 请求排除在外，或者操作系统保留了旧的网络接口优先级。检测页面本身也可能使用缓存，因此应清理浏览器缓存、使用隐私窗口或重新建立网络连接后复测。
不同系统中的检查方向
Windows 用户可以查看当前网络适配器的 DNS 配置、活动路由和虚拟网络接口，重点确认 VPN 连接建立后是否出现新的 DNS 设置，以及原有网卡是否仍被系统优先使用。macOS 用户可在网络设置中查看当前服务顺序，并注意 WiFi、网线和 VPN 服务同时存在时的优先级。Linux 用户则应检查系统解析服务和 VPN 客户端的 DNS 接管方式，尤其要留意 NetworkManager、systemd-resolved 或其他本地解析服务之间是否产生冲突。
Android 和 iOS 设备的系统权限更受限制，普通用户通常无法像桌面系统那样查看所有底层请求。可以先在断开和连接两种状态下使用同一个检测页面，再观察 VPN 客户端是否提供“保护 DNS”“阻止 DNS 泄漏”或类似选项。若设备启用了系统级私人 DNS、企业配置文件或其他安全应用，也应暂时确认它们是否会改变解析路径。不要同时开启多个会接管 DNS 的工具，否则检测结果可能难以解释。
WebRTC 泄漏如何验证与理解
WebRTC 检测需要在支持实时通信的现代浏览器中进行。连接 VPN 后打开专门的 WebRTC 检测页面，允许页面执行必要的浏览器测试，但不要授予摄像头、麦克风或屏幕共享权限；检测网络候选地址并不等于必须打开这些设备。页面通常会列出本地地址、局域网地址、代理地址或公网地址，具体字段名称会因浏览器和检测工具不同而变化。
观察结果时，首先区分本地地址与公网出口地址。本地地址可能属于局域网接口，只能说明设备连接过某个网络，不一定代表公网身份暴露。真正需要重点关注的是：在 VPN 已连接时，检测页面是否出现了与当前真实网络相对应的公网地址；是否出现了不应直接暴露的 IPv6 地址；以及浏览器是否在未经过预期代理路径的情况下建立候选连接。
不同浏览器的 WebRTC 行为并不完全一致。浏览器设置、隐私防护级别、扩展以及企业策略都可能影响候选地址收集。某些扩展会修改 WebRTC 的接口访问方式，但扩展自身也可能读取浏览器网络信息，因此应优先使用浏览器内置隐私设置和可靠客户端功能，避免安装来源不明的“防泄漏”插件。移动端浏览器还可能受到系统 WebView 和应用权限模型影响，桌面浏览器的检测结果不能直接代表手机上的所有应用。
检测到异常后的处理顺序
- 先确认 VPN 客户端使用的是系统级 VPN 或虚拟网络接口，而不是只为某个浏览器设置的手动代理。
- 在客户端中查找 WebRTC 防护、IPv6 防护、全局路由或阻止直连等相关选项，并逐项记录修改内容。
- 关闭浏览器中不必要的实时通信权限，清理站点权限和缓存后重新启动浏览器。
- 重新连接 VPN，再检测公网地址、候选地址和 DNS 结果是否一致地经过预期出口。
- 使用另一款浏览器或新的浏览器配置文件复测，以排除扩展和旧缓存干扰。
如果只有某个网站报告异常，而其他检测页面没有发现真实公网地址，应先检查该网站的脚本实现、浏览器权限和缓存，不要马上认定客户端失效。反过来，如果多个浏览器和多个检测页面都观察到真实网络出口，说明问题更可能位于系统路由、IPv6、客户端模式或线路配置，需要从设备层面继续处理。
Kill Switch、协议与分流怎样影响安全性
Kill Switch 的作用是在 VPN 隧道中断、客户端退出或线路切换期间，阻止符合保护范围的流量直接恢复为普通连接。它解决的是“短暂断线时是否自动直连”，并不等同于 DNS 防护，也不能阻止用户主动把某个应用设置为直连。启用后应确认规则覆盖范围：有的客户端只保护浏览器流量，有的可以保护整个系统；移动系统则可能要求通过系统 VPN 设置确认“始终开启”或类似功能。
协议选择也会影响连接的可维护性和兼容性。WireGuard 配置简洁、切换网络时恢复较快，适合手机和桌面设备；OpenVPN 生态成熟，参数与客户端选择较多；Shadowsocks 更常见于代理型客户端；VMess、Trojan 和 Hysteria2 则可能出现在不同服务端与兼容客户端组合中。协议名称本身不代表绝对安全，也不能替代正确的证书验证、密钥保护、路由策略和客户端更新。
使用 Clash Verge、sing-box、Shadowrocket 或系统官方客户端时，必须先确认订阅导入方式和模式。规则分流可以让本地银行、公司内网和局域网设备保持直连，也可能让某些隐私敏感请求意外绕过隧道；全局模式覆盖范围更广，但可能影响本地服务、打印机和办公系统。导入订阅链接时，应从账户面板或可信页面复制，避免把链接发布到群组、截图或公开文档中，因为订阅链接通常相当于配置访问凭证。
- ✅ 需要完整保护时，优先确认客户端是否为系统级 VPN，而不是单一浏览器代理
- ✅ 开启 Kill Switch 后，断开隧道并测试浏览器、终端和后台应用的实际行为
- ✅ 使用分流时，检查 DNS、IPv6、实时通信和目标应用是否被错误加入直连
- ✅ 更新客户端与订阅配置前，先确认来源和权限，避免导入陌生配置
- ❌ 不要同时运行两个会创建虚拟网卡或修改系统代理的客户端
- ❌ 不要把协议名称、节点标签或测速排名当作完整的隐私安全证明
公共 WiFi 下的安全自查流程
公共 WiFi 的主要风险不只是网络速度慢，还包括热点名称仿冒、认证页面被篡改、局域网设备互相可见以及连接在切换时短暂中断。连接前先确认热点名称和密码来源，关闭设备的自动加入陌生网络功能；连接后再启动 VPN，并等待客户端明确显示隧道建立。若必须先通过网页认证才能上网，可先完成必要的热点登录，再立即连接 VPN，同时避免在认证页面输入与重要账户相同的密码。
在机场、酒店、展会或咖啡店等环境中，尽量关闭文件共享、网络发现和不必要的局域网服务。不要因为 VPN 已连接就忽略网站自身的 HTTPS、账号多因素验证和设备锁屏。VPN 可以减少本地网络观察到的内容，但无法阻止钓鱼页面窃取用户主动输入的信息，也不能替代操作系统补丁、浏览器更新和账户安全设置。
网络从移动数据切换到 WiFi、从 WiFi 切换到另一热点，或设备从休眠状态唤醒后，建议重新执行一次简化检查：确认客户端仍处于连接状态，访问检测页面观察 DNS 和公网出口，再打开需要长期保持的网页或终端任务。若 Kill Switch 生效，短暂断线期间应用可能暂时无法访问，这是保护机制的一部分；如果应用仍然顺畅访问，却检测到真实出口，则应检查 Kill Switch 是否只覆盖部分程序。
| 检查环节 | 应观察的现象 | 异常时的处理方向 |
|---|---|---|
| 连接状态 | 客户端显示已连接，虚拟接口正常工作 | 重启客户端并检查权限、网络适配器 |
| DNS 请求 | 解析服务符合当前保护策略 | 检查 IPv6、系统 DNS 与分流规则 |
| WebRTC 候选 | 不出现真实公网出口或不应公开的接口 | 检查浏览器权限、扩展和 WebRTC 防护 |
| 断线行为 | 隧道中断时受保护流量不会自动直连 | 开启并验证 Kill Switch 覆盖范围 |
| 网络切换 | 恢复连接后 DNS、出口和应用路径保持一致 | 重新连接并复测，不要只看客户端图标 |
完成一次完整的 VPN 安全自查
一次合格的自查不需要追求复杂工具，而要保证测试覆盖不同层面。先在当前网络下记录未连接 VPN 时的基础结果，再固定客户端、线路和浏览器，依次测试 DNS、WebRTC、IPv6 和断线行为。之后切换到另一种网络环境，重新连接并重复关键步骤。这样可以区分客户端配置问题、特定网络问题和浏览器自身行为。
记录时不要只写“安全”或“不安全”，而应写清楚检测时间、设备系统、使用的客户端、连接模式、是否启用分流、浏览器设置以及检测页面显示的结果。遇到异常时，一次只修改一个设置，然后重新检测。若同时改动协议、节点、DNS 和浏览器扩展，最后即使结果变好，也无法知道真正起作用的因素。
还要把隐私边界理解完整：VPN 主要保护设备到 VPN 入口之间的网络路径，不能保证目标网站不记录账号活动，不能阻止恶意软件读取本地数据，也不能让用户免于钓鱼、弱密码和错误权限的风险。对于办公、支付和重要账号，仍应使用 HTTPS、多因素验证、独立密码和可信设备。VPN 安全是网络路径管理的一部分，而不是所有安全问题的单一答案。