WebRTC 泄露检测

WebRTC（Web Real-Time Communication）是浏览器自带的一项技术，让你不装任何插件就能进行视频通话、语音聊天和文件传输。听起来挺好的对吧？

但问题是：WebRTC 在建立连接时，会通过 STUN 服务器主动获取你的真实外网 IP。这个过程走的是 UDP 协议，而很多代理只处理 TCP 流量。结果就是——你以为自己在代理保护下，WebRTC 却在背后偷偷把你的真实 IP 发出去了。

更关键的是，网页上的 JavaScript 可以在你毫不知情的情况下调用 WebRTC，无需弹出任何权限确认框。

本工具同时向多个不同的 STUN 服务器（Google、Cloudflare 等）发送 UDP 请求，收集所有返回的 IP 地址，帮你看清楚：

• 你的代理是否接管了 UDP 流量 — 如果 STUN 返回的是代理出口 IP，说明 UDP 被正确代理了
• 是否存在 IP 泄露 — 如果 STUN 返回了你的真实运营商 IP，说明 UDP 绕过了代理
• 分流规则是否生效 — 不同 STUN 服务器可能走了不同的出口，可以验证你的分流策略是否符合预期
• IPv6 是否泄露 — 有些代理只处理 IPv4，IPv6 流量可能直接暴露。检测结果会显示所有发现的 IPv6 地址

简单来说：一键按下去，你就知道你的 UDP 流量到底走了哪里。

UDP（User Datagram Protocol）是互联网上最基础的传输协议之一。和 TCP 不同，UDP 不需要建立连接就能直接发送数据包，速度快但不保证送达。视频通话、在线游戏、语音聊天这些对实时性要求高的场景，基本都用 UDP。

STUN（Session Traversal Utilities for NAT）是一个帮你"发现自己外网 IP"的协议。你的设备通常在路由器后面（NAT），不知道自己的真实公网 IP 是多少。STUN 服务器的作用就是：你发一个 UDP 包过去，它告诉你"我看到你的 IP 是 X.X.X.X"。

WebRTC 依赖 STUN 来建立点对点连接。问题在于：这个 UDP 包不一定走你的代理通道。很多代理工具只处理 TCP 流量，UDP 直接走了本地网络，于是你的真实 IP 就被 STUN 服务器看到了。

很简单：对比你的代理出口 IP 和 WebRTC 检测到的 IP。

• 如果同一地址族的 HTTPS 出口与 WebRTC 公网地址一致 → 未发现泄露
• 如果 WebRTC 返回了一个不同的 IP，而且这个 IP 是你真实的运营商 IP → 泄露了
• 如果 WebRTC 没有返回公网候选，但 API 仍可用 → 无法判断，可能是 UDP/STUN 被拦截
• 如果 WebRTC API 被浏览器禁用或隐私策略拦截 → WebRTC 不可用，不等同于测试成功

本页面会自动帮你做这个对比，不需要手动操作。

Firefox：地址栏输入 about:config，搜索 media.peerconnection.enabled，双击设为 false。这会完全禁用 WebRTC。

Chrome / Edge：浏览器本身不提供关闭 WebRTC 的选项。建议安装 uBlock Origin 扩展，在"设置 → 隐私"里勾选"阻止 WebRTC 泄露本地 IP 地址"。

Brave：进入设置 → 隐私和安全 → WebRTC IP 处理策略，选择"禁用非代理 UDP"。

Safari：默认对 WebRTC 有一定限制，泄露风险较低。但可以在"开发"菜单中进一步限制 WebRTC 功能。

进阶方案：UDP 分流

上面的方法本质上都是"一刀切"——要么禁用 WebRTC，要么限制它。但如果你日常需要用到 WebRTC（比如 Google Meet、Discord 语音），完全禁用会影响使用体验。

更优雅的做法是：在代理客户端里对 UDP 流量做单独分流。大多数代理工具都支持针对 UDP 协议设置独立的路由规则，你可以把 STUN 服务器的流量（比如 Google 和 Cloudflare 的 STUN 地址）指定走代理出口，而不影响其他 UDP 流量（比如游戏、本地局域网）。这样既保证了 WebRTC 不泄露真实 IP，又不会因为全局禁用而影响正常功能。

改完之后，回到本页重新测一次，确认泄露已修复。

先别慌。如果你的检测结果显示了多个不同的公网 IP，这不一定是 WebRTC 泄露。

很多用户使用了代理分流规则（比如国内直连、国际走代理），不同的 STUN 服务器可能分别命中了不同的分流策略。举个例子：

• Google 的 STUN 服务器 → 走代理 → 显示代理出口 IP（比如日本）
• Cloudflare 的 STUN 服务器 → 走另一条代理线路 → 显示另一个出口 IP（比如香港）

这种情况下出现多个不同 IP 是正常的，因为你的分流规则本来就把它们路由到了不同的出口。你需要做的是：对照你自己的代理规则，看看这些 IP 对应的地区是否符合预期。

但有一种情况需要特别警惕：

如果你明明开了代理，但 WebRTC 检测到的公网 IP 全部是你本地运营商的 IP（比如你在中国大陆境内，检测到的全是中国电信的 IP），那就说明 WebRTC 完全绕过了你的代理，直接走了本地网络。这才是真正的泄露。

简单判断方法：看检测结果里的归属地。如果归属地和你的物理位置一致，而且你认为这些流量应该走代理，那就要处理了——参考上面"发现泄露了，怎么修？"的方法。

很多人只关注 WebRTC 泄露，却忽略了另一个同样严重的隐私威胁：DNS 泄露。

你每次访问一个网站，浏览器都要先查 DNS 把域名翻译成 IP 地址。如果这个 DNS 查询没有走代理，而是直接发给了你本地运营商的 DNS 服务器，那运营商就能清楚地看到你访问了哪些网站。

更隐蔽的是：DNS 泄露不像 WebRTC 那样可以在浏览器里直接检测到。你需要专门的工具来验证 DNS 查询到底走了哪条路。

两种泄露的区别：

• WebRTC 泄露 → 暴露你的真实 IP 地址（对方知道你是谁）
• DNS 泄露 → 暴露你的访问记录（运营商知道你去了哪）

建议两个都测一下。WebRTC 你已经在这里测过了，DNS 泄露可以去本站的 DNS 泄露检测 页面，5 秒出结果，看看你的 DNS 有没有在背后出卖你。

很多用户发现一个奇怪的现象：用代理模式检测显示"无泄露"，切换到 TUN 模式反而显示泄露了。这不是检测出错，而是两种模式的工作原理完全不同。

代理模式（HTTP/SOCKS5）：浏览器通常通过系统代理发送网页请求，但 WebRTC 的 STUN UDP 不一定被同一代理接管。若 STUN 请求无法发出，页面会显示“无法判断”，而不是把连接失败当作“无泄露”。

TUN 模式（全局/虚拟网卡）：TUN 会创建一个虚拟网卡劫持所有网络流量，包括 TCP 和 UDP。这意味着 STUN 的 UDP 请求能够成功发出。如果你的代理节点不支持 UDP 转发、或者 UDP 走了不同的出口线路、或者分流规则没覆盖 STUN 服务器地址，就会导致 UDP 出口 IP 和 TCP 出口 IP 不一致，从而被判定为泄露。

模式	STUN UDP	检测结果
代理模式	可能发不出去	无法判断，需要检查 UDP
TUN 模式	能发出去	真实反映 UDP 出口情况

结论：代理模式下 STUN 无结果不代表安全，可能只是 UDP 被挡住。想准确检查 WebRTC 出口，可在符合自身网络方案的 TUN/全局模式下复测；如果同地址族的 WebRTC 出口与 HTTPS 基准不同，再排查 UDP 转发或分流规则。