VPN 显示已连接，只能说明客户端建立了连接，不能证明设备上的每一种请求都经过同一条加密隧道。浏览器可能使用不同的 DNS 解析方式，WebRTC 也可能依据自身规则收集网络地址；分流设置、IPv6 配置和断线保护同样会影响实际结果。检查时应把 DNS、WebRTC 与流量路由分别验证，而不是只看客户端的连接图标。
DNS 与 WebRTC 泄漏分别是什么
DNS 负责把域名转换成网络地址。访问网站时，设备或浏览器会向 DNS 解析器发出查询。若查询绕过 VPN 隧道，外部网络上的解析服务可能看到查询请求来自你的本地网络；这不等于网页内容一定被读取，也不代表每次 DNS 请求都包含可直接识别个人身份的信息，但它可能暴露访问过的域名或网络使用特征。
DNS 查询路径有时与网页连接路径不同。例如，客户端只代理部分流量，浏览器启用了独立的加密 DNS，操作系统使用了自定义解析器，或某个应用绕过代理，都可能导致解析请求走另一条路径。反过来，测试页面显示某个公共 DNS 服务商，也不一定就证明发生泄漏：VPN 服务可能使用该解析器，浏览器也可能通过加密 DNS 连接它。应结合连接状态、解析器归属与配置判断。
WebRTC 是浏览器用于实时通信的一组技术，常见于语音、视频和点对点连接功能。建立连接时，浏览器可能收集候选网络地址，以便通信双方协商可用路径。测试页面若显示本地地址、公共地址或网络候选信息，含义各不相同：本地地址可能是局域网范围地址，浏览器也可能通过 mDNS 以名称形式隐藏它；公共地址可能是 VPN 出口，也可能是原网络出口。关键是判断是否出现了不应暴露的真实公网出口地址，而不是看到任何地址就认定泄漏。
2 类
重点检查：DNS 与 WebRTC
3 步
对照、连接、复测
1 条
最终判断：实际请求路径
检查结果应当解释成“这次测试、这个浏览器和当前网络环境下观察到什么”，不要据此推断所有应用、所有网络和所有时间都具有相同表现。若正在比较工具或配置，包括了解VPNGF等服务时，也应把客户端能力、浏览器行为和服务端说明分开核对，避免把单个测试结果当作全面的隐私认证。
按步骤自查 DNS 与 WebRTC
动手前先记录环境：使用的操作系统、浏览器、客户端、连接模式，以及是否启用分应用代理或自定义 DNS。测试期间尽量不要同时更换网络、浏览器扩展和代理规则，否则结果变化时难以找到原因。在线检测页面会收到浏览器发出的网络请求，因此选择可信的测试服务，不要在页面中输入账号密码、订阅链接或其他敏感资料。
- 建立未连接基线。关闭 VPN 后打开检测页面，分别查看 DNS 检测与 WebRTC 检测结果。记下解析器名称或网络归属，以及页面显示的公网地址类别；不要公开截图中可能出现的真实公网地址。
- 连接 VPN 后重新测试。确认客户端显示已连接，等待页面重新执行检测。DNS 结果应结合服务说明判断；WebRTC 结果则重点看是否仍出现未连接时的本地网络公网地址。测试页面可能使用缓存，必要时重新载入或清除该站点缓存后再测。
- 对照实际路由。检查客户端是否为全局代理或规则分流，目标检测站点是否被设置为直连；确认浏览器没有被分应用规则排除。若 DNS 服务属于浏览器自带的安全 DNS，需继续确认其连接是否也进入隧道。
- 改变网络再复测。在允许的情况下，从无线网络切换到移动网络，或重新连接当前网络，再运行相同测试。网络变化会改变系统 DNS 和地址候选；复测有助于发现只在特定网络出现的问题。
- 记录而不夸大结论。写下测试时间、客户端模式、浏览器 DNS 设置及观察到的结果。若结果矛盾，先关闭可能影响网络的扩展并重复测试，再分别检查浏览器、操作系统和客户端，避免一次异常就认定服务存在普遍泄漏。
| 观察现象 | 可能原因 | 下一步检查 |
|---|---|---|
| DNS 显示本地网络运营商解析器 | DNS 请求可能未进入隧道，也可能是浏览器或系统使用了独立解析设置。 | 核对解析器归属、客户端 DNS 配置与浏览器安全 DNS 设置，并重复测试。 |
| DNS 显示公共解析服务 | 可能由 VPN、浏览器加密 DNS 或操作系统设置提供，单凭名称无法判定泄漏。 | 对照服务说明，检查解析连接的路由与浏览器配置。 |
| WebRTC 显示 VPN 出口地址 | 候选地址可能沿 VPN 路由呈现，不等同于暴露原网络出口。 | 与未连接基线及当前出口信息比较，避免仅凭地址格式下结论。 |
| WebRTC 显示未连接时的公网地址 | 浏览器候选地址可能绕过隧道，或当前代理模式未接管相关流量。 | 检查浏览器 WebRTC 设置、分流规则及客户端是否提供断线保护。 |
检查浏览器与 DNS 设置
浏览器的安全 DNS、加密 DNS 或 DNS over HTTPS 设置，可能让解析请求由浏览器直接交给指定服务，而不是使用操作系统或 VPN 客户端配置的解析器。它的目的通常是加密 DNS 查询，并不能单独证明请求经过 VPN 隧道。检查时先记下浏览器当前设置，再确认客户端是否支持相应解析方式，以及浏览器到解析服务的连接是否受代理规则管理。
如果怀疑浏览器的 WebRTC 行为暴露了原网络地址，先查看浏览器自身提供的隐私与网络设置，以及当前版本的官方说明。部分浏览器允许限制非代理路径上的 WebRTC 流量，部分浏览器则通过地址候选策略隐藏或减少本地地址信息。设置名称和可用选项会因浏览器、版本及扩展而异，不宜照搬某个菜单路径或安装来历不明的扩展。调整后重新运行同一检测，并实际验证语音、视频等依赖 WebRTC 的功能是否仍正常。
DNS 配置应尽量避免多层设置互相覆盖。操作系统指定一个解析器、浏览器另设加密 DNS、客户端再强制接管 DNS 时，最终路径可能与界面预期不同。逐项记录后，可一次只调整一个设置，再测试结果是否随之改变。不要为了让检测页面只显示某个特定服务商，就随意填写不熟悉的 DNS 地址；选择解析服务还需考虑可信度、稳定性、隐私政策和客户端兼容性。
IPv6 也值得单独核对。若 VPN 隧道只处理 IPv4，而系统或浏览器仍可通过 IPv6 直连，部分请求可能沿另一条路径发出。是否存在这种情况取决于操作系统、客户端和网络环境，不能仅凭设备启用了 IPv6 就断定泄漏。可在客户端文档中确认 IPv6 支持方式，随后在连接状态下使用支持 IPv6 检查的测试页面验证；不确定时，不要通过随意禁用系统网络功能来掩盖问题。
核对分流与断线保护
分流决定哪些请求交给代理出站，哪些请求直连。全局代理通常更容易统一观察路径，但本地设备、局域网服务或特定应用的行为仍受客户端和系统设置影响；规则分流则更灵活，也更需要确认浏览器、DNS 请求及检测页面命中了哪条规则。检查客户端日志或规则匹配记录，比反复更换节点更能帮助定位路由问题。
断线保护常被称为 Kill Switch 或网络锁。它的目标是在隧道中断或客户端退出时，阻止被保护的流量直接从普通网络发出。不同实现可能只保护指定应用、只在客户端运行期间生效，或需要系统授权；“已开启”不代表所有设备流量都已被覆盖。阅读客户端说明，并确认保护范围、启动条件以及手动断开时的行为。
可以在不进行敏感操作的前提下做安全验证：先连接 VPN，确认测试页面与普通网页可用；再按客户端说明触发受控的断线情形，观察受保护的请求是被阻断还是改走本地网络；随后重新连接并确认服务恢复。不要在断线测试时登录重要账户、传输敏感文件或访问可能泄露身份的信息。若客户端没有明确说明断线保护范围，不要把它视为系统级全流量屏障。
- ✅ 确认浏览器与检测站点没有被规则设置为直连，并检查 DNS 请求使用的解析方式。
- ✅ 对照未连接和已连接时的结果，必要时在网络切换后再次检测。
- ✅ 查阅断线保护的适用范围，并验证实际断线时被保护的流量如何处理。
- ❌ 不把连接图标、单次检测或公共 DNS 服务商名称单独当作隐私安全证明。
- ❌ 不将包含公网地址、账户凭据或订阅信息的检测截图和配置公开分享。
建立可重复的隐私检查习惯
隐私自查不是一次性打勾。客户端更新、浏览器版本变化、规则订阅更新、切换网络或启用新的安全扩展，都可能改变 DNS 解析与 WebRTC 候选地址的表现。每次调整重要网络设置后，用相同测试流程复核，并保留不含敏感信息的简要记录，方便比较变化来自哪里。
检测工具只能观察它自身能够看到的请求，不能证明设备上的全部流量都已加密，也不能替代对服务隐私政策、客户端权限和账户安全的评估。还应使用可信来源的客户端，及时更新系统与浏览器，避免把订阅链接、密钥或账户凭据交给不必要的第三方页面。对重要账户，优先启用服务支持的额外验证方式，并谨慎处理浏览器保存的登录状态。
如果多次测试仍显示本地公网地址，应按顺序排查：确认客户端是否实际接管浏览器流量；检查分流规则和按应用代理；核对浏览器加密 DNS 与 WebRTC 设置；再检查 IPv6 支持和断线保护。每次只改变一个条件，并在恢复连接后再次验证。这样既能减少误判，也能判断问题是浏览器配置、操作系统解析路径，还是代理路由范围造成的。
可靠的结论不应依赖一个绿色状态图标或一句“无泄漏”提示，而应能说明测试环境、观察到的地址类型、DNS 解析路径和客户端保护范围。把这些信息分开检查，才能更理性地了解 VPN 在当前设备和网络下提供了什么保护，也能清楚知道仍有哪些请求可能走隧道之外。