配置STUN服务器后Chrome createAnswer无法收集srflx候选问题咨询

你遇到的这个情况其实是WebRTC ICE流程里Chrome特有的兼容性细节，我之前也碰到过类似的问题，结合你的代码和现象，给你几个排查方向：

1. 确保ICE流程的正确顺序 #

Chrome在处理createAnswer时，对SDP的依赖比createOffer更强。如果你的代码中先调用了createAnswer，再设置远端的offer SDP，Chrome就会跳过完整的ICE遍历，只收集host候选。

正确的流程必须是：

• 接收远端发送的offer SDP
• 调用pc.setRemoteDescription(offer)（必须等这个Promise resolve）
• 再调用pc.createAnswer()
• 最后设置本地answer SDP并发送给远端

如果你的代码顺序不对，先把这个调整过来，这是最常见的原因。

2. 清理ICE服务器配置的冗余字段 #

看你的iceConfig里同时写了urls和url字段——虽然url是旧版API的写法，但Chrome对这种混合配置可能出现解析异常，导致没有正确加载STUN服务器。建议统一使用新版的urls字段，去掉多余的url：

var iceConfig = { 
  iceServers: [ 
    { urls: ['stun:stun.l.google.com:19302'] } 
  ] 
};

3. 明确createAnswer的媒体方向参数 #

如果调用createAnswer时没有指定媒体接收的选项，Chrome可能会认为不需要建立完整的媒体连接，从而跳过STUN反射候选的收集。建议显式设置媒体方向：

pc.createAnswer({
  offerToReceiveAudio: true,
  offerToReceiveVideo: true
}).then(answer => {
  pc.setLocalDescription(answer);
  // 发送answer给远端
});

4. 检查Chrome的运行环境 #

• Chrome对非HTTPS环境的限制更严格：如果你的页面是通过http协议访问的（除了localhost），Chrome会禁用STUN功能，只允许host候选。测试时尽量用HTTPS或者localhost。
• 打开Chrome开发者工具的Network面板，过滤STUN请求，看有没有向stun.l.google.com:19302发起请求。如果没有请求，说明STUN配置没生效；如果有请求但无响应，可能是网络防火墙阻止了STUN流量。

先从这几个方向排查，尤其是流程顺序和配置字段，大概率能解决问题。

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