WebRTC 泄露是什么：网页能读到你设备的网络地址
WebRTC 是浏览器内置的实时通信技术，网页版视频会议、语音通话都依赖它。为了让两台设备能直接建立连接，WebRTC 会向 STUN 服务器询问“我的公网地址是什么”，并收集本机网卡上的各种地址。这些信息能被网页里的脚本读取。如果你的流量其实走了 VPN，而 WebRTC 的探测请求绕开了隧道，页面读到的就可能是真实出口地址，这就是 WebRTC 泄露。这篇文章讲清它的成因、自测方法，以及不同浏览器的处理办法。
泄露是怎么发生的
WebRTC 泄露和 DNS 泄露不同，它发生在浏览器内部，和网页脚本的读取能力有关。
STUN 请求没有走隧道
全局模式的 VPN 会把所有流量都放进隧道，STUN 请求也不例外，所以通常不会泄露。泄露更多出现在三类情形：只代理了部分应用、使用了按规则分流的模式，或者代理只覆盖 TCP 而 WebRTC 用的是 UDP。UDP 请求没有被接管，就会直接从本地网卡发出。
IPv6 地址没有被隧道覆盖
如果本地网络同时提供 IPv6，而隧道只处理了 IPv4，WebRTC 探测时就可能把本地的 IPv6 公网地址一并暴露出去。这和上一类原因经常同时出现，检测页面上会同时显示两类地址。
局域网地址会不会暴露
早期 WebRTC 会直接把设备在局域网里的地址交给网页。现在主流浏览器已经改成用随机生成的 mDNS 主机名代替真实局域网地址，所以这一部分的风险已经明显降低，需要重点关注的是公网地址是否经过隧道。
| 现象 | 可能原因 | 处理方向 |
|---|---|---|
| 检测页显示本地公网地址 | UDP 探测没有走隧道 | 改用全局模式，或确认分流规则覆盖了 UDP |
| 同时出现 IPv6 本地地址 | 隧道没有接管 IPv6 | 临时关闭 IPv6，或使用支持 IPv6 的线路 |
| 只有浏览器里出现，其他程序正常 | 浏览器的 WebRTC 行为不受代理设置约束 | 调整浏览器的 WebRTC 设置 |
| 局域网地址显示为随机名称 | 浏览器启用了 mDNS 保护 | 属于正常现象，无需处理 |
三步自测
- 先断开 VPN，搜索“WebRTC leak test”，打开一个检测页面，记下它显示的公网地址，这是你的本地基线。
- 连接 VPN，等状态稳定后，换一个无痕窗口重新打开同一个检测页面。
- 对比两次结果：如果连接后页面仍然列出本地基线里的地址，说明发生了泄露；如果列出的都是线路出口的地址，基本正常。
处理办法与副作用
Firefox：直接关闭 WebRTC 的对等连接
在地址栏输入 about:config，搜索 media.peerconnection.enabled，把它设为 false，就能关闭这项功能。这是 Firefox 提供的原生开关。
Chrome 和基于它的浏览器：没有原生开关
这一类浏览器没有直接关闭 WebRTC 的设置项，可以使用浏览器官方提供的 WebRTC 网络限制类扩展，限制它只通过默认路由发出请求。具体入口会随浏览器版本变化，以当前版本的说明为准。
关闭之后会有什么副作用
关闭 WebRTC 以后，网页版视频会议、语音通话、部分在线协作工具可能无法使用。如果你经常用网页开会，更合适的做法是保留 WebRTC，用全局模式让探测请求也走隧道，而不是直接关闭。
日常使用中的两个小习惯
第一个习惯是在更换浏览器、升级浏览器大版本之后重新做一次检测，因为 WebRTC 的行为会随版本调整。第二个习惯是在需要使用网页视频会议的设备上，优先保留 WebRTC，把重点放在让 VPN 覆盖 UDP 和 IPv6 上，而不是一关了之。检测页面也不必频繁去测，换设备、升级客户端、更换网络这三个时间点各测一次，已经足够发现大部分问题。
想直接用全局模式体验，可以试试 TonBoVPN，装好之后按上面的三步自测一遍，结果以你的浏览器和网络环境为准。
小结：全局隧道加三步自测
WebRTC 泄露的核心是探测请求没有进隧道。优先用全局模式覆盖 UDP 和 IPv6，再用三步自测确认；确实不需要网页通话的话，才考虑直接关闭 WebRTC。换浏览器、升级客户端之后，别忘了重新检测一次。