很多人在使用代理、VPN 或机场之后，都会习惯性地打开 IP 查询网站，看一眼自己的公网 IP。
只要发现：
“IP 已经变成节点 IP 了，应该就没问题了。”
很多人就到此为止了。
但实际上，IP 地址变了，并不代表浏览器就完全没有暴露其他网络信息。
很多人只关注“网页显示的公网 IP 有没有变化”，却忽略了浏览器中还有一个容易被忽视的网络通信机制：
WebRTC。
在特定的浏览器、代理方式和网络环境下，WebRTC 可能使用不同于普通网页请求的网络连接路径，从而获取额外的网络信息。
于是就可能出现：
普通 IP 检测
↓
代理节点 IP ✅
WebRTC 检测
↓
出现其他网络信息 ⚠️
这也是为什么有些人明明已经连接了机场，普通 IP 检测看起来完全正常，但 WebRTC 测试却出现了不符合预期的结果。
—
一、WebRTC 到底是什么？
WebRTC（Web Real-Time Communication）是一套浏览器实时通信技术。
它主要用于：
- 网页视频通话
- 浏览器语音聊天
- 在线会议
- P2P 实时通信
- 浏览器实时音视频服务
Chrome、Edge、Firefox 等现代浏览器都支持 WebRTC。
WebRTC 为了寻找合适的通信路径，会检查和使用不同的网络接口。
正常情况下这对视频会议、语音聊天等功能非常有用。
但对于非常重视网络隐私的人来说，就需要注意：
浏览器的 WebRTC 网络行为，不一定和你普通的网页代理请求完全一样。
—
二、WebRTC 泄漏有什么危害？
首先要澄清：
WebRTC 泄漏不代表你的电脑被黑了。
它主要涉及的是网络连接信息暴露问题。
在特定环境下，可能暴露：
- 局域网地址
- 网络接口信息
- 公网 IP
- ISP / ASN 等网络信息
公网 IP 本身不能直接等同于真实住址，但通常可以用于判断大致的国家、地区、运营商等信息。
对于普通用户来说，这可能只是隐私问题。
而对于比较重视隐私的人来说，就值得认真处理。
—
三、为什么“我已经换了 IP”还可能有问题？
这是最容易被忽略的地方。
很多人使用机场之后，会看到：
IP 检测
日本 / 美国 / 香港 / 新加坡节点 ✅
于是认为：
但实际网络可能并没有这么简单。
例如：
普通 HTTPS 请求
↓
代理节点
↓
目标网站
WebRTC
↓
浏览器的另一套连接机制
↓
可能出现额外网络信息
所以：
“IP 变了” ≠ “所有网络信息都按照你的预期经过代理”。
这也是为什么测试代理时，不应该只看一个 IP 查询网站。
—
四、先测试：自己到底有没有 WebRTC 泄漏？
建议先进行一次测试，再决定是否修改浏览器。
WebRTC Leak Test
测试时建议：
第一步
先关闭机场 / VPN。
记录当前公网 IP。
第二步
连接机场节点。
重新检查公网 IP。
第三步
进入 WebRTC Leak Test。
观察 WebRTC 检测结果。
重点不是看到一个局域网地址就马上认为“泄漏”。
真正需要关注的是：
—
五、Firefox：最直接的方法
如果你使用桌面版 Firefox，可以通过高级配置限制 WebRTC。
在地址栏输入：
about:config
确认进入高级配置页面。
然后搜索：
media.peerconnection.enabled
将：
true
改成：
false
这样会直接关闭 Firefox 的 WebRTC PeerConnection 功能。
需要注意：
关闭 WebRTC 可能影响网页视频会议、语音聊天和部分实时通信功能。
如果你经常使用 Google Meet、网页语音/视频聊天等服务，就不建议在不了解影响的情况下长期关闭。Mozilla 支持社区目前仍有关于这一配置项的说明，但 Android Firefox 的 about:config 可用性与桌面版并不完全相同。
—
六、Chrome / Chromium：不要乱改 Flags
Chrome 和其他 Chromium 浏览器的情况不太一样。
目前并没有一个普通用户设置页面，可以直接点击“关闭 WebRTC”。
Chromium 官方提供的是 WebRTC IP 处理策略，例如：
default
default_public_and_private_interfaces
default_public_interface_only
disable_non_proxied_udp
其中：
default_public_interface_only
可以限制 WebRTC 不使用本地私有 IP；
而：
disable_non_proxied_udp
会限制非代理 UDP，并使用 TCP 或代理支持的 UDP。
对于普通用户来说，不建议为了教程方便去修改一堆 chrome://flags。
—
七、Chrome 最简单的处理方式：使用 WebRTC 控制扩展
如果你使用 Chrome、Chromium、Brave、部分其他 Chromium 浏览器，可以使用专门控制 WebRTC 的扩展。
例如：
WebRTC Leak Prevent
Chrome Web Store 目前仍有该扩展，开发者说明它通过 Chrome 官方隐私 API 控制 WebRTC 的相关设置，并默认使用 default_public_interface_only 策略。
安装之后，按照扩展提供的设置进行配置，然后：
开启扩展
↓
限制 WebRTC
↓
重新测试 WebRTC
需要注意：
WebRTC 被限制后，部分网页的视频会议、语音聊天等功能可能受到影响。 该扩展自身也明确提醒了这一点。
所以建议：
日常浏览可以开启，需要使用视频会议时再根据情况调整。
—
八、Edge 怎么处理？
Edge 使用 Chromium 内核，因此原理和 Chrome 基本类似。
对于企业或高级用户，Microsoft Edge 提供官方的 WebRTC 策略：
WebRtcLocalhostIpHandling
其中：
AllowPublicInterfaceOnly
以及：
DisableNonProxiedUdp
都可以减少 WebRTC 暴露本地 IP 的情况。Microsoft 的官方文档也明确说明了这些策略的行为。
较新的 Edge 还提供：
WebRtcIPHandlingUrl
可以针对不同网站指定 WebRTC 的 IP 处理方式。
不过这一部分更适合企业管理员和高级用户，普通用户使用扩展控制会简单很多。
—
九、别忘了 IPv6
很多人检查 WebRTC 的时候只看 IPv4。
实际上，如果你的网络支持 IPv6，也建议同时检查：
IPv4
IPv6
WebRTC
DNS
例如：
IPv4 → 代理节点 ✅
IPv6 → 本地网络 ⚠️
这种情况下，即使你看到 IPv4 已经成功切换，也不能说明所有网络连接都经过代理。
所以排查的时候，最好把 IPv4 和 IPv6 一起检查。
—
十、机场到底能不能解决 WebRTC 泄漏？
这里一定要讲清楚：
机场节点本身不能保证浏览器绝对不会产生 WebRTC 泄漏。
因为 WebRTC 是否出现额外网络连接，与很多因素有关：
- 浏览器实现
- 浏览器设置
- 客户端代理模式
- TUN / VPN 模式
- IPv4 / IPv6
- 网络环境
- WebRTC 本身的配置
所以更合理的思路是：
机场节点
+
代理客户端
+
TUN / 全局接管
+
浏览器 WebRTC 设置
+
IPv4 / IPv6 检查
多个环节一起处理。
—
十一、使用机场时，推荐这样做
如果你平时主要用于网页、YouTube、Telegram、X、Google、GitHub 或其他海外服务，可以考虑：
① 使用支持 TUN 的客户端
相比单纯配置浏览器 HTTP/SOCKS 代理，TUN 可以让更多系统流量进入代理处理链路。
② 根据自己的需求限制 WebRTC
不需要网页视频会议：
经常使用网页视频会议：
更适合使用 WebRTC IP 处理策略，避免直接把整个功能关闭。
③ 检查 IPv4 和 IPv6
不要只测 IPv4。
④ 更换节点后重新测试
尤其是：
- 更换客户端
- 更换浏览器
- 更换节点
- 开启 IPv6
- 修改 TUN 模式
之后，都值得重新检查一次。
—
十二、总结
很多人理解代理的方式是：
实际上，一个完整的网络隐私检查至少应该考虑：
公网 IP
↓
IPv4 / IPv6
↓
DNS
↓
WebRTC
↓
是否存在绕过代理的连接
所以以后连接机场之后，别只打开 IP 查询网站看一眼。
IP 变了，只能说明某一部分流量已经按照预期经过代理。
想进一步减少浏览器暴露网络信息的可能性，还应该检查 WebRTC、IPv6、DNS 以及客户端的流量接管方式。
—
🌍 NBNet｜连接，无界
🚀 50+ 地区节点
💰 ¥2/月起 · 50GB 起
🎁 新用户 24 小时免费试用
🔐 支持现代代理协议与加密传输方案
👉 官网： https://www.nbnet.vip
