WebRTC 与 ICE：候选地址、会话协商和 IP 泄漏检测

WebRTC 是什么

WebRTC（Web Real-Time Communication）让浏览器（或其他应用）之间可以尽量直接地传输音视频和任意数据，常见于网页视频会议、语音通话、浏览器间传文件、云游戏和远程桌面。

它不是一个协议，而是一组协议和 API 的组合：

ICE 候选地址

ICE 候选地址（ICE candidate）不是单纯的 IP，而是一条“你可以试着从这里找到我”的线索。一台设备通常会收集到好几个。

候选地址里有什么

网页拿到的每个候选地址都是一行文本，格式来自 SDP 的 a=candidate 行：

candidate:842163049 1 udp 1677729535 203.0.113.10 62000 typ srflx raddr 0.0.0.0 rport 9
          └基础标识┘ │  │   └─优先级─┘ └──地址──┘ └端口┘ └─类型─┘ └──对应的本地地址──┘
                  组件 协议

typ 后面就是类型；raddr/rport 是它所对应的本机地址。浏览器启用 mDNS 隐藏时，这里会填成 0.0.0.0 和 9，免得从旁边漏出内网 IP。

候选地址的优先级按 RFC 8445 的公式计算：

四种候选类型

srflx 不是你的电脑真正拥有的地址，而是 NAT 设备为这次通信临时开的映射；relay 则不只是一个地址，TURN 服务器会真的替你转发数据。

从收集到连通：ICE 的完整流程

交换候选与 Trickle ICE

双方各自收集好候选后，要通过信令把候选发给对方（写在 SDP 里，或单独一条条发）。信令服务器只负责转交这些信息，一般不参与之后的数据传输。

传统做法是等全部收集完再一次性发送。Trickle ICE（Trickle ICE）则是收集到一个就发一个，双方能更早开始检查，连接建立更快。浏览器的 icecandidate 事件就是按这种方式一条条吐出候选的；最后会再触发一次 candidate 为 null 的事件，表示收集结束。

候选对、连通性检查和提名

1. 配对：把自己的每个候选和对方的每个候选组合成候选对（candidate pair），按两边优先级排序。
2. 连通性检查：在每个候选对上发 STUN Binding 请求，收到对应的响应，说明这条路径双向可达。检查过程中如果发现了新的映射地址，就生成 prflx 候选。
3. 提名：ICE 给双方分配角色，控制方（controlling agent）从检查通过的候选对里选一条，再发一个带“提名”标记的 STUN 请求告诉对方（RFC 8445 第 2.3 节）。
4. 传输：之后的音视频和数据都走被提名的那一对。如果选中的是 host 或 srflx 组合，TURN 就完全不参与。

Offer 与本地描述

检测网站的脚本里总有 createOffer() 和 setLocalDescription() 两步。它们本身不负责“获取 IP”，而是 WebRTC 会话协商的起点。

createOffer：写一份会话提议

Offer（SDP offer）只是一份文本，生成它不会向任何人发送数据。只建了一个数据通道时，Offer 大致长这样：

v=0
o=- 4611731400430051336 2 IN IP4 127.0.0.1
s=-
t=0 0
m=application 9 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=ice-ufrag:EsAw
a=ice-pwd:bP+XJMM09aR8AiX1jdukzR6Y
a=fingerprint:sha-256 0F:74:31:25:...
a=setup:actpass
a=mid:0
a=sctp-port:5000

setLocalDescription：把提议正式生效

createOffer() 只是写好了草稿；setLocalDescription(offer) 才把它设为这条连接的本地描述，更新协商状态。W3C 规范注明，这一步可能触发 ICE 候选收集（依据 JSEP，RFC 9429 第 5.9 节），于是浏览器开始收集候选并逐个触发 icecandidate 事件。

正常的双端通信还差一半：对方要回一份 Answer，发起方用 setRemoteDescription() 设为远端描述，ICE 检查才有对象可测。

STUN 到底参与了哪些环节

原对话里你问：“STUN 只在获取 srflx 时有作用，host 和 TURN 都与 STUN 无关，对吧？”原回答说“基本正确”。更准确的说法是：收集 host 候选确实不需要 STUN 服务器，但 STUN 这套消息格式贯穿了 ICE 的好几个环节。

泄漏检测网站做了什么

一段脚本就能读出候选地址

检测网站不需要扫描你的网卡，也不需要向你的路由器发请求。它做的只是让浏览器自己准备一次连接：

const pc = new RTCPeerConnection({
  iceServers: [{ urls: "stun:stun.l.google.com:19302" }]  // 指定一个 STUN 服务器
});
pc.onicecandidate = (e) => {
  if (e.candidate) console.log(e.candidate.candidate);    // 每收集到一个就打印
  else console.log("收集结束");
};
pc.createDataChannel("probe");                            // 让 Offer 里有 m= 段
await pc.setLocalDescription(await pc.createOffer());     // 触发候选收集

它不需要把 Offer 发给任何人、不需要对方回 Answer、也不需要真的建立数据通道。只要本地收集到候选，网页前端就已经读到了。

网页普通请求的来源 IP（HTTP 出口）   ── 网站后台直接看到
WebRTC 候选里的 srflx / host / IPv6   ── 前端脚本读到后上报
                    │
            两者比对：候选里有没有出现 HTTP 出口以外的公网地址？
                    │
        有 → 报告“可能泄漏”；  没有 → 至少这一次没发现

两个 IP 不一致不一定是泄漏，比如 WebRTC 走了另一个同样属于代理的出口；也要结合地址归属判断。

谁能看到什么

开了 TUN + Global 还会泄漏吗

浏览器默认只用默认路由那块网卡

原对话举例说，Windows 有以太网、Wi-Fi、Clash TUN 三块网卡时，“浏览器可能收集这些网络接口对应的候选地址”。这不是浏览器的默认行为。RFC 8828 定义了四种地址处理模式：

标准要求：没有得到用户同意时不得使用模式 1，应使用模式 2；摄像头、麦克风授权可以算作一种同意。在此之上，浏览器还会用 mDNS 候选（mDNS ICE candidate）隐藏私有地址。

所以开了 TUN 且接管了系统默认路由之后，按模式 2，浏览器选中的“默认路由网卡”就是 TUN 虚拟网卡本身。

STUN 请求经过 VPS 的三种结果

假设环境如下（地址都是示例）：

“STUN 经过 VPS 就不会泄漏”有三个前提：

1. 是 VPS 替你发出去的：请求从 VPS 出口到达 STUN 服务器，而不是只在本机绕了一圈又从原网卡出去。
2. UDP 全程有人接：STUN 通常走 UDP，代理客户端、代理协议和服务端都要支持 UDP 转发；不支持时结果是失败，而不是自动变成 VPS 地址。
3. 其他候选也没漏：srflx 已经是 VPS 地址，host 候选、IPv6 地址、TURN 候选仍要单独看。

地址暴露 ≠ 流量泄漏

ICE 会根据双方候选的配对和检查结果选路，所以 STUN 请求经过 VPS，不代表之后的连通性检查和数据都经过 VPS。反过来，host 候选暴露了 192.168.1.100，也不代表互联网上的网站能连进你的内网。

动手测一遍

本篇小结

• WebRTC 的点对点是“数据尽量直连”，信令总要服务器，直连失败还要 TURN 中继。
• 候选地址有四种：host（本机网卡）、srflx（STUN/TURN 看到的 NAT 映射）、prflx（检查时发现）、relay（TURN 分配）；优先级 host 最高、relay 最低。
• ICE 流程：收集 → 交换（可以 Trickle）→ 配对 → STUN 连通性检查 → 控制方提名 → 传输。
• createOffer() 写会话提议，setLocalDescription() 让它生效并通常触发收集；检测网站只走到这一步就够了。
• STUN 服务器只管 srflx，但 STUN 协议贯穿连通性检查和 TURN。
• 浏览器默认只用默认路由那块网卡并用 mDNS 藏私有地址；开 TUN 后重点看 srflx 是不是 VPS、IPv6 有没有漏，并分清“地址暴露”和“流量泄漏”。

拓展

以下内容来自 ChatGPT 结合我之前的提问（Tailscale、UDP 打洞）做的联想，不属于本篇正文，留作后续学习线索。

WebRTC 和 Tailscale 的对照。 两者都要解决“两台在 NAT 后面的设备怎么直连”，思路很像，但定位不同：WebRTC 是一套给应用用的实时通信能力，Tailscale 是把设备组成同一个私有网络的组网产品。

Tailscale 一侧依据官方文档 DERP servers 核实；原对话把 Tailscale 的穿透写成“DERP、STUN、WireGuard 等机制”，文档里 DERP 同时负责协商连接和兜底中继，具体是否使用标准 STUN 未在本次查阅的文档中核实。

下一步可以学：NAT 类型与 UDP 打洞。 现在已经知道 ICE 怎么收集、配对、检查地址；接下来要弄清为什么有些 NAT 环境能打洞成功，有些却只能走 TURN 中继。这和端点无关映射（Endpoint-Independent Mapping）等 NAT 行为有关，可以从 RFC 4787 入手。