做跨境运营、海外公开信息调研的从业者，可能遇到过这样一类棘手现象：代理已经配置完成，IP 检测网站返回代理出口地址，但访问目标业务平台时，依然触发风控、弹出验证，严重时还会出现账号异常。
反复排查之后，业务代码没有问题，代理链路也没有掉线，问题究竟出在哪里？
很多时候，真实公网 IP 被浏览器内置机制悄悄泄露出去，这个容易被忽略的技术点就是 WebRTC。
什么是 WebRTC
WebRTC（Web Real‑Time Communication）是浏览器内置的实时通信标准，无需安装额外插件，网页就可以实现视频通话、语音交互、文件传输等能力。网页版视频会议、网页语音聊天工具，底层都依赖这套能力。
WebRTC 本身是实用性很强的 Web 技术，但是它的通信逻辑，会和代理服务产生兼容性问题。
WebRTC 为什么可以绕过代理通道
要建立浏览器之间实时音视频通信，设备之间需要完成网络寻址，WebRTC 依靠 ICE 框架收集本机全部可用网络地址，再借助 STUN 服务器完成公网地址探测。
浏览器网络请求分为两类：
普通网页 HTTP/HTTPS 请求，基于 TCP 协议，可以被 HTTP、SOCKS5 代理接管转发。WebRTC 发起的 STUN 探测请求，基于 UDP 协议，直接在网络层完成通信。
大部分普通代理只接管 TCP 流量，并不会处理 UDP 数据包。STUN 的 UDP 探测报文会直接绕过代理隧道，使用本机本地网络出口，向 STUN 服务器上报本机真实公网 IP。
业务页面嵌入简单 JS 脚本，调用 WebRTC 相关 API，就可以拿到这套探测出来的真实公网地址。即便业务访问走代理出口，网站侧依旧可以获取到用户本机真实网络信息，进而触发风控策略。
WebRTC 泄露简易检测脚本
说明：仅用于本地环境技术排查，在浏览器 F12 控制台‑Console 面板运行，用于自查本机浏览器环境风险。
javascript
运行
// WebRTC IP泄露简易检测脚本function checkWebRTCLeak() { return new Promise((resolve) => { const pc = new RTCPeerConnection({ iceServers: [{ urls: "stun:stun.l.google.com:19302" }] }); pc.createDataChannel("test"); pc.createOffer() .then(offer => pc.setLocalDescription(offer)) .catch(() => resolve([])); pc.onicecandidate = (event) => { if (!event.candidate) return; const candidate = event.candidate.candidate; const ipMatch = candidate.match(/(\d{1,3}\.){3}\d{1,3}/); if (ipMatch) { console.log("检测到WebRTC候选IP：", ipMatch[0]); resolve([ipMatch[0]]); } }; setTimeout(() => resolve([]), 3000); });}checkWebRTCLeak().then(ips => { if (ips.length > 0) { console.log("⚠️存在WebRTC地址泄露风险，请检查代理与浏览器配置"); } else { console.log("✅未检测到WebRTC地址泄露"); }});
执行脚本后，如果输出结果为本机宽带真实公网 IP，就代表浏览器存在 WebRTC 地址泄露风险。
常见错误处理思路：直接禁用 WebRTC
不少人遇到泄露，第一选择就是直接关闭浏览器 WebRTC 能力，借助浏览器扩展屏蔽 WebRTC API，确实可以解决泄露问题，但会带来明显副作用。
当下大量网页业务依赖 WebRTC 能力：网页语音通话、线上会议、直播推流、在线协同编辑工具等。直接一刀切禁用 WebRTC，会造成上述网页功能无法正常工作。对于需要同时使用视频会议、直播、协同工具的跨境业务团队，这种处理方式会严重影响日常办公，实用性很差。
合理处理方案：让 STUN 探测流量走代理隧道
最优方案不是关闭 WebRTC 功能，而是让 WebRTC 产生的 STUN‑UDP 探测请求，同样经由代理隧道转发，需要同时满足两个条件：
代理服务侧支持 SOCKS5 UDP 转发能力SOCKS5 协议标准本身支持 UDP 报文转发，但很多代理服务商默认没有开启该能力。只有代理支持 UDP 转发，STUN 的 UDP 探测包才会走代理通道，STUN 服务器返回的才是代理出口 IP，而不是本机真实 IP。
浏览器 / 指纹客户端完成 UDP 代理配置服务端支持 UDP 转发还不够，客户端侧也需要正确配置：
Chrome、Edge：可安装 WebRTC Network Limiter 扩展，IP 处理策略设置为Disable non‑proxied UDP（force proxy），强制 UDP 流量走代理。指纹浏览器（AdsPower、候鸟浏览器等）：在 WebRTC 设置项，选择转发 / 替换模式，把 ICE STUN 请求强制交给代理链路。命令行启动浏览器：借助启动参数约束 ICE 候选生成逻辑，管控 WebRTC 网络行为。
WebRTC 防护的核心，不是废掉该功能，而是把它全部纳入代理转发链路。
代理 IP 质量高，为什么还会出现泄露？
很多从业者会陷入误区：出现 WebRTC 泄露就去更换更高质量代理节点。即便代理 IP 本身纯净无污染，如果 UDP 探测报文直接绕过代理，业务站点拿到的就不是代理出口 IP，而是本机真实网络地址。
代理 IP 质量管控的是业务 HTTP 请求出口；WebRTC 泄露风险来自浏览器独立 UDP 探测行为，二者属于两套独立维度，缺一不可。
部分代理服务商例如 9HTTP，产品层面已经支持 SOCKS5 UDP 转发能力。搭配指纹浏览器 WebRTC 转发配置，可把 STUN 探测流量纳入代理隧道，既保留 WebRTC 音视频、协同网页功能可用，又从源头规避真实公网 IP 外泄风险。
总结
WebRTC 泄露属于很容易被忽略的浏览器侧风险，它不会被代理 IP 质量修复，根源在于 UDP 探测报文绕过代理隧道。不建议直接禁用 WebRTC，会破坏大量网页实时业务。可行方案是：代理支持 SOCKS5 UDP 转发，同时客户端浏览器做好 WebRTC 流量管控，让 STUN 探测报文同样走代理通道。
建议先运行检测脚本，确认本地环境是否存在泄露风险，再针对性调整配置。
声明：本文仅为 Web 技术科普，仅供合法合规的技术调研、业务调试参考。网络工具请遵守平台规则以及属地网络相关法规。
