什么是 WebRTC 泄露

理解 WebRTC 如何在实时连接阶段暴露网络地址，并用可执行步骤修复"IP 已隐藏但仍被识别"的问题。

WebRTC 泄露到底是什么

WebRTC 在建立点对点连接时会通过 ICE（Interactive Connectivity Establishment）协议收集候选地址（ICE Candidate），这些候选可能包含本地 IP、经过 NAT 映射后的公网 IP 以及中继地址。

当网站脚本获取到候选后，即便你的 HTTP 流量走了 VPN，WebRTC 的 UDP 路径仍可能暴露真实网络信息，这就是常说的 WebRTC 泄露。

ICE 候选的生成速度非常快，在连接建立阶段的一个短暂暴露就足以被恶意网站捕获。这也是为什么单次 WebRTC 检测通常就足以发现泄露问题。

为什么"IP 已变更"仍会暴露

很多用户只检查了 HTTP 层的出口 IP，却忽略了 WebRTC 的 UDP 路径。两条路径不一致时，就会出现"页面显示 VPN 地区，但候选里出现本地 ISP"的冲突。

风控系统通常会把这种跨层不一致视为高风险信号，常见表现是验证码增加、登录中断或会话异常缩短。

由于 WebRTC 默认启用，你即便从不使用语音或视频通话，也可能无意中泄露 IP 信息。

最常见的泄露来源

VPN 未覆盖 WebRTC UDP 路径：部分 VPN 不处理 WebRTC 的 UDP 流量，导致 direct candidate 直连本地接口，暴露真实 IP。

多网卡环境：同时启用 Wi-Fi 和有线网，或存在虚拟网卡（VM 接口、VPN 适配器），会生成额外候选，扩大暴露面。

浏览器默认策略优先直连：为追求性能，部分浏览器优先使用直接连接而非中继，大幅增加泄露风险。

如何判断是否"实质泄露"

先看候选中是否出现可归属到本地 ISP 的公网地址，再对照 IP 查询与 DNS 泄露检测结果。

若 IP/DNS 指向 VPN，而 WebRTC 候选指向本地运营商，就属于高优先级修复问题；若仅出现内网段地址，需结合业务场景进一步评估风险。

修复步骤（建议按顺序）

先在 VPN 客户端开启 WebRTC 防护与 kill switch，再在浏览器端启用更严格的候选策略（如仅允许中继候选）。

随后清理浏览器会话并重启网络适配器，避免旧连接残留。每改一项就复测一次，不要一次改动过多，便于定位真正生效项。

ICE 候选类型详解

Host Candidate（主机候选）：来自本地网络接口，是最敏感的类型，直接暴露局域网 IP 或本地 IP。

Server-Reflexive Candidate（服务器反射候选）：通过 STUN 服务器发现，代表公网 IP 地址，也是常见的泄露来源。

Relay Candidate（中继候选）：由 TURN 服务器生成，通常是最安全的选项，因为它完全隐藏了直接地址。

如果你在使用 VPN 时仍看到 Host Candidate，应立即收紧设置。

IPv6 的特殊性

双栈网络（IPv4 + IPv6 并行）可能在 IPv6 路径上泄露，即便 IPv4 已受 VPN 保护。如果在 VPN 之外出现了公网 IPv6 地址，即构成泄露。

确保 VPN 隧道化了 IPv6，或在排障时暂时禁用 IPv6，并在任何变更后重新测试。

隐私与功能的取舍

禁用 WebRTC 会破坏语音/视频通话、文件共享和部分协作工具的功能。

"仅中继模式"（Relay-Only Mode）通常能在保留功能的同时显著降低泄露风险，代价是略微增加的延迟。

如果你日常依赖 WebRTC，每次隐私调整后都应测试通话质量，避免在关键时刻才发现问题。

常见浏览器配置建议

Firefox 提供了限制本地 IP 暴露的偏好设置，且在启用 WebRTC 的同时保持通话功能，企业策略也可强制这些设置。

基于 Chromium 的浏览器通常需要扩展或命令行参数来实现中继模式。更新后务必复测，因为部分参数可能在版本更新后失效。

网卡与适配器清洁

禁用不使用的适配器：虚拟以太网、虚拟机接口、过期的 VPN 适配器。每个活跃接口都可能生成额外 ICE 候选。

如果你经常切换网络，在敏感会话前重启或重置网络适配器，以减少残留候选数据。

干净的适配器列表能简化候选集，也让泄露检测结果更清晰。

TURN 与 STUN 提供商

STUN 服务器用于发现公网 IP，是泄露的常见来源。TURN 服务器转发流量，对隐私更友好，但可能带来额外带宽成本。

如果你自建 WebRTC 基础设施，对于隐私敏感场景建议强制使用 TURN。

企业策略执行

组织可以通过浏览器管理策略禁用 WebRTC 或限制候选类型，适用于高风险环境。

记录策略配置并定期验证，确保浏览器更新不会覆盖这些限制。如果允许使用 WebRTC，应强制中继模式并在策略变更后监控是否有漂移。

长期防回归清单

确认 ICE 候选中不出现 VPN 之外的公网 IP
如需 WebRTC 功能，优先使用仅中继模式
VPN、浏览器或系统更新后重新测试
记录候选类型、IP 归属与测试时间作为基线

风险模型与场景

对于轻度浏览场景，内网 IP 泄露可能尚可接受。但对于记者、活动人士或企业环境，即便内网 IP 也可能暴露敏感信息。

先明确自己的风险容忍度，再决定是完全禁用 WebRTC 还是使用仅中继模式。不确定时，优先选择更严格的限制，并在调整后测试功能是否正常。

常见问题