工程上最危险的不是完全不可用，而是在理想环境里正常、进入真实网络和真实数据量后悄悄失去边界。 无法仅从一个失败包证明 UDP 被封，可能是节点、DNS 或 NAT 问题。诊断需要比较 UDP TURN 与同域 TCP/TLS 以及 STUN 响应。
网络诊断必须区分观察事实与推断结论。候选类型、选中路径和阶段耗时可以证明连接过程，完整 IP 或一次探测结果既不必要，也不足以代表真实可达性。
工程边界与取舍
实现之前先列出不可违反的不变量，再为性能与体验留出调节参数。参数可以灰度，身份、权限和终态规则不能在运行时随意漂移。
- 候选收集并行包括 UDP 和有限后备，记录每 transport 的 allocation/check 结果；UDP 在预算内无任何响应且 TLS 成功时给出高置信提示。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 兼容性通过显式能力协商决定，旧客户端得到可解释的降级路径，而不是进入半可用状态。
“UDP 被封时怎么快速判断并切后备，不让用户干等”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
生产环境会怎样出错
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 串行先等 UDP 20 秒会让企业网络体验极差；一次 TCP 成功就永久记住禁 UDP 会在用户换网后继续走慢路径。
- 失败被压成一个布尔值，调用方无法区分可重试、需用户介入与永久拒绝，最终形成无限循环。
- 降级路径从未压测，主路径故障时所有流量同时进入更慢、更昂贵的后备方案。
把测试跑成闭环
测试不能以“最后成功了”结束。还要测量经历了多少次副作用、等待多久、是否泄露内容，以及失败后再次执行能否从干净基线开始。
- 在全 UDP、仅 3478 UDP、全部 UDP 被封、单 TURN 节点故障和网络切换中测首次连接、误判、缓存失效与最终路径。
- 让刷新、取消、超时和远端完成在同一调度窗口发生，断言系统只产生一个终态和一次副作用。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
当实现能够安全降级、重复执行不产生额外副作用、故障指标早于投诉出现时，这项能力才算具备长期维护价值。