WebRTC 泄漏怎么修复?Firefox 代理环境下的排查步骤
简答:WebRTC 检测页出现多个地址,不一定代表真实公网 IP 已泄漏;先把普通网页出口、本地候选、IPv6 和 DNS 结果分开记录。Firefox 桌面版可在已配置代理的前提下,将 media.peerconnection.ice.proxy_only_if_behind_proxy 改为 true,再完全重启浏览器并用相同条件复测。若普通网页也显示直连地址,应先排查代理客户端是否真正接管了 Firefox 流量。
定义:WebRTC 泄漏是指网页通过 ICE、STUN 等实时通信机制获得本地接口、公网或其他连接候选地址,使检测页面显示出用户不希望暴露的网络信息。
先试这一步:Firefox WebRTC 泄漏速查
如果你刚在检测页面看到多个 IP,先不要立即关闭全部 WebRTC,也不要公开粘贴订阅链接。先确认 Firefox 普通网页是否已经通过预期代理访问,再按下面的现象分类处理。
| 检测现象 | 更可能的含义 | 下一步动作 | 复测标准 |
|---|---|---|---|
| 普通网页出口已切换,但 WebRTC 显示额外公网地址 | WebRTC 候选路径可能没有按代理策略限制 | 检查 media.peerconnection.ice.proxy_only_if_behind_proxy | 同一条件下不再出现要隐藏的公网候选 |
| 只出现局域网或本地接口地址 | 属于本地候选暴露,不等同于公网出口泄漏 | 先记录地址类型,再评估是否需要限制本地候选 | 复测结果中不再显示不希望暴露的本地地址 |
| 普通网页和 WebRTC 都显示直连公网地址 | 浏览器流量可能没有经过代理,或 IPv6 单独直连 | 先检查代理客户端、系统代理和 IPv6 路由 | 普通网页出口先与预期一致,再复测 WebRTC |
| 修改后视频会议无法加入 | WebRTC 候选路径受到限制,业务功能受到影响 | 恢复修改过的设置并重启 Firefox | 会议功能恢复,再选择更细粒度的限制方式 |
WebRTC 的 ICE 会寻找可用连接路径,STUN 可帮助浏览器发现网络侧地址;因此检测页面显示的地址需要结合候选类型和普通网页出口一起判断,而不能只看地址数量。MDN 对 ICE、STUN 与 TURN 的说明。
前置条件:先确认本文适用范围
本文只讲 Firefox 桌面版在已配置代理或网络加速客户端环境下的 WebRTC 排查,不覆盖 Chrome、Edge、Safari、移动版 Firefox,也不把浏览器设置当成代理客户端的完整配置教程。
- 准备同一个 Firefox 桌面版、同一网络和同一个检测页面。
- 准备一个已经配置好的浏览器代理、系统代理或代理客户端;本文不提供公共代理、订阅链接或凭据。
- 修复前先记录普通网页显示的公网出口,以及 WebRTC 检测页显示的公网、局域网和 IPv6 候选。
- 如果普通网页本身没有经过预期代理,先处理代理接管问题,再判断 WebRTC 是否泄漏。
Mozilla 的帮助文档明确说明,WebRTC 用于浏览器间的音频、视频和文件共享,在某些网络环境中可能让网站看到本地 IP,即使设备处于 VPN 或 NAT 路由器之后。Mozilla Firefox 帮助文档。
本文是第三方使用指南,不代表 Firefox、代理客户端或网络服务的官方页面。
Firefox 桌面版修复步骤:限制代理环境下的 WebRTC 路径
第一步:记录修复前结果
- 在不改变网络、浏览器和代理状态的情况下,打开同一个 WebRTC 检测页面。
- 分别记录普通网页出口、WebRTC 公网候选、局域网候选和 IPv6 候选;不要把完整 IP、订阅链接或访问令牌发到论坛。
- 如果普通网页出口仍是直连地址,先暂停后续设置,检查 Firefox 或代理客户端是否真的接管了浏览器流量。
第二步:打开 Firefox 高级配置
- 在 Firefox 地址栏输入
about:config并回车。 - 出现风险提示时,确认进入高级配置页面。
- 搜索
media.peerconnection.ice.proxy_only_if_behind_proxy。 - 将该项设置为
true。这个设置的适用前提是 Firefox 确实配置了代理;Mozilla 的公开缺陷记录说明,它用于在代理启用时限制 WebRTC 的非代理 UDP 和直接点对点路径。Mozilla Bugzilla:WebRTC does not use proxy。
不要把 media.peerconnection.ice.proxy_only 作为普通替代方案直接照抄。Mozilla 的记录指出,强制只允许代理路径可能在没有代理或缺少可用中继时导致 WebRTC 无法建立连接;本文优先使用“检测到代理时才限制”的设置。
第三步:完全重启并复测
- 关闭所有 Firefox 窗口,确认 Firefox 进程已经退出,再重新打开。
- 保持与修复前相同的代理客户端、网络和检测页面。
- 先打开普通网页确认出口是否仍符合预期,再打开同一个 WebRTC 检测页面。
- 比较修复前后的公网候选、局域网候选和 IPv6 候选,不要只看检测页是否显示“无结果”。
Mozilla 的 WebRTC 隐私说明页列出了 media.peerconnection.ice.proxy_only_if_behind_proxy、media.peerconnection.ice.no_host 等候选地址控制项,但也明确提示这些选项仍有未完成的文档和实现边界。Mozilla Wiki:Media/WebRTC/Privacy。
复测记录模板:用同一条件判断是否修复
建议把修复前后结果写成一张小表。下面的字段不要求填写完整 IP,只记录类型、是否变化和下一步动作。
| 项目 | 修复前 | 修复后 | 判断 |
|---|---|---|---|
| 普通网页公网出口 | 例如:代理出口/直连出口 | 例如:代理出口/直连出口 | 先确认浏览器普通流量是否经过代理 |
| WebRTC 公网候选 | 是否出现未预期地址 | 是否仍出现 | 若仍出现,继续检查代理策略或 IPv6 |
| 局域网候选 | 是否出现 | 是否出现 | 结合隐私需求决定是否进一步限制 |
| IPv6 候选 | 是否出现 | 是否出现 | 单独检查 IPv6 是否绕过代理出口 |
| 视频会议或语音功能 | 正常/异常 | 正常/异常 | 异常时恢复设置并重新评估 |
候选地址可能包含有关设备位置、网络拓扑和指纹的信息,但这不等于每一个显示的地址都是你的真实公网出口。MDN:RTCIceCandidate address 属性与隐私说明。
常见失败及对应动作
- 改为 true 后仍看到直连公网地址:先检查普通网页出口。如果普通网页也未经过预期代理,问题在代理接管范围,不是 Firefox WebRTC 设置单独造成的。随后再检查 IPv6 是否使用了独立直连路径。
- about:config 找不到该项:确认使用的是 Firefox 桌面版,并完整复制设置名称;不要把移动版、企业策略或扩展设置混在一起。Mozilla Wiki 将这些项目列为高级配置项,当前版本的可见性和行为仍可能变化。
- 视频会议、语音或文件共享失效:将刚修改的设置恢复原值,完全重启 Firefox 后再测试。WebRTC 本身承担实时音视频和点对点通信功能,限制候选路径可能影响连接建立。
- 检测页显示多个地址:先按公网、局域网、IPv6 和 DNS 分类。地址数量多不能直接证明代理完全失效,也不能仅凭“没有结果”证明所有候选都被隐藏。
- 使用代理客户端但 Firefox 仍直连:检查 Firefox 使用的是系统代理、手动代理还是扩展代理,并确认代理客户端是否只接管部分应用或部分协议。不要在排查过程中同时更换浏览器、扩展和节点,否则无法定位变化来源。
安全提醒与范围限制
不要把订阅链接、访问令牌、私钥、用户名和密码粘贴到在线检测页、公共转换页或聊天群。复测时只保留地址类型和结果变化,必要时遮挡 IP 中间部分。
WebRTC 修复只处理 Firefox 浏览器的实时通信候选路径,不能替代代理客户端的流量接管、DNS 设置、IPv6 路由和终端安全检查。本文没有对任何具体服务的价格、速度、稳定性或泄漏结果作出判断;这些信息未核实。
本文依据截至2026年10月27日可查到的 Mozilla、MDN 资料整理。Firefox 的设置名称、默认值和代理行为可能随当前版本变化;如果当前版本与本文不同,应以当前版本帮助文档和配置页面为准。
常见问题 FAQ
WebRTC 检测到地址就一定是公网 IP 泄漏吗?
不一定。检测页可能同时显示普通网页出口、本地接口、IPv6 或其他 ICE 候选。应先对照复测记录,确认普通网页出口是否经过预期代理,再判断 WebRTC 是否出现未预期的公网候选。
Firefox 设置 media.peerconnection.ice.proxy_only_if_behind_proxy 后还能开视频会议吗?
可能可以,但取决于代理和会议服务是否存在可用的中继路径。若会议无法加入、没有声音或摄像头连接失败,应恢复设置并重启 Firefox,再逐项测试,而不是直接把所有 WebRTC 功能关闭。
为什么不建议直接把 media.peerconnection.enabled 改成 false?
这个设置会关闭 Firefox 创建 RTCPeerConnection 的能力,影响依赖 WebRTC 的视频、语音和点对点功能。它适合作为明确知道业务影响时的强硬排查手段,不适合作为所有用户的默认修复步骤。
普通网页出口正常,但 WebRTC 仍显示额外地址,下一步查什么?
先确认 media.peerconnection.ice.proxy_only_if_behind_proxy 是否为 true,并已完全重启 Firefox;随后单独检查 IPv6 和代理覆盖范围。不要同时更换检测页、浏览器和代理客户端。
常见问题
WebRTC 检测到地址就一定是公网 IP 泄漏吗?
不一定。检测页可能显示本地接口、IPv6 或其他 ICE 候选,应先确认普通网页出口是否经过预期代理,再判断是否出现未预期的公网候选。
Firefox 设置 proxy_only_if_behind_proxy 后还能开视频会议吗?
可能可以,但取决于代理和会议服务是否存在可用中继路径。若会议无法加入,应恢复设置并重启 Firefox。
为什么不建议直接关闭 media.peerconnection.enabled?
该设置会关闭 Firefox 创建 RTCPeerConnection 的能力,可能影响视频、语音和点对点功能,不适合作为所有用户的默认修复步骤。
普通网页出口正常但 WebRTC 仍显示额外地址怎么办?
确认 proxy_only_if_behind_proxy 为 true 并重启 Firefox,再单独检查 IPv6 和代理覆盖范围。
相关阅读
- 先用 BrowserLeaks 区分 IP、DNS、WebRTC 与 IPv6 结果
- 检查网络加速客户端是否真正接管 Firefox 流量
- 如果修复后变慢,再按节点、DNS 与 TUN 分层排查
- 查看连接失败与隐私设置常见问题
