更新于：2026-09

WebRTC 为什么会暴露 IP

WebRTC 是浏览器内置的实时通信技术，用于音视频通话、屏幕共享和点对点数据传输。为了让两台设备建立连接，它需要先知道双方"在哪里"——这个收集地址的过程会向网页暴露你的网络信息，而且与 HTTP 代理无关。理解这一点，是判断"WebRTC 泄漏"的前提。

建立连接前先交换 ICE 候选

WebRTC 建立连接前会通过 ICE（Interactive Connectivity Establishment）机制收集候选地址，并与对端交换。候选地址通常分为三类：

• host candidate：来自本机网卡的地址，包括内网地址（如 192.168.x.x），精确到具体设备；
• server reflexive candidate：通过 STUN 服务器协商得到的公网地址，即 NAT 后的出口 IP；
• relay candidate：通过 TURN 中继服务器转发的地址，通常只在直连失败时使用。

关键点在于：网页脚本在真正建立连接之前就能读到这些候选。因此浏览器里打开一个网页，网站在检测脚本的配合下就可能得知你的内网或公网地址。

浏览器为什么会暴露这些地址

暴露不是 bug，而是机制本身：

• ICE 收集要求枚举本机网卡并联系 STUN 服务器，这是建立连接的必要步骤，浏览器无法替你决定；
• WebRTC 流量不经过 HTTP 代理，代理设置（如 PAC 或系统代理）对它基本无效；
• 即使 VPN 改变了公网出口，本机网卡上的内网地址（以及部分场景下的真实公网地址）仍可能被收集。

模糊显示、降级方案与真实暴露

不同防护手段的效果差别很大：

• mDNS 模糊显示：部分浏览器把 host candidate 显示为随机 .local 名字，隐藏内网地址，但 server reflexive 得到的公网地址仍可能暴露；
• 完全禁用 WebRTC：能阻止候选收集，但会破坏正常的音视频与点对点功能，属于"降级"而非"修复"；
• 扩展与 VPN 客户端：部分扩展只是隐藏界面上的地址，或在候选交换前拦截，效果取决于实现，需要实测验证。

正因为手段多样，LE59 的 WebRTC 泄漏检测工具只做一件事：查看当前浏览器通过 WebRTC 暴露了哪些候选地址。候选仅用于当次检测，不会被长期保存。需要提醒的是，结果中"无候选"或 STUN 协商失败并不等于安全，可能是环境限制或拦截所致，应结合多种方式综合判断。

何时需要检测

• 使用 VPN/代理，且关心真实出口是否暴露；
• 排查"为什么对方能看到我的内网地址"；
• 浏览器更新或安装隐私扩展后，确认防护是否真的生效；
• 对隐私要求较高的场景，了解当前暴露面的情况。

想查看你的浏览器暴露了哪些地址？打开 WebRTC 泄漏检测工具，当次查看、无需登录。