什么是 WebRTC 泄露？检测候选地址并限制浏览器暴露

WebRTC 泄露是浏览器实时通信功能意外暴露地址，例如本来希望使用 VPN 出口，却让网站看到原始公网 IP。私网地址或 mDNS 名称不是同一种发现：先分类候选，再判断行为是否违反你的策略。

关键要点：

• 公网候选要与原始网络和 VPN 出口分别对照。
• 私网地址、mDNS 名称和中继地址，含义不同。
• 浏览器限制涉及隐私和通话质量取舍，设置不能跨浏览器照搬。
• 修改后测一次真正需要的通话，失败就恢复原值。

WebRTC 泄露会暴露什么？

WebRTC 支持实时音视频和数据交换。ICE 为寻找可用路径收集候选端点，网站得到的地址信息可能超出普通网页请求使用的地址。具体候选受浏览器行为、权限、网络配置及策略影响。［1］

候选是可能路径，不证明通话选用了它。即使媒体经中继传送，诊断也可能列出多个候选。“地址向页面暴露”和“接口传送了通话”是两个问题，都可能有价值，但需要不同证据。

图按候选表达的含义分类，不是截图或某个 VPN 的实测结果。用它先标记观察，再决定是否称为泄露。

候选观察	描述什么	解释
私网本地地址	路由器后方或私网内的本地端点	本地信息，不自动等于原始公网 IP
mDNS 主机名	用名称隐藏本地主机候选	本身不是暴露的数字公网地址
公网地址匹配基线	原始网络上的可能端点	连接 VPN 后出现时，调查意外公网暴露
公网地址匹配 VPN 出口	与观察到的 VPN 出口一致的可能端点	符合该次观察，不证明全设备覆盖
中继地址	作为候选的中继端点	不自动等于接入运营商地址

WebRTC 泄露检测前要记录什么？

在可信网络和有权设置的设备上测试。记录浏览器名称及版本、系统、VPN 配置、代理、活动接口，以及页面是否获得麦克风或摄像头权限。权限可能改变候选暴露；中途改变权限，就不是条件一致的比较。

选报告候选类型、无需无关账户凭据或上传的诊断工具。不能因为网站自称“隐私检测”，就无条件授予摄像头权限。如果工具确实需要权限才能复现日常通话条件，应有意识地选择并记录。

没有候选也可能是页面被阻断、工具故障或受限制，不等于所有应用已保护。整体连接健康可先按VPN 综合测试顺序检查，再用本文解释候选。

怎样检测并分类地址？

1. 记录原始公网出口。 断开 VPN，查看公网 IP，记录可用地址族。在同一浏览器运行 WebRTC 诊断，私下保存候选类型，不公开完整地址或设备标识。
2. 建立连接后参考。 用 AethoVPN 对照时，选择应用当前可用位置，连接并核对网页出口，再收集候选。这样获得两个公网参考，便于区分浏览器结果；不代表产品会过滤 WebRTC。Mac、iPhone、iPad 配置需要 Pro 或 Premium。［6］需要建立此对照时，可开始 3 天 Pro 试用，每人仅一次。［6］
3. 相同条件重做。 保持浏览器、网络、权限和工具一致，把结果标记为本地私网、mDNS、公网或中继。可用时按地址族记录，再与原始出口、VPN 出口比较。
4. 调查相关差异。 连接后出现原始公网地址，值得检查路由与浏览器策略；只有本地私网地址或 mDNS 名称，不能证明同一种暴露。不能分类就记录不确定，查说明，不要一次修改所有隐私设置。
5. 应用受支持的限制。 记原值和范围，每次改一个受支持控制；文档要求时重启浏览器。按下方浏览器差异处理，不能因为另一浏览器教程列了开关就推断本机也有。
6. 重测隐私和通信。 重做候选收集，再用实际需要的服务进行非敏感通话，查音频、视频、建连和稳定性。限制破坏必要通信，就恢复原设置，与管理员讨论受支持中继或网络策略。

浏览器升级或网络变化后，重做相关对照。一个配置档或一张 Wi-Fi 网络的结果，不是整台设备的认证。目标是复现明确的不期望暴露，再验证特定受支持变更对它的影响。

Chrome、Firefox、Edge 与 Safari 有哪些差异？

Chrome 提供策略和扩展接口

Chrome 的隐私 API 说明 webRTCIPHandlingPolicy，包括 disable_non_proxied_udp。这是面向扩展的控制，不保证每个版本设置菜单都有对应复选框。策略或其它扩展可能控制设置，所以请求修改与实际生效值可能不同。［2］

不要只为获得开关就安装陌生“泄露拦截器”。查开发方、权限、维护及当前文档。限制未代理 UDP 可能改变媒体路径，应测实际通话，不能只看绿色检测徽章。

Firefox 有自己的网络隐私 API

Mozilla 为扩展说明 WebRTC 网络属性，包括 IP 处理策略及对等连接控制。它们属于浏览器接口，需对照安装版本的支持行为，不能据此照抄没有来源的 about:config 配方，或把每个首选项当稳定用户设置。［3］

禁用对等连接比隐藏地址范围更广，可能停掉通话或浏览器数据通道所需功能。按需求选择限制，保存原值，再测真实通信服务。

Edge 受管理策略有平台范围

Microsoft 的 WebRtcIPHandlingUrl 让管理员针对匹配 URL 应用 IP 处理策略。官方列出的支持范围是桌面 Edge 135 起，Android 和 iOS 不在支持列表；这不是通用手机操作指南。［4］

企业管理的浏览器应向管理员确认有效策略和 URL 匹配，不绕过管理，也不能推断 Chromium 家族都原样继承 Chrome 每个接口。

Safari 要以安装版本为证据

WebKit 的 2017 年工程说明介绍候选暴露和权限相关差异，只能作历史背景，不能证明所有当前 Safari 默认行为。该来源没有建立当前通用用户开关，本文也不凭空给出一个。［5］

测已安装的 Safari，记录权限状态。发现意外公网地址时，查当前平台或管理员指引；拒绝摄像头权限，不能直接证明所有候选收集被阻断或全设备已被 VPN 覆盖。

何时限制 WebRTC，何时保留通话？

取舍由任务决定。某个浏览器配置档从不用通话或数据通道时，受支持的严格策略可能适合；依赖会议时，全面禁用可能比范围明确的路由或中继策略更具破坏性。

VPN 与浏览器限制作用层次不同。改浏览器策略不证明提供方有 WebRTC 功能，网页 IP 测试成功也不证明浏览器策略生效。解析器异常按DNS 路径检查处理；涉及另一地址族时用IPv6 检测。

保留一份简表：基线公网地址、连接后公网地址、候选分类、版本、权限、原值、新值及通话结果。工具无法给出可用候选时，标为无结论，不当成成功隐藏地址。找不到有授权且受支持的修复，就停止并求助。

把结论记入试用决策表，判断剩余暴露是否符合需求。隧道、浏览器和应用安全的关系，可回到VPN 基础解释。

总结

• 先分类候选，再判断原始公网地址是否暴露。
• 比较时保持浏览器、权限和网络不变。
• 只使用实际浏览器与平台支持的控制。
• 重测候选及真实通话，并记录回退方法。

常见问题

私网地址就是原始公网 IP 泄露吗？

不是，它可能暴露本地网络信息，但这与暴露原始互联网连接的公网地址不同，应分别判断风险。

mDNS 名称会直接泄露原始公网地址吗？

单凭名称不会。它是本地主机候选的另一表达方式，判定原始公网地址暴露前，还应分别比较公网候选。

中继候选意味着 VPN 失败吗？

不是，中继地址表示中继端点。先判类型，再比较相应公网参考，不能把每个陌生地址都当失败。

拒绝摄像头权限能解决所有 WebRTC 泄露吗？

不能，权限可能影响行为，但不证明所有浏览器的候选收集或全部网络路径都被阻断。

应该彻底禁用 WebRTC 吗？

只有受支持控制和功能代价符合需求时才考虑。全面限制可能令会议或数据通道失效，因此必须保留回退。

桌面和手机的隐私设置一样吗？

不一样，API 与管理策略都有平台和版本限制。应按安装浏览器文档操作，不能把桌面方法直接复制到手机。

为什么检查地址后还要测试通话？

隐私限制可能改变媒体路径或阻止建连。诊断结果成功，不能说明必需音视频仍然可以正常使用。

免责声明： 仅测试获准设备和网络。浏览器结果描述所记录版本、权限及配置，不代表设备上每个应用。

来源

1. RFC 8828 — WebRTC IP Address Handling Requirements
2. Chrome — browser.privacy API
3. Mozilla — privacy.network
4. Microsoft Edge — WebRtcIPHandlingUrl policy
5. WebKit — A Closer Look Into WebRTC
6. AethoVPN — Official website

Sources checked 2026 年 10 月 5 日。

延伸阅读

• 记录是否付费的试用决定
• 分清 DNS 路由症状
• 比较两个地址族的路径
• 完成整体连接检查