ZH当浏览器暴露您希望 VPN、代理或隐私设置隐藏的网络地址信息时，就会发生 WebRTC 泄露。 最明显的例子是您的 ISP 公共 IP 出现，而不是您计划使用的 VPN 或代理 IP。
WebRTC 本身并不是一个有害的功能。 它支持视频通话、语音聊天、屏幕共享和浏览器中的实时数据。 隐私问题来自于它寻找工作网络路径的方式。
简单来说，WebRTC 泄露意味着浏览器在准备实时连接时显示了意外的地址。
什么是 WebRTC 泄露？
泄漏这个词需要上下文。 网站通常会看到用于加载页面的公共 IP。 WebRTC 测试也可能显示相同的地址。 如果两个结果都指向您选择的 VPN 或代理，则可能根本没有泄漏。
当 WebRTC 显示预期路线之外的地址时，问题就开始了。 您可能会在正常的 IP 检查中看到 VPN IP，然后在 WebRTC 结果中找到您的家庭 ISP IP。 您还可能会发现第一次测试遗漏的暴露的 IPv6 地址。
我不会将泄漏检查器上的每一行都视为失败。 我寻找当前设置要隐藏的地址。
当IP暴露变成泄密时
假设您的常用 ISP 地址位于伦敦。 您连接到纽约的代理。 标准 IP 检查器现在显示纽约代理。 该部分按预期工作。
然后运行 WebRTC 测试。 如果它还显示纽约地址，则网络信号一致。 如果它也显示原始的伦敦 ISP 地址，则浏览器暴露了意外的路径。
同样的逻辑也适用于 VPN。 它也适用于 IPv6。 如果单独的 IPv6 地址仍然指向原始网络，则受保护的 IPv4 路由不会有太大帮助。
为什么 WebRTC 需要网络地址
实时通信需要两个端点之间的路径。 这条路可能是直接的。 它可以通过 NAT 设备。 当无法建立直接连接时，可能需要中继。
WebRTC 收集可能的路线，以便选择一条有效的路线。 这有助于更快地启动呼叫并减少延迟。 这也意味着 Web 应用程序可以比普通页面请求了解更多有关网络的信息。
此过程独立于摄像头和麦克风访问。 页面可以创建对等连接或数据通道并开始收集候选连接。 访问媒体设备仍需要相关浏览器权限。
WebRTC 泄露是如何发生的？
该过程从RTCPeerConnection开始。 Web 应用程序在需要实时连接时创建此对象。 然后，浏览器使用交互式连接建立（通常称为 ICE）来收集可能的连接候选者。
这些候选人描述了这种联系可能发挥作用的方式。 Web应用程序可以读取候选人信息并通过其信令系统与远端共享。
如果浏览器包含本应保留在 VPN 或代理后面的 ISP 地址，则应用程序可能会看到它。 分割隧道、额外的网络接口、不受保护的 IPv6 路由或仍允许 WebRTC 在预期路径之外进行连接的浏览器代理可能会发生这种情况。
ICE候选人聚会
该流程有五个步骤：
- 页面创建
RTCPeerConnection。 - ICE 代理检查可用的连接路径。
- 浏览器收集主机、STUN 派生或 TURN 中继候选者。
- 该应用程序接收允许其查看的候选人。
- ICE 测试候选对并选择工作路径。
ICE 不是服务器。 它是用于查找和测试连接选项的过程。 STUN 和 TURN 以不同的方式支持该过程。
主持人、STUN 和 TURN 候选者
每种候选类型都揭示了连接的不同部分。
| 候选人类型 | 它来自哪里 | 它可能揭示什么 |
|---|---|---|
| 主持人 | 本地网络接口 | 本地 IP 或 mDNS 名称 |
| 服务器自反 | 通过 STUN 学习的面向公众的地址 | 用于访问 STUN 服务器的公共 IP |
| 中继 | TURN 服务器提供的地址 | 中继服务器地址而不是直接端点地址 |
TURN 中继可以使直接端点地址远离远程对等点。 它还将另一个服务器添加到路径中。 这会增加延迟、带宽成本以及对中继的操作依赖性。
当 VPN 或代理暴露意外路径时
VPN 和代理不应被视为同一工具。 全隧道 VPN 可以路由广泛的设备流量，并使用防火墙规则阻止隧道外的流量。 分割隧道 VPN 允许选定的流量使用另一条路由。
浏览器代理通常处理一个浏览器或配置文件的 Web 请求。 它可能无法控制每个 WebRTC 路径。 SOCKS5可以支持UDP，但实际的WebRTC路由仍然取决于浏览器及其配置。
代理、VPN 和反检测浏览器 控制不同的层。 代理路由选定的流量。 VPN 可以管理更广泛的加密隧道。 反检测浏览器管理浏览器配置文件和浏览器端信号。 其中之一不会自动取代其他。
WebRTC 可以暴露哪些信息？
大多数测试页显示多个字段。 这些标签看起来可能令人震惊，尤其是当本地地址和公共地址同时出现时。 它有助于单独判断每种类型。
公共IP地址
公共 IP 在互联网上可见。 它可以指示 ISP、ASN、大致位置以及所使用的网络类型。
当 VPN 或代理处于活动状态时，最重要的警告是基线 ISP 公共 IP 的出现。 这可以是 IPv4 地址、IPv6 地址或两者。
IP地址本身通常不会显示确切的家庭地址。 它仍然是有用的网络信息。 它还可能与预期退出 IP 显示的位置和提供商发生冲突。
本地 IP 地址和 mDNS 名称
本地地址通常以 192.168 或 10 等范围开头。 这些地址在许多专用网络中重复使用。 本地 IP 地址通常比公共 ISP 地址更不那么暴露。
这并不会使本地信息变得毫无意义。 它可能会揭示部分网络布局。 本地接口的稳定组合还可以在比较会话时添加另一个信号。
现代浏览器通常将本地主机地址隐藏在随机 .local mDNS 名称后面。 看到该名称并不意味着您的 ISP 公共 IP 已泄露。 这意味着浏览器正在避免直接暴露本地地址。 它也不会删除所有可能的 WebRTC 信号。
IPv6 和多个网络接口
许多人检查 IPv4 并就此止步。 这很容易理解。 IPv4 仍然是大多数用户认可的地址。
IPv6 需要自己的检查。 VPN 可以正确处理 IPv4，而其他配置则使 IPv6 可见。 Wi-Fi、以太网、虚拟适配器和 VPN 接口也可以创建多个候选者。
结果因浏览器、操作系统、网络和隐私政策而异。 对您使用的设置进行实时测试可以告诉您的不仅仅是一般浏览器列表。
如何测试 WebRTC 泄露
干净的测试从基线开始。 如果没有它，您可能会看到多个地址，并且没有可靠的方法来知道哪一个属于原始连接。
分步WebRTC 泄露测试
- 断开 VPN 或代理。
- 记录当前的公共 IPv4 和 IPv6 地址。
- 关闭测试页面。
- 连接 VPN 或代理，或启动您要检查的浏览器配置文件。
- 使用普通的 IP 检查器来确认预期的退出 IP。
- 打开特定于 WebRTC 的检查器。
- 将公共、本地、mDNS、IPv6 和中继结果与基线进行比较。
- 更改相关设置并再次测试是否出现原来的ISP地址。
浏览器控件随着时间的推移而变化。 仔细的 WebRTC 泄露测试 比旧的所谓安全设置列表更重要。
如何读取测试结果
| 测试结果 | 一般解释 |
|---|---|
| WebRTC公共IP与VPN或代理IP匹配 | 结果通常遵循预期的路线 |
| 基线 ISP 公共 IP 出现 | 有一个重要的 WebRTC 泄露 |
出现随机的 .local 名称 | 本地主机地址通过 mDNS 隐藏 |
| 仅出现 TURN 继电器地址 | 连接正在使用中继候选者 |
| WebRTC 不可用 | WebRTC被禁用或受限，因此相关功能可能会失败 |
MoreLogin 的一项 BrowserLeaks 测试检查了同一配置文件中的 IP、WebRTC、时区、语言、Canvas、WebGL 和字体。
这是对一种配置的一项测试。 不应将其视为对每个浏览器版本、设备、代理或配置文件的承诺。
为什么一次通过检测不代表永久有效
绿色的结果让人感到安心。 我仍然不会将其视为永不过期的证书。
任何可能影响浏览器或网络的更改后再次测试：
- 浏览器更新
- 新的 VPN 服务器或代理
- 扩展名更改
- 一个新的网络
- IPv6 已启用
- 新的浏览器配置文件
- 不同的 WebRTC 策略
泄漏测试是一个浏览器、网络和配置的快照。 这足以做出有用的决定。 它不是永久的隐私保证。
如何防止或修复 WebRTC 泄露
没有一个解决方案适合所有浏览器和每个工作流程。 正确的选择取决于 WebRTC 功能是否需要保持可用。
使用具有经过测试的泄漏保护功能的 VPN
系统级 VPN 可以通过路由和防火墙规则保护 WebRTC 流量。 检查分割隧道是否处于活动状态。 还要检查 IPv6。 然后运行测试，而不是信任应用程序中的连接状态。
VPN 品牌比您实际使用的设备和浏览器上观察到的结果更重要。
限制非代理流量或使用仅中继的 WebRTC
另一种选择是阻止 WebRTC 使用代理外部的路径。 某些控件会阻止非代理 UDP。 其他人强制流量通过配置的代理。
如果 UDP 无法使用该路由，WebRTC 可能会回退到 TCP 或 TURN。 也可能会失败。 结果取决于实施。
仅中继 WebRTC 使用 TURN 候选者。 它可以使直接候选人远离远程对等方，同时保持实时通信。 代价是更多的延迟、更多的中继流量以及对 TURN 可用性的更强依赖。
更改浏览器设置或使用扩展程序
Firefox 提供了可以限制或禁用 WebRTC 的高级首选项。 基于 Chromium 的浏览器通常依赖于扩展、企业策略或浏览器级网络控制。
扩展可以提供帮助。 他们也需要照顾。 浏览器更新后，过时的扩展可能会停止工作。 它可能会请求广泛的权限。 它在不同浏览器版本之间的行为也可能有所不同。
如果您使用其中一个，请选择一个已维护的源并再次测试结果。 工具栏中的图标不是证据。 网络结果是。
使用每个配置文件的 WebRTC 控件
当多个配置文件使用不同的代理或网络位置时，全局设置会变得很尴尬。 每个配置文件都需要明确的代理分配和适合任务的 WebRTC 策略。
配置文件尚未准备好，只是因为其代理已连接。 在 MoreLogin 中配置代理 后，确认可见 IP 并运行单独的 WebRTC 检查。
MoreLogin 浏览器配置文件 API 文档 列出了隐私、替换、真实、禁用和转发作为每个配置文件的 WebRTC 选项。 它没有完全解释每种模式如何处理主机、STUN、TURN、UDP、IPv4 和 IPv6 候选者。
仅有模式标签是不够的。 验证当前产品版本中所选的行为。
您应该禁用 WebRTC 吗？
禁用WebRTC可以关闭这个地址暴露路径。 它也是最有可能影响正常浏览器功能的选项。
禁用 WebRTC 可以防止什么
当 RTCPeerConnection 不可用时，页面无法使用该 API 来收集相同的连接候选者。 这可以防止基于 WebRTC 的 IP 泄漏。
它并不能阻止 DNS 泄漏。 它不会隐藏浏览器指纹。 它不会删除 cookie 或帐户数据。
什么可能会停止工作
网站可能会失去依赖于 WebRTC 的功能，包括：
- 浏览器视频通话
- 语音聊天
- 屏幕共享
- 点对点文件传输
- 实时支持和协作小部件
某些服务可能会提供另一条路线。 其他人可能会失败或失去质量。
禁用、限制或中继
| 方法 | WebRTC 功能 | 隐私控制 | 主要权衡 |
|---|---|---|---|
| 禁用 | 通常不可用 | 强力对抗这种泄漏路径 | 兼容性最低 |
| 限制或强制代理 | 通常仍然可用 | 取决于实施 | 需要仔细设置和重新测试 |
| 仅中继 | 通过 TURN 仍然可用 | 避免直接候选人 | 增加了延迟、成本和中继依赖性 |
当配置文件不需要实时通信时，禁用 WebRTC。 当功能需要保持可用并且可以验证网络路径时，限制或中继它。
WebRTC 泄露与 DNS 泄漏
WebRTC 和 DNS 泄漏很容易混淆，因为两者都会削弱隐私设置。 他们暴露了不同的信息。
| WebRTC 泄露 | DNS 泄漏 |
|---|---|
| 通过 ICE 候选暴露意外的网络地址 | 将 DNS 查询发送到意外的解析器 |
| 通过特定于 WebRTC 的测试进行检查 | 通过 DNS 泄漏测试进行检查 |
| 通过 WebRTC 策略、路由、代理、UDP 控制或 TURN 进行修复 | 通过 DNS 路由、解析器和 VPN 设置进行修复 |
两者可以同时发生。 修复一个并不能证明另一个已经消失。
WebRTC 泄露和孤立的浏览器配置文件
网络身份和浏览器身份位于不同的层。 当配置文件随着时间的推移被重复使用时，这种区别就变得很重要。
代理或 VPN 控制网络路由。 WebRTC 策略控制如何公开或中继候选连接。 浏览器配置文件保存 cookie、本地存储、浏览器设置和其他信号。
WebRTC 信息可以与浏览器版本、时区、字体、Canvas 输出和 WebGL 行为一起成为更广泛的 浏览器指纹 的一部分。
保持每个配置文件的网络信号一致
在使用配置文件之前，请检查应符合的部分：
- 预期的代理或 VPN 公共 IP
- WebRTC 公共 IP
- IPv6暴露
- 本地 IP 或 mDNS 行为
- 时区和地理位置
- 浏览器语言
一致性并不会使配置文件变得不可见。 它确实减少了可避免的不匹配并使问题更容易诊断。
在重要工作之前验证个人资料
当正常的 IP 检查看起来正确时，人们很容易停下来。 几天后发现泄漏是令人沮丧的，而且更难以解决。
在 MoreLogin 中，多帐户浏览器配置文件 将代理设置、WebRTC 配置、Cookie、存储和其他浏览器信号保存在一个可重用的环境中。 这使得设置更容易检查。 结果仍然取决于所选的设置、网络和代理。
在使用新配置文件之前对其进行测试。 当代理、浏览器版本或WebRTC策略发生变化时再次测试。
要点
- WebRTC 泄露是意外的网络地址暴露，而不是测试中出现任何 IP。
- ICE 可以收集主机、STUN 衍生的和 TURN 中继候选者。
- 有用的测试将基线 ISP IP 与 VPN、代理或配置文件结果进行比较。
- 禁用、限制、代理和仅中继 WebRTC 具有不同的隐私和兼容性权衡。
WebRTC 泄露常见问题解答
WebRTC 是否总是泄露您的真实IP地址？
不。 结果取决于浏览器、网络、VPN 或代理路由、IPv6 配置和 WebRTC 策略。 正确路由的设置可能仅显示 VPN 或代理 IP。 仅中继设置可能会显示 TURN 地址。
WebRTC 可以绕过 VPN 或代理吗？
当允许浏览器使用另一个网络路径时，它可以公开额外的地址。 分割隧道、不受保护的 IPv6 路由或不控制 WebRTC 流量的浏览器代理可能会导致此结果。
本地IP地址是否是WebRTC 泄露？
是本地网络信息暴露。 它通常不如透露 ISP 公共 IP 直接。 它的值取决于地址、其稳定性、存在的其他接口以及信息组合的方式。
.local 地址在 WebRTC 测试中意味着什么？
随机 .local 地址通常是 mDNS 主机名。 现代浏览器使用它来避免直接显示本地主机IP。 这并不意味着 ISP 公共 IP 已泄露。
网站可以在没有相机许可的情况下检查WebRTC吗？
页面可以创建对等连接或数据通道并触发 ICE 候选者收集。 摄像头和麦克风访问仍需要相关媒体许可。
禁用 WebRTC 会破坏网站吗？
它可能会影响视频通话、语音聊天、屏幕共享、文件传输和其他实时功能。 有些网站可能会提供后备方案。 其他人可能会失去功能或工作质量下降。
我应该多久测试一次 WebRTC 泄漏？
更改浏览器、VPN、代理、扩展、网络、IPv6 设置、浏览器配置文件或 WebRTC 策略后进行测试。 快速重新测试可以捕获在没有明显警告的情况下发生变化的路线。
保持 WebRTC 和代理设置井井有条
当 WebRTC 保护被视为整个配置文件设置的一部分时，其效果最佳。 代理、可见 IP、IPv6 路由、时区、语言和 WebRTC 策略应该一起有意义。
免费尝试MoreLogin 创建可重复使用的浏览器配置文件，分别配置网络和浏览器设置，并在使用前验证每个环境。
