WebRTC IP 泄漏：什么是 WebRTC 泄漏以及如何防护

简介

WebRTC 是一种浏览器技术，支持实时通信：视频通话、语音聊天、点对点文件共享。为建立这些连接，浏览器使用 ICE（交互式连接建立）协议，收集网络接口地址并与对等方交换。问题在于 ICE 收集你的真实 IP 地址，包括本地网络 IP 和公共 IP，并通过 JavaScript 使它们可用。这发生在正常的 HTTP 代理路径之外，意味着仅靠代理无法保护你。

BotBrowser 在浏览器引擎级别控制 WebRTC ICE 行为。BotBrowser 不是完全禁用 WebRTC（这本身是可检测的信号），而是确保 ICE 候选只包含与你的代理身份一致的 IP 地址。

隐私影响

WebRTC IP 泄漏是浏览器技术中最知名的隐私漏洞之一。当网页发起 WebRTC 对等连接时，浏览器从每个可用的网络接口收集 ICE 候选。这些候选包含：

• 本地 IP 地址：你的机器在本地网络上的私有 IP（如 192.168.1.100）
• 公共 IP 地址：来自 STUN 服务器响应的你的真实公共 IP
• IPv6 地址：如果可用，你的完整 IPv6 地址

网站可以通过 RTCPeerConnection API 收集这些候选，无需任何用户交互或权限提示。即使你通过代理路由所有 HTTP 流量，WebRTC STUN 请求直接传输到 STUN 服务器，暴露你的真实公共 IP。

这创建了一条直接的去匿名化路径。看到你的代理 IP 在 HTTP 请求中但你的真实 IP 在 WebRTC 候选中的追踪系统，清楚地知道发生了什么。不一致本身就是强信号。

技术背景

ICE 候选收集工作原理

当 JavaScript 创建 RTCPeerConnection 时，浏览器开始收集 ICE 候选。此过程涉及：

1. 主机候选：浏览器枚举本地网络接口并收集其 IP 地址。这些成为"host"候选。

2. 服务器反射候选：浏览器向配置的 STUN 服务器发送 STUN 绑定请求。STUN 服务器用它观察到的公共 IP 地址响应，创建"srflx"候选。

3. 中继候选：如果配置了 TURN 服务器，浏览器通过它们建立中继路径，创建"relay"候选。

每种候选类型暴露不同的网络信息。主机候选揭示本地 IP。服务器反射候选揭示公共 IP。三者的组合提供了你网络拓扑的详细映射。

为什么扩展无法完全解决这个问题

试图控制 WebRTC 的浏览器扩展有根本性的局限：

• 完全禁用 WebRTC 防止 ICE 收集但创建可检测的指纹。网站可以检查 RTCPeerConnection 的缺失并标记它。
• 阻止 STUN 请求可能遗漏在扩展加载前或从 service workers 发起的请求。
• 通过 JavaScript 猴子补丁修改 ICE 候选是脆弱的。真实候选在原生代码中生成，在 JavaScript 有机会拦截之前。

引擎级控制是唯一能在源头修改 ICE 候选生成的方法，在页面上任何 JavaScript 可以观察到原始值之前。

常见方法及其局限性

在浏览器设置中禁用 WebRTC

一些浏览器允许通过标志禁用 WebRTC。这阻止了所有 ICE 收集，但也破坏了合法的 WebRTC 功能如视频会议。更重要的是，WebRTC API 的缺失是独特的指纹信号。缺少 RTCPeerConnection 的浏览器会引人注目。

WebRTC 控制扩展

像 WebRTC Leak Prevent 或 uBlock Origin 这样的扩展可以限制 WebRTC 到某些 IP 范围。然而，扩展在浏览器引擎已经收集候选之后的 JavaScript 层操作。它们可以拦截 onicecandidate 回调，但原始候选存在于内存中。一些扩展方法也创建可检测的副作用。

VPN 级保护

VPN 路由所有系统流量，包括 STUN 请求，通过 VPN 隧道。这防止 STUN 服务器看到你的真实 IP。然而，VPN 不控制本地（主机）ICE 候选。你的本地网络 IP（如 192.168.x.x）仍然被收集和暴露。

BotBrowser 的引擎级方法

BotBrowser 在 Chromium 网络栈内修改 ICE 候选生成。这与上述所有方法有根本不同：

• WebRTC 保持完全功能。RTCPeerConnection 存在且正常工作。
• ICE 候选从一开始就使用受控的 IP 信息生成。
• WebRTC 对象上没有 JavaScript 可见的修改。
• STUN/TURN 行为在网络层控制，而不是事后拦截。

BotBrowser 的方法

--bot-webrtc-ice 标志

BotBrowser 的 --bot-webrtc-ice 标志（ENT Tier1）控制使用哪些 ICE 服务器以及候选中出现什么 IP 信息：

# 使用 Google 的 STUN 服务器（预设）
chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-webrtc-ice="google"

# 使用自定义 STUN 和 TURN 服务器
chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-webrtc-ice="custom:stun:stun.example.com:3478,turn:turn.example.com:3478"

google 预设配置 stun:stun.l.google.com:19302，这是普通 Chrome 浏览器中最常见的 STUN 配置。

与代理协同工作

与 --proxy-server 结合时，BotBrowser 确保：

1. STUN 请求通过代理路由，所以 STUN 服务器看到代理的 IP
2. ICE 候选只包含代理 IP 作为公共地址
3. 本地网络 IP 不出现在主机候选中
4. WebRTC 指纹匹配该代理后正常用户会产生的

SOCKS5 UDP（ENT Tier3）

对于 ENT Tier3 用户，BotBrowser 支持 SOCKS5 UDP ASSOCIATE。当代理支持 UDP 时，这会自动将 QUIC 流量和 STUN 探测通过 SOCKS5 代理隧道：

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080"

不需要额外标志。如果 SOCKS5 代理支持 UDP ASSOCIATE，BotBrowser 自动通过它隧道 STUN 流量。

通过配置文件的 WebRTC 配置

WebRTC 行为也可以通过配置文件的配置控制：

# 使用配置文件定义的 WebRTC 设置
chrome --bot-profile="/path/to/profile.enc" \
       --bot-config-webrtc=profile

# 完全禁用 WebRTC（不建议为了一致性）
chrome --bot-profile="/path/to/profile.enc" \
       --bot-config-webrtc=disabled

配置和使用

完整隐私配置（CLI）

将 WebRTC 保护与代理、DNS 和指纹设置结合：

chrome --bot-profile="/path/to/profile.enc" \
       --proxy-server="socks5://user:pass@proxy:1080" \
       --bot-webrtc-ice="google" \
       --bot-local-dns \
       --bot-config-timezone="America/New_York" \
       --bot-config-locale="en-US"

Playwright 集成

const { chromium } = require('playwright-core');

(async () => {
  const browser = await chromium.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
      '--bot-webrtc-ice=google',
      '--bot-local-dns',
    ],
    headless: true,
  });

  const context = await browser.newContext();
  const page = await context.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

Puppeteer 集成

const puppeteer = require('puppeteer-core');

(async () => {
  const browser = await puppeteer.launch({
    executablePath: '/path/to/botbrowser/chrome',
    args: [
      '--bot-profile=/path/to/profile.enc',
      '--proxy-server=socks5://user:pass@proxy:1080',
      '--bot-webrtc-ice=google',
      '--bot-local-dns',
    ],
    headless: true,
    defaultViewport: null,
  });

  const page = await browser.newPage();
  await page.goto('https://example.com');
  await browser.close();
})();

验证

启动带有 WebRTC 保护的 BotBrowser 后：

1. 访问 WebRTC 泄漏测试网站（如 browserleaks.com/webrtc）
2. 检查 ICE 候选中没有出现本地 IP 地址（192.168.x.x、10.x.x.x）
3. 验证只有代理 IP 作为公共地址出现
4. 确认你的真实公共 IP 在任何候选中都不可见
5. 测试 WebRTC 功能仍然正常（API 应该存在且工作）

你也可以通过编程验证：

const candidates = await page.evaluate(() => {
  return new Promise((resolve) => {
    const ips = [];
    const pc = new RTCPeerConnection({
      iceServers: [{ urls: 'stun:stun.l.google.com:19302' }]
    });
    pc.createDataChannel('test');
    pc.onicecandidate = (e) => {
      if (e.candidate) {
        const match = e.candidate.candidate.match(/([0-9]{1,3}\.){3}[0-9]{1,3}/);
        if (match) ips.push(match[0]);
      } else {
        resolve(ips);
      }
    };
    pc.createOffer().then(o => pc.setLocalDescription(o));
  });
});
console.log('ICE candidate IPs:', candidates);

最佳实践

1. 始终将 --bot-webrtc-ice 与 --proxy-server 结合使用。 WebRTC 保护只有在通过代理路由流量时才有意义。没有代理，你的真实 IP 在 HTTP 请求中已经可见。

2. 除非有特定需求，否则使用 "google" 预设。 Google STUN 服务器是最常观察到的配置，产生最自然的 ICE 候选。

3. 添加 --bot-local-dns 以获得完整网络隐私。 WebRTC 和 DNS 是两个最常见的网络级泄漏路径。关闭两者确保全面保护。

4. 除非绝对必要，否则不要禁用 WebRTC。 禁用 WebRTC 创建可检测的指纹信号。BotBrowser 的受控方法保持 WebRTC 功能同时保护你的 IP。

5. 每次配置更改后测试。 WebRTC 行为取决于代理、ICE 服务器和网络配置之间的交互。更改后始终验证。

常见问题

BotBrowser 会破坏 WebRTC 视频通话吗？ 不会。WebRTC 保持完全功能。视频通话、语音聊天和点对点连接都正常工作。BotBrowser 只控制 ICE 候选中出现哪些 IP 地址。

--bot-webrtc-ice 和 --bot-config-webrtc 有什么区别？ --bot-webrtc-ice 标志控制 ICE 服务器配置和 IP 暴露。--bot-config-webrtc 标志控制 WebRTC 是使用配置文件设置、真实系统设置还是完全禁用。

如果使用 VPN，还需要 --bot-webrtc-ice 吗？ VPN 防止 STUN 服务器看到你的真实公共 IP，但本地主机候选可能仍然暴露。BotBrowser 对所有候选类型提供更完整的控制。

网站能检测到 ICE 候选被控制了吗？ BotBrowser 在引擎级别修改候选生成。ICE 候选看起来与使用该 IP 的代理后面的浏览器产生的完全相同。没有 JavaScript 可见的痕迹。

IPv6 通过 WebRTC 泄漏呢？ BotBrowser 控制 IPv4 和 IPv6 候选生成。你真实网络接口的 IPv6 地址不会出现在 ICE 候选中。

SOCKS5 UDP 需要特殊代理配置吗？ 代理必须支持 SOCKS5 UDP ASSOCIATE（RFC 1928）。BotBrowser 自动检测此能力。除了 --proxy-server 外不需要额外标志。

总结

WebRTC IP 泄漏是代理本身无法解决的重大隐私问题。BotBrowser 在浏览器引擎级别控制 ICE 候选生成，确保只有与代理一致的 IP 地址出现在 WebRTC 候选中，同时保持 WebRTC 完全功能。

完整的网络隐私配置请将 WebRTC 保护与代理配置和 DNS 泄漏防护结合。管理具有不同网络配置的多个身份请参阅多账户浏览器隔离。