开着 VPN 不代表所有网络请求都已经受到保护。客户端界面显示“已连接”，通常只说明某条隧道或代理配置已经建立，并不能直接证明 DNS 查询、浏览器的 WebRTC 通信以及断线后的系统流量都经过了预期路径。DNS 泄漏可能暴露你正在查询的域名，WebRTC 泄漏可能让网页获得本地网络接口或真实出口相关信息，而断线切换处理不当时，应用还可能在 VPN 失效后继续使用普通网络。
这类问题不宜只依赖一次在线检测得出结论。浏览器扩展、系统代理、VPN 客户端的隧道模式、分流规则、IPv6 设置和网络切换状态，都会影响检测结果。更可靠的做法是先记录未连接时的基础状态，再逐项开启保护，分别检查 DNS、WebRTC 和断线行为，最后在不同浏览器与网络环境下复查。下面按照“理解暴露来源—执行检测—调整配置—再次验证”的顺序展开。
先区分 DNS、WebRTC 与断线泄漏
DNS 是把域名转换为 IP 地址的解析服务。当你在地址栏输入一个域名时，设备需要先向 DNS 服务器发起查询。若 VPN 只接管了网页连接，却没有接管系统 DNS，查询可能仍然发送给本地宽带运营商、公共热点或路由器提供的解析服务。即使网页内容最终通过 VPN 出口访问，查询记录也可能暴露你访问过哪些域名。
DNS 泄漏不一定表现为“完全没有 VPN”。更常见的情况是网页出口地址已经改变，但检测页面显示的 DNS 服务商仍属于本地网络；或者 IPv4 查询经过隧道，IPv6 查询却走了原生网络。浏览器启用加密 DNS 后，查询会被封装到 DoH 或 DoT 服务中，但这并不自动表示隐私一定更好。如果浏览器的加密 DNS 绕过了 VPN 客户端设定，查询仍可能走另一条独立路径。
WebRTC 是浏览器用于实时音视频、点对点连接和网络连通性探测的技术。网页在建立 WebRTC 会话时，可能通过 ICE 候选信息识别本地接口地址、局域网地址，或者发现与当前连接相关的公网地址。现代浏览器通常会使用 mDNS 等机制减少本地地址直接暴露，但具体行为取决于浏览器版本、权限、扩展和 WebRTC 设置，不能把“浏览器很新”当成绝对保证。
断线泄漏则发生在 VPN 连接中断、客户端崩溃、电脑从 Wi-Fi 切换到移动热点，或者系统从睡眠状态恢复之后。若客户端没有阻止非隧道流量，系统可能立即恢复普通路由。此时浏览器、同步软件、邮件客户端和后台应用可能在用户没有察觉的情况下继续联网。它与 DNS 泄漏、WebRTC 泄漏是不同问题，需要单独测试。
3
重点检查路径
4
建议复查场景
IPv4
与 IPv6 分开确认
WebRTC
浏览器单独处理
如何检查 DNS 是否泄漏
检测前先关闭 VPN，记录当前网络的出口地址、DNS 服务商和 IPv4、IPv6 状态。然后只开启 VPN，不改变浏览器扩展和系统网络设置，再打开可信的 DNS 泄漏检测页面。检测页面通常会列出执行查询的 DNS 服务器、所属网络或地区，以及是否同时出现多组解析来源。这里要关注“查询由谁处理”，不要只看页面顶部显示的公网 IP。
如果连接后仍显示本地运营商 DNS，首先检查客户端的连接模式。部分代理客户端的“系统代理”只影响支持系统代理的应用，未必接管所有系统 DNS；而 VPN 隧道模式或 TUN 模式通常能够处理更多系统流量，但是否包含 DNS 仍取决于客户端内核与配置。Clash Verge、sing-box 等兼容客户端中，应查看 DNS 模式、监听地址、Fake-IP 或 Redir-Host 相关设置，避免只导入订阅后就认为所有选项已经适合当前设备。
浏览器也是常见的旁路来源。Firefox、Chrome、Edge、Safari 以及隐私扩展可能各自管理安全 DNS。若浏览器启用了“安全 DNS”或 DoH，先记录其服务商，再分别测试开启与关闭后的结果。不要同时修改太多选项，否则很难判断问题到底来自浏览器、客户端还是系统。若关闭浏览器安全 DNS 后 DNS 结果恢复正常，说明浏览器此前可能绕过了客户端的 DNS 处理；若开启后结果更稳定，也要确认该解析请求确实通过了你信任的路径。
IPv6 需要单独观察。设备即使通过 IPv4 连接了 VPN，也可能保留原生 IPv6 路由。如果检测页显示 IPv6 地址来自本地网络，或者在 VPN 断开后 IPv6 与连接前完全一致，应在客户端中查找 IPv6 防泄漏或 IPv6 隧道选项。没有明确支持时，不要随意手工填写未知的 IPv6 参数；可以先按客户端说明关闭 IPv6，随后重新连接并进行对照检测。
DNS 泄漏的处理顺序
- 确认客户端使用的是 VPN 隧道模式，还是仅修改系统代理的应用代理模式。
- 检查客户端 DNS 设置、分流规则和启动方式，确认 DNS 请求没有被规则送往直连出口。
- 查看浏览器是否单独启用 DoH、安全 DNS 或 DNS 相关扩展，并一次只调整一个选项。
- 分别检查 IPv4 与 IPv6，尤其要留意网络切换和电脑从睡眠恢复后的状态。
- 清理浏览器 DNS 缓存或重启客户端后再次检测，避免把旧连接结果当成当前结果。
如何检查和限制 WebRTC 泄漏
WebRTC 检测应在连接 VPN 后进行，并且最好在常用浏览器中分别测试。打开检测页面后，观察页面是否列出本地局域网地址、原始公网地址、VPN 出口地址或 IPv6 地址。检测结果中出现内网地址不一定等于真实公网身份泄漏，因为部分浏览器会展示局域网接口信息；真正需要重点关注的是连接前使用的公网地址是否仍可被网页识别，以及是否有未预期的 IPv6 地址出现。
浏览器代理设置与 WebRTC 不是完全相同的通道。某些代理只处理 HTTP 或 HTTPS 请求，而 WebRTC 的候选地址收集、UDP 通信和点对点连接可能采用不同机制。因此，即使普通网页已经显示 VPN 出口，也不能推断 WebRTC 已经按照相同路径工作。代理客户端支持的 TUN 模式可以覆盖更多系统流量，但浏览器本身的 WebRTC 策略仍然值得单独检查。
在基于 Chromium 的浏览器中，可以查看隐私与安全设置、WebRTC 相关策略以及扩展权限；Firefox 则可以在高级配置和隐私设置中检查 WebRTC 行为。不同版本的名称可能变化，建议以当前版本的设置说明为准。若不需要网页实时通话，可以限制 WebRTC 暴露本地接口的能力；若必须使用视频会议，则不要盲目完全禁用 WebRTC，而应优先选择限制本地地址候选、避免不必要点对点暴露的设置，并在目标会议页面复测麦克风、摄像头和通话功能。
移动设备也不能忽略 WebRTC。Android 和 iOS 上的浏览器可能受系统权限、应用内浏览器、VPN 配置方式和后台切换影响。Shadowrocket 等客户端通常以系统 VPN 或代理配置接入网络，但浏览器内置的 WebRTC 行为仍由浏览器决定。若同一账户在手机浏览器、桌面浏览器和应用内网页中表现不同，应分别记录，不要只用桌面端检测结果代表所有设备。
- ✅ 连接 VPN 前后分别记录公网地址，确认连接后的结果没有回到原始出口。
- ✅ 在常用浏览器和隐私模式中各做一次对照，排除扩展或缓存影响。
- ✅ 需要视频会议时，限制不必要的本地地址暴露，同时测试通话功能是否正常。
- ❌ 不要把检测页面显示的每一个局域网地址都直接判断为公网身份泄漏。
- ❌ 不要安装来源不明的“防泄漏扩展”，它们可能读取浏览内容或修改代理设置。
检查断线保护与网络切换
断线测试应先保存工作，再关闭客户端的自动重连，避免测试期间连接立即恢复。连接 VPN 后打开一个普通网页或持续请求的应用，随后使用客户端的断开按钮，观察现有请求是否停止，以及浏览器能否在无提示的情况下继续访问。也可以在 Wi-Fi、移动热点和有线网络之间切换，检查客户端是否重新建立保护，而不是在切换瞬间让应用直接使用普通网络。
如果客户端提供 Kill Switch、网络锁、阻止非 VPN 流量或类似选项，应先阅读其说明，再在非关键任务中启用。该功能的目标是在隧道不可用时阻止流量外发，而不是让所有应用永远无法联网。某些实现只在客户端进程运行时有效，退出客户端、系统重启、权限变化或网络服务重置后可能失效，因此还要检查启动项、系统 VPN 权限和防火墙规则。
Windows 和 macOS 用户应分别查看系统网络适配器、系统代理与防火墙状态。Linux 用户还需要关注 NetworkManager、systemd-resolved、iptables 或 nftables，以及代理客户端创建的 TUN 接口是否在网络重连后仍然存在。Android 和 iOS 的系统 VPN 通常由客户端申请管理，用户应确认“始终开启 VPN”“阻止无 VPN 连接”等选项是否由当前版本支持。不同系统的名称和权限范围并不完全相同，不能照搬另一平台的设置。
测试结束后，重新开启 VPN 自动连接，确认 DNS、普通网页访问和需要的应用都能恢复。若开启 Kill Switch 后所有网络都被阻断，不要立即认为客户端损坏，先检查是否选择了不存在的接口、是否启用了错误的分流规则，或者客户端是否缺少当前系统的权限。
不同客户端中的配置排查思路
官方 Windows、macOS、Android、iOS 和 Linux 客户端通常会把协议、节点、DNS、分流和断线保护集中在一个界面中。排查时先确认客户端版本与账户配置，再看当前连接是全局隧道、规则分流还是仅应用代理。订阅更新只负责取得新的节点和参数，不一定会覆盖本地手工设置；更新之后应重新检查 DNS 模式、IPv6、TUN 和断线保护。
Clash Verge 适合查看系统代理、TUN、DNS 和规则分流之间的关系。若只开启系统代理，某些不遵循系统代理的应用可能绕过；若开启 TUN，则要确认虚拟网卡、DNS 劫持和路由规则没有冲突。sing-box 的配置项更细，DNS、路由、出站和入站可能分散在不同配置段，修改前应备份配置，并确认 JSON 或订阅转换结果能够被客户端正确解析。Shadowrocket 用户则应关注系统 VPN 状态、全局或规则模式、DNS 设置以及连接断开后的系统行为。
| 排查对象 | 需要确认的内容 | 常见误区 |
|---|---|---|
| 连接模式 | 是系统代理、应用代理，还是 TUN 或系统 VPN 隧道 | 把客户端显示已连接当成所有应用都已接管 |
| DNS 设置 | 解析请求由谁处理，是否存在浏览器独立 DoH | 只查看网页出口，不查看 DNS 服务商 |
| IPv6 路径 | IPv6 是否被隧道接管，或是否需要按说明关闭 | 只测试 IPv4 就宣布没有泄漏 |
| WebRTC | 浏览器是否暴露原始公网地址或不必要的本地候选 | 把局域网地址与公网地址混为一谈 |
| 断线保护 | VPN 中断、网络切换和系统唤醒后是否阻止直连 | 只测试手动断开，不测试自动重连和切网 |
复查结果与日常维护
调整完成后，至少按四种场景复查：VPN 正常连接、VPN 手动断开、网络从一个接入方式切换到另一个接入方式、设备从睡眠或后台恢复。每种场景都观察普通网页、DNS 检测、WebRTC 检测和需要长期连接的应用。检测时尽量使用相同浏览器窗口和相同网络条件，避免因为变量过多而误判。
如果某次检测出现异常，先不要反复更换节点或协议。先保留异常结果，记录客户端模式、浏览器设置、DNS 服务商、IPv4 与 IPv6 展示情况，再逐项恢复默认设置。之后可以更换一个节点或协议进行交叉比较，但更换线路只能帮助判断问题是否与特定节点有关，不能代替 DNS、WebRTC 和断线保护的独立检查。
订阅更新、客户端升级、浏览器升级和系统网络重置都可能改变原有行为。更新后应重新确认系统代理、TUN、DNS、IPv6 与 Kill Switch 状态。不要把订阅链接、完整配置文件、认证令牌或含有节点信息的截图提交给公开检测网站；这些内容可能包含账户权限或连接凭据。若怀疑订阅已经泄露，应按照服务商面板提供的方式重置或重新生成，而不是继续公开使用旧链接。
这类检查不需要一次修改所有高级参数。先建立未连接时的基线，再确认客户端接管范围，接着处理浏览器独立通道，最后测试断线与切网，是最容易定位问题的顺序。对于需要实时通信的用户，应在隐私保护与功能可用之间做出明确取舍；对于普通网页使用者，则应优先保证 DNS 不旁路、IPv6 不意外直连，并让客户端在隧道失效时阻止未受保护的流量。