WebRTC 有没有绕过你的代理？

网页请求走了代理，不代表浏览器的每一种连接都走了代理。页面让浏览器向三个 STUN 服务器问一次“我在外面看起来是哪个 IP”，再和本站看到的 IP 对比：两条线经过同一个出口才算没有泄露。

本地站台检测中

正在收集 WebRTC 候选地址…

浏览器正在联系 STUN 服务器，最多等待 5 秒。

原始 ICE 候选（检测完成后显示）

还没有收集到候选地址。

视频通话、网页会议、在线游戏常用 WebRTC 建立点对点连接。为了让双方找到彼此，浏览器会收集一组“候选地址”，其中一部分要靠 STUN 服务器帮忙：浏览器发一个 UDP 请求过去，服务器把它看到的来源 IP 原样告诉浏览器。网页的脚本可以读到这些候选地址。

网页线网站看到的 IP

你的设备代理出口本站接口

页面请求本站的 /api/trace，这是一次普通的 HTTPS 请求，和你打开任何网页走的是同一条路。它是对比的基准。
WebRTC 线WebRTC 公网 IP

你的设备绕过代理出口 STUN 服务器

STUN 服务器回报的地址，候选类型为 srflx。本页同时询问 Cloudflare、小米和谷歌的 STUN 服务器。它和网站看到的 IP 一致，说明 UDP 也走了同一个出口；不一致，网页就能拿到你没想让它看到的那个 IP。
本地站台本地地址

本机网卡上的地址，候选类型为 host。新版 Chrome、Edge、Firefox 默认用一串随机的 .local 名字代替真实地址（mDNS），Safari 则在没有摄像头、麦克风权限时干脆不提供。如果这里出现 192.168.x.x 这样的原始地址，说明保护被关掉了。

图中画的是泄露时的情形：网页线经过代理出口，WebRTC 线绕了过去。

分流检测一切正常，为什么这里还会显示泄露？

分流检测看的是网页请求，WebRTC 用的是 UDP。客户端只设置了系统代理时，浏览器的 UDP 请求不经过代理，STUN 服务器看到的就是你的宽带 IP。开启客户端的 TUN 模式通常可以解决。

开了 TUN 模式，为什么还是有一个 IP 不一样？

看看那个 IP 是不是来自小米的 STUN 服务器。它是国内域名，在规则模式下会按规则直连，所以回报的是你的宽带 IP。任何网页都可以用国内 STUN 服务器拿到这个 IP，想避免就需要让 STUN 流量也走代理。

WebRTC 公网 IP 一栏是空的，正常吗？

正常，说明 STUN 请求没有拿到回应。常见原因是代理节点不转发 UDP、浏览器扩展限制了 WebRTC，或者所在网络屏蔽了 UDP。这种情况下网页拿不到额外的 IP。

检测结果会上传吗？

不会。候选地址只在你的浏览器里解析和比较，本站接口只返回它看到的 IP，不保存记录。STUN 服务器会看到发起请求的 IP，这是 STUN 的工作方式本身决定的。