WebRTC 泄露检测 - 检测 VPN 背后的真实 IP
doc检测 WebRTC 是否泄露真实 IP，识别本地与公网泄露。
WebRTC 泄露检测
检测 WebRTC 是否泄露真实 IP，识别本地与公网泄露。
WebRTC 泄露检测
打开工具这个检测在看什么
工具会触发浏览器的 ICE 候选收集流程，观察当前会话会暴露哪些地址类型，包括 host（本地地址）、srflx（公网反射地址）和 relay（中继地址）。
核心目标是判断：你以为自己在 VPN 或代理后面时，浏览器是否仍然把真实出口地址暴露给页面脚本。
为什么 WebRTC 泄露很常见
很多 VPN 只覆盖 HTTP/HTTPS 或仅覆盖默认路由，未完全处理 WebRTC 使用的 UDP/STUN 路径，导致浏览器仍可拿到真实公网候选。
在双网卡、多虚拟网卡、远程桌面、容器化浏览器等环境中，候选来源更复杂，泄露概率会显著上升。
结果应该怎么读
如果只看到 relay 候选且不暴露本地/真实公网地址，通常风险较低。
如果出现 ISP 的公网 IP（而不是 VPN 出口 IP），可直接判定存在泄露；如果出现大量 host 候选，则说明本地网络结构被暴露面较大。
高频误区
误区一：IP 查询显示是 VPN 出口，就认为一定安全。实际上 IP 页面与 WebRTC 候选来自不同路径，必须分别验证。
误区二：只测一次就下结论。WebRTC 候选会受网络切换、浏览器更新、扩展策略影响，建议至少连续复测 2~3 次。
快速修复步骤（建议顺序）
先在 VPN 客户端中开启 WebRTC 防护、阻断本地网段泄露或"仅中继"选项；若无该选项，再在浏览器侧限制 WebRTC 地址暴露策略。
随后禁用不必要虚拟网卡（旧 VPN、虚拟机、容器网卡），重启浏览器并复测，确认候选数量与地址类型已收敛。
IPv6 与双栈场景
很多用户只检查 IPv4，但泄露常发生在 IPv6。若浏览器暴露了真实 IPv6，而 VPN 仅隧道 IPv4，仍属于有效泄露。
排障时请同时核对 IPv4/IPv6 候选；无法快速处理时可临时关闭系统 IPv6，后续再做完整双栈方案。
企业与团队运维建议
在企业场景中，WebRTC 泄露不仅影响个人隐私，也可能暴露内网段、网关结构与办公网络拓扑，增加攻击面。
建议通过浏览器策略统一限制候选类型，并把 WebRTC 泄露检测纳入版本升级后的例行验收项。
推荐联动检测
先做 IP 查询 与 DNS 泄露检测，再看 WebRTC 候选；三者结果一致时，网络身份才更可信。
若结果不一致（例如 IP 在美国、DNS 在本地、WebRTC 暴露本机公网），应按"VPN 路径未完全生效"处理，并逐层排查客户端、浏览器与网络策略。