risk/security · 集群 A · 隐私与日志 · 5/6

WebRTC 泄露真实 IP 的原理与浏览器侧防护方法

WebRTC 泄露是怎么发生的

WebRTC 泄露的本质是：浏览器为了实现网页里的实时音视频，会主动收集并向网页提供你的网络地址，而这部分请求可能没有经过代理。

WebRTC 是浏览器内置的实时通信技术，网页视频会议、在线语音和部分点对点传输都依赖它。为了让两台设备直接连上，浏览器需要先知道「我在网络上的位置」，于是会做两件事：读取本机网卡的地址（局域网地址），以及向 STUN 服务器询问「你看到的我是什么地址」（公网地址）。这些地址被称为 ICE 候选，网页脚本可以读取它们。

为什么代理没能挡住

直接回答：系统代理通常只覆盖遵循代理设置的 TCP 请求，而 WebRTC 的 STUN 请求多走 UDP，可能直接从本机网卡发出，于是 STUN 服务器看到的就是你的真实公网 IP。

系统代理模式下：
  网页 HTTP/HTTPS 请求 ──(遵循代理设置)──> 机场节点 ──> 目标网站      [出口 IP]
  WebRTC STUN 请求(UDP) ──(未经过代理)───> STUN 服务器               [真实公网 IP]
                                               │
                                               v
                                  网页脚本读取 ICE 候选，得到真实 IP

TUN 模式且 UDP 被接管时：
  所有 TCP/UDP ──(虚拟网卡)──> 客户端 ──> 机场节点 ──> 目标       [出口 IP]

所以同一个网页可能同时看到两个地址：一个是代理出口 IP，一个是你的真实 IP。对于想把真实 IP 与浏览行为分开的用户来说，这是一个明显的漏洞。

泄露会带来什么影响

结论：WebRTC 泄露的接收方是你访问的网页及其使用的第三方脚本，影响主要是「真实 IP 被网站获知」。

最后一行值得注意：部分平台会把「检测到代理」作为风控信号之一。使用代理服务访问 AI 或流媒体平台时，请遵守平台服务条款与支持地区规定，本站不提供规避平台风控的操作，相关一般性说明见 AI 工具访问专题 与 合规与法律专题。

自查方法

直接回答：打开一个 WebRTC 检测页，对比它显示的 IP 与代理出口 IP，如果出现了你的真实公网 IP，就说明存在泄露。

1. 关闭代理，访问任一 IP 查询页，记下你的真实公网 IP；
2. 开启代理，再访问 IP 查询页，确认显示的是出口 IP；
3. 打开 WebRTC 检测页，查看列出的候选地址；
4. 如果候选中出现了第 1 步记录的真实 IP，即存在 WebRTC 泄露；
5. 修改设置后重复第 3 步确认。

检测页是第三方网站，不要在上面登录或输入任何个人信息。

三类防护思路及取舍

结论：防护可以从浏览器、扩展和系统三个层面入手，层面越低覆盖越全，但对其他功能的影响也越大。

几点补充：

• 扩展的风险不可忽视：浏览器扩展可以读取你访问的所有页面，选择扩展本身就是一次信任决策，恶意扩展的危害与恶意客户端类似，见 恶意客户端的常见行为与识别方法。
• TUN 模式要确认 UDP：部分配置中 TUN 只处理 TCP，或节点协议对 UDP 支持有限，开启后仍需重新自查。TUN 的配置见 桌面客户端专题，协议对 UDP 的支持差异见 代理协议专题。
• 按需分配浏览器：如果你经常需要网页视频会议，可以用一个浏览器专门开会、另一个浏览器用于日常浏览，分别设置。

几个常见误解

直接回答：关于 WebRTC 泄露，最常见的误解是把它当作服务商的问题，或者认为换个节点就能解决。

理解这些之后就会发现，WebRTC 防护主要是你自己的设置问题，选择哪家服务商并不能替你解决。

防护之后仍然存在的暴露

直接回答：修复 WebRTC 泄露只解决了「网页拿到真实 IP」这一项，账号、Cookie、浏览器指纹依然能识别你，服务商也依然能看到连接元数据。

换句话说，WebRTC 防护是隐私拼图中的一块，而不是全部。DNS 泄露需要单独检查，见 DNS 泄露自查与修复；服务商侧的可见范围见 机场服务商能看到你的哪些数据。

做完这些检查后，如果你想进一步整理整体的数据暴露面，可以对照 使用代理服务的隐私最小化清单。在挑选品牌时，也可以到 机场品牌库 查看资料中的协议与客户端类型，作为了解技术形态的参考。