---
description: WebRTC 的工作原理
icon: wave-square
---

# WebRTC 泄漏的工作原理

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

### 检查流程

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

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

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

<br>

<figure>
  <picture>
    <source srcset="../../.gitbook/assets/webrtc-leak_black.svg" media="(prefers-color-scheme: dark)">
    <img src="../../.gitbook/assets/webrtc-leak_white.svg" alt="WebRTC 通过代理时的工作场景">
  </picture>
</figure>

### 场景 1：代理转发 UDP，两个地址一致

1. TCP 会话通过 SOCKS5 代理建立，因此网站看到 `198.51.100.7`。
2. 反欺诈系统向页面提供一个配置了其 STUN 服务器的脚本。
3. 浏览器通过同一代理建立 UDP 关联（`UDP ASSOCIATE`，RFC 1928），并通过该代理发送 Binding Request。
4. STUN 看到的是代理地址，并在 `XOR-MAPPED-ADDRESS` 中返回相同的值：`198.51.100.7`。
5. 脚本比较两个值。TCP 会话 IP 与 srflx 候选项一致。

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

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

***

### 场景 2：UDP 绕过代理并暴露真实地址

1. TCP 会话通过代理建立，因此网站看到 `198.51.100.7`。
2. 反欺诈系统向页面提供一个配置了其 STUN 服务器的脚本。
3. 浏览器**直接从网络接口**发送 Binding Request，绕过代理。
4. STUN 看到真实地址 `113.22.13.2`，并将其作为 srflx 候选项返回。
5. 脚本比较两个值：`113.22.13.2` ≠ `198.51.100.7`。代理被识别，真实 IP 地址也被暴露。

**结果：** 发生 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 地址。

***

### 场景 3：浏览器禁用 WebRTC，没有泄漏但会产生异常信号

1. TCP 会话通过代理建立，因此网站看到 `198.51.100.7`。
2. 反欺诈系统向页面提供一个配置了其 STUN 服务器的脚本。
3. `RTCPeerConnection` 被扩展、浏览器设置或反检测浏览器中修改过的 API 阻止。STUN 请求既不会通过代理发送，也不会直接发送。
4. 没有服务器返回响应。`onicecandidate` 不会触发，候选项收集最终得到空列表。
5. 脚本没有可比较的地址。

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

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