WebRTC连接卡在连接状态的原因排查求助

1. 排查SSH SOCKS代理对ICE候选的干扰 #

• WebRTC的ICE候选收集不应走SSH SOCKS代理，浏览器默认会绕过代理处理WebRTC流量，但系统级全局代理会强制转发ICE请求，导致TURN服务器无法识别代理后的请求，进而无法生成有效中继候选。
• 验证方法：暂时替换SSH SOCKS代理为GCP端口转发（命令示例：gcloud compute ssh --ssh-flag="-L 8080:localhost:8080" [你的VM名称]），将VM的WebSocket端口映射到本地后重新测试，观察ICE候选是否正常生成。

2. 修正TURN服务器配置细节 #

• 当前配置缺少传输协议指定，且未补充TCP fallback选项，修改为：

  iceServers = [
      { 
          urls: "turn:freeturn.net:3478?transport=udp", 
          username: "free", 
          credential: "free"
      },
      { 
          urls: "turn:freeturn.net:3478?transport=tcp", 
          username: "free", 
          credential: "free"
      }
  ]
  

• icecandidateerror 701多为UDP候选收集失败，补充TCP选项可规避部分防火墙拦截问题。

3. 检查GCP VM的公网访问能力 #

• 确认VM能正常访问TURN服务器：
  • 在VM内执行telnet freeturn.net 3478验证TCP连通性，nc -u -zv freeturn.net 3478验证UDP连通性。
  • 检查GCP防火墙规则，允许VM出站访问任意IP的3478端口（UDP/TCP）。
  • 若VM在私有网络，确认VPC的云NAT配置正常，保证VM具备公网访问权限。

4. 强制WebRTC仅使用TURN中继候选 #

• 默认ICE策略优先尝试本地/反射候选，可通过iceTransportPolicy强制仅使用TURN候选，排除其他候选干扰：

  const peerConnection = new RTCPeerConnection({
      iceServers: [...你的TURN配置...],
      iceTransportPolicy: "relay"
  });
  

• 查看浏览器控制台日志，确认是否生成type: "relay"的ICE候选。

5. 验证信令流程的完整性 #

• 跨网络场景下，检查Offer/Answer的SDP是否包含正确的TURN服务器信息（查看a=ice-server字段），同时确认所有ICE候选通过WebSocket信令完整传递到对端。
• 可在信令收发环节打印SDP和候选内容，排查是否存在信息丢失或格式错误。

6. 更换公共TURN服务器测试 #

• 公共TURN服务器可能存在带宽或地域限制，可替换为其他公共服务测试，示例配置：

  iceServers = [
      { urls: "turn:turn.cloudflare.com:3478", username: "webrtc", credential: "webrtc" }
  ]
  

• 条件允许的话，使用GCP自带的Cloud WebRTC TURN服务，稳定性和兼容性更优。

内容的提问来源于stack exchange，提问作者Valentin Menu Cerri