- 只要页面能执行 JavaScript，就能在后台调用 RTCPeerConnection 发起 ICE 候选收集——全程零权限弹窗，用户毫无感知。
- 泄漏主因在于协议割裂：STUN 探测默认走 UDP，而传统 HTTP/HTTPS/SOCKS（TCP-only）代理不会转发 UDP，导致探测包直接从本地运营商宽带发出。
- 现代 Chrome/Edge/Safari 已默认用 xxxx.local mDNS 名称遮蔽 host 局域网 IP（如 192.168.x.x），真正致命的是被 STUN 反射出来的公网 srflx 候选地址。
- 最彻底的治本方案是启用支持接管 UDP 的 TUN 虚拟网卡模式，或在独立跨境环境浏览器中限制非代理 UDP / 按业务取舍关闭 WebRTC。
1. WebRTC 是什么？为什么无需授权就能拿到网络地址
WebRTC（Web Real-Time Communication）是现代桌面与移动浏览器原生内置的实时通信协议栈，网页视频会议、语音客服、直播连麦、云桌面乃至浏览器的 P2P 文件传输都依赖它。为了在两台终端设备之间尽可能建立直连（Peer-to-Peer）而无需所有音视频都绕行中转服务器，浏览器必须先摸清本机所有可达的网络出口。
这个摸底过程在规范里被称为 ICE 候选收集（Interactive Connectivity Establishment Candidate Gathering）。网页只需要在前端实例化一个隐藏的 RTCPeerConnection 对象，向 STUN 服务器发出极轻量的 UDP Binding 请求，就能被动收到本机不同网卡与 NAT 映射后的候选地址。整个探测只涉及网络地址发现，完全不会触发摄像头或麦克风的权限询问弹窗。
网页 HTTP/HTTPS 请求（包括 IP 查询网站首屏显示的访客 IP、Cookie 写入、表单提交）全部运行在 TCP 层之上，确实走过了代理通道；但嵌入式风控脚本（如 Meta/PayPal/TikTok 风控探针或 Stripe Radar 前端遥测）会同时触发 WebRTC STUN UDP 探测，一旦两者归属国家或 ASN 不一致，风控引擎立刻将其标记为「疑似代理隐匿 / 环境篡改」。
2. 泄漏是怎么发生的？ICE 三类候选地址与 UDP 绕行机制
在 ICE 协商过程中，浏览器会并行收集以下三类核心候选地址（外加少量服务端被动反射出的 prflx 对端反射地址），真正发生公网真实 IP 泄漏的关键就在第二类 srflx 上：
host（本机网卡地址 / mDNS 遮蔽）
代表本机操作系统网卡上绑定的内网或直连地址（例如 192.168.1.x 或 10.x.x.x）。早期浏览器会明文暴露具体内网段，容易泄露设备局域网拓扑或代理虚拟网卡特征。
srflx（Server Reflexive · STUN 反射公网 IP）
浏览器向公网 STUN 服务器发出 UDP 探测包后，STUN 服务器原样回传「我看到这个 UDP 包是从哪个公网 IP 与端口发出来的」。一旦该包未进代理隧道，返回的正是你的真实家庭/公司运营商公网 IP。
relay（TURN 中继服务器地址）
当企业防火墙彻底封锁 UDP 直连、或浏览器强制限制仅通过代理转发 WebRTC 媒体时，所有通信被迫走 TURN 服务器中继，对外仅露出 TURN 节点 IP（或经过代理转发的出口 IP）。
prflx（Peer Reflexive · 对端反射地址）
在连通性检查阶段当浏览器与远端对等体直接握手时动态发现的临时 NAT 映射地址；同样受制于本地 NAT 与 UDP 是否真正经过代理通道。
交互模拟器：不同代理模式下的 WebRTC ICE 暴露情况
PRV-01 LAB3. 为什么专业检测要同时测「国内 STUN」与「海外 STUN」？
很多出海运营和工程师在使用带规则分流（Split-Tunneling）的代理客户端时，会出现一种极其隐蔽的「半泄漏」：测试单个 STUN 节点看似正常，一上实战环境却依然被判定 IP 异常。原因在于分流引擎对不同目的地 STUN 域名的处置策略完全不同。
专业隐私体检工具必须并行向境内 STUN 服务器与境外 STUN 服务器发起探测：如果境外 STUN 返回的 srflx IP 与代理出口一致，往往说明该域名被规则命中了 UDP 转发；而如果境外 STUN 返回的依然是你本地电信/联通的公网 IP，则铁定证明「代理客户端没有接管 UDP，或该节点的 UDP 转发未通」。相反，若业务分流本意是国内直连、海外走代理，则国内 STUN 返回本地 IP 属于分流预期，但海外核心站点的 STUN 绝对不能暴露真实宽带地址。
不少中转机场或静态代理套餐仅开启了 TCP 转发而未开放 SOCKS5 UDP Associate（或机场节点上游阻断了 3478/19302 UDP）。此时哪怕你在客户端打开了 TUN 模式，UDP 包也可能在底层悄悄回退直连或被静默丢弃；上线核心店铺或投放号前，务必实测海外 STUN 的真实回显。
4. 多端与跨国团队 WebRTC 防护策略全对照
针对个人日常浏览器、代理客户端配置与跨境多账号专业工作环境，建议按「传输层全接管优先、浏览器策略兜底、业务按需取舍」三步构建防线，并对照下表选择与你业务兼容性最高的方案：
| 防护层级 / 方案 | 操作配置方法 | WebRTC 测试结果 | 风控兼容性评估 |
|---|---|---|---|
| 代理客户端 TUN 模式 / 全局接管 UDP（首选） | 在代理端启用 TUN 虚拟网卡，确认机场/独享节点支持完整 UDP 转发 | srflx 显示为代理出口 IP（与网页 TCP IP 一致） | 极高：既有真实可用 WebRTC 能力，又不泄露真身，适合 Meta Ads / TikTok / Shopify |
| Chrome / Edge 企业策略或专用限制配置 | 将 WebRTCIPHandlingPolicy 设为 disable_non_proxied_udp（禁止非代理 UDP 直出） | 仅允许通过代理转发的路由或回落至 relay，彻底阻断本地公网 IP 泄漏 | 高：推荐给不使用 TUN、仅挂 SOCKS5/HTTP 本地端口的高敏浏览器 Profile |
| 指纹浏览器「替换 (Replace / Forward)」模式 | 在独立 Profile 网络设置中开启 WebRTC「基于出口 IP 替换」并掩蔽真实公网 | JS 读到的 srflx 与当前代理公网 IP 一致，host 以 .local mDNS 呈现 | 高：电商多店、独立站与社交矩阵最稳妥方案，避免被识别为功能残缺 |
| Firefox about:config 完全禁用 | 将 media.peerconnection.enabled 设为 false（或扩展一刀切屏蔽 RTCPeerConnection） | RTCPeerConnection 对象直接不可用，彻底消除全部候选 | 中：完全杜绝泄漏，但无法使用网页语音/视频，且极少数强风控站会把彻底禁用 API 视作异常指纹特征 |
浏览器扩展、操作系统更新或代理客户端重装规则文件后，原本锁定的 UDP 策略极易失效。养成「切完节点 / 更新客户端后，立刻跑一次 WebRTC + DNS 双项体检」的 SOP 习惯，只需 5 秒即可避免价值数万元的高权重广告账户被底层 UDP 穿帮连坐。
WebRTC 泄漏常见问题与工程排查 (FAQ)
Chrome、Edge 和 Safari 现在还会泄露 192.168.x.x 局域网 IP 吗？
基本已经缓解。现代主流浏览器默认启用 mDNS 规范（RFC 8828），在未授予摄像头/麦克风权限的情况下，host 候选中的局域网 IPv4/IPv6 地址会被替换为一个随机 UUID.local 别名。但你仍需高度警惕：一旦用户在当前站点曾经点过「允许麦克风/摄像头」，mDNS 遮蔽会在该授权生命周期内解除，且公网 srflx 地址从来不受 mDNS 保护。
把 WebRTC 完全禁用（Disabled）一定比显示代理 IP（Replace）更安全吗？
不一定。对于纯浏览隐私来说，完全禁用是最省心的「绝对不漏」方案；但对于跨境电商（Amazon/TikTok/Stripe/PayPal）或社媒广告后台（Meta/Google Ads）而言，绝大多数真实普通用户的 Chrome 默认都是开启 WebRTC 的。如果一个声称正常家宽客户的浏览器却连 window.RTCPeerConnection 都报错或完全为空，部分高级反欺诈脚本（如 ThreatMetrix、Forter）反而会给「反指纹插件干预信号」加分。最优解是让 UDP 走 TUN 或限制仅代理转发，使 WebRTC 正常返回当前干净住宅出口的 srflx。
为什么我在指纹浏览器里选了静态住宅 SOCKS5，检测 WebRTC 还是超时的或空白？
因为很多代理商卖的传统静态住宅只开通了 HTTP/HTTPS 与 SOCKS5 TCP 通道，服务器侧并未打开 UDP Associate，或者本地与代理节点之间的防火墙截断了 UDP 包。此时如果指纹浏览器选的是「跟随/真实模式」，探测包无法通过代理便只能超时；如果选「基于当前出口 IP 自动替换」，即使代理不支持 UDP 也不会暴露真实公网，但在高精度风控场景建议优先选购确认支持 UDP 或通过 TUN 转发的独享双 ISP 资源。
手机端（iOS / Android）开启代理 APP 后也会有 WebRTC 泄漏吗？
通常移动端表现与桌面不同。iOS 的代理工具几乎全都基于系统级 NEPacketTunnelProvider（等价于虚拟网卡/TUN）工作，只要未手动把 STUN UDP 排外放行，通常会顺带接管；但 Android 部分分应用代理或老旧 WebView 内核仍可能在特定规则下直接放行物理蜂窝网卡的 UDP 流量，手机养号前同样应先打开浏览器运行 MyIP / WebRTC 在线校验。
用 Evaoo 零日志工具实测你的 WebRTC 真实暴露情况
无需安装插件，直接在浏览器运行多节点 STUN 检测、国内/海外出口核对，以及当前 IP 的原生度与 ASN 类型诊断。