非NAT环境下WebRTC客户端是否应生成SRFLX ICE候选？测试差异分析

核心问题 #

非NAT环境下，客户端与STUN服务器通信时，是否应生成本地SRFLX ICE候选？还是因HOST候选已包含公网IP而被优化？

测试背景 #

• 环境：Chrome 112.0.5615.50（Windows 11）
• 测试结果：两款Trickle ICE测试工具表现不一致
  • 工具1：仅生成HOST候选，10秒后触发STUN绑定请求超时（错误码701）
  • 工具2：立即生成SRFLX候选，即使出现STUN主机查找错误（错误码701）仍保留候选
• 排查结论：两款工具的API调用参数、系统安全标签、STUN认证参数均无差异

疑问解答 #

1. 结果差异的成因 #

Chrome的ICE候选生成逻辑会根据STUN请求的错误类型和本地网络接口状态动态调整：

• 工具2遇到的是STUN主机查找错误（域名解析类问题），Chrome判定STUN服务器地址不可达，但此时本地网卡已持有公网IP，因此会直接生成模拟的SRFLX候选（无需等待STUN绑定响应）；
• 工具1遇到的是STUN绑定请求超时，Chrome判定STUN服务器完全无法通信，此时会跳过SRFLX候选生成——因为无法验证公网IP的外部可达性，且HOST候选已是公网IP，被判定为冗余。

此外，两款工具的ICE代理配置、STUN服务器的实际路由路径可能存在细微差异，导致Chrome触发不同的候选生成分支。

2. 哪种候选更利于连接？ #

非NAT环境下，含公网IP的HOST候选优先级更高：

• HOST候选直接使用本地网卡的公网IP，延迟更低、可靠性更强，无需经过STUN服务器中转；
• SRFLX候选属于冗余选项，但在部分场景下可作为备选（如防火墙限制直连、对等端仅支持SRFLX候选等）。

3. 为何工具2能生成SRFLX候选？ #

工具2触发的STUN主机查找错误，触发了Chrome的兜底逻辑：即使STUN服务器域名解析失败，只要本地已有公网IP，就直接生成SRFLX候选，避免因STUN服务故障导致无公网候选可用。

4. HOST候选含公网IP时SRFLX候选的意义 #

• 兼容性兜底：部分老旧WebRTC客户端或对等端可能优先识别SRFLX候选；
• 可达性验证：SRFLX候选是经STUN服务器确认的公网IP，可验证该IP是否能被外部主动访问（HOST候选的公网IP可能受防火墙限制）；
• 动态IP适配：本地公网IP动态变化时，SRFLX候选可通过STUN服务器实时获取最新IP，避免HOST候选缓存旧地址。

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