什么是 WebRTC 泄漏？
WebRTC (Web Real-Time Communication) 是 W3C 标准的浏览器实时通信 API—— Google Meet / Zoom 网页版 / Discord 网页版 / 视频客服 等所有「浏览器原生视频通话」都用它。 WebRTC 工作时需要知道对端的网络位置，所以它会通过 STUN（Session Traversal Utilities for NAT） 协议向公开服务器查询「我的公网 IP 是多少 / 我的内网 IP 是多少」。
问题来了：STUN 走的是 UDP 协议。很多 VPN / 代理服务只接管 TCP 流量 + DNS 流量， 不接管 UDP。这意味着你的浏览器开着 VPN 显示「美国 IP」， 但只要它一执行 WebRTC API（即使你没在打视频通话——网站可以悄悄触发）， STUN 请求就直接从你的真实 IP 发出去，目标网站立刻能在 ICE candidate 里拿到你的真实公网 IP。
这就是 WebRTC IP 泄漏（WebRTC IP Leak）——是反指纹 / 跨境多账号 / 隐私保护场景里的经典翻车点。 chdh.me 在 2026 国产指纹浏览器深度横评 的「反共识 2：路由器 MAC / WebRTC 延迟封号」章节中详细说明： 一个泄漏的 WebRTC IP 把你 50 个 profile 全部串成一个真实身份。
这工具检测什么？
1. 服务端看到的公网 IP（基准）
调一次 chdh.me 的 /api/check 拿到「网站看到的你」——
这是 VPN/代理生效后的"门面 IP"，作为对比基准。
2. WebRTC 拿到的公网 IPv4（关键泄漏字段）
向 4 个公开 STUN 服务器（Google × 2 + Cloudflare + Mozilla）发起 RTCPeerConnection，
解析 ICE candidate 里 typ srflx（Server Reflexive）的 IP——
这是 STUN 反射给浏览器的"你真实的公网 IPv4"。
判定逻辑：如果这个 IP 与服务端 IP 不一致—— 说明 VPN 没接管 WebRTC，红色泄漏警告。
3. WebRTC 拿到的公网 IPv6（双栈泄漏专项）
很多 VPN 只代理 IPv4 不代理 IPv6——一旦你的家庭网络支持 IPv6（中国电信 / 联通 2020 后大量启用）， WebRTC 会拿到你真实的 IPv6 地址。即使 IPv4 没泄漏，IPv6 单独泄漏也算泄漏。 本工具单独标识 IPv6 泄漏，方便定位是双栈问题还是全栈问题。
4. 本地 IP / mDNS
ICE candidate 的 typ host 是浏览器看到的本地 IP（如 192.168.1.5）。
Chrome 80+ 和 Firefox 较新版本会自动把它替换成
abcd-1234-efgh.local 这种 mDNS hostname——这是浏览器主动的隐私保护。
如果你看到 192.168.x.x 直接暴露在 candidates 里，说明 mDNS 保护被禁用了
（Chrome flag #enable-webrtc-hide-local-ips-with-mdns 被关闭），
不算严重泄漏但反映你的隐私设置不严。
为什么要用 4 个 STUN 服务器同时探测？
单一 STUN 有几个问题：① 该 STUN 服务器临时不可达；② 该 STUN 被你的网络环境屏蔽（中国大陆部分网络屏蔽 Google STUN）； ③ 不同 STUN 返回的 IP 可能不一致（极少见，但 NAT 类型异常时会发生）。 多 STUN 互相印证 + 任意一个能拿到 srflx 就足以下泄漏判定。chdh.me 选 Google × 2 + Cloudflare + Mozilla 4 家，覆盖全球网络环境。
跨境运营场景的 5 个真实案例
案例 1：广告投手用商业 VPN 投美区结果一上线就封 BM
你买了 NordVPN / Surfshark / ExpressVPN 切到美国节点， 用 AdsPower 一个 profile 注册新的 Facebook BM， 一上线就被封禁。原因可能不是 VPN 出口 IP 不干净（参见 代理 / VPN 检测）， 而是 WebRTC 把你真实的家庭 IP 漏出去了。 Facebook 风控引擎对比「VPN 出口 IP（美国）」与「WebRTC 拿到的真实 IP（中国）」—— 不一致 = 自动判定欺诈，秒挂 BM。
案例 2：TikTok Shop 美区真本土店 IPv6 泄漏
你做了真本土 LLC + 美国地址 + 美国手机号 + 住宅代理（很贵的 Bright Data 静态住宅 IP）， TikTok 看到的 IPv4 是「美国得州 Comcast」。但你的家庭网络启用了 IPv6， WebRTC 拿到你真实的中国 IPv6——TikTok 的反欺诈引擎自动比对， 新店出第一单第二天就冻店。这是 chdh.me 在 国产指纹浏览器深度横评 中提到的「TikTok Shop 美区 2024-2025 末 80% 新店被封」的隐性触发器之一。
案例 3：广告投手多 profile 串号
你在 AdsPower 跑 20 个 profile 投广告，每个 profile 都配独立住宅代理 IP。 但你忘了在每个 profile 里检查 WebRTC—— 所有 profile 共用一个真实的家庭 WebRTC IP（路由器层）。 Meta 的 Behavioral Clustering 算法把所有 20 个 BM 关联成同一台机器同一个真人， 一个 BM 出问题，剩下 19 个也一起挂。
案例 4：跨境收款账户 KYC 视频被 WebRTC 漏 IP
你注册 PingPong / Payoneer / Mercury / Wise，做视频 KYC 验证时—— KYC 平台用 WebRTC 通话同时悄悄记录你的 STUN candidates。 KYC 通过了，但平台风控系统已经把你的真实 IP + 提交资料绑定。 下一次你用 VPN 登陆同一个账号，平台立刻识别「同账号但 IP 异常」——加风控。
案例 5：跨境企业内网员工 VPN 自检
公司给员工配 VPN 访问海外内网（GitHub Enterprise / Slack / Notion / Linear）。 员工本来以为 VPN 流量是受保护的，但 WebRTC 一旦被恶意网站触发—— 会泄漏「员工真实家庭 IP + 内网 IP」组合，是钓鱼攻击的高价值情报。 企业安全审计场景必须用 WebRTC 检测做基线验证。
怎么修复 WebRTC 泄漏？
- Firefox（最彻底）：
about:config→media.peerconnection.enabled→ 设false。 这会完全禁用 WebRTC，副作用是无法用 Firefox 打视频通话。 - Chrome / Edge：浏览器不提供原生关闭开关，需要装扩展：
WebRTC Leak Prevent / WebRTC Control / uBlock Origin（高级模式自定义 disable WebRTC）。
或者用企业策略关闭：
chrome://policy→WebRtcIPHandling: disable_non_proxied_udp。 - Brave Browser（推荐）：Settings → Shields → Fingerprinting →
WebRTC IP handling切「Disable Non-Proxied UDP」。 这是最优雅的方案——WebRTC 还能用（开视频会议没问题）， 但只允许走代理的 UDP 通道，从源头杜绝泄漏。 - 系统层禁用 IPv6（针对 IPv6 单独泄漏场景）：
macOS 用
networksetup -setv6off Wi-Fi； Windows 在网络适配器属性里取消勾选 IPv6； Linuxsysctl -w net.ipv6.conf.all.disable_ipv6=1。 - 用支持双栈接管的 VPN：Mullvad / ProtonVPN / 自建 WireGuard 等。 商业大厂 VPN（NordVPN / Surfshark）默认配置常常不接管 IPv6 + UDP，需要手动配。
这工具的局限
- 不是所有跨境平台都会主动触发 WebRTC。Amazon / TikTok Shop / Facebook / Stripe / PayPal 等大平台已经主动用 WebRTC 反指纹，但小平台 / 普通电商站点不一定。 即使本工具说"未泄漏"也不代表网站从来不会触发，只代表 chdh.me 这次没触发。
- 4 个 STUN 在中国大陆部分网络下可能不可达。 如果"STUN 响应 0/4"，说明你的网络屏蔽了所有公开 STUN 服务器—— 反过来也意味着大部分跨境平台的 WebRTC 也用不了，泄漏风险天然降低。
- 只覆盖浏览器层。如果你用 native app（亚马逊客户端 / TikTok Shop Seller Center App）， app 内部的网络栈完全不走浏览器，本工具检测不到 app 层的 IP 暴露。
常见问题
Q1: 我看到"未发现 WebRTC 公网 IP"，是不是 WebRTC 完全没用？
不一定。两种可能：① 你的浏览器关掉了 WebRTC（Firefox media.peerconnection.enabled=false
或扩展拦截）—— 这是最好的状态；② STUN 服务器不可达 / 网络屏蔽——
看顶部"STUN 响应 0/4"可以判定。前者说明隐私设置极严，后者说明你的网络环境特殊。
Q2: WebRTC IP 与服务端 IP 完全一致，但我没用 VPN，正常吗？
正常。"WebRTC IP = 服务端 IP" 意味着没有任何代理 / VPN 在中间， 你直接用真实 IP 上网——所以两个 IP 自然是同一个，没有泄漏可言（因为本来就没东西要"漏"）。
Q3: 这工具支持移动端浏览器吗？
支持。iOS Safari / Android Chrome 都支持 WebRTC API，本工具能正常采集。 但移动端隐私机制更严，特别是 iOS 17+ 对 WebRTC 做了大量限制， 多数情况只会看到 mDNS hostname 不会看到真实本地 IP，公网 IP 也常常被运营商 NAT。
Q4: 我用了 Cloudflare WARP / 1.1.1.1 客户端，会有 WebRTC 泄漏吗？
Cloudflare WARP 默认接管 UDP（这是 WireGuard 协议的特性），所以理论上 WebRTC 也走 WARP—— 但实测 macOS / iOS 上的 WARP 有时不接管 WebRTC（涉及系统层 entitlement）。 用本工具实测一次最稳。
Q5: chdh.me 这工具会上传我的 IP / candidates 数据吗？
WebRTC 探测 100% 在浏览器本地完成，不上传 candidate 数据到 chdh.me 后端。 唯一调用后端的是"拿网站看到的服务端 IP"——这本来访问任何网站都会暴露给对方，不是新增信息。 所有 STUN 请求直接从你的浏览器发到 Google / Cloudflare / Mozilla 公开 STUN 服务器，chdh.me 后端不参与。
关于 chdh.me
出海导航 chdh.me 是面向中国跨境电商 / 独立站 / 海外 SaaS 创业者的独立工具评测与发现平台。 截至 2026-07 收录 2,200+ 出海工具 + 27 篇深度评测 + 1,700+ 工具对比页。 独立运营 · 纯公益 · 不接联盟链接 · 不接付费收录 · 不接付费排名。 详见 收录与评测标准 与 公益承诺。