WebRTC 泄漏的工作原理

反欺诈系统并不是通过某个单独请求来获取您的真实 IP 地址。它会比较两个地址：建立 TCP 会话时使用的地址，以及浏览器通过 WebRTC 和 UDP 返回的地址。两者不一致就是风险信号。

以下流程适用于三种场景：

浏览器通过 SOCKS5 代理打开页面。所有 HTTP/HTTPS 流量都使用 TCP，因此网站看到的是代理 IP 地址。
反欺诈系统向页面提供一个脚本。该脚本创建 RTCPeerConnection，并在 iceServers 中指定自己的 STUN 或 TURN 服务器。
浏览器开始收集 ICE 候选项，并通过 UDP 向该服务器发送 STUN Binding Request。
STUN 服务器返回带有 XOR-MAPPED-ADDRESS 属性的 Binding Response。该属性包含数据包来源的公网地址，浏览器会将其转换为 srflx 候选项。
脚本通过 onicecandidate 接收候选项，提取其中的 IP 地址，并与 TCP 会话地址进行比较。

关键在于第 3 步。UDP 数据包是否经过代理取决于两个条件：代理是否支持 UDP，以及浏览器是否会把 UDP 流量交给该代理。由此会产生三种结果。

结果： WebRTC 正常工作，可以获得候选项，并且地址一致。从网络层面看，该配置的行为与普通用户相同。

这需要同时满足两个条件：代理支持 UDP ASSOCIATE，并且客户端（浏览器或反检测浏览器）确实会通过代理转发 WebRTC 流量。

结果： 发生 IP 泄漏。反欺诈系统获得的是具体地址，而不仅是一个可疑信号。

UDP 可能因以下原因绕过代理：

代理仅支持 TCP：使用 CONNECT 的 HTTP 代理只能转发 TCP，不支持 UDP ASSOCIATE 的 SOCKS5 代理也是如此；
代理支持 UDP，但浏览器不会通过它转发 UDP：Chrome 默认不会通过已配置的代理发送 WebRTC 流量，而是直接发送；
代理只为特定配置文件或扩展设置，但 WebRTC 在整个浏览器进程层面运行。

如果反欺诈系统控制 iceServers 中的 STUN/TURN 服务器，它甚至不需要执行第 5 步。该服务器可以直接从传入 UDP 数据包的来源地址看到真实 IP。

192.168.*、10.* 等本地地址在这里的重要性较低。从 Chrome 80 开始，host 候选项会以 <uuid>.local 这类 mDNS 名称提供，因此通过 WebRTC 获取本地网络信息变得更困难。在此场景中，暴露的是公网 srflx 地址。

结果： 真实 IP 地址没有暴露，但反欺诈系统会发现另一种异常：当前桌面版 Chrome 中的 WebRTC 完全不可用。大多数普通用户都启用了 WebRTC，因此空的候选项列表可能提高风险评分，就像声明的 user-agent 与 API 实际行为不一致一样。

因此，关闭 WebRTC 只是把 IP 泄漏换成了指纹异常。在某些情况下可以接受这种取舍，但它并不是完整的解决方案。