WebRTC 泄漏原理

开启代理或 VPN 后，网页上显示的 IP 已经变了，但网站仍可能通过 WebRTC 拿到你的真实 IP。这就是 WebRTC 泄漏。它不需要任何权限弹窗，普通网页的一段脚本就能完成。

WebRTC 是什么

WebRTC 是浏览器内置的实时通信技术，网页视频会议、语音通话、P2P 文件传输都依赖它。为了让两台设备尽量直接连接，WebRTC 需要知道本机所有可用的网络地址，这个过程叫 ICE 候选收集。

ICE 会收集三类候选地址：

host：本机网卡地址，例如局域网的 192.168.x.x；
srflx（服务器反射地址）：浏览器向 STUN 服务器发送一个 UDP 请求，STUN 服务器把「看到的来源 IP」告诉浏览器——这就是你的公网出口；
relay：经由 TURN 中继服务器的地址。

关键在 srflx：STUN 请求走的是 UDP。很多代理只转发 TCP（HTTP / HTTPS / SOCKS 的 TCP 部分），UDP 流量会绕过代理直接从本地网络发出。于是 STUN 服务器看到的是你的真实公网 IP，网页脚本读取候选地址后，就拿到了它。

只要网页能运行 JavaScript，就能发起 STUN 请求，不需要摄像头或麦克风权限，用户也不会看到任何提示。

使用分流规则时，访问国内与国外服务器可能走不同出口。本站分别用国内和国外的 STUN 服务器检测：如果国外 STUN 拿到的仍是本地运营商的 IP，说明 UDP 没有进入代理，存在泄漏。

早期浏览器会直接暴露 host 候选里的局域网 IP。现在 Chrome、Edge、Safari 默认用 xxxx.local 形式的 mDNS 名称代替局域网地址，局域网 IP 泄漏已基本缓解；真正需要关注的是公网 IP 的泄漏。

让 UDP 也走代理：在代理客户端中开启 TUN / 虚拟网卡模式或全局模式，使 STUN 的 UDP 请求也经过代理出口。这是最彻底的办法。
Firefox：在 about:config 中把 media.peerconnection.enabled 设为 false 可完全禁用 WebRTC（会影响网页视频通话）。
Chrome / Edge：安装限制 WebRTC 的扩展，或在策略中设置 WebRTC IP 处理方式为「仅通过代理」。
修复后复查：每次更换代理软件或规则后，重新做一次泄漏检测。

DNS 查询是另一条常见的泄漏途径，原理与 WebRTC 不同，见 DNS 泄漏原理。