一、先说结论：IP 查询正常，不代表 WebRTC 没有泄露

普通 IP 查询页面通常检测的是浏览器发起 HTTP/HTTPS 请求时，服务端看到的访问来源。

而 WebRTC 泄露测试关注的是另一件事：

浏览器在建立实时通信连接时，会暴露哪些网络候选地址？
这些地址是否和当前代理、VPN 或加速出口一致？
是否出现了本地局域网地址、公网真实地址或异常 NAT 信息？

所以它和普通 IP 检测不是一个维度。

可以这样理解：

检测项目关注点典型结论
IP 查询HTTP 请求出口当前网页访问从哪里来
DNS 泄露测试域名解析出口DNS 查询是否走预期线路
WebRTC 泄露测试浏览器实时通信候选地址WebRTC 是否绕过代理暴露其他地址

如果 IP 查询正常，但 WebRTC 检测结果出现了本地真实网络信息，就说明还需要继续排查浏览器和代理链路。

二、WebRTC 是什么：为什么浏览器需要它

WebRTC 全称是 Web Real-Time Communication。它是一套让浏览器直接进行实时音视频、语音、数据通道通信的技术。

常见应用包括：

  • 网页版视频会议
  • 在线客服音视频
  • 浏览器语音通话
  • 远程协作白板
  • 网页端直播连麦
  • 点对点文件传输
  • 在线面试、远程教育、远程控制类应用

WebRTC 的特点是尽量寻找低延迟、可直连的路径。为了实现这一点，它需要探测当前网络环境：

本机有哪些网络接口？
本机处于什么 NAT 后面？
能否通过 UDP 直连？
公网出口是什么？
是否需要中继服务器 TURN？

这些探测动作本身就是 WebRTC 可能泄露信息的来源。

三、WebRTC 连接里的 ICE、STUN、TURN 是什么

排查 WebRTC 泄露时，经常会看到几个词。

名词作用和泄露风险的关系
ICE收集并选择可用连接路径会生成 candidate，里面可能有地址信息
STUN帮助客户端发现公网映射地址可能暴露 NAT 后的公网出口
TURN无法直连时走中继转发通常更可控，但延迟更高
Candidate候选连接地址检测工具主要观察的对象
mDNS用随机主机名隐藏本地 IP现代浏览器常用于减少内网 IP 暴露

一个简化流程如下：

浏览器启用 WebRTC
  -> 收集本地网络接口
  -> 请求 STUN 服务器
  -> 获取公网映射地址和 NAT 信息
  -> 生成 ICE candidate
  -> 选择最合适的通信路径

如果浏览器生成的 candidate 中包含真实公网 IP 或本地局域网 IP，而这些信息和用户预期不一致，就可能被认为存在 WebRTC 泄露风险。

四、WebRTC 泄露到底会暴露什么

不同浏览器、不同系统、不同代理模式下，检测结果可能不同。

常见结果包括：

检测结果含义风险判断
代理出口 IPWebRTC 与当前出口一致通常较符合预期
本地公网 IP可能绕过代理暴露真实出口需要重点排查
局域网 IP如 192.168.x.x、10.x.x.x现代浏览器通常会用 mDNS 隐藏
mDNS 主机名随机本地域名形式比直接暴露内网 IP 更安全
多个候选地址可能存在多网卡、IPv6 或分流需要结合网络环境判断
无 candidate浏览器策略限制或检测失败不一定代表绝对安全

注意：看到 mDNS 并不等于泄露严重。现代浏览器为了保护隐私，常用 mDNS 主机名替代真实局域网 IP。

五、为什么代理场景更需要测 WebRTC

很多代理配置只覆盖 HTTP/HTTPS 流量，或者只对特定应用生效。但 WebRTC 通常偏向 UDP、STUN 和点对点连接，路径选择可能和普通网页请求不一样。

常见风险场景：

浏览器 HTTP 请求 -> 代理出口
WebRTC STUN 请求 -> 本地直连出口

这就会出现：

IP 查询页面显示：代理节点 IP
WebRTC 检测显示：本地真实 IP

这种结果说明浏览器实时通信路径没有被完整覆盖。

在跨境办公、网页会议、在线语音、远程协作和浏览器代理场景里，这一点尤其值得关注。

六、在线 WebRTC 泄露测试怎么做

最直观的方式是打开 WebRTC 泄露测试页面。页面通常会调用多个 STUN 服务器，从不同角度观察浏览器生成的候选地址、NAT、网络和地区信息。

测试入口可以访问：

https://www.wenrugou.net/tools/webrtc-leak-test

建议按这个流程测试：

1. 关闭代理、VPN 或加速节点，做一次基线测试
2. 记录检测到的 IP、NAT、网络和地区
3. 开启代理、VPN 或加速节点
4. 刷新 WebRTC 检测
5. 对比候选地址是否变化
6. 观察是否出现本地真实公网 IP、局域网 IP 或多个异常出口

如果检测结果与当前公网 IP、代理节点或 VPN 出口不一致，需要进一步检查浏览器 WebRTC 设置、系统代理模式、TUN 模式、分流规则、浏览器扩展和客户端 DNS 设置。

七、为什么要用多个 STUN 服务器

单个 STUN 服务器可能因为网络不可达、被阻断、响应慢或路径特殊，导致结果不完整。

多个 STUN 服务器可以提升检测覆盖面，例如：

stun.l.google.com:19302
stun.voip.blackberry.com:3478
global.stun.twilio.com
stun.cloudflare.com

如果多个 STUN 服务器都检测到同一个异常地址，问题更可信。

如果只有某一个 STUN 服务器返回异常，需要结合日志判断：

  • 是 STUN 服务器本身不可达？
  • 是 UDP 请求被拦截？
  • 是浏览器策略不同？
  • 是网络环境临时波动？
  • 是代理规则没有覆盖某类 UDP 流量？

检测结果不是越多越好，而是要看它们是否和你的预期网络路径一致。

八、如何和当前公网 IP 做对比

第一步先查 HTTP 出口：

curl https://api.ipify.org

Windows PowerShell：

curl.exe https://api.ipify.org

也可以用浏览器打开公网 IP 查询页面。然后再打开 WebRTC 测试页面对比。

对比思路：

HTTP 出口WebRTC 出口判断
代理 IP同一代理 IP较符合预期
代理 IP本地公网 IP可能 WebRTC 绕过代理
代理 IPmDNS可能隐藏了本地候选，需看是否还有公网候选
本地 IP本地 IP未使用代理或测试基线状态
多个地址多个地址检查多网卡、IPv6、浏览器策略

如果普通网页出口和 WebRTC 出口不一致，不能只看一个结果就下结论，要继续查代理模式和浏览器配置。

九、DNS 泄露和 WebRTC 泄露要分开看

WebRTC 泄露经常和 DNS 泄露一起被讨论，但它们不是同一个问题。

DNS 泄露关注：

域名解析请求从哪里发出

WebRTC 泄露关注：

浏览器实时通信候选地址暴露了什么

所以推荐同时检测：

1. 当前公网 IP
2. DNS 泄露
3. WebRTC 泄露
4. IPv6 出口
5. 浏览器安全 DNS

如果 DNS 正常但 WebRTC 异常，问题更可能在浏览器 WebRTC 策略、UDP 连接、代理规则或系统流量接管。

如果 DNS 和 WebRTC 都异常，说明当前代理或加速模式可能没有完整接管系统网络。

十、浏览器为什么会出现不同结果

Chrome、Edge、Firefox、Safari 对 WebRTC 隐私策略不完全一样。

影响结果的因素包括：

  • 浏览器版本
  • WebRTC IP handling policy
  • 是否启用 mDNS 隐藏本地 IP
  • 是否安装代理或隐私扩展
  • 是否使用无痕模式
  • 企业策略是否限制 WebRTC
  • 是否启用安全 DNS
  • 当前网络是否支持 IPv6

同一台电脑上，可能出现：

Chrome：只显示 mDNS
Firefox：显示代理出口
Edge：检测失败或无候选地址

这不一定说明某个测试工具不准，而是不同浏览器策略不同。

十一、Chrome/Edge 如何降低 WebRTC 泄露风险

Chrome 和 Edge 可以通过隐私设置、扩展或企业策略影响 WebRTC 行为。普通用户最容易操作的是检查扩展和浏览器设置。

建议步骤：

1. 先在普通窗口测试
2. 再用无痕窗口测试
3. 禁用代理类、隐私类、脚本拦截类扩展后再测
4. 检查浏览器是否有 WebRTC 相关扩展
5. 对比 Edge 和 Chrome 结果

部分浏览器扩展可以限制 WebRTC 暴露非代理地址，但扩展本身也可能影响网络行为，建议测试时做前后对比，而不是装完就默认安全。

十二、Firefox 的 WebRTC 配置

Firefox 提供了更直接的高级配置入口。

地址栏输入：

about:config

常见相关配置：

media.peerconnection.enabled
media.peerconnection.ice.default_address_only
media.peerconnection.ice.no_host

含义大致如下：

配置作用
media.peerconnection.enabled是否启用 WebRTC
media.peerconnection.ice.default_address_only限制 ICE 使用默认地址
media.peerconnection.ice.no_host避免暴露 host candidate

注意：直接关闭 WebRTC 可能会影响网页会议、在线语音和实时协作工具。更合理的做法是先测试，再根据自己的业务需求调整。

十三、IPv6 是另一个常见盲区

很多泄露问题不是 IPv4，而是 IPv6。

例如：

IPv4 HTTP 请求走代理
IPv6 WebRTC candidate 暴露本地运营商 IPv6

Windows 查看 IPv6：

ipconfig /all
Get-NetIPAddress -AddressFamily IPv6

Linux：

ip -6 addr
ip -6 route

如果 WebRTC 检测结果出现 IPv6 地址，而你当前代理或加速模式没有处理 IPv6，就需要重点排查。

临时排障时可以关闭 IPv6 做对比，但长期是否关闭要看业务场景。有些公司内网、校园网或云环境依赖 IPv6，不建议盲目修改。

十四、NAT 类型怎么看

WebRTC 检测中经常会出现 NAT 信息。NAT 类型和直连能力有关。

常见理解：

NAT 情况可能影响
Full Cone更容易建立直连
Restricted Cone有一定限制
Port Restricted对端口映射更严格
Symmetric NAT直连更困难，可能需要 TURN 中继

如果 NAT 很严格，WebRTC 不一定泄露真实公网 IP，但实时通信可能更依赖中继，延迟会更高。

因此 NAT 信息不只是隐私指标，也能辅助判断会议、语音、连麦、远程协作为什么卡顿。

十五、命令行能不能直接测试 WebRTC 泄露？

严格来说，WebRTC 泄露是浏览器行为，命令行不能完全替代浏览器测试。

但是命令行可以帮助你建立对照组：

浏览器 HTTP 出口是什么？
系统 DNS 是什么？
IPv6 是否启用？
当前路由表是什么？
UDP 连接是否受限？

这些信息能帮助解释 WebRTC 测试结果。

Windows 查看路由：

route print

查看当前网络接口：

Get-NetIPConfiguration

Linux/macOS：

ifconfig
netstat -rn

Linux 新系统更推荐：

ip addr
ip route

十六、Node.js：打开检测页面并记录本机网络信息

下面这个脚本不能直接获取浏览器 WebRTC candidate，但可以作为辅助：打开检测页面，同时记录本机网卡和当前 HTTP 出口，方便你对照浏览器结果。

文件名：open_webrtc_leak_check.js

const os = require("os");
const { exec } = require("child_process");

const url = "https://www.wenrugou.net/tools/webrtc-leak-test";

console.log("[network interfaces]");
for (const [name, list] of Object.entries(os.networkInterfaces())) {
  for (const item of list || []) {
    if (!item.internal) {
      console.log(`${name} ${item.family} ${item.address}`);
    }
  }
}

console.log("\n[current http ip]");
exec("curl -s https://api.ipify.org", (error, stdout) => {
  if (error) {
    console.log("ip query failed:", error.message);
  } else {
    console.log(stdout.trim());
  }

  const command =
    process.platform === "win32"
      ? `start ${url}`
      : process.platform === "darwin"
      ? `open ${url}`
      : `xdg-open ${url}`;

  exec(command);
});

运行：

node open_webrtc_leak_check.js

打开页面后，把页面检测到的 WebRTC 地址和脚本输出的本机地址、HTTP 出口做对比。

十七、PowerShell：记录本机 IP、DNS 和路由信息

Windows 上可以准备一个排查脚本。

文件名：webrtc_local_probe.ps1

$Output = ".\webrtc_local_probe.txt"

"=== Time ===" | Out-File -Encoding UTF8 $Output
Get-Date | Out-File -Append -Encoding UTF8 $Output

"`n=== Public IP ===" | Out-File -Append -Encoding UTF8 $Output
curl.exe -s https://api.ipify.org | Out-File -Append -Encoding UTF8 $Output

"`n=== IP Configuration ===" | Out-File -Append -Encoding UTF8 $Output
ipconfig /all | Out-File -Append -Encoding UTF8 $Output

"`n=== DNS Servers ===" | Out-File -Append -Encoding UTF8 $Output
Get-DnsClientServerAddress | Out-File -Append -Encoding UTF8 $Output

"`n=== IPv6 Addresses ===" | Out-File -Append -Encoding UTF8 $Output
Get-NetIPAddress -AddressFamily IPv6 | Out-File -Append -Encoding UTF8 $Output

"`n=== Route Table ===" | Out-File -Append -Encoding UTF8 $Output
route print | Out-File -Append -Encoding UTF8 $Output

Start-Process "https://www.wenrugou.net/tools/webrtc-leak-test"
Write-Host "Saved to $Output"

运行：

powershell -ExecutionPolicy Bypass -File .\webrtc_local_probe.ps1

这份记录适合用于问题复现：

当前公网 IP 是什么
当前 DNS 是什么
是否有 IPv6
本机有哪些网卡
路由表是否有异常默认路由
WebRTC 页面检测结果是什么

十八、Python：整理多浏览器测试结果

WebRTC 泄露测试经常需要换浏览器对比。可以用 CSV 记录结果，再用 Python 汇总。

输入文件：webrtc_browser_compare.csv

time,browser,mode,http_ip,webrtc_ip,webrtc_type,ipv6,dns_provider,note
10:00,Chrome,direct,local-ip,local-ip,host,yes,isp,baseline
10:10,Chrome,proxy,node-ip,local-ip,srflx,yes,isp,webrtc leak
10:20,Edge,proxy,node-ip,mdns,host,yes,secure-dns,mdns hidden
10:30,Firefox,proxy,node-ip,node-ip,srflx,no,secure-dns,expected

分析脚本：analyze_webrtc_compare.py

import csv
from collections import Counter


rows = []
with open("webrtc_browser_compare.csv", "r", encoding="utf-8-sig", newline="") as f:
    rows = list(csv.DictReader(f))

leak_rows = []
for row in rows:
    http_ip = row.get("http_ip", "").strip()
    webrtc_ip = row.get("webrtc_ip", "").strip()
    if http_ip and webrtc_ip and http_ip != webrtc_ip and webrtc_ip != "mdns":
        leak_rows.append(row)

print(f"total: {len(rows)}")
print(f"suspected leaks: {len(leak_rows)}")

print("\n[browser count]")
for browser, count in Counter(row["browser"] for row in rows).items():
    print(f"{browser}: {count}")

print("\n[suspected leak rows]")
for row in leak_rows:
    print(
        f"{row['time']} {row['browser']} mode={row['mode']} "
        f"http={row['http_ip']} webrtc={row['webrtc_ip']} note={row['note']}"
    )

这个脚本的判断很粗糙，但适合把多轮测试结果结构化，避免只凭一次截图下结论。

十九、常见故障案例一：IP 查询正常，WebRTC 显示本地 IP

现象：

IP 查询页面显示代理出口。
WebRTC 检测显示本地真实公网 IP。

可能原因：

  1. 代理只覆盖 HTTP/HTTPS。
  2. WebRTC UDP 连接没有被接管。
  3. 浏览器 WebRTC 策略允许非代理候选。
  4. 分流规则没有覆盖 STUN。
  5. 当前模式不是 TUN 或全局接管模式。

排查步骤：

1. 切换到全局或 TUN 模式后再测
2. 换浏览器测试
3. 禁用浏览器扩展后再测
4. 检查是否启用 IPv6
5. 对比 DNS 泄露测试结果
6. 查看 WebRTC candidate 是否包含 srflx、host、relay

如果切换到更完整的系统接管模式后结果正常，说明原模式没有覆盖 WebRTC 路径。

二十、常见故障案例二：WebRTC 没有结果

现象：

WebRTC 测试一直等待，或者所有 STUN 检测失败。

可能原因：

  • 浏览器禁用了 WebRTC。
  • 网络拦截 UDP。
  • STUN 服务器不可达。
  • 企业网络策略阻断实时通信。
  • 安全软件拦截浏览器 UDP。

这时不能简单说“没有泄露”。因为检测失败可能是 WebRTC 被阻断，也可能是浏览器策略限制。

可以换一个浏览器、换一个网络，或者打开真实网页会议测试是否能正常建立连接。

二十一、常见故障案例三：只显示 mDNS

现象：

WebRTC 检测显示随机的 .local 或 mDNS 主机名。

这通常是现代浏览器的隐私保护策略，用 mDNS 主机名替代真实局域网 IP。

判断方式：

1. 看是否同时出现真实公网 IP
2. 看是否出现局域网 IP
3. 看 HTTP 出口是否符合预期
4. 看 DNS 泄露测试是否正常

如果只出现 mDNS，没有出现真实公网 IP 或局域网 IP，一般风险较低。但仍要结合代理出口、DNS 出口和业务需求判断。

二十二、WebRTC candidate 类型怎么看

常见 candidate 类型有：

类型含义排查价值
host本机本地候选地址可能涉及局域网 IP 或 mDNS
srflx通过 STUN 获得的公网映射地址可能暴露公网出口
relay通过 TURN 中继地址通常更可控，但延迟较高
prflx对端反射候选较少直接用于普通泄露检测

如果检测结果里出现 srflx，并且它不是你的代理或 VPN 出口，就要重点关注。

如果只出现 relay，说明 WebRTC 可能走了中继，隐私风险相对可控，但实时通信延迟可能上升。

二十三、一个完整排查流程

建议按下面步骤执行：

1. 记录当前网络环境：Wi-Fi、有线、公司网络、手机热点
2. 查询 HTTP 公网 IP
3. 打开 WebRTC 泄露测试页面
4. 记录 candidate、NAT、网络、地区
5. 做 DNS 泄露测试
6. 检查 IPv6 是否启用
7. 换浏览器对比
8. 关闭浏览器扩展对比
9. 切换代理模式或 TUN 模式对比
10. 清理浏览器缓存后重测
11. 记录每次结果，形成判断链

建议记录模板：

time,network,browser,mode,http_ip,webrtc_ip,candidate_type,nat,dns_ok,ipv6,note
10:00,home-wifi,Chrome,direct,local,local,srflx,cone,false,true,baseline
10:10,home-wifi,Chrome,proxy,node,local,srflx,cone,false,true,leak
10:20,home-wifi,Firefox,proxy,node,node,srflx,cone,true,false,expected

有了记录以后，就能把“感觉可能泄露”变成“哪种浏览器、哪种模式、哪种网络下出现了什么候选地址”。

二十四、什么时候可以认为 WebRTC 泄露风险较低

可以参考下面标准：

1. HTTP 出口符合预期
2. WebRTC candidate 没有出现本地真实公网 IP
3. 没有直接暴露局域网 IP
4. mDNS 只作为本地候选保护形式出现
5. DNS 泄露测试也符合预期
6. IPv6 没有单独绕过
7. 不同浏览器测试结果差异可解释
8. 切换网络后结果仍稳定

满足这些条件，WebRTC 泄露风险相对较低。

但如果你的使用场景高度依赖浏览器会议、在线语音或远程协作，不建议简单关闭 WebRTC。更好的做法是调整浏览器隐私策略和网络接管方式，让实时功能和隐私保护之间取得平衡。

二十五、WebRTC 泄露测试和网络工具箱的关系

一个完整的浏览器网络体检，通常不只测 WebRTC。

更建议按组合方式检查：

IP 查询：看 HTTP 出口
DNS 泄露：看域名解析出口
WebRTC 泄露：看实时通信候选地址
端口检测：看目标服务连通性
路由追踪：看链路路径
HTTP 状态：看应用响应

这些检测组合在一起，才能更接近真实网络行为。

稳如狗网络把 WebRTC 泄露检测放进网络工具箱，本质上是为了让用户能从浏览器层面观察代理、VPN、加速节点和本机网络之间是否一致。如果你在使用网页会议、在线语音、海外协作平台或浏览器代理，建议把 WebRTC 检测加入日常排障流程。

二十六、总结

WebRTC 泄露测试关注的是浏览器实时通信路径，而不是普通网页访问路径。IP 查询正常，并不代表 WebRTC 一定没有暴露本地地址；DNS 泄露正常，也不代表 WebRTC candidate 一定安全。

排查时不要只看一个结果。建议同时记录 HTTP 出口、DNS 出口、WebRTC candidate、IPv6、浏览器设置、代理模式和网络环境。尤其是在不同浏览器之间对比时，要把 mDNS、host、srflx、relay 等 candidate 类型一起看。

真正有效的网络隐私排查，应该像排查延迟、丢包和路由一样，形成可复现的数据链：先测基线，再切换模式，再对比结果。稳如狗网络提供的这类工具，适合帮助用户把隐藏在浏览器底层的连接行为显性化，减少“明明 IP 正常，为什么还是有泄露风险”的困惑。

参考资料

  1. WebRTC 泄漏检测工具页面：https://wenrugou.net/tools/webrtc-leak-test
  2. 稳如狗网络工具箱：https://www.wenrugou.net/tools
  3. WebRTC 官方项目文档：https://webrtc.org/
  4. MDN WebRTC API 文档：https://developer.mozilla.org/docs/Web/API/WebRTC_API
# webrtc # tcp/ip # 服务器 # 网络 # 网络协议 # 安全 # 性能优化
Logo
火山引擎视频云技术社区

邀请您加入社区

更多推荐

Stagewise + Remotion 视频配音实战：用 ElevenLabs 逐场景生成语音并动态对齐画面时长

> 本文基于仓库内 [create-remotion-video 技能](https://link.gitcode.com/i/1dcbae309c34a2dfa32d905717d19b85) 中内置的配音规则文档 [voiceover.md](https://link.gitcode.com/i/1d2dca6455f0c22dd7ffb7d71df6ccfe) 展开。该技能是 Stagewi

avatar 火山引擎视频云技术社区

answer-me-with-html：用 ElevenLabs 为解释视频配音——环境变量、语音模型选择、缓存机制与报错排查

`am video` 可以把 Markdown 稿件渲染成带旁白的解释视频，而 ElevenLabs 是它可选的云端配音后端：只要设置了 `ELEVENLABS_API_KEY`，旁白就会自动交给 ElevenLabs 合成；没有 key 时则回退到系统语音，因此整套配置是可选项。本文覆盖 ElevenLabs 接入的完整流程——创建最小权限 API key、三个环境变量（`ELEVENLABS_

avatar 火山引擎视频云技术社区

[流媒体开发】H264/AAC封装格式、ADTS头、SPS/PPS、RTP打包全解

在做流媒体服务器（RTMP/RTSP/HLS 互转）时，封装格式是最容易踩坑的地方。很多同学能跑通 Demo，但一遇到花屏、音画不同步、SPS/PPS 丢失就抓瞎。本文从底层字节讲起，覆盖：H264 的 NALU 结构与两种封装（Annex-B / AVCC）AAC 的三种格式（raw / ADTS / ASC）ADTS 头 7 字节逐位分析SPS/PPS 的作用与传输RTP 封包完整实现（H26

avatar 火山引擎视频云技术社区