使用代理仍暴露IP？WebRTC泄露原理、检测与防护指南
浏览器已经显示代理出口，普通IP检测页也只看到代理地址，但WebRTC检测页却列出了另一个公网IP，甚至出现本地网段或一串.local名称。这是否意味着代理失效？
答案取决于第二个地址是什么、它属于哪种ICE候选，以及WebRTC流量是否真的绕过了预期网络路径。把检测页中出现的每一个地址都叫作“真实IP泄露”会造成误判；反过来，只检查普通HTTP出口，也可能漏掉浏览器通过UDP建立的实时通信路径。
本文依据W3C WebRTC规范和WebRTC官方资料，建立一套可以复现的判断方法，并结合紫纹浏览器当前实现的五种WebRTC模式说明如何选择。本文讨论的是隐私保护、授权测试和正常业务环境管理，不用于绕过平台规则或隐藏违法活动。
本文于2026年7月复核。浏览器内核、网络策略和代理能力会持续变化，任何配置修改后都应使用当前实际环境重新测试。
1. 代理修改了哪一条网络路径？
HTTP代理通常处理浏览器发出的HTTP和HTTPS请求。访问普通网站时，请求先到代理服务器，再由代理访问目标站点，站点看到的来源地址通常是代理出口。
WebRTC用于浏览器中的音视频、屏幕共享和点对点数据通信。为了在不同NAT、防火墙和网络条件下找到可用连接，它会运行ICE（Interactive Connectivity Establishment）流程，收集若干可能的连接地址，再选择能够连通、优先级合适的候选对。
ICE发现路径时可以使用：
- 本机网络接口；
- STUN服务器，用于了解NAT映射后的公网地址；
- TURN服务器，在无法或不适合直连时中继媒体和数据；
- UDP或TCP等不同传输方式。
如果代理只接管浏览器的HTTP/HTTPS请求，而没有接管WebRTC使用的UDP、IPv6或其他套接字，ICE可能从代理之外的接口得到候选地址。这才是“普通网页走代理、WebRTC走另一条路”的技术基础，而不是WebRTC故意绕过安全措施。
2. 看懂四种ICE候选地址
检测WebRTC时，候选类型比地址本身更重要。
| 类型 | 含义 | 检测时如何理解 |
|---|---|---|
host | 来自本机网络接口的候选 | 可能是内网地址、IPv6或经mDNS隐藏的主机名；单独出现不等于公网IP泄露 |
srflx | 服务器反射候选，通常由STUN发现NAT映射 | 如果这里出现不应暴露的运营商公网IP，才是典型泄露信号 |
prflx | 建连检查过程中发现的对等反射候选 | 常在实际连通过程出现，普通静态测试不一定能完整展示 |
relay | 由TURN服务器分配的中继候选 | 显示的是TURN中继地址，不是终端本身的公网IP |
W3C规范指出，ICE候选可能暴露位置、连接方式和本地网络拓扑，也会增加浏览器指纹面；应用可以通过只使用中继候选降低向通信对端暴露地址的范围。参见W3C WebRTC规范的IP地址隐私说明。
.local主机名不等于泄露
现代浏览器可能用mDNS主机名替代部分本地接口地址。因此检测页显示类似随机字符串加.local时，通常表示本地地址已被混淆，而不是网站拿到了一个新的公网IP。是否安全仍需结合srflx、relay和最终选中的候选对判断。
3. 使用代理后仍可能泄露的五种原因
3.1 浏览器代理只覆盖HTTP和HTTPS
浏览器扩展或手动代理设置往往只影响Web请求。WebRTC的UDP套接字可能直接使用系统默认路由，因此STUN看到的是原始网络的NAT出口。
3.2 代理不支持UDP
即使代理协议本身可以处理TCP，服务端、客户端或当前套餐也不一定转发UDP。此时浏览器可能直连、退回TCP、使用TURN，或者连接失败。不能仅凭“代理支持某协议”的宣传判断实际路径。
3.3 IPv4进入代理，IPv6仍直连
常见配置只代理IPv4，而系统仍拥有可直连的IPv6地址。检测页可能因此同时显示代理IPv4和原始IPv6。DNS、WebRTC和普通网页也可能分别选择不同的IP协议族。
3.4 分流、绕过规则或本地网络策略
VPN的split tunneling、代理PAC规则、安全软件、防火墙和企业策略都可能让部分进程、域名或协议不进入隧道。浏览器内核更新后，旧扩展也可能不再覆盖相同的网络行为。
3.5 测试结果被错误解读
内网地址、mDNS名称、代理出口和TURN地址都可能出现在检测结果中。若没有记录候选类型，仅因为它与HTTP出口不同就判定泄露，结论并不可靠。
4. 一套可复现的WebRTC泄露检测方法
第一步：记录基线
关闭代理时，记录当前运营商IPv4和IPv6，仅用于本次对照。不要在公开工单或聊天中发送完整地址，可以保留脱敏后的前缀和时间戳。
第二步：确认代理的网页出口
启用代理后重启目标浏览器环境，访问可信IP检测服务，分别记录IPv4、IPv6和DNS出口。网页出口仍是原始地址时，应先修复代理，不必继续讨论WebRTC。
第三步：收集并分类ICE候选
打开能够显示ICE候选类型的WebRTC测试页，等待收集完成，记录：
type：host、srflx、prflx或relay；protocol：UDP或TCP；- 地址属于内网、mDNS、代理出口、TURN服务器还是原运营商；
- 是否存在IPv6候选；
- 测试页是否真正建立连接，还是只收集候选。
MDN的RTCIceCandidate类型说明对四种候选的含义有清晰定义。
第四步：按证据判断
| 结果 | 结论 |
|---|---|
srflx显示原运营商公网IP | 存在明显的WebRTC公网地址泄露风险 |
仅出现代理出口的srflx | 当前测试中STUN看到代理路径 |
仅出现relay地址 | 连接通过TURN中继，不能把中继地址当作真实IP |
出现RFC1918内网地址或.local | 说明存在主机候选或mDNS映射，本身不足以证明公网泄露 |
| 原始IPv6出现，而网页只走代理IPv4 | IPv6路径没有被一致处理 |
| 没有任何候选 | 可能是WebRTC被禁用、策略阻止、脚本失败或网络不可达，需要结合功能测试 |
第五步：重启并复测
清理测试页状态，完整关闭浏览器环境后重新启动。分别测试有无麦克风权限、IPv4/IPv6和实际音视频页面。候选收集不一定需要媒体权限，因此“未允许麦克风”不能作为没有泄露的证明。
5. 如何降低WebRTC地址暴露风险
使用覆盖实际传输的网络方案
需要所有应用流量都进入同一出口时，优先考虑能够明确处理系统流量、UDP和IPv6的可信VPN或隧道，并核对分流规则。若使用HTTP或SOCKS代理，应确认具体客户端和代理服务如何处理UDP，而不是默认其一定支持。
限制非代理UDP
浏览器或受管环境可设置WebRTC IP处理策略，禁止不经过代理的UDP路径。代价可能是点对点连接变慢、转向TURN，或部分音视频功能不可用。修改后必须通过候选收集和实际通话双重验证。
仅在不需要时禁用WebRTC
完全禁用能阻止页面使用WebRTC API，但也会影响视频会议、语音、屏幕共享、远程支持和依赖数据通道的应用。它是功能取舍，不是适用于所有人的默认答案。
网站开发者可强制中继
WebRTC应用开发者可以将RTCIceTransportPolicy设为relay并部署TURN，从而只向通信对端提供中继候选。这样会增加带宽成本、延迟和TURN容量要求，而且这是网站应用的配置，普通访问者不能替远端网站决定。WebRTC官方的Peer connection入门说明了STUN、TURN和ICE候选的关系。
分别检查DNS与IPv6
WebRTC、DNS和网页出口是不同问题。修复WebRTC不代表DNS一定进入隧道；禁用IPv6也不应成为未经评估的万能做法。应分别记录并验证每条路径。
6. 紫纹浏览器的五种WebRTC模式
紫纹浏览器当前提供五种模式。选择前应明确业务是否需要音视频、代理是否支持UDP，以及隐私目标是什么。
| 模式 | 当前行为 | 适合的验证场景 |
|---|---|---|
转发（forward） | 通过指定STUN转发配置处理候选 | 需要保留WebRTC能力时，必须结合实际代理和候选结果复测 |
替换（replace） | 使用与当前代理出口匹配的WebRTC IPv4信息 | 希望页面读取值与代理出口一致的环境 |
真实（real） | 保留本机真实WebRTC网络信息 | 本地网络调试、隐私不要求隐藏真实地址的场景 |
禁用（disable） | 阻止网站读取WebRTC参数 | 完全不依赖WebRTC功能的隐私优先场景 |
代理UDP（proxy_udp） | 禁止非代理UDP；支持时由代理处理UDP | 代理与内核支持UDP转发的环境；需要Patch 2.8.2.0及以上 |
配置建议：
- 在环境编辑器中先完成代理连接测试，确认出口IP。
- 根据业务功能选择WebRTC模式，不盲目照抄其他账号配置。
- 保存并完全重启环境。
- 检查HTTP出口、IPv6、DNS和ICE候选。
- 在业务需要时测试真实音视频或数据通道。
- 把测试日期、客户端版本、代理类型和结果写入运维记录。
“替换”或“代理UDP”都不是对所有网络的结果保证。代理能力、系统路由、内核版本和网站实现仍会影响实际表现。
7. 多账号团队的正确目标是隔离与可审计
对于获得授权的品牌、地区、测试或客户账号，独立环境能减少Cookie串用、代理错配和人员误登录。团队应为每个账号记录业务所有者、允许地区、代理负责人、WebRTC模式、最近检测时间和恢复责任人。
不要把WebRTC防护理解为规避平台封禁的工具。一次地址一致并不能证明账号合规，更不能掩盖垃圾信息、虚假互动或绕过处罚等行为。紫纹浏览器负责环境隔离和配置执行，账号内容、授权和平台政策仍由使用者负责。
8. 排错检查表
- 普通网页出口是否已经是预期代理？
- IPv4和IPv6是否都按预期路由？
- ICE候选分别属于哪一种类型？
srflx是否出现原运营商公网地址？- 检测到的是内网、mDNS、TURN还是公网地址？
- 代理是否明确支持UDP，客户端是否启用？
- 是否存在分流、PAC、扩展或防火墙规则？
- 修改后是否完整重启环境并复测？
- 真实音视频功能是否仍可用？
- 是否将结果和配置版本写入记录？
9. 常见问题
看到192.168.x.x就是WebRTC泄露吗？
它是私有网段地址，说明页面获得了某种主机候选，但不等同于运营商公网IP暴露。仍需检查srflx和最终候选对，并根据隐私目标决定是否限制本地地址。
出现.local地址安全吗？
它通常是浏览器用mDNS混淆本地接口地址的结果。它降低了直接暴露本地IP的程度，但不能代表所有公网、IPv6和中继路径都正确。
用了系统VPN还会泄露吗？
配置正确且覆盖UDP与IPv6的系统级隧道通常比只代理HTTP的扩展覆盖更广，但分流、IPv6、故障回退和应用排除仍可能造成不同路径。必须实测。
禁用WebRTC能一劳永逸吗？
它能阻止WebRTC功能，但会破坏依赖该API的页面，也不能修复DNS、扩展、恶意软件或其他网络泄露。
检测页面全绿，账号就一定安全吗？
不能。测试只说明当时、该页面可观察到的网络候选。账号安全还取决于凭据保护、授权行为、内容合规、恢复方式和平台规则。
结语
WebRTC泄露不是“检测页出现第二个地址”这么简单。可靠判断需要依次确认普通网页出口、候选类型、UDP与IPv6路径，再把结果与代理出口和原始网络基线对照。最有价值的证据通常是srflx候选中出现不应暴露的运营商公网地址，而不是一个内网地址或TURN中继地址。
修复同样不是只切换一个开关。网络隧道能力、浏览器策略、代理UDP支持、IPv6和业务功能必须一起验证。对长期运营团队而言，稳定配置、逐项复测和可审计记录，比不断随机更换环境更可靠。