Q：WebRTC 是什么？跟我有什么关系？#
WebRTC 是浏览器内置的实时通信技术，视频通话、语音聊天都靠它。问题在于：为了建立点对点连接，它会绕过代理去探测你的真实 IP——包括内网 IP 和公网真实 IP。也就是说，你开着代理刷网页，自以为隐身了，网站用一段 JS 就能把你的真实 IP 读出来。
Q：怎么知道自己有没有泄露？#
很简单：开着代理，访问任意一个 “WebRTC leak test” 检测网站（搜一下就有好几个），看它显示的 IP 是不是你的真实 IP。如果是，说明正在泄露；如果显示的是代理出口 IP，说明没问题。建议每个常用浏览器都测一遍，因为泄露是按浏览器发生的，不是按系统。
Q：各浏览器怎么关？一张表看全#
| 浏览器 | 关闭/缓解方法 | 备注 |
|---|---|---|
| Chrome / Edge | 没有原生开关，用扩展（如 WebRTC Leak Shield）或 uBlock Origin 的相关选项 | 扩展方案最省事，记得只装可信来源的 |
| Firefox | 地址栏输 about:config，搜 media.peerconnection.enabled，设为 false | 最彻底的原生方案，改完重启生效 |
| Safari | 无直接开关，依赖内容拦截器或系统级代理 | macOS 上开 TUN 模式可大幅缓解 |
| Brave | 设置 → 隐私里有 WebRTC 指纹防护选项 | 对隐私用户最友好 |
Q：关了 WebRTC 会影响正常使用吗？#
对 99% 的人没影响。WebRTC 主要用在浏览器内的音视频通话（比如网页版会议、在线客服视频）。你如果不用网页版开视频会议，关掉它感知为零。需要用的时候再临时打开，用完关掉就行。
手把手：三分钟检测流程#
光讲原理不够，来走一遍实操：
- 开代理，连上你常用的节点：确保是日常使用的状态，别为了检测特意换个"干净"节点，那样测出来没意义。
- 搜一个 “WebRTC leak test” 网站：找排名靠前的两三个，交叉验证，避免单个网站误报。
- 看结果里的 IP 地址：如果显示的是代理出口的 IP——恭喜，没泄露；如果出现了你的真实 IP（可以先在关掉代理时记下自己的真实 IP 做对比）——正在泄露。
- 每个浏览器单独测：Chrome 测完测 Firefox，手机浏览器也别漏。泄露是按浏览器发生的，A 浏览器没事不代表 B 浏览器没事。
- 处理完再测一遍：按上面的表格关掉或装好扩展后，刷新检测页确认结果干净，形成闭环。
建议把这个检测加入"季度安检"：每隔两三个月花三分钟跑一遍。浏览器大版本更新、换了新代理客户端之后，更要重测——这两类变更最容易把之前的防护重置掉，而你往往毫无察觉。花三分钟，买个安心。
Q：除了浏览器，还有别的泄露面吗？#
有，WebRTC 只是最出名的一个。完整的防泄露 checklist 应该包括：
- WebRTC：按上表处理，这是本篇的重点。
- DNS 泄露：DNS 请求没走代理，直接暴露你在查询哪些域名。排查看DNS 泄露修复。
- 代理模式：系统代理只管浏览器流量，其他 App 的流量可能裸奔。TUN 模式和系统代理的区别看TUN 与系统代理对比。
Q：手机端需要处理吗？#
手机浏览器同样有 WebRTC，检测方法一样。但手机端更推荐用客户端的 TUN 模式做系统级接管，一次管住所有 App，比逐个浏览器折腾省事。实测下来，TUN 模式对 WebRTC 泄露的缓解效果很明显，因为流量在系统层面就被接管了，浏览器想绕都绕不过去。
Telegram 这类 App 的代理设置是另一套逻辑，参考Telegram 代理设置。注意：App 内单独设的代理（比如 Telegram 的 MTProto）和系统 TUN 可能叠加，叠加使用时延迟会更高，按需取舍。
Q：检测网站显示的 IP 看不懂，怎么判断？#
记住一条：把检测出的 IP 和"关掉代理时的真实 IP"对比。两者一样等于在泄露；不一样、且和代理节点的出口 IP 一致等于安全。对比之前先记下自己的真实 IP，不然看了也是白看。
一句话总结#
WebRTC 泄露是"开着代理却裸奔"的头号原因，Firefox 改一个配置项、Chrome 装一个扩展，五分钟解决。测一遍、关一遍，然后每隔几个月复查一次——浏览器大版本更新有时会重置这类设置。想了解更底层的协议知识，可以看TUIC 协议详解。