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 流量到底走了哪里。

STUN 和 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。

如果两者一致（或者 WebRTC 被禁用没返回 IP） → 安全，没有泄露
如果 WebRTC 返回了一个不同的 IP，而且这个 IP 是你真实的运营商 IP → 泄露了

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

发现泄露了，怎么修？

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 泄露

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

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

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

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

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

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

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

除了 WebRTC，DNS 泄露同样危险

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

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

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

两种泄露的区别：

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

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

为什么代理模式和 TUN 模式检测结果不同

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

代理模式（HTTP/SOCKS5）：浏览器通过系统代理发送请求，但代理协议只能转发 TCP 流量。WebRTC 的 STUN 协议使用的是 UDP，根本走不了 HTTP/SOCKS 代理。结果就是 STUN 请求直接发不出去，页面自然显示"无泄露"。

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

模式	STUN UDP	检测结果
代理模式	发不出去	"无泄露"（可能是假象）
TUN 模式	能发出去	真实反映 UDP 出口情况

结论：代理模式下的"无泄露"不代表真的安全，只是 UDP 被挡住了而已。想要准确检测 WebRTC 泄露情况，应该在 TUN 模式下进行测试。如果 TUN 模式下显示泄露，说明你的 UDP 出口确实和 TCP 不一致，需要排查代理节点的 UDP 转发配置或分流规则。

WebRTC 泄露检测

📖 拓展阅读