WebRTC如何在VPN环境下正常运行？已尝试TURN/STUN仍遇ICE candidate失败

第一优先级：核查VPN对WebRTC流量的底层阻断逻辑 #

• 先做连通性验证：在终端开启VPN的状态下，直接测试所有配置的STUN、TURN服务的端口连通性，重点验证UDP 3478、TCP 3478、TLS 3478、TLS 443四类端口的可达性，很多VPN会默认拦截非业务端口的UDP流量，一旦UDP链路被拦，且没有配置TCP回退的TURN链路，就会直接触发ICE失败
• 确认VPN的路由接管范围：区分VPN是全局流量接管，还是分应用/分域名的分流模式。如果是全局接管模式，检查VPN出口的NAT类型——如果VPN出口本身是对称型NAT，普通的STUN探测无法获取真实的公网映射地址，所有直连候选都会失效
• 验证TURN服务自身的网络环境：TURN节点必须部署在带固定公网IP、全锥型NAT的公网环境，才能兼容VPN出口的对称NAT场景；如果TURN节点自身处于多层NAT后面，即使链路连通，也无法为对称NAT场景的终端分配可用中继地址
• 排查企业类VPN的DPI规则：多数企业零信任VPN会内置WebRTC识别规则，默认拦截会泄露用户真实IP的本地候选、mDNS候选流量，这类场景下所有直连类的ICE候选都会被丢弃。

第二优先级：修正现有ICE配置的适配性问题 #

• 调整ICE传输优先级：避免仅依赖UDP传输，要在iceServers配置中显式开启TURN的TCP、TLS传输支持，优先把TURN over TLS 443端口作为最高优先级的中继链路，适配VPN环境下仅放行443端口流量的常规规则
• 优化ICE候选收集策略：
  • 关闭本地局域网候选、mDNS候选的收集逻辑，避免生成被VPN阻断的无效候选，减少ICE收集的超时等待
  • 分开配置STUN的生效场景：公网STUN仅用于无VPN的直连探测，内网私有STUN不要和公网场景混配——开VPN后终端无法打通内网私域链路，配置这类无效STUN会白白消耗ICE收集的超时窗口
• 调整TURN服务的鉴权规则：不要使用静态IP白名单控制TURN访问，VPN场景下用户的出口IP是动态的VPN公共地址，不在白名单内会直接被拒绝分配中继地址，要替换为动态的长期凭据鉴权机制。

第三优先级：针对特殊VPN场景的适配 #

• 针对消费类免费VPN场景：这类VPN大多没有固定公网IP，自身处于对称NAT层级，所有直连、STUN探测生成的候选均不可用，需将TURN服务部署在带固定公网IP、无严格出站限制的公网节点，同时适当拉长ICE收集的超时时间（从默认3s调整到8-10s），适配VPN链路的高延迟特性
• 针对强制WebRTC拦截的VPN场景：如果检测到VPN会直接丢弃ICE候选报文，要显式将iceTransportPolicy设置为relay，所有媒体流量强制走TURN中继，不在SDP中携带任何非中继类型的候选，规避VPN的识别拦截。

排查阶段需要分别在开、关VPN的状态下抓包对比ICE收集阶段的候选类型、连通性结果，不要在未验证连通性的前提下盲目调整STUN/TURN地址配置。

内容的提问来源于stack exchange，提问作者Jonathan DeCollibus