WebRTC在WiFi下无法连接（移动数据正常）的问题排查求助

以下是针对你遇到的问题（乌克兰地区WiFi下WebRTC无法建立连接，移动数据/美国网络正常、防火墙已关闭）的具体排查方向：

1. WiFi网络NAT类型限制 #

乌克兰本地运营商的WiFi网络可能使用对称NAT，而移动数据或美国网络采用的是锥形NAT。对称NAT会对不同目标IP/端口分配独立的公网映射端口，导致STUN服务器无法生成有效的server reflexive候选，ICE无法完成连通性检查。

排查方法：

• 打开浏览器chrome://webrtc-internals页面，对比WiFi和移动数据下的ICE候选列表：如果WiFi下只有host类型候选，没有srflx或relay候选，说明NAT类型是主要问题。
• 解决方式：必须配置TURN服务器（STUN无法穿透对称NAT），确保TURN服务器支持UDP/TCP传输，且在乌克兰地区有可用节点。

2. WiFi网络UDP流量被阻断 #

部分ISP会在WiFi网络环境下限制或过滤UDP流量（WebRTC默认优先使用UDP传输），导致ICE候选交换后无法建立数据通道。

排查方法：

• 强制WebRTC使用TCP传输进行测试，修改PeerConnection配置：

  const pcConfig = {
    iceServers: [{ urls: 'stun:stun.l.google.com:19302' }],
    iceTransportPolicy: 'tcp'
  };
  const peerConnection = new RTCPeerConnection(pcConfig);
  

  如果切换TCP后连接恢复，说明WiFi网络的UDP流量被限制。

3. TURN服务器在本地网络不可用 #

如果你的WebRTC依赖TURN服务器进行中继，但TURN服务器在乌克兰WiFi网络下存在访问延迟高、端口被阻断或认证失败的情况，会导致ICE无法获取relay类型候选，最终连接失败。

排查方法：

• 使用trickle-ice工具（浏览器内即可运行）测试STUN/TURN服务器的候选生成情况，检查WiFi下是否能成功获取relay候选。
• 用telnet <turn-server-ip> 3478测试TURN服务器的UDP端口连通性，或telnet <turn-server-ip> 5349测试TCP端口。

4. WiFi网络DNS解析异常 #

WiFi环境下的本地DNS服务器可能无法正确解析STUN/TURN服务器域名，导致WebRTC无法获取有效的服务器地址，进而无法生成远程候选。

排查方法：

• 在WiFi下执行命令nslookup stun.l.google.com，对比移动数据下的解析结果，确认是否返回正确的公网IP。
• 如果DNS解析异常，直接在PeerConnection配置中指定STUN/TURN服务器的IP地址替代域名。

5. ISP层面的WebRTC流量拦截 #

部分地区的ISP会针对WiFi网络（共享带宽场景）拦截WebRTC流量，以控制带宽消耗或满足合规要求，而移动数据网络未做此类限制。

排查方法：

• 连接美国节点的VPN后，再用WiFi测试WebRTC连接。如果VPN环境下连接正常，即可确认是本地ISP的流量拦截导致问题。

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