WebRTC穿透与VPN的协作逻辑
WebRTC旨在实现浏览器间的低延迟实时通信，但其依赖的NAT遍历机制（如STUN、TURN）常因网络拓扑复杂而失败。当本地或远程节点处于双重NAT后，ICE候选收集受阻，香蕉VPN连接无法建立。此时，VPN并非直接优化WebRTC，而是通过提供稳定的中间节点，改变终端看到的源IP和网络层级，间接提升连通率。其核心价值在于将不可控的对端NAT环境，转化为相对可控的点对点隧道环境。
通过VPN封装WebRTC流量，可有效绕过企业内网复杂NAT限制，提升实时协作连通率。
场景一：企业内网用户访问公网协作平台
此场景适用于使用静态IP或复杂内网路由的企业员工，需访问Slack、Teams或内部WebRTC视频会议系统。企业防火墙通常严格限制UDP 443以外的出站端口，且WebRTC常用的UDP随机端口可能被阻断。启用IPsec或WireGuard VPN后，所有WebRTC流量被封装进加密隧道，仅占用TCP 443或专用UDP端口。这绕过了企业侧的端口策略限制。验证时，可检查浏览器DevTools中的ICE连接状态，若从“Failed”变为“Completed”，说明穿透成功。需注意，此操作仅改变传输路径，香蕉VPN不保证媒体质量，若带宽受限，码率可能自动降低。
场景二：远程开发者连接自建开发服务器
当开发人员位于家庭宽带，需通过WebRTC界面（如JupyterLab的Live Server或远程图形界面）访问位于云厂商VPC内的开发服务器，且VPC安全组仅允许特定IP访问。家庭宽带的出口IP动态变化，香蕉VPN导致直接连接失败。此时，VPN客户端建立到VPC网段的持久隧道，使终端操作系统视VPC为本地子网。WebRTC应用在终端发起连接时，目标IP指向VPC内网地址，流量经VPN路由至云端，避免了公网IP漂移带来的鉴权问题。此方案依赖VPN协议的路由控制能力，需确保客户端路由表中包含目标VPC网段。若未正确配置路由，WebRTC仍会尝试直连公网IP，导致超时。
场景三：规避运营商对UDP流量的QoS限速
部分运营商会对非加密的UDP流量实施深度包检测（DPI），识别为P2P或游戏流量后降低优先级，导致WebRTC音视频卡顿。通过启用支持UDP分片或TCP回退的VPN（如WireGuard的UDP over TCP封装，或OpenVPN的TCP模式），将实时媒体流封装在加密隧道中，规避运营商DPI识别。结果是UDP丢包转化为TCP重传或隧道内重传，虽增加少量延迟，但稳定性显著提升。验证方法是使用网络测速工具对比开启VPN前后的UDP丢包率与RTT。若UDP丢包从10%降至0.1%，则说明QoS规避有效。需注意，若带宽本身不足，封装开销会进一步加剧拥塞，此时应优先扩容而非单纯切换协议。
只读验证：检查ICE候选来源
为确认VPN是否改变了WebRTC的网络路径，可在浏览器开发者工具的Network面板中筛选WebRTC相关的WebSocket或UDP流量，或在Chrome地址栏输入chrome://webrtc-internals查看ICE候选列表。重点观察Host Candidate和Srflx Candidate的IP地址：若Host IP显示为VPN分配的私有IP（如10.x.x.x或192.168.x.x），香蕉加速器说明流量已走隧道；若仍显示为宽带拨号获得的公网IP，则WebRTC绕过了VPN路由，直接连接。此检查无需修改任何配置，能直观反映当前网络栈的实际路由行为。若候选地址与预期不符，需检查VPN客户端的系统级路由规则是否覆盖了应用进程。
