WebRTC 泄漏：为什么开了 VPN 还是暴露真实 IP，以及怎么修

绕过隧道的那个漏洞

WebRTC 是浏览器里实现网页语音和视频通话的技术。为了建立点对点直连，它需要发现设备所有的网络路径——做法是向操作系统询问所有本地网卡、向 STUN 服务器发起查询，而这整个过程完全绕开你的 HTTP 代理设置。在很多配置下，WebRTC 流量根本不走 VPN 隧道，因为它用的是直接的 UDP 套接字，而不是浏览器的常规请求通道。

结果是：一个网站跑几行 JavaScript、创建一个 RTCPeerConnection，就能拿到你的真实公网 IP——而你的 VPN 图标还骄傲地显示着外国。这不是 VPN 的 bug，也不是你的机器被黑了——这是 WebRTC 在忠实地执行它的设计目标。只是这个设计目标（快速通话）和隐私目标（只暴露一个地址）天然冲突。

如何测试是否泄漏

先连好 VPN 或代理——测试只有在隧道建立时才有意义。然后跑一次 IP 检测记下地址；再打开任意一个 WebRTC 泄漏测试页（或者用浏览器控制台：创建一个 peer connection、加一个 STUN 服务器、读 ICE candidate）。对比两者。如果 WebRTC 结果显示的是你真实运营商的地址而不是 VPN 出口，你就在泄漏。还要对比 IPv6：很多配置正确地隧化了 IPv4，而设备的全局 IPv6 地址却畅通无阻地直奔目的地。

在你实际使用的每一个浏览器里重复这个测试。Chrome、Firefox、Safari、Edge 对 WebRTC 的处理各不相同，修好一个不代表修好了全部。

分浏览器列出真正有效的修复

• Firefox：地址栏输入 about:config，把 media.peerconnection.enabled 设为 false。这是唯一自带完整开关的主流浏览器。
• Chrome / Edge：没有内置开关；安装 VPN 服务商官方发布的 WebRTC 控制扩展（多数正规 VPN 都有），或使用强制"仅公共网卡"策略的 WebRTC Network Limiter 类扩展。
• Safari：因为权限弹窗更严格，泄漏较少见，但仍要测——旧版本会随意暴露 candidate。
• 所有浏览器：IPv6 要在系统层面处理——在设备上禁用 IPv6 或确保 VPN 隧化了它；浏览器设置修不好一个没被隧化的 IPv6 协议栈。

关掉 WebRTC 会失去什么

浏览器内的通话（网页版 Google Meet、Discord 网页语音、很多远程医疗和面试平台）都依赖 WebRTC。完全关闭会让这些通话失效，这就是为什么"仅公共网卡"策略通常是更好的修法：通话照常工作，同时隐藏未隧化的地址。如果某个网站确实需要通话，用完那个会话再关，而不是长期敞着泄漏。

最后，每次浏览器更新、每次 VPN 客户端变更后都重新测一遍。泄漏行为是移动靶：浏览器默认设置会变，VPN 客户端会增删自己的 WebRTC 防护，扩展可能被策略更新静默禁用。泄漏测试只要三十秒；把它变成更新后的例行动作，是唯一持久的修复。

参考资料

以下来源供读者核验技术背景。列出不代表这些机构认可 TrustIP。

• MDN — WebRTC API overview
• RFC 8825 — WebRTC security considerations