如何检测 WebRTC 泄漏：一套可复现的浏览器测试方法

有用的 WebRTC 泄漏检测会比较同一次浏览器会话中的两个观察值：网页请求被服务器看到的公网地址，以及 WebRTC 收集 ICE 候选时公开的公网地址。地址不同值得继续排查，但检测本身不能确定原因；地址相同也只表示本次测试没有观察到另一个公网地址。

可以先运行实时 WebRTC 泄漏检测，再结合下面的方法理解结果。

2026年8月30日的 BrowserCheck 真实截图；两个地址值在图片保存前已主动遮蔽。

BrowserCheck 实际检测了什么

检测包含三个有明确边界的步骤：

1. 页面请求 BrowserCheck 自己的网络接口，服务器返回与该请求关联的公网地址。
2. 浏览器创建 RTCPeerConnection 数据通道，通过 STUN 收集 ICE 候选；BrowserCheck 最多等待四秒获取服务器反射候选。
3. 当两个公网地址都可用时，BrowserCheck 进行标准化并比较，结果只有相同、不同或未测试，不生成安全评分。

W3C WebRTC 规范说明，ICE 候选收集可能公开额外网络背景，浏览器也可以过滤应用能够获得的地址。MDN 的 ICE 候选类型说明将服务器反射候选描述为通过 STUN 获得的 NAT 映射。

可复现的测试记录

上图采用以下已记录流程：

脱敏后的机器可读记录位于 webrtc-leak-test-record.json，仓库中的 scripts/capture-webrtc-guide.mjs 可以复现截图流程。

这只是一个环境中的一次测试。它能够证明当次检测路径产生了不同地址，不能证明 Chrome、macOS、某个 VPN 或其他产品始终如此。

三种结果分别意味着什么

公网地址相同

本次收集到的服务器反射候选没有显示另一个公网地址。这比“没有泄漏”窄得多：浏览器可能过滤了候选，网络可能只有一条出口，其他不在本检测范围内的泄漏类型也可能存在。

公网地址不同

WebRTC 候选与页面请求使用了不同公网地址。可能原因包括 VPN 或代理路由差异、分流、浏览器策略、扩展或多网络接口。仅靠这次比较无法确定具体原因。

没有可比较的地址

这不是通过，而是比较的一侧不可用。STUN 可能被阻止，浏览器可能隐藏候选，连接可能超时，或站内网络接口没有返回地址。

安全的手动测试流程

1. 记录浏览器系列和主版本，不要公开完整 User Agent。
2. 在普通标签页打开 BrowserCheck 泄漏检测，等待状态停止变化。
3. 只记录相同、不同或不可用，不要把两个公网地址复制到论坛或公开 issue。
4. 如果使用 VPN 且出现不同地址，查看该 VPN 厂商当前的 WebRTC 或分流文档，不要假设一套通用浏览器开关适合所有产品。
5. 每次只改一个条件再复测。一次同时更换 VPN、浏览器配置和扩展，会让结果无法诊断。

出现不同地址后怎么做

• 确认 VPN 或代理是否设计为承载 WebRTC 流量，而不仅是普通 HTTP 流量。
• 按浏览器和扩展的最新官方文档检查设置。全局禁用 WebRTC 可能破坏通话、会议、屏幕共享和点对点应用。
• 使用干净浏览器配置测试扩展是否改变候选处理；不要同时安装多个所谓“防泄漏”扩展。
• 如果威胁模型要求更强的网络匿名与指纹标准化，请阅读 Tor Browser 官方保护说明并保持默认配置。

本指南的边界

BrowserCheck 不检测 DNS 解析器、观察值之外的 IPv6 路由、开放端口、恶意软件、扩展安全、VPN 归属、Tor 使用状态，也无法判断账户是否已经识别了用户。检测还会发起 STUN 请求，因此候选发现过程会有 STUN 服务参与。

W3C 规范说明了真实的隐私与连通性权衡：限制候选可以减少地址暴露，也可能阻止最直接的连接路径。因此检测结果应该被理解为观察值，而不是浏览器总评分。

来源与审核说明

• WebRTC 1.0：公开 IP 地址 — W3C
• RTCIceCandidate 类型 — MDN
• WebRTC IP 地址处理要求 — IETF RFC 8828
• Tor Browser 指纹防护 — Tor Project

审核方法： BrowserCheck 工程审核对照当前实现，运行线上检测，保存脱敏测试记录，并确认截图不包含地址值。最后审核日期为 2026年8月30日。