思考记录
VPN的WebRTC泄漏检测怎么看？分清公网IP、内网地址与候选类型
WebRTC检测页出现地址，不一定代表VPN泄漏了原公网IP。先分清它是内网地址、VPN出口，还是不希望暴露的原网络公网地址，再与连接设置对照。只看一个红色提示就下结论，容易把门牌号和小区名称混在一起。
WebRTC为什么会显示多个地址？
WebRTC帮助浏览器建立音视频或数据连接。它会收集可用路线的ICE候选，类似打车软件同时找几条路；候选不等于最终选中的连接。RFC 8828说明，这个过程可能获取普通网页请求之外的地址信息。
同一设备上的网页请求与WebRTC连接，也可能受不同路由、分流或代理限制影响。所以网页出口变了，还需要单独检查WebRTC路径。
先把检测结果认清楚
MDN候选类型文档区分了几种来源：
| 显示内容 | 可以说明什么 |
|---|---|
| host候选 | 来自设备的网络接口 |
| srflx候选 | 经服务器发现的映射地址 |
| relay候选 | 中继服务器提供的地址 |
| 没有候选或测试报错 | 可能未完成检测，不能直接判定通过 |
再看地址本身。例如192.168开头、10开头以及172.16至172.31网段属于RFC 1918规定的私有地址。显示它们不能单独证明原公网IP曝光，但暴露本地网络信息仍有隐私意义。
随机字符串加“.local”可能对应mDNS隐藏本地地址的机制。IETF相关历史草案描述了用临时名称替换候选IP的方法；这是机制说明，不能据此保证每款浏览器都采用相同策略，更不能把名称隐藏理解成完全匿名。
按四步做对照，别边测边换五个开关
- **记录环境。**保存浏览器和客户端版本、节点、接管方式、分流设置及测试时间。
- **建立基准。**在自己愿意暴露原出口给检测网站的前提下，记录未连接时的公网地址；避免在需要持续保护的会话中断开VPN。
- **连接后重测。**保持同一网络和浏览器，分别记录网页出口与WebRTC候选地址，查看IPv4、IPv6是否都有结果。
- **定位差异。**若候选反复出现基准中的原公网地址，优先检查相关流量有没有绕过隧道，以及浏览器的IP处理设置。一次只调整一项，再重新测试。
公网地址可能变化，因此旧截图只能作线索。测试为空也可能是脚本、网络或浏览器策略阻止了检测，不能当成“满分证书”。
发现异常，是否必须关闭WebRTC？
先按当前浏览器与客户端的官方说明调整；关闭功能可能影响会议、通话和网页数据连接。RFC 8828也讨论了隐私与连接性能的取舍，没有要求所有人直接禁用。
WebRTC检查不能代替DNS泄漏检查，也不能证明服务无日志。理解身份识别的其他边界，可继续看VPN与无痕模式。
作者：仓老师机场观察
资料来源
资料核对日期：2026年10月10日。依据下列官方文档与一手规范整理，排查步骤为机制分析，不包含本站亲测或测速结果。
- RFC 8828：WebRTC IP Address Handling Requirements：2021年1月；核对2026-10-10。用于额外地址暴露、分流和传统代理风险、功能取舍。
- MDN：RTCIceCandidate.type：页面更新2024-07-25；核对2026-10-10。用于host、srflx、relay候选来源。
- RFC 1918：Address Allocation for Private Internets：1996年2月；核对2026-10-10。用于IPv4私有地址范围。
- IETF：Using Multicast DNS to protect privacy when exposing ICE candidates，03版草案：历史草案发布2021-12-05，到期2022-06-08，非正式RFC；核对2026-10-10。用于临时.local名称替换本地候选IP，不保证所有浏览器实现。
评论