快速回答：什么是 WebRTC 泄漏？
WebRTC 泄漏（WebRTC leak）是指浏览器的实时通信功能暴露了一个本应由代理或 VPN 隐藏的 IP 地址。WebRTC 会从多个网络接口收集 ICE 候选地址，而普通网页请求可能按照另一条代理路径传输。因此，IP 查询页显示代理IP，并不代表WebRTC检测一定只会显示该出口。排查时应先记录预期出口，再在实际使用的浏览器配置中运行检测，识别每个地址的类型，修改一个设置后重新验证。检测到多个地址不一定等于公网IP泄漏，关键取决于地址类型和预期网络路径。
本文适用于使用代理、VPN、浏览器扩展或企业网络策略进行隐私排查的用户。文中不把代理IP类型描述成自动防泄漏方案，也不把一次检测结果表述为完全匿名保证。
WebRTC会暴露什么信息？
WebRTC用于什么？
WebRTC（Web Real-Time Communication，网页实时通信）是一组浏览器技术，用于音视频通话、屏幕共享和实时数据通道。浏览器可以通过WebRTC建立点对点连接，而不必让所有媒体数据都经过加载网页时使用的HTTP代理。连接建立期间，浏览器会收集可能的网络路径，这些候选路径称为ICE候选（ICE candidates）。
候选列表可能包含本地网卡、IPv4或IPv6路径，以及通过STUN服务器发现的服务器反射地址。直接连接不可用时，TURN中继可以提供另一条连接路径。这里讨论的是浏览器连接建立机制，不是WebRTC本身存在恶意行为。
WebRTC如何暴露IP地址？
ICE（Interactive Connectivity Establishment，交互式连接建立）会评估多个候选地址并选择可用路径。STUN（Session Traversal Utilities for NAT，NAT会话穿越工具）帮助客户端了解外部服务看到的网络映射；TURN（Traversal Using Relays around NAT，NAT中继穿越）在直接连接不可用时中继流量。
当暴露的候选地址与预期的代理或VPN路径不一致时，才需要进一步判断是否存在泄漏。例如，浏览器扩展可能只代理普通HTTPS请求，而WebRTC仍然评估本地接口或直连UDP路径。最终结果还会受到浏览器、操作系统、客户端、DNS解析、IPv6配置和网络策略影响。
公网IP、私网IP、IPv6和mDNS结果如何判断？
| 检测结果 | 可能代表什么 | 是否立即等于公网IP泄漏 |
|---|---|---|
| 预期代理或VPN公网IPv4 | 检测观察到配置中的出口 | 通常符合测试预期，但结论仅限于本次环境 |
| 本地ISP公网IPv4 | 可能存在直连或绕过路径 | 需要重点排查 |
| 全球可路由IPv6 | 可能有未纳入IPv4保护路径的IPv6连接 | 检查IPv6路由和分流设置 |
| 私网IPv4 | 家庭、办公室或本地网卡地址 | 不等同于暴露公网ISP地址 |
.local名称或mDNS结果 |
通过多播DNS隐藏表示的主机候选 | 不能单独证明所有路径都受保护 |
| 没有候选地址 | 检测被阻止、脚本失败或浏览器不支持 | 不能直接当成已经修复 |
mDNS（Multicast DNS，多播DNS）可能用不可读的本地名称替代本地主机地址。判断检测结果时，不能把每个.local结果都归类为严重泄漏，也不能把它直接当成完整安全证明。
WebRTC泄漏不会自动说明什么？
WebRTC检测结果本身不等于网站已经读取摄像头或麦克风内容，也不代表密码、完整家庭地址或所有浏览器属性已经暴露。WebRTC地址暴露与浏览器指纹、Cookie关联和DNS泄漏属于不同问题。它们可能共同影响跟踪风险，但需要分别检测和处理。
为什么代理或VPN仍可能出现WebRTC泄漏？
ICE、STUN和TURN分别做什么？
WebRTC和ICE规范描述了候选地址的收集与排序方式。STUN规范说明客户端如何发现服务器反射地址，TURN规范说明直接连接不可用时如何使用中继。网页加载经过代理，并不代表网站触发的WebRTC连接也一定使用同一出口。
核心区别在于应用层路由和浏览器连接策略。浏览器代理可以影响HTTP或HTTPS请求，但不能仅凭代理开关证明ICE候选收集、UDP流量、DNS解析和媒体数据都经过相同端点。
应用代理和全隧道VPN有什么区别？
| 网络方式 | 通常可以影响的流量 | 仍需验证的内容 |
|---|---|---|
| 浏览器代理扩展 | 扩展能够控制的请求 | 扩展权限、绕过规则和WebRTC策略 |
| 系统HTTP代理 | 遵循系统设置的应用请求 | 浏览器和WebRTC是否采用该设置 |
| SOCKS5代理 | 客户端实际支持的TCP连接及其他能力 | 客户端、DNS模式、UDP处理和浏览器路由 |
| VPN应用 | VPN隧道及分流规则覆盖的流量 | IPv4、IPv6、UDP、DNS和应用排除项 |
| 完整网络隧道 | 更大范围的系统网络路径 | 客户端配置和当前路由状态 |
SOCKS5是代理协议，不是传输加密层，也不是匿名保证。配置Socks5.IO住宅代理时，可参考住宅代理协议文档核对支持的协议格式和认证方式。不能因为连接使用SOCKS5，就推断WebRTC候选地址一定经过该代理。
为什么代理IP类型不能决定WebRTC结果？
住宅代理、静态住宅代理、移动代理和数据中心代理描述的是IP来源，并不决定浏览器是否通过直连接口收集ICE候选。稳定IP可以帮助控制检测变量，但不会改变浏览器的WebRTC策略。
如果需要进行较长时间的对比，静态住宅代理在产品和账户条件匹配时，可以提供相对稳定的出口。它的价值是帮助保持测试变量一致，不代表浏览器的每个WebRTC请求都会经由该IP。
IPv4、IPv6和UDP路由需要检查什么？
即使IPv4代理或VPN看起来正常，系统仍可能保留一条IPv6路径。UDP限制也会影响WebRTC通话，浏览器或VPN还可能对特定应用执行分流。不要把“关闭IPv6”或“关闭UDP”当成所有环境的通用修复方案，因为这些设置可能影响正常通信。每次修改都应可恢复，并在实际使用环境中验证。
如何检测 WebRTC 泄露？
第1步：记录直连基线
使用计划评估的浏览器和网络，记录未启用代理或VPN时的公网IPv4和IPv6、时间、操作系统、浏览器版本及当前网络。如果设备由公司或学校管理，不应为了测试擅自断开批准的安全配置。
第2步：启用实际使用的代理或VPN配置
应用后续工作流真正会使用的配置，记录预期出口国家、协议、端口、认证方式和会话状态。先通过IP信息服务检查普通网页出口，但不要在日志或截图中保留密码、令牌、Cookie和完整账户信息。
浏览器配置可参考Socks5.IO Chrome代理配置文档，前提是文档中的产品和认证方式与当前端点匹配。普通网页IP检查不能替代WebRTC检测。
第3步：运行WebRTC泄漏检测
在同一个浏览器配置中打开可信的WebRTC检测页面，等待检测完成，记录公网IPv4、IPv6、私网地址和mDNS结果，同时记录时间和检测页面版本（如果页面提供）。页面没有显示地址，可能是脚本被阻止或执行失败，不能直接称为完全匿名。
第4步：比较检测结果
将每个返回地址与直连基线及预期代理或VPN出口对比。代理或VPN启用期间，如果出现不属于预期出口的本地ISP公网IP，应优先排查浏览器策略、IPv6、VPN分流和代理覆盖范围。地理位置数据库的城市标签可能存在误差，单纯城市不一致不能证明WebRTC泄漏。
第5步：重复检测
在相同条件下重复测试。如果结果发生变化，检查扩展、VPN分流、IPv6、网络环境和检测页面本身。第二个独立检测工具有助于识别脚本故障，但不同工具可能展示不同类型的候选地址。记录浏览器、扩展、VPN和代理客户端版本，不要只保留一张结果截图。
常见WebRTC检测结果如何解释？
| 结果 | 初步判断 | 下一步 |
|---|---|---|
| 只出现预期代理IP | 本次测试没有观察到非预期公网地址 | 网络或浏览器变化后重新检查 |
| 出现本地ISP公网IP | 可能存在直连或绕过路径 | 检查WebRTC策略、IPv6、VPN分流和代理范围 |
| 只有私网IP | 本地接口信息可见 | 与公网IP暴露分开评估 |
| 出现未预期IPv6 | IPv6可能没有经过预期路径 | 检查VPN、代理客户端和系统IPv6路由 |
出现.local地址 |
检测可能展示mDNS主机候选 | 结合其他候选地址判断，不单独下结论 |
| 没有任何结果 | 检测可能被阻止、不支持或未完成 | 确认页面和脚本是否真正运行 |
如何修复 WebRTC 泄露？
根据实际需求选择修复方式
| 需求 | 可考虑的控制方式 | 主要影响 |
|---|---|---|
| 不需要WebRTC | 禁用或限制WebRTC | 可能影响通话、屏幕共享和实时数据 |
| 需要保留WebRTC通话 | 限制非代理路径或使用兼容的隧道 | 兼容性和通话质量可能变化 |
| 使用VPN | 检查IPv4、IPv6、UDP、DNS和分流 | 结果取决于VPN客户端和策略 |
| 使用代理 | 检查浏览器范围、协议、认证和WebRTC行为 | 普通代理不一定控制ICE候选 |
| 设备受组织管理 | 使用批准的浏览器或网络策略 | 个人扩展可能被阻止或覆盖 |
Chrome、Edge及Chromium浏览器如何处理？
优先使用当前版本有文档支持的浏览器策略或经过核验的扩展，不要使用来源不明的一键脚本。检查扩展权限，并确认它是在限制非代理UDP、修改候选地址处理，还是完全禁用WebRTC，这些控制方式的功能影响不同。
同时检查代理绕过规则和可能改变路由的其他扩展。Socks5.IO的Chrome配置文档可用于核对浏览器端的代理字段，但不能证明Chrome的WebRTC流量使用相同路径。修改浏览器策略前应记录恢复方式，未经当前版本文档确认的实验性Flags不应作为默认教程。
Firefox如何处理？
Firefox提供可以降低或禁用WebRTC行为的隐私设置，但设置名称和影响取决于当前版本。应区分完全停止WebRTC与限制候选地址路径。完全停止可能影响通话和屏幕共享。修改一个设置后，使用相同检测条件复测，并验证仍需使用的WebRTC服务。
Brave如何处理？
检查当前桌面版或移动版Brave的隐私和WebRTC控制项。反跟踪设置不等于完整网络隧道。修改后应检查实际公网候选地址，不能把浏览器名称当成路由保证。
Safari如何处理？
macOS、iOS和iPadOS的可用控制并不相同，桌面扩展步骤不能直接套用到移动浏览器。如果浏览器层没有合适控制，应检查经过批准的系统网络配置或客户端，并在实际使用的Wi-Fi或蜂窝网络上重新测试。
浏览器控制不足时如何修复网络路径？
检查VPN分流、IPv6、UDP行为、DNS模式和绕过列表，确认多个代理扩展或VPN客户端没有互相覆盖。一次只修改一个变量，才能解释复测结果。不要默认关闭证书验证、防火墙或所有IPv6功能。
如何确认修复有效？
修复后的复测清单
- 根据设置要求重新加载或重启浏览器。
- 在同一浏览器配置中运行相同的WebRTC检测。
- 确认原本应隐藏的公网IPv4或IPv6不再显示。
- 检查普通网页是否仍经预期路径访问。
- 测试必须保留的音频、视频、屏幕共享或数据功能。
- 切换实际Wi-Fi、蜂窝网络或代理会话后再次检查。
一次通过的检测能证明什么？
通过结果只能说明：在本次浏览器、设备、网络和检测页面条件下，没有显示预期之外的地址。它不能证明完全匿名，也不能覆盖所有应用、后续浏览器更新或网络变化。同样，单次通过不能证明DNS泄漏、浏览器指纹、Cookie或账户关联不存在。
如何防止 WebRTC 泄露再次出现？
配置变化后重新检测
浏览器、VPN或代理客户端更新后，切换Wi-Fi或蜂窝网络后，代理重连或会话变化后，新增或删除扩展后，以及修改IPv6、UDP、DNS或分流设置后，都应重新检测。这样可以发现原有修复是否因网络层变化而失效。
保留配置基线
记录操作系统和浏览器版本、代理或VPN客户端、协议、端口、认证方式、预期出口、检测日期、必须保留的WebRTC功能和恢复步骤。后续出现差异时，可以按记录还原变量，而不是凭记忆判断。
避免网络层相互覆盖
不要同时启用多个覆盖范围不明确的代理扩展。检查VPN分流和浏览器绕过规则，不要把普通网页IP检查当成WebRTC结果。不同浏览器配置和不同网络环境应分别保存检测记录。
Socks5.IO代理能控制什么，不能控制什么？
代理可以控制什么？
代理为客户端实际发送经过它的流量提供网络出口。根据所选产品、客户端和已核实的配置文档，代理可用于检查特定网络出口、位置或稳定会话。部署前应以当前官方资料核对协议、端口、认证和位置行为，不应从代理类型名称推导未提供的性能参数。
代理不会自动控制什么？
代理不会自动决定浏览器是否启用WebRTC、如何收集ICE候选、哪些扩展有权修改行为，也不会自动改变操作系统的IPv6和UDP路由。代理同样不会消除Cookie、账户历史或浏览器指纹信号。
如何用代理排查WebRTC泄漏？
- 记录直连基线。
- 配置预期代理端点。
- 检查普通网页出口IP。
- 单独运行WebRTC检测。
- 比较公网IPv4、IPv6、私网和mDNS结果。
- 修改浏览器或网络路径后重新测试。
端点检测验证的是客户端配置的网络出口，WebRTC检测验证的是浏览器实时通信层展示的候选地址。两者都不能单独保证完全匿名。
WebRTC泄漏与其他隐私泄漏有什么区别？
| 问题类型 | 主要暴露内容 | 与WebRTC泄漏的区别 |
|---|---|---|
| WebRTC泄漏 | 实时通信候选地址 | 与浏览器ICE和连接策略有关 |
| DNS泄漏 | 域名请求发送到非预期解析器 | 与域名解析有关，不等同于ICE候选 |
| IPv6泄漏 | IPv6流量绕过预期路径 | 可能绕过只配置IPv4的保护方案 |
| 浏览器指纹 | Canvas、WebGL、字体、时区等特征 | 不需要IP地址也可能识别浏览器 |
| Cookie或账户关联 | 登录状态和浏览活动 | 通过应用层数据关联会话 |
这些问题需要分别控制。修复WebRTC泄漏不能证明其他隐私风险已经消失。
结语
理解什么是 WebRTC 泄漏，首先要把普通网页路由和浏览器实时通信路径分开。先确认检测显示的地址，再与预期出口比较，随后调整产生差异的浏览器、VPN、代理客户端或网络策略。浏览器更新、网络切换和代理重连后应重新检测，同时验证隐私结果和仍需使用的WebRTC功能。Socks5.IO代理可以为排查提供已配置的网络出口，但代理IP类型和SOCKS5协议不会自动控制浏览器的WebRTC行为。
