简体中文
English
虎鲸AI浏览器团队很多人配好代理、确认过"我的 IP"显示是代理地址，就觉得身份已经藏好了。但在浏览器里,还有一条很少被注意的通道会把真实地址送出去——WebRTC。
WebRTC 是什么
WebRTC（Web Real-Time Communication）是现代浏览器内置的一套实时通信能力，视频会议、网页语音通话、屏幕共享、点对点传文件大多靠它。它的目标是让两台设备尽量直接建立连接，而不是所有数据都绕服务器中转，这样延迟更低。
问题就出在"直接连接"这个目标上。两台设备各自可能躲在路由器和 NAT 后面，彼此并不知道对方和自己在公网上长什么样。为了凑出一条能通的线路，WebRTC 会先把自己所有可能的地址都收集起来，这个过程叫 ICE（交互式连接建立）。
为什么挂了代理还会漏
收集地址时，浏览器会向一类叫 STUN 的服务器发请求。STUN 的作用很单纯：你问它"我在你眼里是什么地址"，它把看到的公网 IP 和端口回给你。于是浏览器就拿到了几类候选地址：
- 本机地址：局域网内网 IP，例如
192.168.x.x； - 公网映射地址：经过 NAT 后在公网上呈现的真实出口 IP，由 STUN 告诉你。
关键在于，这些候选地址是通过页面里的 JavaScript 就能读到的——网页新建一个连接对象，监听候选事件，地址就一个个冒出来，不需要你授权摄像头或麦克风。
而更要命的是通道本身。很多代理（尤其是 HTTP/HTTPS 代理）只转发浏览器的网页请求，STUN 走的是 UDP，很可能不经过代理、直接从真实网卡发出去。结果就是：页面上的"我的 IP"是代理地址，WebRTC 报出来的却是你真实的公网出口。你以为换了身份，实际露了底。
一句话：代理管的是"网页流量"这条路，WebRTC 的探测可能走了另一条路。
需要说明的是，近几年主流浏览器对内网 IP做了处理，默认会用一串随机的 .local 主机名替代，内网地址的泄漏比过去轻了。但公网真实 IP 通过 STUN 泄漏这条，在代理配置不当时依然存在。
对多账号和隐私意味着什么
对普通用户，泄漏的主要是隐私——真实公网 IP 能大致定位到你的城市和运营商。
对需要多账号隔离、防关联的场景，后果更直接：你给每个账号配了不同代理，想让平台以为这是不同地区的不同人；可一旦 WebRTC 把同一个真实公网 IP 暴露给多个账号所在的页面，平台就拿到了一条把它们串起来的线索。前面在指纹、Cookie、代理上做的隔离，可能被这一项抵消。
怎么自查
思路是：让一个页面主动用 WebRTC 探测，看它报出来的 IP 是不是你的真实地址。
- 先开着代理，访问一个"查我的 IP"的常规页面，记下它显示的地址（应该是代理 IP）；
- 再用一个能做 WebRTC 泄漏检测的页面，看它单独列出的 WebRTC 地址；
- 两者对比：如果 WebRTC 那栏出现了不是代理、看着像你本地宽带出口的公网 IP，就是漏了。内网 IP（
192.168/10.开头）属不属于泄漏，取决于浏览器是否已用.local掩盖，公网地址对上才是真正的问题。
懂一点代码的也可以在浏览器控制台手动建一个 RTCPeerConnection 并打印候选地址，原理相同。
怎么降低风险
核心是别让 WebRTC 绕开你的代理，几种常见做法：
- 彻底禁用 WebRTC：最干净，但视频通话、网页会议会一起用不了；而且"完全没有 WebRTC"本身也可能成为一个显眼的特征。
- 限制 IP 收集策略：现代浏览器支持把 WebRTC 的 IP 暴露范围收紧（例如只允许走默认代理通道、不额外探测），既保留功能又不漏真实出口。具体开关各浏览器位置不同。
- 让 WebRTC 走和代理一致的出口：比起直接关掉，更理想的是让 WebRTC 报告的公网 IP 和你的代理出口一致、自洽，这样既不穿帮也不显得异常。
做多账号隔离的指纹浏览器，一般会把 WebRTC 这一项纳入统一管理，而不是留给用户手动翻设置——要么关闭，要么让它和当前代理对齐。但具体策略和开关各家实现不同，配好之后仍建议按上面的方法亲手自查一遍，确认真实 IP 没有从这条缝里漏出去。
如果你的日常工作就围绕多账号和防关联，WebRTC 是容易被忽略、却足以让整套隔离前功尽弃的一环。虎鲸 AI 浏览器是面向这类场景的一个选择：它支持关闭 WebRTC，或让 WebRTC 报告的 IP 跟随代理出口，从而和环境的其余设定对齐，避免真实 IP 从这条缝漏出去。
