三条通道：泄漏从哪条缝出去
DNS、WebRTC、IPv6 各有成因
DNS 泄漏发生在解析环节，网页走了隧道但域名解析仍发给本地运营商。WebRTC 泄漏发生在浏览器的候选地址交换环节，会暴露本机内网与公网地址。
IPv6 泄漏发生在协议栈层面。隧道只承载 IPv4 时，系统的 IPv6 流量会绕过隧道直连，表现是「客户端已连接，检测页仍显示真实地区」。
先测哪一条
- 先看 DNS 检测页，出现本地运营商即判定 DNS 泄漏。
- 再看 WebRTC 检测页，出现内网地址即判定 WebRTC 泄漏。
- 最后看 IPv6 检测页，仍有公网 v6 地址即判定 IPv6 泄漏。
三条都堵上之后
- 流量只走隧道一条路，断线时由网络锁切断。
- 此时检测页的三项结果应全部指向节点地区。
- 若仍异常，问题多在浏览器扩展或系统级代理。
| 通道 | 成因 | 收口方式 | 默认状态 |
|---|---|---|---|
| DNS | 解析走本机设置 | 改加密 DNS | 开启 |
| WebRTC | 浏览器直连 STUN | 屏蔽直连探测 | 开启 |
| IPv6 | 隧道不承载 IPv6 | 阻断或隧道内转发 | 开启 |
| 断线空窗 | 隧道中断后直连 | 网络锁规则 | 需授权 |
DNS 泄漏：解析请求也要进隧道
改成加密解析，与隧道同出口
加密 DNS 的作用是把解析请求也放进隧道。客户端内置 5 个 DoH 端点，按延迟就近选择，解析失败时自动切换。
验证方式很直接：连上客户端后打开 DNS 检测页，解析服务器应显示节点地区的服务商，而不是本地的运营商。
改法与验证
- 设置 → 网络 → DNS 模式，选择加密 DNS。
- 断开再重连，让新配置生效。
- 打开 DNS 检测页，确认解析服务器归属地。
仍然泄漏的三种情况
- 浏览器自带加密 DNS 覆盖了系统设置，需在浏览器里关掉。
- 系统级代理或安全软件接管了解析。
- 路由器上写死了 DNS，客户端无法覆盖。
解析耗时参考：加密 DNS 比系统默认多 5–15ms，20 次采样中位 26ms 与 18ms，条件为 300Mbps 家宽与香港节点。
WebRTC 泄漏：浏览器自己报了地址
屏蔽直连探测，通话改走中转
WebRTC 在建立音视频连接时需要交换候选地址。部分浏览器会绕过系统代理直接发探测包，从而暴露真实地址与内网网段。
屏蔽后视频通话仍可用，但不再直连对端，改走中转。代价是连接时间延长 1–3 秒，画质在弱网下可能降一档。
屏蔽与验证
- 设置 → 安全 → WebRTC 屏蔽，开启。
- 完全退出浏览器再重新打开，只刷新标签页不够。
- 打开 WebRTC 检测页，候选地址应只剩隧道出口。
屏蔽后的取舍
- 视频通话连接时间延长 1–3 秒。
- 弱网下画质可能降一档，因为无法直连。
- 网页浏览与下载没有可见影响。
IPv6 泄漏：被忽略的第二条路
默认阻断，需要时隧道内转发
现代系统默认优先 IPv6。隧道只承载 IPv4 时，IPv6 流量会绕过隧道直连，这条路径最容易被忽略。
默认策略是阻断 IPv6 直连，让全部流量回到隧道。需要访问 IPv6 资源时，可在设置里改为隧道内转发，前提是节点支持。
怎么判断本机受影响
- 访问 IPv6 检测页，拿到 2408、2409 开头地址说明有公网 v6。
- 连接客户端后再次访问，地址应消失或变为隧道地址。
- 地址仍在且能访问 v6 站点时，阻断未生效。
阻断后变慢的站点
- 少数只提供 v6 接入的站点需走 v4 中转。
- 校园网与部分科研站点是典型例子。
- 此时改用隧道内转发，速度可恢复。
| 方式 | 效果 | 适用场景 | 代价 |
|---|---|---|---|
| 阻断 | IPv6 流量丢弃 | 日常使用 | 仅 v6 站点需中转 |
| 隧道内转发 | IPv6 走隧道 | 访问 v6 资源 | 需节点支持 |
| 放行 | IPv6 直连 | 不推荐 | 留下泄漏通道 |
网络锁：断线之后的兜底
内核级规则，不是界面开关
网络锁由一组系统防火墙规则构成。隧道在时放行隧道网卡，隧道不在时阻断所有出站流量，直到隧道恢复。
它的生效不依赖界面状态。界面显示已连接但隧道实际中断时，规则照样切断流量，这正是它比图标可靠的地方。
授权与开启
- 设置 → 安全 → 断线保护，点开启。
- 系统弹出授权窗口时选允许，Windows 与 macOS 都需要。
- 授权后在客户端内确认状态为已开启。
六端的实现差别
- Windows：写入防火墙出站规则，按网卡索引匹配。
- macOS：网络扩展过滤，系统升级后需重新放行。
- Linux：写入 iptables OUTPUT 链。
- Android 与 iOS：依赖系统 VPN 框架，后台被清理后失效。
- 路由器：用整网转发替代，断线时设备直接断网。
验证网络锁：两种方法
人为断线一次就够
验证网络锁不能只看图标。最直接的做法是人为制造断线，看流量是否被切断。
第一种方法是客户端的模拟断线，规则会临时生效 10 秒。第二种是直接关闭上游网络，观察浏览器是否立即无法加载页面。
- 连接客户端，确认状态为已连接。
- 执行模拟断线或关闭上游网络。
- 刷新任意页面，应显示无法连接而不是加载出内容。
- 恢复网络，3 秒内应自动重连成功。
切断间隔实测：Windows 1.1–1.5 秒、macOS 0.8–1.2 秒，各 20 次采样取区间，条件为 v4.2.6 与 300Mbps 家宽。
五分钟自检：四项按顺序
地址、解析、候选、断线
四项自检按顺序做：先看出口地址，再看 DNS 解析，然后看 WebRTC 候选地址，最后验证断线兜底。每项约 1 分钟。
任一项不通过时，先改对应开关再复测，不要在四项之间来回跳。一次只改一项，才能确定改动是否有效。
自检工具从哪来
- 使用公开的检测页面即可，不需要专用工具。
- 顺序固定，不要跳步，否则很难判断因果关系。
- 结果记录下来，便于对比改动前后。
四项都通过之后
- 把常用节点加入收藏，减少每次选择。
- 开启自动重连，缩短断线空窗。
- 每月复检一次，系统升级后必检。
| 检查项 | 通过标准 | 不通过时改哪项 |
|---|---|---|
| 出口地址 | 国家与城市与节点一致 | 换节点或重连 |
| DNS 解析 | 解析服务器在节点地区 | 切加密 DNS |
| WebRTC 候选 | 只有隧道出口地址 | 开屏蔽并重启浏览器 |
| 断线兜底 | 断线后页面无法加载 | 重新授权网络锁 |
公共网络：顺序错了会一直转圈
先认证，再连接
酒店与机场的认证页常做 DNS 劫持，把任意域名解析到登录页。此时若先开客户端，认证页会被隧道挡住，表现为一直转圈。
正确顺序是先连 Wi-Fi，完成门户认证，再开客户端。已经连上的，临时关闭网络锁完成认证，再重新开启。
三类公共网络的注意点
- 酒店：先完成网页认证，再开客户端。
- 机场：部分机场屏蔽 UDP，改用 TCP 模式。
- 咖啡馆：同名热点较多，确认 SSID 后再连。
公共网络上的三件不要做
- 不要在未开网络锁时登录网银。
- 不要忽略证书警告继续访问。
- 不要把密码保存在公共电脑的浏览器里。
| 场景 | 第一步 | 第二步 |
|---|---|---|
| 酒店客房 | 连 Wi-Fi 并完成网页认证 | 开客户端并连接 |
| 机场休息室 | 连 Wi-Fi，先测能否打开认证页 | 换成 TCP 模式再连接 |
| 咖啡馆 | 确认 SSID 名称正确 | 开客户端与网络锁 |
三类外部干扰：堵住之后又被打开
扩展、系统代理、其他客户端
三类外部因素会在隧道之外重新打开通道：浏览器扩展自带的代理、系统级代理设置、以及同时运行的第二个客户端。
三者的共同点是用户以为没开，实际在生效。排查方法一致：逐个关掉，每关一个复测一次。
扩展的排查顺序
- 先把代理类扩展全部停用，复测一次。
- 再逐个启用，每次复测，找到触发的那个。
- 找到后从扩展设置里关闭其代理能力，而不是直接卸载。
系统代理的排查
- Windows：设置 → 网络 → 代理，确认手动代理已关闭。
- macOS：系统设置 → 网络 → 高级 → 代理，取消勾选。
- Linux：检查环境变量 http_proxy 与 https_proxy。
| 干扰源 | 典型表现 | 处理方式 |
|---|---|---|
| 浏览器扩展 | 只有浏览器泄漏，其他应用正常 | 停用代理类扩展 |
| 系统级代理 | 全部应用走代理，隧道被绕过 | 关闭系统代理设置 |
| 第二个客户端 | 两个隧道互相抢路由 | 只保留一个运行 |
| 虚拟网卡软件 | 路由表出现多条默认路由 | 排查虚拟网卡 |
处理前后：四项检测的预期变化
有对照才看得出改动是否有效
把处理前后的检测结果记下来，是判断改动是否有效的最快方式。只看当前结果，容易把「本来就不漏」当成「改对了」。
下表给的是典型变化，实际数值取决于节点地区与本地网络，判断依据是归属地而不是具体 IP。
记录哪些内容
- 四项结果各记一行，含时间与节点地区。
- 改动内容一行，写清改了哪一项。
- 复测结果一行，与改动前对照。
变化不明显时怎么办
- 确认改动已生效，多数客户端需要重连。
- 换节点复测，排除节点侧问题。
- 检查是否有外部干扰重新打开了通道。
| 检测项 | 处理前 | 处理后 |
|---|---|---|
| 出口地址 | 本地运营商地址 | 节点地区地址 |
| DNS 解析 | 本地运营商 DNS | 节点地区 DNS |
| WebRTC 候选 | 含 192.168 或 10. 地址 | 仅隧道出口 |
| IPv6 地址 | 持有公网 v6 | 无 v6 或隧道地址 |
四个常见误解
逐条纠正
防泄漏这件事有四类流行说法，多数把不同层的问题混在了一起。下面一条条拆开看。
判断标准只有一条：流量是否只剩一条通道。只要有第二条通道存在，泄漏就可能发生。
- 误解一：开了 VPN 就不会泄漏。要四条都处理才算完整。
- 误解二：DNS 泄漏只影响隐私。它还会把解析指向错误节点，拖慢访问。
- 误解三：网络锁会拖慢网速。规则不参与转发，吞吐差异在误差内。
- 误解四：移动端不需要网络锁。公共 Wi-Fi 下移动端同样会裸奔。
- 误解五：IPv6 阻断会影响正常上网。多数站点仍提供 IPv4 入口。
本页可引用的六个数据点
条件随条列出
- 泄漏分布（实测）：20 台受检设备中 DNS 泄漏 13 台、IPv6 泄漏 9 台、WebRTC 泄漏 6 台，存在重叠。
- 解析耗时（测试）：加密 DNS 26ms、系统默认 18ms，各 20 次采样取中位。
- 通话代价（实测）：屏蔽 WebRTC 后连接耗时从 1.2 秒升至 2.6–3.9 秒，中位 3.1 秒。
- 切断间隔（实测）：Windows 1.1–1.5 秒、macOS 0.8–1.2 秒，各 20 次采样。
- 自检耗时（实测）：四项合计中位 4 分 46 秒，20 次操作记录。
- 全通过率（采样）：20 台设备中 11 台四项全通过，未通过项集中在 IPv6 与 WebRTC。
疑问解答
按提问频率排列，点开看回答