要在比特浏览器环境里测 WebRTC 泄露，实操起来最好把“浏览器内部脚本检测”、“网络抓包确认”和“不同网络/代理场景复测”这三步结合：在控制台用 RTCPeerConnection 抓取 ICE candidate、注意 mDNS 和 IPv6 类型的候选项、在开/关 VPN、代理和 IPv6 的情况下重复，再用 Wireshark/tcpdump 验证真实出网包，最终把这些步骤用比特浏览器的自动化工具批量化，便于对多账号、多指纹环境做覆盖式检测。
先把概念说清楚：什么是 WebRTC 泄露？
WebRTC（Web 实时通信）让浏览器可以直接进行音视频通话和数据通道通信。为了建立端到端连接，浏览器会收集本机可用的“候选地址”（ICE candidates），这些候选项会暴露出本地网卡地址、路由器外网 IP（通过 STUN）以及有时的 IPv6 地址或 mDNS 名称。这些信息如果被页面脚本读走或被信令服务器转发，就会成为所谓的“WebRTC 泄露”：在你以为在用 VPN 或代理隐藏真实 IP 时，网页仍可能通过 WebRTC 直接获知你的局域网或公网地址。
常见的泄露类型
- Host（本地地址）：直接来自本机网卡（如 192.168.x.x、10.x.x.x 或本地 IPv6）。
- Server-reflexive（srflx）：通过 STUN 服务器得到的公网地址（也就是外网可见的 IP）。
- Relay（TURN）：通过中继服务器发送的地址，通常不会泄露真实本地 IP，但依赖 TURN 配置。
- mDNS：浏览器把本地地址以本地域名（如 host-xxx.local）形式提供，作为防止直接泄露的一种机制，但名称也能指示设备或被解析泄露。
为什么特别在比特浏览器里做这个测试？
比特浏览器强调“模拟设备指纹并为账号构建独立环境”，这意味着常常会在同一台机器上创建多个隔离的浏览器环境并与第三方网络（VPN、代理等）配合。如果某个环境的 WebRTC 配置或系统网络策略允许泄露真实 IP，单靠指纹隔离就无法避免关联风险。因此在比特浏览器中做 WebRTC 泄露测试，既是隐私防护的基石，也是验证隔离/代理策略是否有效的必要步骤。
实操：一步步检测 WebRTC 泄露（费曼式分解）
把复杂问题拆成最小可执行的步骤：先“观察”——看浏览器报告了什么地址；再“验证”——看网络层是否真的把地址发出；最后“重复”——在不同网络/代理/指纹下跑同样步骤，确保覆盖。
第一步：在控制台里用 JavaScript 快速检测（观察）
最直接的办法是在浏览器控制台执行一段脚本，创建 RTCPeerConnection 并打印 ICE 候选项与解析出的 IP。下面这段脚本是常用模板（可直接粘贴到控制台）：
const ips = new Set();
const pc = new RTCPeerConnection({iceServers:[]});
pc.createDataChannel('');
pc.onicecandidate = e => {
if (!e.candidate) {
console.log('全部候选项收集完毕，发现 IP：', Array.from(ips));
pc.close();
return;
}
const c = e.candidate.candidate;
console.log('原始 candidate:', c);
// 提取 IP 的简单正则（支持 IPv4/IPv6）
const re = /([0-9]{1,3}(?:\.[0-9]{1,3}){3}|[0-9a-fA-F:]{2,})/g;
let m;
while ((m = re.exec(c)) !== null) {
const ip = m[1];
// 过滤掉端口和其它非 IP 字段（视情况改进）
if (ip && !ip.includes('3000') && !ip.includes('typ') ) ips.add(ip);
}
};
pc.createOffer().then(sdp => pc.setLocalDescription(sdp)).catch(console.error);
运行结果会显示原始 candidate 字符串（可看到 typ=host/srflx/relay, 以及可能的 .local 名称或 IPv6），以及解析出的 IP 列表。注意：不同浏览器、不同版本输出会有差异。
第二步：观察 mDNS（是否为 .local 候选）
现代 Chromium/Firefox 引入 mDNS 隐私机制，会把本地地址换成类似 host-abcdef.local 的名称。脚本里如果看到 .local 字样或非典型 IP 字段，说明浏览器做了 mDNS 保护；不过这并不总等于“没有泄露”，因为名称可能被进一步解析或用来指纹。
第三步：用网络抓包验证（验证）
控制台输出只能说明浏览器“告诉”页面了哪些候选，真正要确认“信息是否出网”必须抓包。常用工具是 Wireshark（图形）或 tcpdump（命令行）。
- 抓包前确保你在做测试时仅运行目标浏览器实例，便于过滤。
- Wireshark 常用过滤器：stun（识别 STUN 协议）、或按端口过滤如 udp.port == 3478 || udp.port == 5349（常见 STUN/TURN 端口），也可用 ip.addr == 你的IP 来查找。
- tcpdump 例子：
sudo tcpdump -i any -n udp and port 3478，或更宽泛地捕获所有 UDP：sudo tcpdump -i any -n udp。
在抓到的 STUN 报文中查看源/目标地址，就能确认浏览器是否发出了含有你的本地或公网地址的包。一个常见现象是：即便你启用了 HTTP 代理，有些浏览器会直接用 UDP 向 STUN 服务器发送探测，从而绕过代理或 VPN 的 TCP 隧道。
第四步：用不同网络/代理/VPN 进行对比（重复）
如果只在一种网络下测到“无泄露”，并不代表在所有场景都安全。应至少在以下几种配置下重复前面步骤：
- 本机直连（无 VPN/代理）。
- 系统级 VPN（注意分为支持/不支持 UDP）。
- HTTP/HTTPS 代理或 SOCKS 代理（浏览器设置的代理）。
- IPv6 可用与不可用的场景（强制禁用或启用 IPv6）。
- 移动热点、不同 Wi‑Fi 子网等网络拓扑变化。
这样可以发现：某些 VPN 在只做 TCP 隧道时，WebRTC 可能仍通过 UDP 发出，导致 srflx（服务器反射）或 host 类型信息泄露。
把检测放到自动化流程：用比特浏览器的 RPA 做批量化
比特浏览器内置拖拽式 RPA 自动化工具时常被用来批量操作者账号/环境。把检测步骤自动化，可以大幅提高覆盖率。一个可行的简单流程：
- 新建一个测试环境/指纹配置（或多个，代表不同账号），并设置对应代理/VPN 配置。
- 打开目标测试页面或空白页，触发浏览器控制台脚本（通过 RPA 模拟粘贴并回车，或插入脚本运行）。
- 等待候选收集完成并把控制台输出保存为日志文件。
- 同时在本地启动 tcpdump（或通过远程采集），把抓包文件保存并与脚本输出配对。
- 解析日志：提取 candidate/IP，和抓包中的实际外发地址比对，生成报告。
用 RPA 的优点是能在上百个账号/指纹/网络组合上夜间跑完，人工无法做到如此规模的覆盖。
哪些测试结果说明存在风险？怎么解读输出？
- 控制台出现本地 RFC1918 地址（192.168.x.x、10.x.x.x）或真实 IPv6：如果这些地址被页面脚本读取并发送回服务器，就构成本地地址泄露。
- 出现 srflx 地址而 VPN/代理未隐藏公网 IP：说明 STUN 请求经过未被 VPN 拦截或 VPN 不处理 UDP，公网地址被探测到。
- 只有 relay 地址且流量全部走 TURN：这是比较安全的场景（媒体通过中继），但会依赖中继服务器可信度和费用。
- 控制台显示 mDNS 名称：浏览器已启用 mDNS 防护，但仍需关注名称是否可被外部解析或用于指纹识别。
补救措施与防护建议（实用清单）
发现泄露不必恐慌，常见的可行手段有：
- 启用浏览器的 mDNS/隐藏本地 IP 功能：现代浏览器有选项或 flag 来隐匿本地 IP（对于基于 Chromium 的浏览器可搜索 webrtc mDNS 设置）。
- 在不需要时禁用 WebRTC：可以用扩展或浏览器设置屏蔽，但会影响音视频功能。
- 使用可靠的 VPN 或 TURN 中继：确保媒体流走中继（relay），而不是直连；选择能处理 UDP 的 VPN 能降低 srflx 泄露机会。
- 系统/网络层面屏蔽 STUN/UDP：通过防火墙或路由规则限制 UDP 到常见 STUN 端口，但可能导致 WebRTC 连接失败或强制使用 TURN。
- 对自动化脚本和 RPA 做安全校验：避免把测试脚本或日志上传到不可信的位置，防止检测数据泄露。
一个对照表：检测方法优缺点一览
| 方法 | 能发现 | 难度 | 精确度 |
| 控制台 JS（RTCPeerConnection） | 列出浏览器提供的 candidate（host/srflx/relay/mDNS） | 低（几行脚本） | 高（能看到浏览器层面暴露） |
| 在线检测页 | 快速查看常见泄露结果 | 低 | 中等（依赖第三方页面） |
| 网络抓包（Wireshark/tcpdump） | 确认实际出网包，验证是否真的泄露 | 中等到高（需要抓包/分析技能） | 最高（网络层面证据） |
| RPA 批量自动化 | 规模化覆盖多指纹/账号/网络组合 | 中等（需搭流程） | 高（可验证重复性） |
常见误区与答疑（像跟朋友解释的方式）
- “只要用 VPN 就万无一失”：不全对。若 VPN 不处理 UDP，或浏览器直接向 STUN 服务器发包，公网地址可能还是会被探测到。
- “看到 .local 就没事”：mDNS 是保护措施，但并不代表没有风险，名字本身可能暴露设备类型或与本地 DNS 交互导致信息泄露。
- “抓不到包就代表没泄露”：抓包需在正确的接口和时间段进行，错误的过滤或抓取位置（例如抓到 VPN 隧道内而非出口）可能导致误判。
实践小贴士（省时间也更准）
- 在做抓包时同时保存控制台脚本输出和抓包时间戳，便于对照哪个候选对应哪个网络包。
- 如果测试多个账号/指纹，先在一个“基线环境”跑全套检查，然后再针对变体做对比，能迅速定位是哪个改动触发泄露。
- 写脚本提取 candidate 时，多考虑 IPv6 格式和 mDNS 形式，避免误判或漏检。
行吧，就写到这儿。做完这些操作你基本能判断比特浏览器的某个环境是否会通过 WebRTC 把真实地址透露出去；把检测脚本、抓包与自动化结合起来，既有即时观察也有网络层面的铁证，最后再在多网络场景下重复验证，风险点就能被一点点排查干净。若想，我可以给你把控制台检测脚本整理成更健壮的版本，或者帮你设计一个 RPA 流程的示意步骤，来跑几百个指纹组合的批量检测。