开启 VPN 后，网页仍能打开，并不等于所有网络请求都经过 VPN。DNS 解析可能继续交给本地网络的解析器，浏览器的 WebRTC 功能也可能尝试建立不经过常规代理路径的连接。它们暴露的信息不一定包含真实姓名或精确位置，但可能让网站看到与你预期不同的公网 IP、解析路径或网络环境。
排查时要区分“检测结果看起来不同”和“真实泄漏”。DNS 测试页显示的解析器名称、所属网络或地理位置，不一定等于你的实际出口位置；WebRTC 页面显示局域网地址，也不必然意味着公网地址已暴露。更可靠的做法是先记录未连接 VPN 时的结果，再连接 VPN，在相同设备、浏览器和网络下重复测试，并结合客户端模式、分流规则与浏览器设置判断。
DNS 与 WebRTC 泄漏分别是什么
DNS 的作用是把域名转换为网络地址。访问网站时，设备通常需要先向某个 DNS 解析器发起查询。若 VPN 只代理网页连接，却没有接管 DNS 请求，查询就可能仍由本地网络、路由器或互联网服务提供商处理。网站页面最终通过 VPN 出口加载，并不能单独证明 DNS 查询也走了相同路径。
WebRTC 是浏览器支持实时音视频、点对点通信等功能的一组技术。建立连接时，浏览器可能通过 STUN 等机制探测可用的网络路径和地址。在代理设置不完整或客户端未接管相关流量时，测试页面可能观察到与 VPN 出口不同的公网地址。某些浏览器会用 mDNS 等方式隐藏局域网地址，因此只看到类似主机名的候选项，不代表公网地址泄漏。
还要区分公网地址与局域网地址。局域网地址通常只在家庭或办公室网络内使用，单独出现并不等于外部网站能够据此直接连接到设备；更值得关注的是，VPN 已连接时，检测页面是否仍能看到未连接 VPN 时的公网出口地址，或者 DNS 查询是否明显绕过了预期路径。
| 检查对象 | 可能暴露的信息 | 不能仅凭什么下结论 |
|---|---|---|
| DNS 查询 | 解析器所属网络、查询路径及部分网络环境信息 | 解析器显示的地理位置与 VPN 出口不一致 |
| WebRTC 候选地址 | 可用于建立连接的网络地址或出口信息 | 只出现局域网地址或经过隐藏处理的主机名 |
| 公网出口 IP | 网站实际看到的网络出口 | 检测页显示的是 VPN 出口 IP，而不是原网络地址 |
| IPv6 连接 | 未被客户端接管的 IPv6 请求可能使用另一条路径 | 设备支持 IPv6 本身就代表发生泄漏 |
按步骤检测 DNS 与 WebRTC
测试前尽量固定环境：暂时不要切换 Wi-Fi 与移动网络，不要同时运行多个代理或 VPN 客户端，也不要在测试中途更换节点。关闭浏览器中不必要的网页标签，记录客户端的代理模式、是否启用 TUN、是否开启 IPv6 处理，以及当前浏览器是否配置了独立代理。这样一旦前后结果不同，才容易定位是哪项设置造成变化。
- 记录基线：断开 VPN，使用同一浏览器查看公网出口地址，并运行 DNS 与 WebRTC 检测。记录检测页面显示的地址类型、解析器信息和浏览器环境，不必把完整结果发布到公开论坛。
- 建立 VPN 连接：确认客户端显示已连接，等待连接状态稳定后再打开新的隐私窗口或无痕窗口。若使用规则分流，确认测试页面和相关域名没有被规则设为直连。
- 检查公网出口：再次查看公网地址。正常情况下，检测到的出口应与 VPN 当前使用的线路相符；它不一定与节点名称所写地区完全一致，也不应只凭单个数据库的地理标签判断。
- 检查 DNS：运行 DNS 泄漏检测并重复刷新结果。重点看查询是否仍由原网络的解析器处理，而不是只看解析器所在城市。公共 DNS 或 VPN 服务使用的解析器可能显示不同品牌与地区，标签不一致本身不足以证明泄漏。
- 检查 WebRTC：查看页面列出的候选地址，将其与断开 VPN 时的基线比较。若 VPN 出口以外的原公网地址仍然出现，先检查浏览器代理范围、客户端的 TUN 接管和 WebRTC 设置，再重复测试。
- 复测其他场景：分别检查连接重建、浏览器重启和网络切换后的状态。某些问题只在 VPN 刚连接、休眠恢复或客户端重连期间出现，单次测试通过不能证明所有场景都已覆盖。
检测结果可能受缓存、浏览器扩展、检测网站脚本、IPv4 与 IPv6 可用性以及客户端规则影响。若结果难以解释，可换一个可信的检测页面交叉验证，但不要把敏感的订阅地址、完整客户端配置或账户信息提交给检测网站。测试应关注路径和地址类型，避免因某个解析器的名称或归属标签产生误判。
- ✅ 在断开和连接 VPN 两种状态下使用相同设备与浏览器进行对照。
- ✅ 确认检测流量没有被规则分流到直连。
- ✅ 将 VPN 出口、DNS 解析器和 WebRTC 候选地址分别判断。
- ✅ 连接重建或网络切换后重新检查，观察是否出现短暂暴露。
- ❌ 不要只凭解析器的地理位置标签判断 DNS 已泄漏。
- ❌ 不要把局域网地址或经过隐藏处理的候选项直接等同于公网泄漏。
常见原因与修复方法
DNS 分流与系统解析设置
若 DNS 查询继续通过本地网络发送，先检查客户端是否提供“代理 DNS”“远程 DNS”或类似选项，并确认相关设置已启用。不同客户端的名称和实现方式可能不同，不要因为菜单中出现 DNS 字样就假设所有查询都会进入 VPN。规则分流模式下，还应检查 DNS 请求是否有单独的分流策略，以及访问检测页面的域名是否被规则设为直连。
浏览器的 DNS-over-HTTPS（DoH）会让浏览器通过加密 HTTPS 请求使用指定的 DNS 服务。它有助于保护查询内容，但如果浏览器自行连接 DoH 服务、而该连接又绕过 VPN，DNS 路径仍可能与预期不同。反过来，DoH 解析器的名称与 VPN 服务不同，也不必然代表泄漏。应检查浏览器的安全 DNS设置、客户端对浏览器流量的接管情况，并避免同时配置多套互相冲突的 DNS 规则。
浏览器代理与 TUN 接管
系统代理通常只影响遵循系统代理设置的应用和请求，不一定覆盖所有 UDP 流量或浏览器功能。若检测发现 WebRTC 暴露原公网地址，可先更新 VPN 客户端与浏览器，再查看客户端是否支持 TUN 模式或完整流量接管。切换模式前应阅读客户端说明，因为 TUN 可能改变本机路由、DNS处理和局域网访问方式。
部分浏览器允许通过隐私设置或扩展限制 WebRTC 暴露的地址信息。优先使用浏览器内置选项或可信扩展，避免安装来源不明、要求读取所有网页数据的工具。限制 WebRTC 可能影响网页语音、视频会议和点对点应用；若相关功能不可用，应逐项调整设置并复测，而不是一次关闭所有网络功能。
IPv6、休眠恢复与连接切换
设备和网络支持 IPv6，而 VPN 客户端只处理 IPv4 时，部分请求可能通过 IPv6 直连。先查看客户端是否明确支持 IPv6 隧道或阻断未接管的 IPv6 流量，再用能够分别显示 IPv4 与 IPv6 的检测方式验证。不要把关闭系统 IPv6 当作首选修复方案：它可能影响本地网络、应用连接或其他系统功能，而且不能解决 DNS 分流、WebRTC 或 Kill Switch 配置问题。
休眠唤醒、Wi-Fi 切换、节点重连时，设备可能短暂恢复原网络路由。若问题只在这些时刻出现，应测试客户端的自动重连与断线保护设置，并确认客户端退出或隧道中断时是否会阻止受保护流量直连。修复后再次进行断开、重连和网络变化测试，确保结果不是只在连接稳定时有效。
不止查泄漏：还要检查 VPN 安全设置
DNS 与 WebRTC 检测只能回答部分问题。它们不能证明 VPN 服务的所有运营行为，也不能替代对账户安全、设备系统和浏览器权限的检查。选择服务时，应阅读无日志政策的具体范围：服务是否说明会收集连接时间、来源地址、带宽使用或诊断信息，数据保存多久，是否会因安全排查而临时收集信息，以及政策如何处理法律请求。仅有“无日志”宣传字样，不能代替清晰且可核对的说明。
加密协议也应结合客户端和使用环境判断。WireGuard、OpenVPN、IKEv2 等协议的配置与实现各有特点；Shadowsocks、VMess、Trojan、Hysteria2 等则常见于兼容客户端和不同代理部署中。不能只看协议名称就推断整体安全性，还要考虑客户端是否来自可信来源、是否及时更新、证书校验是否正常，以及 DNS、IPv6 和断线保护是否一并配置正确。不要关闭证书验证来绕过连接错误。
Kill Switch（断线保护）旨在 VPN 隧道中断时阻止部分或全部流量通过普通网络继续传输，但具体覆盖范围取决于客户端、操作系统和设置。应阅读选项说明，确认它保护的是哪些应用和协议，并在理解影响后进行测试。某些实现会阻止局域网访问或影响网络切换；也有实现只在客户端运行期间生效，无法覆盖客户端被强制退出后的所有情况。
- ✅ 从可信渠道安装客户端，保持系统、浏览器与客户端更新。
- ✅ 了解无日志政策的定义、数据范围、保存方式和例外情形。
- ✅ 检查 DNS、IPv6、分流规则与断线保护是否符合自己的使用场景。
- ✅ 使用独立且不重复的账户密码，并保护好订阅链接和配置文件。
- ❌ 不要把“已连接”当作所有应用、所有协议都已进入隧道的证明。
- ❌ 不要为追求检测页显示一致而关闭证书校验或安装来历不明的根证书。
日常复查可以围绕三个问题进行：当前流量由哪个客户端接管，域名查询发往哪里，隧道中断时系统会如何处理。更换浏览器、调整分流规则、升级系统或切换客户端后，原有检测结果可能不再适用。保留简短的本地检查记录，写下测试日期、客户端模式和结果摘要即可，不需要保存完整 IP、账户凭据或订阅内容。
常见问题
DNS 检测显示的地区与 VPN 节点不同，是否就是泄漏？
不一定。检测页面可能根据解析器的注册信息或地理数据库显示地区，而解析器的实际服务位置、出口路径和 VPN 节点位置并非总能一一对应。应检查是否仍由原网络的解析器处理，并结合多次查询、客户端 DNS 设置和连接路径判断。单独一个地区标签不能作为结论。
WebRTC 结果出现局域网地址，需要担心吗？
局域网地址通常用于设备所在的本地网络，且某些浏览器会将其隐藏为 mDNS 主机名。它与公网出口地址不是一回事。重点比较连接 VPN 前后的公网候选地址；如果只看到局域网地址或隐藏后的主机名，不要据此直接认定外部网站看到了家庭公网地址。
关闭 WebRTC 是否是最好的防护方式？
不一定。完全关闭或限制 WebRTC 可能影响语音、视频会议和其他实时通信功能。优先确认 VPN 是否接管浏览器流量，并使用浏览器支持的隐私设置限制不必要的地址暴露。完成调整后，测试常用网页功能和 WebRTC 检测结果，选择兼顾隐私与实际使用的配置。
开启 Kill Switch 后网络无法使用，怎么办？
断线保护可能在隧道不可用时阻止网络流量，这是它的预期行为之一。先检查 VPN 是否成功连接、系统网络是否正常，以及客户端是否有局域网访问或应用排除设置。不要为了恢复连接就盲目关闭所有保护；可按客户端说明逐项调整，再复测正常连接、隧道断开与恢复后的表现。