很多人第一次接触 WebRTC 泄露这个概念时，通常是这样的场景：代理工具已经连上了，IP 检测页面显示的也是代理 IP，一切看起来都很正常。但一到 WebRTC 泄露检测页面，却可能看到与 HTTP 出口不同的公网地址，甚至出现本地网络相关的 Candidate 信息。这种“明明做了防护，为什么 WebRTC 还能看到别的地址”的落差感，是驱动很多人深入了解 WebRTC 泄露原理的起点。
本文尝试从协议层面回答这个问题：WebRTC 的地址发现机制为什么可能暴露额外的网络信息，它和浏览器代理、系统级全隧道路由之间到底是什么关系。如果你对“为什么某些代理或分流环境下仍会出现 WebRTC 地址不一致”这个问题已经困惑很久，或者想理解 ICE、STUN、TURN 这些术语到底在做什么，这篇文章应该能帮你建立一套更完整的技术认知。
总览
| 文章定位 | WebRTC 主题集群 · 原理深度篇 |
| 适合读者 | 已了解 WebRTC 泄露基本概念，想深入理解技术机制的用户 |
| 核心内容 | ICE Candidate 四种类型、STUN/TURN 协议机制、代理/VPN 路由差异、浏览器 IP 处理策略 |
| 关联文章 | WebRTC 测试完全指南 |
*表注：本篇属于 WebRTC 主题集群的原理深度篇，侧重协议级技术解析。如需检测工具步骤，请参考关联文章。
目录
- 一、WebRTC 的设计初衷与隐私矛盾
- 二、ICE 框架：WebRTC 泄露的技术根源
- 三、STUN 与 TURN：WebRTC 中的两个关键角色
- 四、为什么代理或分流隧道环境下仍可能出现 WebRTC 泄露
- 五、五大浏览器的 WebRTC IP 处理差异
- 六、WebRTC IP 暴露的实际隐私影响
- FAQ：关于 WebRTC 泄露原理的高频问题
一、WebRTC 的设计初衷与隐私矛盾
1.1 WebRTC 不是漏洞，是一套完整的实时通信框架
WebRTC（Web Real-Time Communication）是由 W3C 与 IETF 相关规范共同构成的一套浏览器实时通信技术体系，其目标是在网页中实现实时音视频和点对点数据传输。理解这套框架时，可以先抓住几个最常见的 API：
- getUserMedia：在获得用户授权后获取摄像头、麦克风等媒体输入；屏幕共享通常由
getDisplayMedia()完成 - RTCPeerConnection：负责协商并维护与远端的实时通信连接，可承载媒体轨道和数据通道
- RTCDataChannel：在 PeerConnection 上传输任意二进制或文本数据，例如消息、文件片段或应用状态
这几类 API 分工不同：媒体采集负责提供音视频轨道，RTCPeerConnection 负责协商传输路径并维护连接，RTCDataChannel 则用于数据传输。浏览器中的实时会议、在线客服、协作工具和点对点数据应用，都可以建立在这套能力之上。
1.2 P2P 连接的前提：双方要交换可用的网络路径
WebRTC 支持点对点连接，但并不意味着所有连接都一定是“双方真实 IP 直接互连”。在真正建立媒体或数据通道之前，双方需要先发现并交换一组可能可用的网络路径；如果直连条件不满足，也可以通过 TURN 中继完成通信。
负责发现这些网络路径的机制叫做 ICE（Interactive Connectivity Establishment，交互式连接建立）。ICE 会收集 Candidate（候选地址），再通过连通性检查选出可用路径。WebRTC 标准本身没有规定应用必须使用哪一种信令方式，Candidate 通常由应用自己的信令通道交换；与此同时，页面脚本也可能通过 WebRTC API 获得浏览器允许暴露的 Candidate 信息。
这也是所谓“WebRTC IP 泄露”真正需要关注的地方：网页通过普通 HTTP 请求通常只看到一个出口地址，而 WebRTC 在建立连接时可能接触到额外的本地地址、NAT 映射地址或其他网络路径。IETF 的 RFC 8828 专门讨论了这种 IP 地址暴露与媒体性能之间的隐私权衡。
1.3 连接能力与隐私之间的取舍
WebRTC 的目标不是“绕过所有网络限制”，而是在浏览器和操作系统允许的范围内，尽可能找到一条可用的实时通信路径。ICE 可以同时考虑 host、STUN 发现的 server-reflexive、TURN relay 等候选路径，并通过连通性检查决定最终使用哪一条。
这种设计天然存在一个取舍：可尝试的网络路径越多，连接成功率和网络适应能力通常越好，但网页可能接触到的地址信息也越多。RFC 8828 因此定义了多种 IP 处理模式，用来在媒体性能和隐私之间做不同程度的限制；而 WebRTC 本身的通信安全则另有专门的 RFC 8827（WebRTC Security Architecture） 进行规范。
所以，把 WebRTC 地址暴露简单理解成“安全性被放在最后”并不准确。更合适的理解是：WebRTC 为连通性保留了多种候选路径，而浏览器需要通过权限、路由策略和 IP 处理规则限制这些路径向网页暴露多少信息。
二、ICE 框架：WebRTC 泄露的技术根源
ICE 是理解 WebRTC 泄露的核心概念。前面提到 ICE 负责发现网络路径，但“候选地址”到底有哪些类型？哪些地址会在初始收集阶段出现，哪些是在连通性检查中动态发现？这一节把 ICE 的内部机制拆开来看。
2.1 ICE 的工作方式：发现、排序并检查可用网络路径
ICE（Interactive Connectivity Establishment）定义于 RFC 8445。它不是一个单独的传输协议，而是一套用于 NAT 穿越和连接路径选择的框架。它的核心职责可以概括为：
发现可能可用的 Candidate，为它们计算优先级，并对 Candidate Pair 执行连通性检查，从中选出可工作的连接路径。
按照 RFC 8445，ICE Candidate 共有四种类型：host、server-reflexive（srflx）、peer-reflexive（prflx）和 relayed（relay）。其中 prflx 与另外三种有一点不同：它通常不是 Candidate Gathering 阶段预先收集出来的，而是在后续连通性检查中动态发现。
以常见的 WebRTC 建连流程为例，ICE Agent 可能经历下面这些步骤。实际能收集和暴露哪些地址，还会受到浏览器 IP 处理策略、权限和系统路由的限制：
- 根据浏览器允许使用的网络接口生成 host Candidate
- 如果配置了 STUN 服务，通过 STUN 发现 server-reflexive（srflx）Candidate
- 如果配置了 TURN 服务，申请 relay Candidate，作为可参与 ICE 检查的一条中继路径
- 为 Candidate 计算优先级并组成 Candidate Pair，执行 STUN 连通性检查
- 连通性检查过程中，如果发现此前未预先获知的 NAT 映射，可形成 peer-reflexive（prflx）Candidate
从隐私角度看，真正需要关注的不是“ICE 一定会泄露某个固定地址”，而是网页最终能看到哪些 Candidate，以及这些 Candidate 是否暴露了超出用户预期的本地地址或公网出口。下面分别看几种 Candidate 的含义。
2.2 host Candidate：可能暴露本地网络地址
host Candidate（主机候选地址）来源于本机可用于通信的网络接口地址。从 ICE 协议角度看，它代表端点自身可直接使用的传输地址；但现代浏览器不一定会把原始本地 IP 原封不动地暴露给网页，具体呈现方式取决于浏览器的隐私策略。
在 IPv4 NAT 场景下，这类地址经常落在 RFC 1918 定义的私有地址空间：
192.168.0.0/16：家用和小型局域网中很常见10.0.0.0/8：企业、云网络和大型局域网中常见172.16.0.0/12：另一段常见的私有 IPv4 地址空间
系统级 VPN 或全隧道路由通常不会把局域网接口本身的私有地址“改写成 VPN 地址”，因此设备仍然可能同时拥有物理网卡地址和虚拟网卡地址。不过，设备拥有这些地址，不等于网页一定能看到这些原始地址；RFC 8828 就是为了限制 WebRTC 在未经额外信任的情况下暴露过多本地网络信息。
host Candidate 的隐私价值也需要准确理解：
- 常见的
192.168.x.x本身并不能证明两个用户处于同一个物理位置，因为私有地址会在全球大量网络中重复使用 - 但更具体、长期稳定的私有地址可能增加浏览器指纹的熵，RFC 8828 也明确把私有 IPv4 地址视为潜在的指纹面
- 如果网页能结合其他网络与浏览器信息，本地地址仍可能成为识别同一设备或同一浏览环境的辅助信号之一
为降低 host Candidate 直接暴露私有 IP 的风险，一些浏览器采用了用随机 .local 主机名代替原始地址的 mDNS 隐藏方案。例如，原本的 192.168.1.5 可能在 Candidate 中表现为随机的 xxxx.local 名称。需要注意的是，RFC 8828 本身定义的是 WebRTC IP 地址处理要求，并不是 mDNS Candidate 的规范；mDNS 隐藏 Candidate 的具体方案曾由 IETF 的 Internet-Draft 描述，该草案后来过期，因此更适合把它理解为浏览器采用的一类隐私实现，而不是一个已经发布的 RFC 标准。
2.3 srflx Candidate：最值得关注的公网映射地址
srflx Candidate（Server Reflexive Candidate，服务器反射候选地址）代表的是STUN 服务器从外部观察到的 NAT 映射地址。在普通家庭网络中，它往往对应 ISP 出口公网 IP；但如果 STUN 流量已经被一个正确配置的全隧道 VPN 接管，那么 STUN 看到的也可能是 VPN 出口地址，而不是 ISP 原始公网地址。
因此，判断 WebRTC 是否发生“真实公网 IP 泄露”，不能只看有没有 srflx Candidate，而要看它是否出现了一个本不应该暴露的公网路径。例如，网页 HTTP 请求走代理或 VPN 出口，但 srflx 却显示 ISP 公网地址，这才说明 WebRTC 的网络路径与预期出口不一致。
从 Candidate 的角度理解到这里就够了：srflx 的重点是“它代表 STUN 在这条网络路径上看到的映射地址”，而不是“它一定等于真实 ISP 公网 IP”。至于 STUN 如何通过 Binding Request、XOR-MAPPED-ADDRESS 返回这个地址，以及为什么它还能参与 ICE 连通性检查，放到第三章再单独拆解。
公网 IP 可以被 IP 地理位置和 ASN/运营商数据库用于估算网络归属和大致区域，但这种定位通常是网络级、城市或区域级的近似信息，并不能等同于精确物理位置。
2.4 relay Candidate：通过 TURN 中继降低直接地址暴露
relay Candidate（Relayed Candidate，中继候选地址）由 TURN 服务器分配。它代表的不是客户端本地接口或 NAT 映射地址，而是一条由 TURN 提供的中继路径；当 ICE 最终选择 relay 路径通信时，远端实际连接的是 TURN 分配的 relay 地址，因此可以减少双方之间的直接 IP 暴露。
不过，“最终通过 relay 建连”和“远端从未见过其他 Candidate”不是一回事。如果应用在 ICE 协商阶段同时交换了 host 或 srflx Candidate，远端仍可能已经获得这些地址。隐私敏感应用可以进一步使用 iceTransportPolicy: "relay" 等策略，只收集/使用 relay Candidate。至于 TURN 为什么比 STUN 更消耗带宽、什么时候会被选中，第三章再从服务机制角度展开。
四种 Candidate 类型的区别可以参考下表：
| Candidate 类型 | 地址含义 | 隐私关注点 | 形成方式 |
|---|---|---|---|
| host | 本机可直接使用的接口地址；现代浏览器可能以 mDNS 名称隐藏 | 可能暴露本地网络信息或增加指纹面 | 本地网络接口 |
| srflx | STUN 观察到的 NAT 映射地址 | 若绕过预期代理/VPN 路由，可能暴露 ISP 公网出口 | STUN 地址发现 |
| prflx | 连通性检查过程中发现的 NAT 映射地址 | 主要属于 ICE 动态路径发现，不是初始 Candidate Gathering 的主要泄露来源 | ICE Connectivity Checks |
| relay | TURN 服务器分配的中继地址 | 实际连接使用 relay 地址；是否还能获知其他 Candidate 取决于应用的 ICE 策略 | TURN 分配 |
*表注：RFC 8445 推荐的 Candidate 类型偏好值是 host 126、prflx 110、srflx 100、relay 0，但最终 Candidate priority 还会结合 local preference 和 component ID 计算；实际使用哪条路径还取决于 Candidate Pair 的连通性检查与应用策略，不能简单理解为固定的“host → srflx → relay”执行顺序。
三、STUN 与 TURN：WebRTC 中的两个关键角色
第二章已经讲清楚 Candidate 是什么，这一章只继续回答两个问题：STUN 怎样发现映射地址，TURN 怎样提供中继路径。两者都参与 ICE，但承担的任务完全不同。
3.1 STUN：轻量级的地址发现与连通性辅助协议
STUN（Session Traversal Utilities for NAT）最直观的作用，是让客户端知道“外部服务器在这条网络路径上看到我的地址是什么”。客户端向 STUN 服务器发送 Binding Request，服务器根据收到的数据包确定映射源地址，并在 Binding Response 的 XOR-MAPPED-ADDRESS 中返回结果；ICE 随后可以据此形成 srflx Candidate。
但 STUN 并不只负责“查公网地址”。在 ICE 进入 Connectivity Checks 后，STUN 消息还用于验证 Candidate Pair 是否真的能够双向通信。因此，更准确的理解是：STUN 同时参与地址发现和连通性检查，但不负责持续中继媒体流量。
当前 STUN 规范是 RFC 8489（2020 年）。普通 STUN 默认端口为 3478（UDP/TCP），STUN over TLS/DTLS 默认端口为 5349。
官方文档中可以看到的一些 STUN 服务示例包括：
stun:stun.cloudflare.com:3478（Cloudflare Realtime）stun:global.stun.twilio.com:3478（Twilio Network Traversal Service）
这些地址仅作协议示例，生产环境应以服务商当前文档和使用条款为准。
3.2 TURN：承担真实流量的中继服务
TURN（Traversal Using Relays around NAT）解决的是另一类问题：当端点之间的直接路径受 NAT、防火墙或企业网络策略限制时，它在公网提供一个可达的中继地址，并转发实际通信流量。
实际建连时，ICE 可以把 TURN 路径与其他路径一起检查；应用也可以主动使用 relay-only 策略，不必等直连失败后才使用 TURN。
TURN 的当前规范是 RFC 8656。默认端口包括 3478（UDP/TCP）以及用于 TURN over TLS/DTLS 的 5349。
一旦中继路径被选中，TURN 服务器就要持续转发会话数据，因此带宽成本通常明显高于 STUN；很多系统会优先尝试可用直连，但 TURN 仍是常见的可靠性保障手段。
3.3 STUN 与 TURN 的核心差异
| 维度 | STUN | TURN |
|---|---|---|
| 核心功能 | 发现 NAT 映射地址，并参与 ICE 连通性检查 | 分配 relay 地址并中继实际通信流量 |
| 带宽消耗 | 通常较低 | 随被中继的实际流量增长 |
| 默认端口 | 3478（UDP/TCP）；TLS/DTLS 默认 5349 | 3478（UDP/TCP）；TLS/DTLS 默认 5349 |
| 对地址暴露的影响 | 可能向应用产生 srflx 映射地址 | 远端通过 relay 地址通信，可减少直接 IP 暴露 |
*表注：STUN 和 TURN 经常一起出现在 ICE 配置中，但一个主要负责“发现/检查路径”，另一个负责“提供中继路径”，不能简单按“免费”和“昂贵”来区分。
3.4 为什么 WebRTC 检测工具常使用 STUN
理解了 STUN 的工作原理，就不难理解 WebRTC 检测工具为什么经常配置 STUN。一个典型的公网地址检测逻辑可以概括为：
- 在页面中创建 RTCPeerConnection，并配置一个或多个 STUN 服务器
- ICE Agent 通过 STUN 尝试获得 srflx Candidate
- 工具把浏览器允许暴露的 Candidate 与页面 HTTP 出口 IP 放在一起比较，观察是否出现了用户预期之外的公网路径
需要注意：没有 STUN 仍可能观察到 host Candidate；同时，浏览器还可能按权限和 IP Handling Policy 限制 Candidate 暴露。因此检测结果反映的是当前浏览器 + 当前网络路由 + 当前策略的组合。
如果你的目的不是继续研究协议，而是想直接判断当前浏览器有没有泄露、检测结果应该怎么看以及不同浏览器怎么处理，可以转到 WebRTC 测试完全指南。本篇继续聚焦原理，避免把检测步骤和修复操作重复展开。
四、为什么代理或分流隧道环境下仍可能出现 WebRTC 泄露
这是搜索“WebRTC 泄露”的用户最想理解的问题之一。真正的关键不在于“WebRTC 天生能够穿透任何代理或 VPN”，而在于：WebRTC 使用的网络路径是否和 HTTP 请求使用的出口一致。 RFC 8828 对经典应用代理、分流 VPN 和多网卡环境下的 IP 暴露问题都有明确讨论。
4.1 浏览器代理为什么不一定覆盖 WebRTC
HTTP 代理主要代理应用层的 HTTP/HTTPS 请求。WebRTC 的 ICE/STUN 通信不是普通 HTTP 请求，因此如果浏览器仍允许 WebRTC 直接访问网络，经典 HTTP 代理并不会自动覆盖这些 UDP/TCP 路径。RFC 8828 也明确指出，在“经典应用代理”场景下，如果客户端仍被允许直接访问互联网，STUN 检查可能绕过代理并暴露客户端的公网地址。
SOCKS5 代理则不适合简单贴上“OSI 第 5 层”的固定标签。更准确的说法是：SOCKS5 是一种通用代理协议，RFC 1928 明确定义了 UDP ASSOCIATE，所以协议本身具备 UDP 中继能力。但 WebRTC 是否真的通过 SOCKS5 转发 UDP，还取决于浏览器实现和具体 IP Handling Policy，不能仅凭“用了 SOCKS5”就判断一定会防住或一定会泄露。
因此，浏览器代理场景更适合这样理解：普通网页请求已经走代理，不代表 ICE 的所有候选路径也自动被同一个代理覆盖。 现代浏览器可以通过更严格的 WebRTC IP 处理策略强制使用默认路由、限制本地地址，甚至禁止非代理 UDP，但不同浏览器提供的控制方式并不完全一样。
4.2 系统级全隧道为什么通常更可靠，但仍要看路由范围
系统级全隧道 VPN 的逻辑与浏览器代理不同。它通常通过虚拟网络接口和系统路由规则接管 IP 流量；如果 IPv4、IPv6、UDP 等相关路由都被完整纳入隧道，而且没有 split tunneling 或接口排除，那么 WebRTC 的 STUN/TURN 流量通常也会按照系统路由经过隧道。此时 srflx Candidate 更可能反映 VPN 出口，而不是 ISP 原始公网出口。
真正容易出现问题的是“并没有完全全隧道”的情况。RFC 8828 特别提到：在支持多接口或 split-tunnel 的 VPN 环境中，WebRTC 可能同时发现 VPN 公网地址和承载 VPN 的 ISP 公网地址。常见触发条件包括：
- IPv4 已进入隧道，但 IPv6 没有被同样接管
- 启用了 Split Tunneling，部分目标、应用或接口被明确排除在隧道之外
- 设备同时处于多个可用网络接口上，而浏览器策略允许枚举或尝试额外接口
- VPN 客户端缺少 kill switch / 防火墙约束，隧道异常时系统仍允许直接出站
所以，“WebRTC 会直接无视系统路由、穿透 TUN 虚拟网卡”并不适合作为通用结论。更准确的判断标准是：操作系统是否仍然存在一条允许 WebRTC 使用的隧道外路径，以及浏览器当前的 IP 处理策略是否允许使用这条路径。
4.3 “同时出现两个 IP”应该怎么解释
在代理、分流 VPN 或多网卡环境下访问 WebRTC 检测页面时，有时会看到两类地址：
- HTTP 出口 IP：网页请求所使用的代理/VPN 出口
- srflx Candidate 中的公网映射地址：STUN 服务器在当前 WebRTC 网络路径上看到的 NAT 映射地址
如果 HTTP 出口 IP 与 srflx 映射地址不同，说明 HTTP 请求与 STUN 至少使用了不同的公网路径；但“地址不同”本身还不能直接等同于真实公网 IP 泄露，还需要结合 IPv4/IPv6、系统路由、代理/VPN 配置和浏览器策略继续判断。只有当 srflx 暴露了本应被代理/VPN 隐藏的 ISP 公网地址时，才是最典型的“真实公网 IP 泄露”。如果两者相同，则说明 STUN 很可能也走了当前预期出口。
如果你看到的是一份包含代理/VPN 标记、DNS、WebRTC 等多个字段的综合检测报告，而不只是单独的 Candidate 列表，可以结合 IP 地址检测结果解读指南 逐项判断各字段代表什么；这里重点只讨论 HTTP 出口与 WebRTC 网络路径为什么会出现差异。
4.4 不同网络覆盖方式对 WebRTC 的影响
| 网络方式 | 覆盖范围 | UDP 能力 | 对 WebRTC 的约束 | 说明 |
|---|---|---|---|---|
| HTTP 代理 | 主要覆盖 HTTP/HTTPS 请求 | 不直接代理 WebRTC UDP | 通常不足 | 若仍允许直接联网，STUN 可能走代理外路径 |
| SOCKS5 代理 | 通用代理协议 | 协议支持 UDP ASSOCIATE | 取决于浏览器实现与策略 | 不能把协议支持 UDP 等同于浏览器一定代理 WebRTC UDP |
| 系统级全隧道（TUN） | 按系统路由接管 IP 流量 | 通常可通过隧道承载 | 通常较强 | 前提是 IPv4/IPv6/UDP 都被完整覆盖，且没有分流排除 |
| 全隧道 + 防火墙 / Kill Switch | 隧道外出站同时被限制 | 按隧道路由处理 | 较强 | 可减少隧道异常或路由遗漏时的直接出站 |
| 系统代理 / 混合代理模式 | 取决于操作系统与代理软件 | 取决于实现 | 需要实测 | 不能仅凭“系统级”名称判断是否覆盖 ICE/STUN |
*表注：影响 WebRTC 是否泄露的关键不是“代理层级越低就一定越安全”，而是当前网络方案是否真正覆盖 WebRTC 会使用的 IPv4、IPv6、UDP/TCP 路径，以及浏览器是否允许使用其他接口。
五、五大浏览器的 WebRTC IP 处理差异
不同浏览器对 WebRTC 的本地地址暴露、默认路由和代理策略确实存在差异，但很难用“高风险 / 低风险”给浏览器做永久排名：这些行为会随版本、权限、操作系统和策略变化。更可靠的比较方式，是看各浏览器提供了哪些 IP 处理机制。
5.1 主流浏览器 WebRTC IP 处理机制对比
| 浏览器 | 引擎 | 用户可见的 WebRTC 总开关 | IP / 路由控制特点 | 需要注意 |
|---|---|---|---|---|
| Chrome | Blink / Chromium | 设置界面没有简单的“关闭 WebRTC”开关 | Chromium 提供 WebRTC IP Handling Policy，可由扩展或管理策略使用 | 具体 Candidate 暴露还受版本、权限与网络环境影响 |
| Edge | Blink / Chromium | 设置界面通常没有简单的“关闭 WebRTC”开关 | 核心 WebRTC 行为与 Chromium 体系接近 | 企业策略和具体版本可能与 Chrome 有差异 |
| Firefox | Gecko | 可通过 about:config 的内部偏好禁用 PeerConnection | 提供 no_host、default_address_only、proxy_only 等高级偏好 | 这些属于高级内部配置，名称和行为可能随版本变化 |
| Safari | WebKit | 没有面向普通用户的简单总开关 | WebKit 曾通过权限限制 Host Candidate 暴露；当前表现还受 Safari 版本、mDNS 与权限状态影响 | 具有版本依赖，建议以当前 Safari/WebKit 实测为准 |
| Brave | Blink / Chromium | 不以“完全关闭 WebRTC”为默认策略 | 提供独立的 WebRTC IP Handling Policy，包括 Default Public Interface Only、Disable Non-Proxied UDP 等 | Brave 官方文档明确说明 Default 模式仍允许 WebRTC 枚举接口，不能等同于“默认阻止 srflx” |
*表注：这里汇总的是浏览器公开文档、可核验源码与已公开实现机制，不代表所有版本始终保持相同行为，也不用于给浏览器做固定的“泄露风险排名”。实际结果应以当前浏览器版本和检测环境为准。
Safari 的权限策略值得单独说明。WebKit 曾在 官方 WebRTC 隐私说明中指出：未获得摄像头/麦克风等 capture device 访问权限时，会限制 Host Candidate 的暴露；获得采集权限后，则可以放宽这项限制以提高连接成功率和效率。不过，这份说明来自 Safari 11 时期，不能直接视为当前 Safari 所有版本的完整行为描述。后续 WebKit 又在 Safari Technology Preview 74 中默认启用了 mDNS ICE Candidate 支持，因此当前 Safari 的实际 Candidate 表现还会受到具体版本、mDNS、媒体权限和网络环境影响，仍应以当前版本测试结果为准。
5.2 Chromium 系：Chrome、Edge 与 Brave 的差异
Chrome 和 Edge 都基于 Chromium，核心 WebRTC 行为有较多共同点。Chrome 官方的扩展隐私 API 当前定义了四种 WebRTC IPHandlingPolicy 值：default、default_public_and_private_interfaces、default_public_interface_only 和 disable_non_proxied_udp。这说明 Chromium 本身并不是“完全不支持 WebRTC IP 控制”，只是普通设置界面没有提供一个简单的总开关。
Brave 同样基于 Chromium，但它把这套 WebRTC IP Handling Policy 直接提供给用户配置。根据 Brave 官方帮助文档，Default 模式下 WebRTC 仍有权枚举接口并绑定它们来发现公网接口；更严格的 Default Public Interface Only 会只使用 HTTP 的默认路由并避免暴露本地地址，而 Disable Non-Proxied UDP 会进一步禁止非代理 UDP（除非代理本身支持 UDP）。
因此，Brave 更准确的优势是“提供了明确、可调的 WebRTC IP 处理策略”，而不是“Shields 默认过滤所有 srflx Candidate”或“默认状态几乎不可能泄露”。
5.3 mDNS 隐藏 Host Candidate：能解决什么，不能解决什么
mDNS 隐藏 Host Candidate 的基本思路，是在向网页或远端描述本地 Candidate 时，不直接放入私有 IP，而是使用动态生成的 .local 主机名。这样可以降低网页直接读取局域网 IP 的机会。
这里最需要避免的是把 mDNS 和 RFC 8828 混为一谈：RFC 8828 定义的是 WebRTC IP 地址处理模式和隐私要求；mDNS Candidate 隐藏方案曾由 IETF Internet-Draft 描述，但没有最终发布为 RFC。也正因为不同浏览器会在实现细节上做自己的取舍，所以不宜把“每个 Origin 一定生成怎样的 UUID”“每次刷新一定变化”之类行为写成跨浏览器的固定规则。
mDNS 能解决的核心问题：降低 host Candidate 直接暴露私有 IP 地址的风险。
mDNS 不能解决的核心问题：它不会天然阻止 srflx Candidate 的产生。如果 STUN 流量走了用户不希望暴露的公网路径，srflx 仍可能反映那个公网映射地址。因此，mDNS 更像是“本地地址保护的一层”，而不是完整的 WebRTC 公网 IP 防泄露方案。
5.4 Firefox：高级偏好提供了更细的控制空间
Firefox 的一个特点，是在 about:config 中保留了多项 WebRTC 相关高级偏好。Mozilla 当前源码可以核对到以下配置项：
media.peerconnection.enabled：控制 RTCPeerConnection 支持；设为 false 会使依赖 WebRTC PeerConnection 的功能无法正常工作media.peerconnection.ice.no_host：限制 host Candidatemedia.peerconnection.ice.default_address_only：限制 ICE 使用默认地址路径media.peerconnection.ice.proxy_only：提供更严格的代理路径控制
这些配置项可以从 Mozilla Searchfox 当前源码 中核对。但它们属于高级内部偏好，不应当当作长期稳定的公共产品界面来描述；浏览器升级后，名称、默认值或具体行为都可能调整。
如果把 media.peerconnection.enabled 设为 false，依赖 RTCPeerConnection 的音视频或实时数据功能可能无法使用。因此，更实际的做法通常是先确认当前网络到底泄露了哪一类 Candidate，再决定是限制 host、收紧代理路径，还是完全关闭 WebRTC。
六、WebRTC IP 暴露的实际隐私影响
理解了技术原理之后，再看实际风险会更清楚。WebRTC 暴露的价值主要不在于“一个 IP 就能直接识别一个人”，而在于它可能让网页获得普通 HTTP 请求之外的网络信息，并与其他信号组合使用。
6.1 多账号与隔离环境：重点是网络一致性
在多账号、浏览器隔离或跨境业务环境中，用户通常希望每个浏览环境的网络出口与预期代理保持一致。如果 HTTP 页面显示的是代理出口，而 WebRTC Candidate 又暴露了另一个公网路径，就会产生明显的“网络环境不一致”。这类不一致至少能够被当前网页观察到。
至于 Amazon、eBay、Google、Meta、TikTok 等平台是否把 WebRTC IP 作为具体风控字段、权重多高，公开资料通常不会完整披露，因此不适合直接写成“平台一定会收集并据此关联账号”。更可靠的表达是：网络出口不一致会增加环境一致性风险，但平台最终如何使用这些信号属于其内部风控策略。
6.2 指纹隔离工具也不能替代网络层检查
浏览器隔离或指纹管理工具可以控制 User-Agent、Canvas、字体、时区等浏览器侧特征，但网络出口是否一致仍然需要单独验证。即使浏览器指纹看起来彼此独立，如果 WebRTC 仍然暴露了同一个预期之外的公网地址，网页层面仍然可能看到这些环境之间存在共同的网络路径。
反过来，也不能仅凭“两个环境出现同一个私有地址段”就判断它们位于同一物理网络，因为 RFC 1918 私有地址在不同局域网中会大量重复。真正有意义的是结合公网出口、Candidate 类型、浏览器策略以及其他上下文综合判断。
6.3 个人隐私：IP 更适合看作网络归属信号
WebRTC 暴露的公网地址可以帮助第三方估算网络归属、ASN/运营商和大致区域，也可能成为浏览器指纹或跨会话关联中的一个辅助信号。但 IP 地理位置通常只是近似值，不能据此直接推导用户的精确住址或“真实物理位置”。
如果 WebRTC 公网地址与 HTTP 出口不同，确实说明当前设备存在多条可观察的网络路径；这可能与代理、VPN、分流、多网卡或 IPv4/IPv6 路由差异有关。它可以提示“网络路径不一致”，但仅凭这一点也不能百分之百证明用户一定正在使用某一种代理工具。
6.4 网络安全测试：用于发现路由与隐私配置问题
在授权的安全测试或隐私排查中，WebRTC Candidate 信息可以用来检查浏览器是否暴露了超出预期的本地地址、ISP 出口或额外网络接口。这类测试的价值是发现代理、VPN、IPv6、分流策略和浏览器 IP Handling Policy 之间的不一致。
但把它描述成“Web 页面可以稳定穿透任何代理或全局网络隧道，并直接定位真实物理位置”是不准确的。正确配置的全隧道路由与防火墙可以让 WebRTC 走同一出口，而公网 IP 本身通常也只能提供近似的网络地理信息。
FAQ：关于 WebRTC 泄露原理的高频问题
Q1：WebRTC 泄露是安全漏洞吗？
通常不应把“WebRTC 能暴露额外 IP 信息”简单等同于软件漏洞。ICE 本来就需要发现网络路径，IETF 也在 RFC 8828 中把由此产生的 IP 暴露作为隐私问题专门处理，并定义了不同的限制模式。当然，如果某个浏览器实现违反了预期的权限或隐私策略，那又属于具体实现层面的安全问题，需要单独判断。
Q2：ICE Candidate 有几种类型？分别代表什么？
RFC 8445 中有四种 Candidate：host 代表本机可直接使用的接口地址；srflx 是通过 STUN 等方式发现的 NAT 映射地址；prflx 是在 ICE 连通性检查过程中动态发现的 peer-reflexive 地址；relay 则是 TURN 服务器分配的中继地址。实际做 WebRTC 泄露排查时，最常关注的是 host 是否暴露本地地址，以及 srflx 是否出现了绕过预期代理/VPN 的公网出口。
Q3：STUN 和 TURN 有什么区别？
STUN 主要用于发现 NAT 映射地址并参与 ICE 连通性检查，传输量通常较小；TURN 会分配 relay 地址，并在被选中时持续中继实际通信流量，因此带宽成本通常更高。TURN 不只是“直连失败才会出现”的被动兜底，应用也可以主动使用 iceTransportPolicy: "relay" 强制只走中继。
Q4：mDNS 混淆能防止 WebRTC 泄露吗？
不能单独解决所有 WebRTC IP 暴露问题。mDNS 隐藏主要针对 host Candidate 中的本地 IP，把原始地址替换为 .local 名称；它不会天然阻止 srflx Candidate。如果 STUN 仍通过用户不希望暴露的公网路径出站，公网映射地址依然可能被发现。需要注意的是，RFC 8828 规定的是 WebRTC IP 地址处理要求，mDNS Candidate 方案本身并不是 RFC 8828 的内容。
Q5：关闭 WebRTC 会影响正常使用吗？
会影响依赖 RTCPeerConnection 的实时音视频、数据通道等功能。Firefox 当前可以通过 media.peerconnection.enabled 这类高级偏好关闭 PeerConnection；Chromium 系浏览器则更多通过 IP Handling Policy、扩展或管理策略限制网络路径。对大多数用户来说，比“全部关闭”更稳妥的做法，是先检测当前暴露的是 host、srflx 还是其他 Candidate，再针对性调整网络和浏览器策略。
