搜索 K
Appearance
WebRTC 真实 IP 泄漏危机与规避：浏览器无感出卖你位置的隐蔽后门
一、TL;DR：先给结论，再看原理
如果你的代理客户端是 HTTP/HTTPS 代理，或者 SOCKS5 但没有开启 UDP ASSOCIATE，那么你在 Chrome 里打开任何一个内置了 RTCPeerConnection 的页面（视频客服、广告 SDK、部分风控脚本、在线会议），浏览器就会通过 STUN 探测把 NAT 出口的真实公网 IP 直接送出去——你不需要点"允许"，也不需要真的接通通话。
三个立刻要做的动作：
- 打开
chrome://webrtc-internals，主动创建一个测试连接，看local-candidate里有没有出现你真实运营商的 IP 段； - 把浏览器策略
WebRtcIPHandlingPolicy设为disable_non_proxied_udp，让 UDP 必须走代理，否则宁可不发； - 回头检查代理链路本身是否真的接管了 UDP——这一步 90% 的人漏掉，插件和扩展关得再干净也没用。
下面把机理、量化对照、分平台配置、抓包命令和避坑矩阵一次讲透。
二、底层机理：WebRTC 为什么能绕过你的代理
2.1 ICE 候选地址的四种来源
WebRTC 在打通 P2P 之前必须做 ICE（Interactive Connectivity Establishment）收集。浏览器会枚举本机所有网络接口，把可用地址写进 SDP 的 candidate 行，并通过 STUN 服务器（典型端口 3478、19302）做 NAT 穿透探测。候选分四类：
- host：本机网卡地址，例如
192.168.1.34、10.8.0.6（TUN 虚拟网卡）、172.17.0.1（Docker 网桥） - srflx（Server Reflexive）：STUN 服务器回给你的"你从哪个公网 IP 来"，也就是 NAT 出口 IP
- prflx（Peer Reflexive）：对端在连通性检查过程中观察到的地址
- relay：TURN 中继地址，走服务器带宽
真正致命的是 srflx。它通过 UDP 发包，路径完全由系统路由表决定，跟你的 HTTP 代理监听在哪个端口毫无关系。
2.2 mDNS 只藏住了 host，藏不住 srflx
Chrome 从 M76 起引入 mDNS 混淆（RFC 8828）：在未授予摄像头/麦克风权限的页面上，host 候选会被替换为随机 .local 域名，局域网 IP 不会明文出现在 SDP 里。这是很多人误以为"已经安全"的来源。
但有两个坑：
- 权限一旦授予就永久生效。你在某个域名点过一次"允许使用摄像头"，该域名的 mDNS 保护即失效，host 候选恢复明文，内网拓扑（
192.168.x.x、10.x.x.x）全部暴露。 - mDNS 对 srflx 完全无效。它只改 host 的呈现形式，STUN 返回的公网 IP 是实打实的。
2.3 代理形态决定泄漏形态
| 代理形态 | UDP 是否被接管 | srflx 结果 | 风险等级 |
|---|---|---|---|
| HTTP / HTTPS 代理 | 否 | 真实 ISP 公网 IP | 极高 |
| SOCKS5（未开 UDP ASSOCIATE） | 否 | 真实 ISP 公网 IP | 极高 |
| SOCKS5 + UDP ASSOCIATE | 是 | 代理出口 IP | 低 |
| TUN 模式（Clash / sing-box） | 是 | 代理出口 IP | 低 |
| 系统级 VPN 全流量接管 | 是 | 代理出口 IP | 低 |
很多人只在浏览器侧关 WebRTC，却忽略了代理链路本身不转发 UDP，结果换了个端口、换了个协议，泄漏照旧。
2.4 为什么说这是"无感"泄漏
页面只要执行 new RTCPeerConnection()，收集阶段就已经开始发包，不需要用户交互，也不需要真的建立媒体流。广告联盟 SDK、客服系统、部分风控脚本都可能内嵌这段逻辑。这就是"浏览器无感出卖你位置"的字面含义。
三、泄漏分级矩阵：你属于哪一档
| 档位 | 判定特征 | 典型人群 | 处置建议 |
|---|---|---|---|
| A 级（已泄漏） | 检测页返回真实 ISP 名称，与代理出口国不符 | 用 HTTP 代理 + 默认浏览器策略 | 立即改代理为 TUN 或开 UDP ASSOCIATE |
| B 级（半泄漏） | 无 srflx，但 host 暴露 192.168.x.x | 曾授权过摄像头/麦克风的站点 | 清理站点权限 + 设置 ice.no_host |
| C 级（策略泄漏） | 策略为 default，仅在部分内核暴露 | 企业统一下发配置未收紧 | 下发 disable_non_proxied_udp |
| D 级（干净） | 无 host 明文、无 srflx、UDP 全走代理 | TUN 模式 + 严格策略 | 保持，定期复测 |
四、核心量化指标对照表
| 指标 | Chrome 默认 | Chrome 严格策略 | Firefox 默认 | Firefox 严格 | Safari 默认 |
|---|---|---|---|---|---|
| host 明文泄漏 | 授权后泄漏 | 不泄漏 | 泄漏 | 不泄漏 | 不泄漏 |
| mDNS 生效条件 | 未授权时 | 未授权时 | 无 mDNS | 无 mDNS | 原生隐藏 |
| srflx 泄漏 | 是 | 视 UDP 接管 | 是 | 视 UDP 接管 | 是 |
| IPv6 候选 | 默认收集 | 可关闭 | 默认收集 | 可关闭 | 默认收集 |
| 视频通话误杀率 | 0 | 约 15%（代理无 UDP 时） | 0 | 约 20% | 0 |
| 企业策略可控性 | 高（GPO/注册表） | 高 | 中（policies.json） | 中 | 低 |
| 移动端一致性 | Android 同桌面 | 同 | 无 | 无 | iOS 独立实现 |
| 风控触发权重 | 极高 | 极低 | 高 | 低 | 高 |
| 检测可绕过 | 否 | 否 | 否 | 否 | 否 |
| 复测建议周期 | 7 天 | 30 天 | 7 天 | 30 天 | 7 天 |
五、分人群选型：谁必须立刻关掉 WebRTC
- 跨境电商多账号运营：亚马逊、eBay、Shopify 后台普遍采集浏览器指纹。一旦 WebRTC 泄漏出中国大陆 ISP 段，与你的美国收货地址、美国支付卡形成逻辑矛盾，账号关联与二审几乎必中。必须做到 D 级。
- 广告投放与联盟营销：Meta Ads、Google Ads 的账号安全团队会做环境一致性校验，出口 IP、时区、语言、WebRTC 候选四者不一致是最常见的封号触发点。
- 海外风控穿透检测场景：支付网关（Stripe、PayPal）在风控评分中会读取 WebRTC 候选，判断"申述人的网络环境是否与其声称的所在地一致"。这是纯粹的穿透检测，跟你好不好用无关。
- 流媒体解锁用户：Netflix、Disney+ 部分区域会做候选地址比对，但优先级低于电商与支付场景，属于"顺手做"。
- 普通跨境办公：如果用的是企业级 IEPL/IPLC 专线，UDP 全量接管，主要风险在 host 候选暴露内网结构，清理站点权限即可。
💡 ⭐ 2026 企业级防挤兑专线 · 【隐形人】读者专享特惠通道：
海外新加坡团队运营，企业级 IEPL 专线 + 60+ 原生机房独立 IP，晚高峰 500M 冗余带宽不挤兑，UDP 全量接管不泄漏 srflx，支持 24h 退款保障：直达隐形人官网 ↗
海外新加坡团队运营，企业级 IEPL 专线 + 60+ 原生机房独立 IP，晚高峰 500M 冗余带宽不挤兑，UDP 全量接管不泄漏 srflx，支持 24h 退款保障：
8折特惠yxr888复制 📋
六、分平台实操封堵配置
6.1 Chrome / Edge（策略层，最彻底）
地址栏输入 chrome://policy 可核对生效状态。企业环境推荐通过组策略或注册表下发：
WebRtcIPHandlingPolicy=disable_non_proxied_udp（最严格，UDP 必须走代理）WebRtcUdpPortRange= 限制 UDP 端口范围，便于防火墙统一拦截WebRtcLocalIpsAllowedUrls留空，避免白名单误放行
注意：disable_non_proxied_udp 在代理不支持 UDP 时会直接让视频通话失败，这是"安全换可用性"的取舍，个人用户可以先降级到 default_public_interface_only 观察。
6.2 Firefox（about:config）
media.peerconnection.enabled=false（核弹级，直接禁用）media.peerconnection.ice.no_host=true（不发送 host 候选）media.peerconnection.ice.default_address_only=true（只用一个接口）media.peerconnection.ice.proxy_only_if_behind_proxy=true（有代理时只走代理）
四项组合后 Firefox 的泄漏面基本收敛，代价是部分会议软件需要重新手动放开。
6.3 Safari / iOS
Safari 的 host 候选默认隐藏，但没有暴露给用户的策略开关。实践做法是在系统层解决：iOS 上使用支持 UDP 的 Network Extension 类客户端，并在"设置 → 隐私 → 位置服务"中检查浏览器权限。移动端复测建议每周一次。
6.4 系统防火墙兜底（Windows）
powershell
New-NetFirewallRule -DisplayName "Block WebRTC STUN" `
-Direction Outbound -Protocol UDP `
-RemotePort 3478,3479,5349,19302 -Action Block这条规则把常见 STUN/TURN 端口全部封死，属于"宁可错杀"的兜底手段，适合风控敏感的多账号环境。
七、抓包排障诊断手册
7.1 三步定位法
bash
# 1. 确认 HTTP 层出口
curl -s https://ipinfo.io/ip
curl -s --socks5-hostname 127.0.0.1:1080 https://ipinfo.io/ip
# 2. 确认 UDP 是否能到达 STUN 服务器
mtr -u -P 3478 -c 20 stun.l.google.com
# 3. 抓 STUN 请求，看源 IP
sudo tcpdump -i any -n udp port 3478 -c 20
sudo ss -uap | grep -E '3478|19302'Windows 侧对应：
cmd
netstat -ano | findstr 34787.2 判定表
| 现象 | 含义 | 处置 |
|---|---|---|
| tcpdump 抓到 STUN 包，源 IP 为真实公网 | UDP 直出 | 改 TUN 模式或开 UDP ASSOCIATE |
| tcpdump 无任何 STUN 包 | 策略已拦截或代理吞掉 | 复查策略是否过严导致通话失败 |
ss -uap 显示浏览器进程持有 UDP socket | 浏览器自行发包 | 收紧 WebRtcIPHandlingPolicy |
mtr -u 到 3478 全丢但 TCP 正常 | 代理不支持 UDP | 换协议或升级客户端 |
检测页显示 IP 与 curl 出口一致 | 链路健康 | 保持并定期复测 |
tcping 只测 TCP，别用它来判断 STUN 连通性，这是很常见的误判来源。
八、行业避坑矩阵
| 坑位 | 典型话术 | 真相 | 识别方法 |
|---|---|---|---|
| 伪屏蔽扩展 | "一键禁用 WebRTC，永久防泄漏" | 只改前端 API，拦截不到 STUN 包 | 开抓包看是否有 UDP 3478 出站 |
| 假检测站 | "免费检测，立刻出结果" | 只读 HTTP Header，不做 ICE 收集 | 检查页面是否真的 new 了 RTCPeerConnection |
| 无 UDP 宣传 | "全程无 IP 泄漏" | 底层用 HTTP 代理，UDP 裸奔 | 要求提供 UDP ASSOCIATE 或 TUN 说明 |
| 超售节点 | "万人共享，价格极低" | 晚高峰 UDP 被限速丢包，视频卡顿 | 高峰时段跑 mtr -u 看丢包 |
| 伪原生 IP | "美国原生住宅 IP" | 实为机房段，风控直接标记 | 查 ASN 与 whois 归属 |
| 跑路预警 | "年付五折，最后三天" | 资金盘特征明显 | 查运营年限、支付通道、退款条款 |
九、常见问题 FAQ
Q1：关了 WebRTC 会不会导致 Google Meet、Zoom 网页版不能用？ 会。disable_non_proxied_udp 配合不支持 UDP 的代理，等于把会议功能锁死。建议为会议域名单独放行，或用桌面客户端替代。
Q2：用了 TUN 模式就万无一失了吗？ 不是。TUN 解决的是 UDP 路由问题，但 host 候选仍可能明文暴露内网结构。两者要一起处理。
Q3：为什么我换了节点，检测页显示的 IP 还是没变？ 大概率是浏览器缓存了 ICE 候选，或检测页复用了上次的 PeerConnection。强制刷新 Ctrl+Shift+R 并关闭标签页重开。
Q4：手机上也存在这个问题吗？ 存在。iOS Safari 隐藏 host 候选但不隐藏 srflx；Android Chrome 与桌面行为基本一致。移动端建议直接用带 TUN 的全局客户端。
Q5：企业统一分发策略后，员工反馈视频会议异常怎么��？ 先用 chrome://policy 确认策略真正生效，再为白名单域名降低策略等级。不要直接全局回滚。
Q6：检测站报告"未检测到泄漏"就真的安全吗？ 不一定。部分检测站只做 host 检测，不做 sr