这类问题看似集中在一个 API 或参数上，真正决定可用性的却是状态归属、资源上限和失败后的恢复方式。 TURN 面向公网接收任意客户端包，错误的 anonymous 或静态账户配置会变成免费代理。realm 参与凭据派生，节点间必须一致且不可随意改变。
TURN 是有成本的共享中继，不只是一个 ICE URL。节点需要短期授权、allocation 并发、字节核算、区域容量和滥用处置，同时保留 UDP、TCP 与 TLS 穿透能力。
先把实现决策说清楚
先从数据和协议能保证的事实出发，再决定界面承诺。下面的规则都应有明确所有者、边界值和兼容策略，不能只存在于某次代码评审的口头共识里。
- 仅监听需要的公网/私网接口，启用 use-auth-secret、fingerprint 与 stale-nonce；拒绝环回、链路本地、私网和云元数据 peer 地址。
- 所有输入都设置大小、次数和时间预算，并在超限时返回可操作的稳定错误码。
- 资源释放是协议的一部分：定时器、句柄、队列和临时数据都要在终态中可重复清理。
“coturn 生产加固：匿名中继、开放端口和默认配置都要关”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
最容易漏掉的失败路径
最值得优先排查的是会静默留下错误事实的故障：界面看似恢复，底层队列、权限或计数却已分叉。这类问题通常在下一次动作才暴露。
- 允许任意 peer IP 会被 TURN 用来扫描内网；把 CLI/metrics 管理端口暴露公网又泄露会话和控制能力。
- 刷新或网络切换同时触发两条恢复路径，重复副作用被误当成两次真实用户操作。
- 降级路径从未压测，主路径故障时所有流量同时进入更慢、更昂贵的后备方案。
上线前怎样验证
验证时同时观察两端状态、持久化记录和可观测指标。单看某个按钮或一次接口响应，无法证明整个闭环成立。
- 用无凭据、过期凭据、错误 realm、私网 peer、端口扫描和合法 WebRTC 五类探测，配合外部扫描确认只开放预期表面。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
最终结果应同时满足正确性、可恢复性和可解释性。任何一项只能依赖刷新页面或工程师猜测，都说明协议闭环仍不完整。