WebRTC 泄露原理：ICE 框架、STUN/TURN 与代理穿透的技术拆解

很多人第一次接触 WebRTC 泄露这个概念时，通常是这样的场景：代理工具已经连上了，IP 检测页面显示的也是代理 IP，一切看起来都很正常。但一到 WebRTC 泄露检测页面，真实公网 IP 依然会被精准抓取与暴露。这种”明明做了防护却还是暴露”的落差感，是驱动大多数人深入了解 WebRTC 泄露原理的起点。

本文尝试从协议层面回答这个问题：WebRTC 泄露的根源在哪里，它和代理/全局加密隧道的工作机制之间到底存在什么矛盾。如果你对”为什么全局网络隧道挡不住”这个问题已经困惑很久，或者想理解 ICE、STUN、TURN 这些术语到底在做什么，这篇文章应该能帮你建立完整的技术认知。

总览卡片

*表注：本篇属于 WebRTC 主题集群的原理深度篇，侧重协议级技术解析。如需检测工具步骤，请参考关联文章。

目录

• 一、WebRTC 的设计初衷与隐私矛盾
• 二、ICE 框架：WebRTC 泄露的技术根源
• 三、STUN 与 TURN：WebRTC 中的两个关键角色
• 四、为什么代理和全局网络隧道挡不住 WebRTC 泄露
• 五、五大浏览器的 WebRTC 实现差异与泄露风险评估
• 六、WebRTC 泄露的真实风险：不只是”IP 暴露”这么简单
• FAQ：关于 WebRTC 泄露原理的高频问题

一、WebRTC 的设计初衷与隐私矛盾

1.1 WebRTC 不是漏洞，是一套完整的实时通信框架

WebRTC（Web Real-Time Communication）是 W3C 和 IETF 联合推动的开放标准，其目标是在浏览器中直接实现音视频通话和点对点数据传输，无需安装任何插件。这套框架的核心由三个 API 协作构成：

• getUserMedia：获取本地媒体流，包括摄像头、麦克风和屏幕共享
• RTCPeerConnection：建立浏览器之间的点对点数据通道，这是整个框架的核心
• RTCDataChannel：在已建立的连接上传输任意二进制或文本数据（文件、消息、游戏状态等）

这三个 API 的协作方式是：getUserMedia 负责采集数据，RTCPeerConnection 负责打通传输通道，RTCDataChannel 负责在通道上发送数据。从功能角度看，这是一套设计得相当完善的技术方案——Google Meet、Zoom Web、Discord 等主流产品的浏览器端通话都依赖它。

1.2 P2P 直连的前提条件：双方必须知道对方的网络地址

WebRTC 的核心目标是点对点直连。所谓直连，就是两个浏览器之间不经过中间服务器，直接建立通信通道。

但这引出了一个根本性的问题：你要和对方建立直连，就必须知道对方的网络地址——就像寄快递需要知道收件地址一样。WebRTC 的 RTCPeerConnection 在建立连接前，必须先完成”地址交换”这个步骤。

这个”地址交换”过程，就是信息泄露的根源所在。

负责收集网络地址的机制叫做 ICE（Interactive Connectivity Establishment，交互式连接建立） 框架。ICE 会在连接建立阶段，主动收集你设备上所有可用的网络地址（Candidate）。但这些地址并不会由 ICE 自己发送给对方——WebRTC 标准刻意没有定义信令（Signaling）层，地址的”交换”是由开发者自行搭建的信令服务器（通常通过 WebSocket）来完成的。ICE 的职责仅限于本地收集候选地址，以及后续的连通性测试。问题在于，Web 页面中的 JavaScript 脚本可以通过 API 接口获取到这些地址——这不是什么后门，而是 API 设计时的正常行为。

1.3 设计优先级与隐私代价

理解 WebRTC 泄露的关键在于理解它的设计优先级。WebRTC 的设计目标排序大致是：

连接成功率 > 延迟 > 带宽效率 > 安全性

在这个优先级下，WebRTC 会尽一切努力找到一条可用的通信路径。如果全局加密隧道走不通，它会尝试物理网卡直连；如果 UDP 被阻断，它会尝试 TCP 兜底；如果有 TURN 中继可用，它就会用中继保底。

“尽一切努力建立连接”对视频通话来说是好事——你不会希望在重要会议中因为网络切换而导致通话中断。但对隐私保护来说，这种”不择手段建立连接”的特性存在极大的隐私暴露隐患：在收集网络地址的过程中，你的真实 IP 地址就会被暴露出来。

这不是 bug，是一个明确的设计取舍——对实时通信有利的特性，对隐私保护反而是不利的。

二、ICE 框架：WebRTC 泄露的技术根源

ICE 是理解 WebRTC 泄露的核心概念。前面提到 ICE 负责收集网络地址，但”收集地址”这个过程到底是怎么工作的？为什么它能拿到你的真实 IP？这一节会把 ICE 的内部机制拆开来看。

2.1 ICE 的工作方式：收集所有可用的网络路径

ICE（Interactive Connectivity Establishment）定义于 RFC 8445，它不是一个单独的协议，而是一个综合性的连接建立框架。ICE 的核心职责可以概括为一句话：

收集设备上所有可用的网络路径，按优先级排序，逐一尝试建立连接，直到成功。

ICE 把每一条可用的网络路径称为一个 Candidate（候选地址）。在连接建立阶段，ICE Agent（运行在浏览器内部的连接管理组件）会执行以下步骤：

1. 枚举本机所有网络接口（Wi-Fi、以太网、底层虚拟网卡等）
2. 从每个网络接口读取本地 IP 地址，生成 host 类型的 Candidate
3. 向外部 STUN 服务器发送探测请求，获取公网映射地址，生成 srflx 类型的 Candidate
4. 如果配置了 TURN 服务器，生成 relay 类型的 Candidate 作为保底
5. 将所有 Candidate 按优先级排序，逐一尝试与对方建立连接

这个过程中的第 1-4 步，就是信息泄露的发生点。其中，host Candidate 和 srflx Candidate 是两种主要的泄露源，而 relay Candidate 理论上是安全的，但在实际使用中几乎不会生效。

2.2 host Candidate：泄露源之一——你的内网 IP

host Candidate（主机候选地址）是最基础的 Candidate 类型。ICE Agent 直接从设备的网卡接口读取本地 IP 地址，不加任何处理就作为 host Candidate 暴露给 Web 页面的 JavaScript 代码。

这些本地 IP 通常属于 RFC 1918 定义的私有地址空间：

• 192.168.0.0/16：最常见的家用路由器分配范围
• 10.0.0.0/8：企业网络和大范围局域网
• 172.16.0.0/12：部分企业网络使用

关键点在于：即使你的全局网络隧道正在运行，这些本地 IP 地址也不会改变。 全局网络隧道创建的是一条从你的设备到服务器的加密隧道，它不会修改你局域网内的 IP 分配。所以 host Candidate 暴露的 192.168.1.x 地址，就是你路由器分配给你的真实局域网地址。

host Candidate 泄露的实际危害取决于攻击者能获取到的信息量：

• 单独一个内网 IP 的危害相对有限——它只能告诉别人你使用的是家用/企业网络
• 但如果结合其他信息（浏览器指纹、时区、语言偏好、屏幕分辨率），就可以显著缩小设备识别范围
• 在多设备共用同一局域网的场景下，多个设备暴露相同的 192.168.x.x 前缀，平台可以据此判定它们处于同一物理位置

为了缓解 host Candidate 的泄露问题，主流浏览器引入了 mDNS 混淆机制（定义于 RFC 8828）。Chrome 和 Firefox 会将内网 IP 替换为随机的 UUID.local 地址，例如把 192.168.1.5 替换为 a1b2c3d4-e5f6-7890-abcd-ef1234567890.local。不过，mDNS 混淆的局限性也比较明显，这个后面在浏览器差异章节会详细分析。

2.3 srflx Candidate：泄露源之二——你的真实公网 IP

srflx Candidate（Server Reflexive Candidate，服务器反射候选地址）是危害最大的泄露源。与 host Candidate 只暴露内网 IP 不同，srflx Candidate 暴露的是你的真实公网 IP 地址——也就是你 ISP（运营商）分配给你的出口 IP。

这个公网 IP 可以通过反向查询定位到你的城市和运营商信息，是 WebRTC 泄露中最有价值的情报。

srflx Candidate 的获取过程：

1. 浏览器的 ICE Agent 向外部 STUN 服务器发送一个 Binding Request（使用 UDP 协议，默认端口 3478）
2. STUN 服务器收到请求后，从 UDP 数据包的头部读取发送方的源 IP 地址
3. STUN 服务器将这个 IP 地址写入 Binding Response 的 XOR-MAPPED-ADDRESS 字段中返回
4. 浏览器收到响应后，解析出公网 IP 地址，将其作为 srflx Candidate
5. Web 页面中的 JavaScript 通过 onicecandidate 事件回调获取这个地址

用一个简化的代码示例来说明，Web 页面中的脚本可以这样获取你的 IP：

const pc = new RTCPeerConnection({
  iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
});

pc.onicecandidate = function(event) {
  if (!event.candidate) return;
  const candidate = event.candidate.candidate;
  // candidate 字符串中包含 "typ srflx" 和 "raddr" 字段
  // 解析后可提取出真实公网 IP
  console.log(candidate);
};

pc.createDataChannel('test');
pc.createOffer().then(offer => pc.setLocalDescription(offer));

执行这段代码后，控制台输出的 candidate 字符串中如果出现 typ srflx，就意味着你的真实公网 IP 已经被暴露给了这个 Web 页面。

为什么 srflx 是最危险的泄露源？

因为 STUN 的”反射”特性本身就是为了获取真实公网 IP 而设计的——这正是它的正常功能。在 WebRTC 的 P2P 连接场景中，双方需要知道彼此的公网地址才能建立直连。但从隐私角度看，任何一个 Web 页面都可以通过嵌入上述几行 JavaScript 代码来触发这个过程，而用户对此毫无感知。

2.4 relay Candidate：理论上安全，但现实中几乎不存在

relay Candidate（Relayed Candidate，中继候选地址）是三种 Candidate 类型中唯一不暴露真实 IP 的一种。它的原理是：所有数据流量都通过 TURN 服务器中转，通信双方只知道 TURN 服务器的公网 IP，彼此的真实 IP 完全隐藏。

但 relay Candidate 在现实中极少出现，原因在于成本：

• TURN 服务器需要承载所有媒体数据的带宽消耗。一场 1080p 视频通话大约需要 3-5 Mbps 的带宽，如果同时有 1000 路通话通过 TURN 中转，就需要 3-5 Gbps 的带宽
• 运营 TURN 服务器意味着实质性的基础设施投入，与完全免费的 STUN 服务形成鲜明对比
• 绝大多数 WebRTC 应用只在 P2P 直连（host 或 srflx）失败时，才会启用 relay 作为最后的保底方案
• 如果前两种 Candidate 中任意一种成功建立了连接，relay 就不会被使用

所以，即使某个 WebRTC 应用声称”支持 TURN 服务器”，也不意味着你的 IP 就不会被泄露——只要 host 或 srflx 能连通，relay 就不会生效。

三种 Candidate 类型的对比可以参考下表：

*表注：Candidate 类型按照 ICE 优先级从高到低排列。ICE 会优先尝试 host，然后 srflx，最后才轮到 relay。

三、STUN 与 TURN：WebRTC 中的两个关键角色

上一节频繁提到了 STUN 和 TURN，它们是 ICE 框架依赖的两个外部服务。这两个角色经常被混淆，但实际上它们的职责完全不同。

3.1 STUN：轻量级的”地址探测”服务

STUN（Session Traversal Utilities for NAT）的核心功能只有一件事：告诉客户端”你的公网 IP 地址是什么”。

客户端向 STUN 服务器发送一个 Binding Request，STUN 服务器从数据包头部读取客户端的源地址，然后把地址写进 Binding Response 返回。整个过程只需要一次请求-响应交互，涉及的数据量极小（几个 UDP 包），所以 STUN 服务的运营成本接近于零。

STUN 协议最初定义于 RFC 3489（2003 年），当时的全称还是 “Simple Traversal of UDP through NAT”。后来在 RFC 5389（2008 年）中去掉了 “Simple”，重新定义为 “Session Traversal Utilities for NAT”，因为实际部署中的 NAT 行为远比最初预期的复杂。目前生效的版本是 RFC 8489（2020 年），它在 RFC 5389 的基础上进一步修订并正式取代了该规范。

一些常见的公共 STUN 服务器包括：

• stun.l.google.com:19302（Google）
• stun:stun.cloudflare.com:3478（Cloudflare）
• global.stun.twilio.com:3478（Twilio）

这些服务器都可以免费使用，这也是为什么 WebRTC 检测工具几乎都会配置 STUN 服务器——它的”反射”特性正好可以用来获取客户端的真实公网 IP。

3.2 TURN：昂贵的”流量中转”服务

TURN（Traversal Using Relays around NAT）的功能与 STUN 完全不同：它在公网中转所有的 P2P 通信流量。

当两个客户端之间的直连尝试（host 和 srflx）全部失败时——例如双方都处于对称型 NAT 之后——就需要一个公网上的”中间人”来转发数据。TURN 服务器就是扮演这个角色。使用 TURN 时，通信双方只知道 TURN 服务器的 IP 地址，彼此的真实 IP 完全隐藏。

TURN 的协议规范在 RFC 8656 中定义。

但 TURN 的代价在于带宽。前面提到过，TURN 服务器需要承担全部媒体流量的传输，这意味着实质性的带宽成本。这也是为什么绝大多数 WebRTC 应用不会默认启用 TURN——它只在 P2P 直连失败时作为保底方案存在。

3.3 STUN 与 TURN 的核心差异

*表注：STUN 和 TURN 经常被放在一起讨论，但两者的职责和成本结构完全不同。大多数 WebRTC 泄露检测工具利用的就是 STUN 的地址反射功能。

3.4 为什么检测工具依赖 STUN

理解了 STUN 的工作原理，就不难理解 WebRTC 检测工具是怎么工作的了。检测工具的原理可以概括为三步：

1. 在嵌入的页面中创建一个 RTCPeerConnection 对象，并指定一个或多个 STUN 服务器
2. ICE Agent 自动向 STUN 服务器发送 Binding Request，获取 srflx Candidate（你的真实公网 IP）
3. 工具将获取到的公网 IP 与页面的 HTTP 出口 IP 进行对比——如果两者不一致，说明存在泄露

这就是为什么几乎所有 WebRTC 检测工具都至少配置了一个 STUN 服务器：没有 STUN 的反射功能，就无法获取 srflx Candidate，也就无法判断是否存在泄露。

四、为什么代理和全局网络隧道挡不住 WebRTC 泄露

这是搜索 “webrtc泄露” 的用户最想理解的核心问题。答案藏在代理/全局网络隧道与 WebRTC 的工作层级差异中。

4.1 代理的工作层级

代理和 WebRTC 分别工作在 OSI 网络模型的不同层级，这是它们”管不住”对方的根本原因。

HTTP 代理工作在应用层（OSI 第 7 层）。浏览器配置 HTTP 代理后，所有的 HTTP/HTTPS 请求会通过代理服务器转发，网站看到的 IP 是代理的出口 IP。但 WebRTC 的 RTCPeerConnection 是一套独立的浏览器原生 API，它的 STUN 请求不经过 HTTP 请求通道，因此 HTTP 代理对它没有任何约束力。

SOCKS5 代理工作在会话层（OSI 第 5 层），理论上可以代理包括 UDP 在内的任意协议。但实际情况比较复杂——不同浏览器对 SOCKS5 代理的 WebRTC 支持程度不一致。Chrome 对 SOCKS5 的 UDP 代理支持并不完整，Firefox 的支持相对更好，但也不是所有版本都稳定可靠。

简单来说：代理的配置作用于浏览器层面的 HTTP/网络请求，而 WebRTC 的 ICE Agent 在更底层的网络接口级别收集地址——两者的作用层级不同，代理自然管不到 WebRTC。

4.2 全局网络隧道的工作机制与 WebRTC 的直连穿透机制

全局网络隧道的防护逻辑比代理更彻底。全局网络隧道通过创建虚拟网卡（TUN 模式工作在网络层，TAP 模式工作在数据链路层），并修改系统路由表，将默认路由指向虚拟网卡。这样一来，理论上所有网络流量（包括 UDP）都应该经过全局网络隧道到达服务器，再由服务器的出口 IP 访问目标网站。

但 WebRTC 有一个直连穿透机制：浏览器的 ICE Agent 在收集 Candidate 时，会直接枚举系统中的所有网络接口。如果你的物理网卡（Wi-Fi 或以太网）仍然处于活跃状态，ICE Agent 就能读取到物理网卡的 IP 地址。而且，STUN 的 Binding Request 作为 UDP 数据包，在某些情况下可能直接通过物理网卡发出，穿透全局网络隧道的 TUN 虚拟网卡。

这种直连穿透通常发生在以下场景中：

• 全局网络隧道未正确路由 IPv6 流量，而 STUN 请求使用了 IPv6 地址
• 全局网络隧道使用了分流规则（Split Tunneling），部分流量被排除在隧道之外
• 浏览器的 WebRTC 实现没有完全遵守系统路由表的设置

所以，全局网络隧道能否防住 WebRTC 泄露，取决于全局网络隧道是否正确路由了所有 UDP 流量，以及浏览器是否完全尊重系统路由表。这是一个涉及全局网络隧道实现、操作系统网络栈和浏览器 WebRTC 引擎三个层面的复杂问题。

4.3 “同时出现两个 IP”的现象解释

全局网络隧道开启后访问 WebRTC 检测页面时，经常会看到这样的结果：

• HTTP 出口 IP：显示为全局网络隧道服务器的 IP（一切正常）
• ICE Candidate 中的 srflx：显示为你的真实公网 IP（泄露发生了）

这个现象的技术解释是：HTTP 请求走了浏览器的网络通道，被全局网络隧道正常代理；而 WebRTC 的 STUN 请求通过 ICE Agent 直接发出，走的是物理网卡的直连路径，穿透了全局网络隧道。两者使用的是不同的网络路径，所以会出现两个不同的 IP。

4.4 不同代理类型对 WebRTC 的防护能力

*表注：代理/全局网络隧道类型越接近网络底层，对 WebRTC 的约束能力通常越强。但即使是最底层的全局网络隧道，在 IPv6 或分流场景下仍可能存在泄露风险。

五、五大浏览器的 WebRTC 实现差异与泄露风险评估

不同浏览器对 WebRTC 的实现方式差异较大，这直接影响了各浏览器的泄露风险等级。这一节从渲染引擎层面分析五大主流浏览器的 WebRTC 行为差异。

5.1 主流浏览器 WebRTC 实现对比

*表注：Chrome 与 Edge 共享 Blink 引擎，WebRTC 行为基本一致。Safari（WebKit 引擎）采用权限强绑定策略——未授予摄像头或麦克风权限时，直接在系统底层拦截并隐藏所有 Host Candidate，防护力度远超简单的 mDNS 混淆。Brave 在 Blink 基础上集成了 Shields 隐私模块，防护能力远超 Chrome/Edge。

5.2 Blink 引擎：Chrome、Edge 与 Brave 的差异

Chrome 和 Edge 使用相同的 Blink 渲染引擎，WebRTC 的底层实现几乎完全一致。两者的共同特点是：

• 没有提供原生的 WebRTC 开关，用户无法在设置界面中直接启用或禁用 WebRTC
• chrome://flags 中有 #enable-webrtc-hide-local-ips-with-mdns 选项（已默认开启），但这个选项只影响 host Candidate 的显示方式，对 srflx Candidate 没有任何限制
• 需要借助浏览器扩展（如 WebRTC Network Limiter）或第三方工具来防护 srflx 泄露

Brave 浏览器同样基于 Blink 引擎，但它在此基础上集成了 Shields 隐私模块。Brave Shields 默认启用 “Block fingerprinting” 功能，这个功能会在 ICE Candidate 收集阶段就过滤掉 srflx 类型的 Candidate。这意味着 Brave 用户在默认配置下就获得了 WebRTC 防护，不需要额外安装扩展。

5.3 mDNS 混淆机制的原理与局限性

前面提到，Chrome、Firefox 等浏览器通过 mDNS 混淆来隐藏 host Candidate 中的内网 IP。这个机制定义于 RFC 8828，工作方式是：

1. 浏览器将 host Candidate 中的 IP 地址替换为一个随机的 UUID.local 地址
2. 例如，192.168.1.5 会被替换为 a1b2c3d4-e5f6-7890-abcd-ef1234567890.local
3. 每个独立站点（Origin）甚至每次对等连接（PeerConnection）会生成不同的 .local 地址（保持隔离性）

从表面看，IP 地址被替换了，泄露问题就解决了。但实际上，mDNS 混淆存在几个明显的局限性：

局限性一：隔离性高度依赖浏览器底层实现。 根据 RFC 8828 规范，现代浏览器必须对每个独立站点（Origin）生成不同的 mDNS UUID，并且规范强烈建议（SHOULD）针对每一次新的 PeerConnection 都生成全新的临时（ephemeral）UUID，以切断跨站乃至跨连接的追踪关联。这意味着即使你在同一站点内刷新页面或发起多次连接，每次得到的 .local 地址也应该是不同的。但如果某款浏览器在 Origin 隔离、UUID 的每次连接唯一性、或 mDNS 组播处理上存在实现缺陷、未严格遵守规范，或者用户修改了高级配置，依然可能存在跨站或跨连接的关联风险。

局限性二：mDNS 解析失败时的回退行为。 在某些网络环境下（例如企业网络禁用了 mDNS 组播，或 DNS 配置异常），浏览器可能会回退显示真实的内网 IP 地址。这意味着 mDNS 混淆的防护并不是 100% 可靠的。

局限性三：只针对 host Candidate。 mDNS 混淆只处理了内网 IP 的显示问题，对 srflx Candidate（通过 STUN 反射获取的公网 IP）完全没有影响。也就是说，即使 mDNS 工作正常，你的真实公网 IP 仍然可能通过 srflx Candidate 被暴露。

各浏览器的 mDNS 实现差异：

• Chrome/Edge：默认开启 mDNS 混淆，可通过 chrome://flags 手动关闭（但一般不建议这样做）
• Firefox：默认开启，提供更精细的 about:config 控制选项
• Safari：实现了类似机制，但具体策略与 Chromium 系有所不同，且在未获取用户麦克风或摄像头权限时会直接拦截并隐藏所有 Host Candidate
• Brave：在 mDNS 之上额外阻止了 srflx Candidate，提供了双重防护

5.4 Gecko 引擎（Firefox）的隐私控制优势

在五大主流浏览器中，Firefox 是唯一提供原生 WebRTC 完全关闭选项的浏览器。通过 about:config 页面，用户可以对 WebRTC 的行为进行非常精细的控制：

• media.peerconnection.enabled = false：完全禁用 WebRTC（最彻底，但会影响所有依赖 WebRTC 的服务）
• media.peerconnection.ice.default_address_only = true：只暴露默认网络接口的地址
• media.peerconnection.ice.no_host = true：不暴露 host Candidate（隐藏内网 IP）
• media.peerconnection.ice.proxy_only = true：只使用代理服务器的地址

Firefox 的优势在于不需要安装任何扩展，原生支持多级防护。用户可以根据自己的需求选择合适的防护级别——如果完全不需要 WebRTC 通话功能，可以直接关闭；如果需要保留 WebRTC 但不想泄露内网 IP，可以只开启 no_host。

不过，完全禁用 WebRTC 的代价也值得注意：Google Meet、Zoom Web、Discord、Slack 等大量 Web 应用依赖 WebRTC 进行音视频通话，禁用后这些功能将无法使用。

六、WebRTC 泄露的真实风险：不只是”IP 暴露”这么简单

理解了技术原理之后，有必要看看这些泄露在实际场景中会造成什么样的影响。WebRTC 泄露的后果往往比单纯的”IP 地址被知道了”要严重得多。

6.1 跨境电商与多账号运营

跨境电商平台（Amazon、eBay、Shopify 等）的反关联系统会收集多种信号来判断多个账号是否属于同一运营者。WebRTC 暴露的真实公网 IP 是一个强关联信号——如果多个店铺账号的 WebRTC 检测结果指向同一个真实 IP，平台的反关联系统就会将这些账号标记为关联账号，严重时可能导致全部店铺触发平台风控限制。

一个常见的误区是：使用了指纹浏览器（如 AdsPower、VMLogin 等）就万事大吉了。但指纹浏览器模拟的是浏览器层面的指纹特征（User-Agent、Canvas、字体等），如果指纹浏览器没有在 WebRTC 层面做好防护，srflx Candidate 仍然会暴露统一的真实公网 IP。

6.2 广告投放与社交媒体多账户

广告投放平台（Facebook Ads、Google Ads、TikTok Ads 等）的风控系统同样会收集 WebRTC IP 作为设备关联信号。多账户运营者如果依赖代理工具但没有处理 WebRTC 泄露，不同”虚拟设备”暴露的 WebRTC 公网 IP 仍然是同一个，风控系统依然可以识别出这些账户来自同一台物理设备。

6.3 个人隐私泄露链

在个人隐私层面，WebRTC 泄露的真实公网 IP 可以通过 ISP 的反向查询定位到城市级别的地理位置和运营商身份。当这个信息与浏览器指纹（Canvas、WebGL、字体列表等）结合后，就可以构建出相当精准的用户画像，用于广告定向、价格歧视和跨站追踪。

更有意思的是，如果 WebRTC 暴露的公网 IP 与 HTTP 出口 IP（代理/全局网络隧道的 IP）不一致，这本身就暴露了一个信息：这个用户正在使用代理或全局网络隧道。 在某些场景下，”知道你用了代理”和”知道你的真实 IP”一样敏感。

6.4 网络安全攻防场景

在网络安全领域，WebRTC 泄露也有其实际影响。在渗透测试或溯源反制中，防守方或攻击者可以通过在 Web 页面中嵌入 JavaScript 代码，利用 WebRTC 机制获取目标（访客）的真实 IP 地址，从而穿透目标客户端的前置代理或全局网络隧道，直接定位到该目标的真实物理网络位置。在攻防演练中，这个技术也被用于溯源反制。

FAQ：关于 WebRTC 泄露原理的高频问题

WebRTC 泄露是安全漏洞吗？

不是。WebRTC 泄露是 ICE 框架在正常工作时的副作用。ICE 的设计目标是尽可能多地收集网络路径以提高 P2P 连接成功率，暴露本地和公网 IP 地址是”收集网络路径”这个过程的自然结果。它不是代码缺陷，而是一个为实时通信效率而做的设计取舍。

ICE Candidate 有几种类型？分别泄露什么信息？

ICE Candidate 分为三种类型：host Candidate 暴露设备的内网 IP 地址（如 192.168.x.x），通过直接读取本地网卡获得；srflx Candidate 暴露设备的真实公网 IP，通过 STUN 服务器的地址反射获得，这是危害最大的泄露源；relay Candidate 只暴露 TURN 服务器的 IP，不暴露设备真实 IP，但因为成本原因在实际中几乎不会启用。

STUN 和 TURN 有什么区别？

两者的核心区别在于职责不同。STUN（Session Traversal Utilities for NAT）只做一件事——告诉客户端它的公网 IP 是什么，数据量极小，运营成本接近零。TURN（Traversal Using Relays around NAT）则是在公网中转所有 P2P 通信流量，客户端的真实 IP 完全隐藏，但需要承担全部媒体数据的带宽成本，运营代价高。大多数 WebRTC 应用默认使用 STUN，只在 P2P 直连失败时才启用 TURN 作为保底。

mDNS 混淆能防止 WebRTC 泄露吗？

不能完全防止。mDNS 混淆（RFC 8828）只是将 host Candidate 中的内网 IP 替换为随机的 UUID.local 地址，它不影响 srflx Candidate（真实公网 IP）的暴露。此外，mDNS 防护的有效性高度依赖浏览器底层实现的严谨性：规范要求浏览器对每个独立站点（Origin）生成不同的 UUID 以防止跨站追踪，但如果浏览器实现存在缺陷或用户修改了高级配置，依然可能存在跨站关联风险。

关闭 WebRTC 会影响正常使用吗？

会。完全关闭 WebRTC 后，所有依赖 WebRTC 的浏览器功能都将无法使用，包括 Google Meet、Zoom Web、Discord、Slack 等主流应用的音视频通话功能。Firefox 是唯一原生支持完全关闭 WebRTC 的主流浏览器（通过 about:config），其他浏览器通常需要安装扩展来实现。如果不想完全关闭，可以选择只限制 ICE Candidate 的暴露范围，在保留 WebRTC 功能的同时降低泄露风险。