WebRTC 泄漏：您的真实 IP 是否在代理背后暴露？
A WebRTC 泄漏 可能会暴露一个与普通 HTTP 流量所用 IP 不同的公网 IP 地址。这种不匹配通常涉及 UDP 流量：WebRTC 可能会通过与已配置代理不一致的路由发送 STUN 或 TURN 连接检测。
本指南将说明 WebRTC、UDP、STUN、TURN 和 HTTP/3 之间的关系、如何检查您的浏览器是否暴露了第二个公网 IP、如何解读结果，以及如何在不盲目禁用浏览器功能的前提下纠正路由不匹配问题。
快速答案： 在您计划使用的浏览器配置文件中连接代理，然后运行 NodeMaven Connection Checker。将 HTTP 出口与 WebRTC、STUN 和 TURN 结果进行对比。 公网 IP 不一致意味着浏览器、配置文件或网络路由存在问题，在进行位置敏感的数据采集、自动化或经授权的账号工作流之前，需要先排查解决。
普通的 IP 检测工具只能确认网站通过 HTTP 看到的地址。Connection Checker 还会测试浏览器上报的 WebRTC、服务器端观测到的基于 UDP 和 TCP的 STUN 与 TURN 路由，以及 HTTP/3 状态。
什么是 WebRTC 泄漏？
WebRTC 是一种浏览器技术，用于视频通话、语音通话、屏幕共享以及浏览器之间的直接连接。在连接建立之前，浏览器会检查它可以使用哪些网络路由。
这一过程可能暴露比普通页面请求更多的网络信息。网站可能通过 HTTP 看到代理 IP，而与 WebRTC 相关的连接却通过另一条独立路由暴露出另一个公网 IP。
浏览器如何暴露两个公网 IP 地址
在一致的配置下，页面请求和 WebRTC 相关流量都会经由所选代理发出：
Browser -> Proxy -> Website Browser -> Proxy -> STUN/TURN service
可能出现的路由不一致如下所示：
Browser -> Proxy -> Website Browser -> Local network -> STUN/TURN service
网站通过 HTTP 看到的是代理 IP，而 STUN 或 TURN 服务看到的却是本地网络的公网 IP。 这第二个公网地址就是潜在的泄漏点。
路由不一致并不自动意味着代理失效。浏览器、代理协议、操作系统、防火墙、网络策略以及防关联浏览器配置文件都可能影响路由。
STUN 和 TURN 的作用
STUN 帮助浏览器发现外部服务器所看到的公网 IP 地址和端口。STUN 服务器会记录接收到浏览器请求时的来源地址，并将其作为一条可能的连接路由返回。
TURN 在无法建立直接点对点连接时负责中继流量。TURN 中继可以观察到浏览器通过以下方式发起的连接： UDP 或 TCP.
浏览器报告的 WebRTC 候选地址与服务器观察到的地址可能不同。将两者进行比较，可以更全面地了解所测试的连接路径。
UDP、HTTP/3 与 WebRTC 代理泄漏
什么是 UDP？HTTP/3 如何使用它？
网页浏览器传统上通过 HTTP/1.1 或 HTTP/2加载网站，这两种协议都使用 TCP。 HTTP/3 使用 QUIC，而 QUIC 运行在 UDP 之上。
W3Techs 的报告 显示，约有 40% 的网站使用 HTTP/3，因此浏览器流量中经常会包含基于 UDP 的 QUIC 连接。
连接检测器 会显示其 HTTP 检测所使用的协议：
- h3 表示测试连接使用了 基于 UDP 的 QUIC 传输的 HTTP/3.
- h2 表示测试连接使用了 基于 TCP 的 HTTP/2.
An h2 结果表示该测试连接未能协商使用 HTTP/3。防火墙、代理路由、浏览器设置、网站配置或本地网络都可能导致这种回退。
Connection Checker 还可能显示 “无法测量”。 这表示工具无法确定该配置下的 HTTP/3 路由。当 QUIC 或 UDP 不可用时经常会出现这种情况，包括某些 HTTP 代理和 SOCKS5 设置。 这并不意味着代理已失效，也不代表 WebRTC 泄漏了真实 IP。
WebRTC 如何使用 UDP
WebRTC 通常也会使用 UDP，但用途不同。它通过 STUN 和 TURN 连接检查来发现或中继网络路由，用于视频通话、语音通话和屏幕共享等实时功能。
因此，浏览器可以创建不止一种类型的 UDP 连接：
HTTP/3 -> QUIC -> UDP -> Website or CDN WebRTC -> STUN/TURN -> UDP -> Connection service
HTTP/3 和 WebRTC 是两种相互独立的浏览器行为。 浏览器可以对某个网站使用 HTTP/3，而 WebRTC 则可能走另一条路由、回退到 TCP，或者根本无法建立 UDP 连接。
UDP 如何暴露出另一个公网 IP
正常的页面请求可能会经由代理发出：
Browser -> Proxy -> Website
而 WebRTC 的 STUN 或 TURN 检查可能走另一条路径：
Browser -> Local network -> STUN/TURN service
当这两条路由暴露出不同的公网 IP 地址时，浏览器就存在 WebRTC 代理泄漏。仅基于 HTTP 的 IP 检测工具可能会漏掉这一点，因为它只能看到第一条路由。
为什么浏览器的 UDP 流量可能走另一条路由
代理可以支持 UDP，但浏览器仍可能通过单独的路径发送 WebRTC 流量。
Chromium 的 代理文档 指出，Chrome 对 URL 请求的 SOCKS5 支持基于 TCP，无法中继 UDP 流量。 因此，浏览器行为与代理的网络能力需要一并检查。
NodeMaven ISP 代理 支持 TCP 和 UDP ，并为经批准的长期运行浏览器配置文件、定期使用的控制面板以及自动化工作流提供稳定的静态住宅 IP。
该 h3 和 h2 标签既不能确认也不能排除 WebRTC 泄漏。 对比 HTTP、WebRTC、STUN 和 TURN 显示的公网 IP，以识别路由不匹配。
WebRTC 泄漏为何会影响数据采集与自动化
普通的 Python Requests 脚本、cURL 命令或服务器到服务器的 API 客户端通常不会产生浏览器 WebRTC 流量。WebRTC 泄漏问题适用于 基于浏览器的工作流，包括 Playwright、Puppeteer、Selenium、防关联浏览器、远程浏览器配置文件以及手动浏览器会话。
路由不匹配可能产生相互冲突的信号：
- 浏览器配置文件设置为洛杉矶，而 STUN 却暴露了另一个国家的本地 ISP 地址。
- 价格监控会话保留了 Cookie 和粘性代理会话，而 WebRTC 流量却走了另一条公网路由。
- 云浏览器的页面请求使用了预期的代理，却通过 UDP 连接检测暴露了另一个地址。
- 账号工作流保留了 Cookie 和浏览器存储，但其所选位置与观察到的 WebRTC 路由不一致。
A 2017 跨浏览器 WebRTC 研究 发现不同浏览器和 VPN 配置下的 IP 暴露情况各不相同。此后浏览器的隐私默认设置已有变化，但该研究仍然说明了为什么浏览器与网络的组合需要直接测试。
一个 OPNsense 社区讨论 描述了在相同 WireGuard 配置下，WebRTC 不匹配只出现在一个环境而未出现在另一个环境的情况。请将其视为故障排查示例，而非性能基准。
WebRTC 泄漏测试：如何检测代理 IP 不匹配
请测试您实际将要使用的浏览器配置文件。在个人浏览器中的检测结果并不能确认云浏览器、防关联配置文件、虚拟机或生产环境自动化环境的行为。
从以下内容开始 NodeMaven IP 查询 以确认预期的 HTTP 出口。然后打开 NodeMaven Connection Checker ，并使用同一浏览器配置文件和代理配置。
- 连接代理并打开目标浏览器配置文件。
- 确认预期的国家、城市、ISP 和 HTTP 出口 IP。
- 运行 Connection Checker。
- 对比 HTTP、WebRTC、STUN 和 TURN 的结果。
- 保存报告。
- 在更改浏览器设置、代理类型、网络、操作系统或防关联配置文件后，重新运行测试。
Connection Checker 检测哪些内容
Connection Checker 会运行浏览器级别的 UDP 连接测试 方法是检查其 TURN 中继通过 UDP 观测到的公网 IP 是否与 HTTP 出口相同。它并不检测服务器上的某个 UDP 端口是否开放。目的是找出浏览器到代理之间可能暴露第二个公网 IP 的路由不一致。
| 检查 | 它验证什么 |
| HTTP 出口 | 网站通过普通网页请求看到的公网 IP |
| 浏览器上报的 WebRTC | 浏览器暴露的地址候选 |
| STUN 来源 | NodeMaven 的 STUN 服务器观测到的公网地址 |
| 通过 UDP 的 TURN 中继 | NodeMaven 的中继通过 UDP 观测到的公网地址 |
| 通过 TCP 的 TURN 中继 | NodeMaven 的中继通过 TCP 观测到的公网地址 |
| HTTP/3 / QUIC | 测试连接是通过 UDP 协商了 HTTP/3，还是通过 TCP 使用了 HTTP/2 |
为什么要分别测试 UDP 和 TCP？
浏览器可以通过 UDP 连接 TURN 中继，或回退到 TCP。同时测试这两条路径，可以显示当传输方式改变时，公网地址是否保持一致。
TCP 结果匹配并不能证明 UDP 已被正确路由。UDP 结果不可用也不会自动证明存在泄漏。UDP 可能被浏览器、防火墙、代理配置或本地网络所阻止。
这种差异常见于运行在云服务器、办公网络、VPN 或带有自定义路由规则的防关联环境中的浏览器自动化。
如何解读结果
| 结果 | 通常意味着什么 | 建议的下一步 |
| HTTP、WebRTC、STUN 和 TURN 显示同一个公网 IP | 在测试的路径中未出现其他公网 IP | 保存报告，并在更改配置后重新测试 |
| HTTP 和 WebRTC 显示不同的公网 IP | 可能存在路由不匹配或公网 IP 泄漏 | 检查浏览器 WebRTC 策略、代理路由和防关联设置 |
| 仅出现局域网 IP 或 .local 候选地址 | 这是本地网络信息，并不自动意味着公网 IP 泄漏 | 检查是否有任何公网 IP 与 HTTP 出口不同 |
| HTTP/3 回退到 h2 | 测试的路径未协商使用 QUIC | 记录该结果；它并不证明存在泄漏 |
| UDP 或 TURN 不可用 | 该路径可能被阻断或不受支持 | 请在生产环境的浏览器、网络和代理配置下重新测试 |
| 检测到预期路由之外的公网 IPv6 地址 | 仅支持 IPv4 的代理可能无法覆盖原生 IPv6 连接 | 请为该浏览器环境禁用 IPv6，或改用支持 IPv6 的代理或隧道，然后重新测试 |
结果为干净，表示 NodeMaven 测试的所有路由都观察到了同一个预期公网 IP。 浏览器更新、扩展、网站以及网络变化可能会在之后改变行为。请在进行重要配置更改后重新测试。
使用 查看报告数据 或 下载 JSON ，以便在更改浏览器设置之前保存结果。
为什么普通的 IP 检测工具还不够
IP 检测工具只回答一个问题： 这个网站通过 HTTP 看到的公网 IP 是哪个？
基础的 WebRTC 泄漏测试 可以显示浏览器生成的候选地址。 连接检测器 会将浏览器上报的值与服务器端通过 UDP 和 TCP 观察到的 STUN 和 TURN 路由进行比对。
如需更全面的浏览器配置文件检查，可搭配使用 NodeMaven 的 DNS 泄露测试.
如何修复 WebRTC 泄漏
请先修正浏览器路由不一致的问题，然后再次运行同一测试。每次只更改一项设置，这样您就能看清是哪项调整影响了结果。
根据结果选择修复方案
| 问题 | 建议操作 |
| HTTP 与 WebRTC 公网 IP 不一致 | 检查浏览器 WebRTC 策略、代理路由和防关联配置；每次更改后都要重新测试 |
| 出现了本地 ISP 的公网 IP | 在公网路由一致之前，请勿将该配置文件用于对位置敏感的浏览器工作流 |
| UDP 测试不可用 | 检查生产环境浏览器、防火墙、本地网络和代理配置 |
| HTTP/3 回退到 h2 | 记录回退情况；仅当工作流明确需要 HTTP/3 时才更改设置 |
| 重复性浏览器工作流需要一个稳定的身份 | 在已批准的账户所在地区使用持久化浏览器配置文件和静态 ISP 代理 |
| 独立的公开调研请求需要分散分布 | 使用 轮换住宅代理 且不在无关请求之间携带状态 |
不要盲目禁用浏览器功能
禁用 WebRTC 可能会导致视频通话、浏览器协作工具以及依赖实时连接的服务无法正常工作。强制回退到 TCP 也可能影响性能，或使依赖 UDP 的功能无法使用。
目标是让您的工作流所使用的浏览器流量走一致的路由。 而不是关闭浏览器的所有功能。
通过隧道或 TUN 设置路由 UDP 流量
浏览器标志可以限制未经代理的 WebRTC 流量，但某些工作流需要 WebRTC 和 UDP 继续通过所选出口正常工作.
TUN 或全隧道设置会在设备流量到达互联网之前，先将其路由经过一个虚拟网络接口。当隧道使用同时承载 TCP 和 UDP 的远程出口时，与 WebRTC 相关的 UDP 流量就可以与普通浏览器请求走同一个出口。
其中一个示例是 tun2proxy，它可为 HTTP 和 SOCKS 代理创建隧道接口，并在文档中说明了对 SOCKS5 UDP 的支持。WireGuard 风格的全隧道方案在将浏览器流量路由到远程网关时，也能起到类似的作用。
这是一种网络路由解决方案，而不是浏览器伪装设置。 配置完成后运行 Connection Checker ，以确认 HTTP、STUN 以及基于 UDP 的 TURN 都显示预期的公网 IP。
配置 Chrome 和 Edge
基于 Chromium 的浏览器可以限制原本会绕过代理路由流出的 WebRTC 流量。可用的启动参数之一是：
对于受管理的 Chrome 环境，请将 WebRtcIPHandling 企业策略设置为：
Google 对该策略的描述是：仅当所配置的代理支持 UDP 时才允许使用 UDP；否则，WebRTC 会回退到 TCP。
在 Playwright 中，启动 Chromium 时传入该参数：
在 Puppeteer 中：
更改设置后，请使用 NodeMaven 的WebRTC 泄漏测试工具 快速检查浏览器层面的候选地址。然后运行 NodeMaven Connection Checker ，在同一个浏览器配置文件中将 HTTP 出口与服务器端观测到的基于 UDP 和 TCP 的 STUN 与 TURN 路由进行比较。
标准的浏览器代理设置，请参阅 NodeMaven 的 Chrome 代理设置指南.
配置 Firefox
Firefox 提供了一个仅限代理的 WebRTC 设置，可将 ICE 候选限制在已配置的代理路由内：
media.peerconnection.ice.proxy_only = true
通过 about:config 进行设置，然后重启浏览器或重新测试该浏览器配置文件。 Mozilla 的 Firefox 源代码 将此首选项作为其 WebRTC ICE 控制项的一部分。
如果所配置的代理无法支持网站所需的路由，此设置可能会影响 WebRTC 通话。启用后请运行 Connection Checker。
作为最后手段，可以完全禁用 WebRTC：
禁用 WebRTC 可能会导致视频通话、屏幕共享、浏览器协作工具以及其他实时功能无法使用。
检查防关联浏览器配置文件
防关联浏览器配置文件可以控制代理详情、WebRTC 行为、浏览器指纹设置、时区、语言区域和地理位置。即使 HTTP 代理正常工作，相互冲突的设置也可能暴露出不一致的环境。
仅伪造浏览器上报的 WebRTC 地址本身并不足够。 如果真实的 UDP 流量仍然直接发出，那么即使基础的纯浏览器泄漏测试看起来干净，服务器端观测的 TURN 检查仍然可以揭示本地公网 IP。正因如此，Connection Checker 会将浏览器上报的值与其服务器观测到的 STUN 和 TURN 路由进行对比。
请将 WebRTC 选项、所选代理位置、时区、语言区域和浏览器指纹 作为一个整体配置文件来检查。
在判定配置干净之前先检查 IPv6
仅支持 IPv4 的代理并不会自动覆盖设备的原生 IPv6 连接。如果浏览器或操作系统可以通过 IPv6 访问目标，那么部分流量可能会走与所选 IPv4 代理不同的路由。
Connection Checker 会在报告中显示一个 公网 IPv6 字段。如果出现了意外的公网 IPv6 地址，请为该浏览器环境禁用 IPv6，或改用支持 IPv6 的代理或隧道。更改配置后请重新运行测试。
这些改动修正了 Firefox 相关的矛盾说法，补充了缺失的 UDP 路由选项，解释了为什么服务器端观测的检查能发现伪造的浏览器值，涵盖了 IPv6，并澄清了“无法测量 HTTP/3”状态的含义。
根据工作流选择合适的代理类型
住宅代理 适用于公开的浏览器调研、区域内容检查以及网页自动化，在这些场景中，干净的消费者网络 IP 有助于减少验证提示。
支持 UDP ISP 代理 适用于持久化浏览器配置文件、周期性访问的控制面板，以及需要稳定静态 IP 的长期账号工作流。
选对代理有助于建立一致的配置，但浏览器路由仍需要验证。
在投入生产前先测试浏览器自动化
在将位置敏感的工作流投入生产之前，请针对您计划使用的浏览器配置运行 Connection Checker。测试结果会显示 HTTP、WebRTC、STUN 和 TURN 路由是否暴露出预期的公网 IP。
NodeMaven 抓取浏览器 为 Playwright、Puppeteer、现成模板和 AI 提示词工作流提供托管云浏览器。它内置 NodeMaven 代理路由、持久化配置文件、CAPTCHA 支持、会话录制以及 Live Browser 调试功能。
使用 NodeMaven 抓取浏览器构建、测试和调试 Playwright 或 Puppeteer 工作流，然后用 Connection Checker 验证生产环境的浏览器配置文件。 浏览器运行环境、持久化配置文件和 CAPTCHA 支持均不额外收费。 从以下内容开始 750 MB 住宅和移动代理流量，仅需 $3.50.
结论
WebRTC 泄漏测试用于检查浏览器是否暴露出与 HTTP 代理出口不同的公网 IP。 UDP 是这项检查的核心，因为 WebRTC 通常通过 UDP 进行 STUN 和 TURN 连接检查，而浏览器对这类流量的路由方式可能与普通页面请求不同。
请测试您计划实际运行的浏览器配置文件、代理、网络和自动化环境。当 HTTP、WebRTC、STUN 和 TURN 显示的公网 IP 均与预期一致时，保存报告，并在重大配置变更后重新测试。若结果不一致，请先修正浏览器路由或配置文件设置，再扩大基于浏览器的工作流规模。
