进行 WebRTC 泄漏测试:防止 IP 泄漏
代理正常工作，并不代表浏览器的每一个连接都受到保护。通过 WebRTC 泄漏测试可以验证流量路由，避免 IP 意外暴露，让您的网络身份保持安全且一致。下面是完整的操作指南。
什么是 WebRTC
WebRTC（Web Real-Time Communication，网页实时通信）是一项开放标准，让浏览器和应用无需插件即可实时交换音频、视频和数据。它通常使用 UDP 实现低延迟通信，同时也支持 TCP 和基于中继的连接。
为了建立连接，WebRTC 会收集 ICE（Interactive Connectivity Establishment，交互式连接建立）候选项：即包含地址、端口和传输协议的潜在网络端点。所有可能的泄漏都源自这些候选项。
如果发现过程走的是未受保护的路由，这些候选项就可能暴露您代理或 VPN 连接之外的 IP。
代理为何会通过 WebRTC 泄漏
当浏览器的连接发现过程暴露了本应被路由配置隐藏的地址时，就发生了 WebRTC 泄漏。WebRTC 泄漏测试可以帮您发现这一问题。
网页启动 WebRTC 候选项收集。
浏览器联系 STUN 服务器，以获取自己的公网地址。
如果该连接绕过了代理，STUN 看到的就是您的 ISP 地址。
浏览器可能通过 ICE 候选项，将该地址暴露给网页 JavaScript。
请注意：
浏览器的代理设置不一定覆盖 WebRTC 流量。
正确强制启用的全隧道 VPN 应当承载这部分流量；WebRTC 本身并不会破坏 VPN 加密。
WebRTC 泄漏为何会暴露您的身份
暴露的公网 IP 可以显示您的网络服务商和大致位置，但不会显示您的姓名或确切地址。它还可能导致：
原本相互独立的浏览器会话被关联起来。
触发基于地理位置的限制。
触发额外验证或账号审核。
这些只是可能出现的后果，并非必然结果。尽管如此，保持谨慎并定期进行 WebRTC 泄漏测试仍然是值得的。
请保持警惕，始终测试 DNS 泄漏和 WebRTC 泄漏。 阅读代理与数据安全相关内容，了解更多。
DNS 泄漏与 WebRTC 泄漏的区别
DNS 泄漏关注的是域名查询经过了哪条路径；WebRTC 泄漏关注的是连接发现过程暴露了哪些地址。两种测试不能互相替代。
维度 | DNS 泄漏 | WebRTC 泄漏 |
层级与协议 | 系统/应用的名称解析；UDP/TCP 53、DoH、DoT | 浏览器/应用的连接；ICE、STUN、TURN，通常基于 UDP |
泄漏的信息 | 被查询的域名；解析器可看到查询来源 | 本地或公网 IPv4/IPv6 地址 |
谁能获知 | 解析器；若 DNS 未加密，则网络观察者也可获知 | 页面脚本、对等端或发现服务器 |
主要风险 | 域名查询活动被暴露 | 网络身份被意外识别，会话被关联 |
影响范围 | 系统级、特定应用或特定浏览器 | 支持 WebRTC 的浏览器和应用 |
触发机制 | DNS 解析发生在预期的受保护路径之外 | WebRTC 收集候选项或检查连通性 |
DNS 测试通常识别出的是递归解析器，而不是您设备的公网 IP。出现意料之外的解析器值得排查；但仅凭其所在国家并不能证明存在泄漏。
如何测试 WebRTC 泄漏
简单来说，WebRTC 泄漏测试就是检查您的真实 IP 是否出现在任何浏览器可见的 ICE 候选项中。可以借助一些专门的服务，例如 BrowserLeaks、IPLeak，或 GitHub 上 WebRTC 官方工具 Trickle ICE。
1. 在不使用代理/VPN 的情况下检查真实的 IPv4 和 IPv6
在关闭保护之前，先关闭敏感的工作会话。
打开 IPLeak。
记录您直连的公网 IPv4 以及可用的 IPv6。
请妥善保管这些基准地址，不要外泄。
“未检测到 IPv6”只说明测试未能建立 IPv6 连接，并不意味着 IPv6 以后永远不可用。
2. 启动代理/VPN 网络，再次检查 IP
连接 VPN，或在目标浏览器配置文件或客户端中配置 CyberYozh App 代理。
打开一个新的测试标签页。
确认公网 IP 已变为预期的出口 IP。
分别检查 IPv4 和 IPv6。
浏览 IP 发生变化，只能证明连接的路由变了，但仍可能存在 WebRTC 泄漏。
3. 打开 BrowserLeaks、IPLeak 或 WebRTC 的 Trickle ICE
选择一个在线 WebRTC 泄漏测试：
BrowserLeaks：查看“Your WebRTC IP”和 SDP 日志。
IPLeak：使用其 DNS 与 WebRTC 合并的泄漏测试。
Trickle ICE：WebRTC 项目的示例；点击“Gather candidates”，查看地址/类型列。它只是诊断示例，并非全面的隐私认证。
4. 检查输出中是否出现您的真实 IP
将 WebRTC 泄漏测试结果与基准地址进行对比：
出现直连的 ISP 公网 IP：需排查 IP 泄漏。
出现预期的代理/VPN 出口 IP：说明路由受到保护。
192.168.x.x 或 10.x.x.x：属于私有网络信息，不是您的公网身份。
.local 主机名：这是本地地址混淆，不能证明公网 IP 受到保护。
没有候选项或出现错误，属于结果无法确定。请重新连接后，用另一个工具再测一次。如果这些工具都没有显示泄漏，就说明您是安全的。想了解如何防止泄漏，请继续阅读。
如何防止 WebRTC 泄漏
不需要 WebRTC 时将其禁用；如果通话和实时应用必须保持可用，则强制使用受保护的路由。阻止未经代理的 UDP 有帮助，但不能取代 WebRTC 泄漏测试，后者能让您了解实际情况。
了解如何确保代理 IP 不被封禁，包括 IP 泄漏防护及其他方法。
在常规浏览器中
参考相应的 浏览器设置指南，然后采用对应的控制方式：
Firefox 桌面版：about:config → media.peerconnection.enabled → false。这会禁用 WebRTC。
Chrome：使用持续维护、支持 disable_non_proxied_udp 的隐私扩展。
Brave：在设置中搜索“WebRTC IP Handling Policy”，选择“Disable Non-Proxied UDP”。
Microsoft Edge：使用兼容的 WebRTC 隐私扩展或托管策略，然后重新测试。
Safari：使用强制启用的设备级 VPN 路由；不要依赖旧版“实验”菜单的操作说明。
Opera：在可用时选择阻止未经代理的 UDP，或使用持续维护的兼容扩展。
在指纹浏览器中
请按照 指纹浏览器设置说明操作。
将代理分配给配置文件，然后检查其 WebRTC 设置。不需要时选择禁用模式；否则使用厂商提供的受保护路由选项。
“Altered”（已修改）等选项名称在不同产品中含义不同：仅仅改变显示的候选项，并不能证明网络流量受到了保护。
之后请逐个测试每个配置文件。
在代理客户端中
请按照 代理客户端设置说明操作。然后：
导入您的 CyberYozh 凭据。
在支持时启用 TUN/全局路由模式。
确认上游支持 UDP。
让 DNS 走预期的路径
禁用不需要的直连回退。
仅启用系统代理模式，不等同于设备级隧道。完成后，请针对实际使用的浏览器配置，再次测试 WebRTC 泄漏。
系统防火墙设置
请参考相应的 操作系统设置指南。
在 Wi-Fi 设置中启用 VPN 终止开关（kill switch），或添加出站规则，将受保护的应用限制为只能通过隧道或代理客户端联网。IPv4 和 IPv6 都要覆盖。这样会阻断所有未经代理的（直连）流量，把 WebRTC 泄漏风险降到最低。
存在 WebRTC 泄漏风险时的最佳实践
测试实际使用的工作配置文件，而不只是默认浏览器；不同环境下的浏览器权限、扩展、代理分配和路由规则可能各不相同。
在浏览器更新、客户端变更、网络切换和重新连接之后重复检查；一次成功的测试只能验证某一特定配置，而不是未来所有可能的状态。
单独验证 DNS 和 IPv6；禁用 WebRTC 并不能修复与之无关的解析器路由问题，也无法阻止普通连接绕过受保护的网络路径。
在正式工作前测试故障时的行为：断开隧道，确认受保护的应用会停止连接，而不是悄悄回退为直连访问。
保留必需的功能：在施加限制后测试通话和屏幕共享，然后记录可用的配置，注意不要保存代理密码，也不要公开分享基准地址。