WebRTC局域网可连通 跨网络/蜂窝数据环境连接失败排查

同局域网可连通、跨公网连接失败，结合日志和现有配置，核心原因有两点：

• 配置的公共TURN服务完全失效，且存在配置字段拼写错误。你代码里用的numb.viagenie.ca免费TURN服务早已停止公开接入，配置的公开账号密码无效；同时TURN配置项错写为url，标准WebRTC API要求使用urls字段，双重问题导致TURN服务根本没有被正常加载。从日志可以验证：两端仅收集到host类型内网候选、srflx类型STUN反射候选，全程没有出现typ relay的TURN中继候选。
• 跨网场景下STUN打洞存在天然局限。蜂窝移动网络、大部分运营商家庭宽带都使用对称型NAT，这类NAT环境下STUN获取的反射候选无法完成P2P打洞，必须依赖TURN中继转发媒体流才能建立连接，没有可用中继候选时，ICE连通性检查必然失败。

• 替换为可用的TURN服务，修正配置错误
  不要使用网上流传的失效公共TURN账号，生产环境建议自行部署coturn等开源TURN服务，测试阶段可使用合规的公开测试TURN服务。配置时严格使用标准字段名，参考如下正确配置：

  new RTCPeerConnection({
    iceServers: [
      { urls: "stun:stun.l.google.com:19302" },
      {
        urls: 'turn:你的TURN服务地址:3478', // 注意字段名是urls，不是url
        username: 'TURN服务账号',
        credential: 'TURN服务密码'
      }
    ]
  });
  

• 验证候选收集完整性
  配置完成后监听icecandidate事件，确认两端候选列表中都出现typ relay类型的中继候选。只要能正常获取中继候选，即使P2P打洞失败，WebRTC也会自动选择中继通道完成连接。
• 兜底排查连通性问题
  如果已获取relay候选仍连接失败，逐项检查以下配置：
  • TURN服务器防火墙是否放通3478端口（UDP/TCP）、49152-65535中继媒体端口段的入站流量
  • 客户端所在网络是否拦截UDP出站流量，必要时开启TURN的TCP、TLS转发模式做兜底
  • 信令通道是否完整传输了所有ICE候选，trickle ICE模式下不要在候选收集完成前关闭信令连接，避免漏传relay候选

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