这类问题看似集中在一个 API 或参数上，真正决定可用性的却是状态归属、资源上限和失败后的恢复方式。 最近的地理位置不一定有最低网络时延，最低 RTT 节点也不一定有足够带宽。下发策略需要把用户粗略区域、节点健康、实时容量和 UDP/TCP/TLS 能力一起考虑，并限制候选数量。
WebRTC 的判断依据必须来自两端状态、信令版本和实际选中的候选对。只看某个浏览器回调会遗漏 glare、ICE 切路与对端刷新造成的分叉。
先把实现决策说清楚
落地时要把关键选择变成稳定契约：输入如何校验、状态由谁推进、资源何时释放、旧版本如何降级。只有这样，后续优化才不会改变原有语义。
- 服务端先过滤不健康或容量告警节点，再下发本区域主节点与一个跨区域后备。
- 客户端让 ICE 并行检查少量 relay 候选，不自行串行 ping 每个大陆。
- 凭据对所有下发节点使用一致身份与配额语义，但密钥和审计按区域隔离。
多地域 TURN 的目标不是列出更多服务器，而是用少量、健康、协议完整的候选降低尾延迟，并让故障转移在用户感知前完成。
最容易漏掉的失败路径
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- DNS 只按来源解析器定位，使用公共 DNS 的用户被送到错误大陆。
- 列表包含十几个 TURN URL，浏览器候选收集变慢并制造无意义 allocation。
- 故障转移节点没有相同的端口和协议配置，主节点故障时后备也无法穿透。
上线前怎样验证
验证时同时观察两端状态、持久化记录和可观测指标。单看某个按钮或一次接口响应，无法证明整个闭环成立。
- 从不同运营商而不只是云主机测量候选收集、首包 RTT 和稳定吞吐。
- 下线主区域并保持现有 allocation，验证新连接转移且旧连接不被立即切断。
- 制造节点健康正常但带宽接近上限的状态，确认容量信号能降低新流量分配。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。