WebRTC 泄漏指的是：网页流量已经走 VPN 或代理，但浏览器为实时音视频收集 ICE 候选地址时，仍把本机公网 IP 或局域网地址交给网页。2026 年这在桌面 Chrome 与 Firefox 上仍然常见。检测的核心是对照候选地址是不是你期望的隧道出口。
WebRTC 泄漏到底泄漏了什么
WebRTC（Web Real-Time Communication）是浏览器内置的实时通信接口，用来做视频通话、屏幕共享和一部分「测速 / 打洞」网页。为了尽快找到一条能通的路径，浏览器会收集一组 ICE 候选地址（Interactive Connectivity Establishment candidates），再交给网页脚本。
候选地址通常分三类：
- host：本机网卡上的地址，常见是局域网
192.168.x.x、10.x.x.x，有时也包括虚拟网卡地址； - srflx（server reflexive）：通过 STUN 服务器看到的「公网侧」地址，往往就是家庭宽带或蜂窝网的真实出口；
- relay：经 TURN 中继的地址，一般不是本机真实 IP。
页面流量可以走 HTTPS 隧道，候选地址却仍是本机真实出口。一个可独立引用的定义句：WebRTC 泄漏是浏览器把本机地址当成实时连接候选交给网页，不是「VPN 没开」。
它和 DNS 泄漏检查 泄漏的不是同一种信息：DNS 泄漏让人看到你查了哪些域名；WebRTC 泄漏让网页直接读到你的 IP 或局域网拓扑。
它为什么经常和 VPN 一起出现
VPN 是什么 强调过：加密传输不等于匿名。WebRTC 是浏览器自己的网络栈，不一定读取系统代理，也不一定完全服从 TUN 全局代理 的默认路由。
常见成因：
| 成因 | 实际效果 |
|---|---|
| 浏览器为 ICE 收集 host / srflx 候选 | 网页拿到局域网或真实公网 IP |
| 只设置了 HTTP/SOCKS 系统代理 | WebRTC 不走代理设置，UDP 直连 STUN |
| TUN 已开，但未拦截 STUN/UDP | 音视频候选仍从物理网卡打洞 |
| 权限不足的半启用 VPN | 接口在，浏览器仍看到物理网卡地址 |
| 未启用 mDNS 主机候选模糊 | host 候选以明文 IP 而不是 .local 名字出现 |
现代 VPN 技术架构 把这类问题标在应用层：路由和 DNS 都正确之后，浏览器仍可能用独立通道做 NAT 打洞。
检查前先记下对照基准
检测页只能列出「这次 ICE 收集到了哪些地址」。要判断是否泄漏，需要事先知道期望值：
- 隧道出口 IP（开着 VPN 时，普通 HTTPS 检测页应显示的地址）；
- 未开隧道时的家庭宽带 / 蜂窝真实 IP（泄漏基线）；
- 本机局域网网段（用来识别 host 候选，而不是把
192.168.1.2误当成公网泄漏）。
没有基准，检测页上的一串 IPv4/IPv6 没有意义。
测试环境写法示例：2026 年 9 月，家庭宽带，Windows 11 + Chrome。记下日期、浏览器和是否开启 TUN / 系统代理。
怎么检查（读候选地址，而不是看有没有摄像头）
公开的 WebRTC leak 页面会请求摄像头/麦克风权限，或仅用 STUN 收集候选，不必真的开始通话。使用步骤保持简单：
- 先断开隧道，打开检测页，记下真实公网 IP 和局域网 host 候选（这是「泄漏基线」）；
- 再开启 VPN/TUN，用同一个浏览器强制刷新（避免缓存的旧候选）；
- 对照：srflx / 公网候选是否从真实 IP 变成了隧道出口；host 候选是否只剩虚拟网卡或已被 mDNS 模糊；
- 若浏览器开了「用代理时禁用非代理 UDP」一类开关，开关前后各测一次，避免把浏览器策略误判成客户端能力。
读结果时只回答三个问题：
- 公网候选是谁：是否仍是第一步记下的家庭宽带 / 蜂窝 IP；
- IPv4 和 IPv6 是否都变了：只变一边，另一边仍可能把真实地址交给网页；
- host 候选暴露了什么：局域网地址一般不直接等于公网泄漏，但会暴露内网拓扑，公共 Wi-Fi 下更敏感。
不要把「列出了多个候选」直接等同于失败。ICE 本来就会列出 host、srflx、relay 多项。失败条件是：出现了你明确不想暴露的真实公网 IP。
结果对照表
| 现象 | 更可能的含义 | 下一步 |
|---|---|---|
| 公网候选变成隧道出口 IP | WebRTC 路径已随隧道 | 再确认 IPv6 与 host 候选 |
| 仍显示家庭宽带真实 IP | STUN 打洞走了物理网卡 | 查浏览器 WebRTC 策略、TUN/UDP 拦截 |
| HTTPS 出口已变、WebRTC 未变 | 浏览器独立网络栈 | 换用系统 VPN API 或关闭非代理 UDP |
| 只有 IPv6 仍是真实地址 | v6 未进隧道或未拦 STUN | 检查 ::/0 与 v6 候选 |
仅出现 .local mDNS 主机名 | host 候选已被模糊 | 公网侧仍要对照 srflx |
| 检测页要摄像头权限后才出结果 | 正常，权限用于采集候选 | 可拒绝摄像头、仅看 STUN 项 |
无法核对地址归属时，标注「据检测页显示」，不要写成确定的运营商名称。
查完之后改什么
按层处理，比反复开关摄像头权限更有效：
- 浏览器策略：是否限制 WebRTC 仅使用默认路由 / 代理接口，或禁用非代理 UDP；
- 接管范围：系统代理管不到 WebRTC；更接近预期的是 TUN 或系统 VPN API；
- 双栈：IPv6 候选是否同样进入隧道；
- mDNS：host 候选是否以 IP 明文出现；这改变的是局域网暴露，不是公网出口；
- 客户端拦截：部分客户端会拦截 STUN。拦截成功表现为检测失败或只剩 relay，而不是继续显示真实 IP。
这些改动改变的是浏览器收集候选的路径，不是某个网站的封锁策略。目标是让「页面 HTTPS」和「ICE 公网候选」指向同一条你已经选择的出口。
各浏览器的具体开关名称和默认值会随版本变化。2026 年仍应以检测结果为准，不要把某次设置页截图当成长期保证。据各浏览器公开说明，策略项属于隐私/网络设置，而不是「让网站一定连得上」的加速选项。
常见误解
误解 1：关掉摄像头就不会泄漏。
候选地址来自 ICE/STUN，不是来自摄像头画面。拒绝摄像头只能少一次媒体采集，STUN 仍可能打出 srflx 地址。
误解 2：WebRTC 泄漏等于 DNS 泄漏。
解析路径和实时连接候选是两条控制面。修了 DNS 不等于修了 WebRTC，需要分开测。
误解 3：TUN 全局就一定没有 WebRTC 泄漏。
TUN 扩大的是 IP 接管范围。浏览器若用独立 UDP 打洞、或虚拟网卡尚未成为默认路由，候选仍可能从物理网卡出去。以检测页为准。
误解 4：看到 192.168. 就是严重公网泄漏。
host 候选暴露的是局域网地址。它值得在公共 Wi-Fi 下重视，但和「网页拿到家庭宽带公网 IP」不是同一件事。先对照 srflx。
建议怎么用这条检查
把 WebRTC 检查和 DNS 泄漏检查放在同一清单里：换浏览器、换客户端、改 TUN 或系统代理之后各测一次。先确认 ICE 公网候选与 HTTPS 出口一致，再比较节点快慢；否则你优化的是页面流量，浏览器仍可能把真实地址交给任意调用了 WebRTC 的网页。