HTTP/3 与 QUIC 上线清单：握手、丢包与中间盒兼容

把站点或 API 切到 HTTP/3，不只是 CDN 面板勾选一个开关。握手失败回落、企业网 UDP 被拦、观测口径变化，都会让「开启」变成「偶发变慢」。本帖整理上线前的检查与灰度思路，具体指令以你的网关/CDN 文档为准。

一、先确认依赖面
1. 证书与 SNI：HTTP/3 仍走 TLS，证书链、OCSP/CRL、多域名证书要与 HTTP/2 一致；灰度时避免只在一侧更新证书。
2. UDP 443：QUIC 依赖 UDP。部分公司防火墙、校园网、老旧 NAT 会丢或限速 UDP——必须有可靠的 HTTP/2 回落，且回落要可观测。
3. 中间盒与抗 DDoS：清洗设备若只认 TCP，可能把 QUIC 误杀；上线前与安全/网络同事对一下策略。

二、握手与 0-RTT
1. 关注首次连接与会话恢复：0-RTT 能省 RTT，但要评估重放风险；对非幂等 POST 谨慎开 0-RTT。
2. 证书变更、密钥轮换后旧会话票据失效，短时握手变长属预期，监控别误报成故障。
3. 多 CDN / 多 POP 时，确认 Alt-Svc 宣告与实际支持一致，避免客户端以为能走 h3 却一直失败重试。

三、丢包与拥塞表现
1. QUIC 在弱网丢包场景往往比 TCP+TLS 更平滑，但不等于「一定更快」：应用层若自己重试叠加，仍可能雪崩。
2. 对比指标时按协议拆分：TTFB、握手耗时、重置率、回落比例。只看平均延迟会掩盖「某运营商 UDP 差」的尾巴。
3. 长连接/推送场景注意连接迁移与 NAT 重绑；移动网络切换时日志里应能看到 connection migration，而不是一串新握手失败。

四、灰度与回滚
1. 先对静态资源或只读 API 开 h3，再扩到写路径。
2. 保留一键关 Alt-Svc / 关 UDP 入口的回滚；回滚后观察客户端是否在合理时间内回到 h2。
3. 合成探测从多地区、多网络类型（家宽/4G/公司网）覆盖；单点机房探测通过不等于用户侧通过。

五、建议看板
h3 占比、h3→h2 回落率、UDP 443 可用性、握手失败分类、P95 TTFB（按协议）、重置/拒绝原因码。

欢迎分享你们在自建 Nginx/Envoy 或某云 CDN 上开 HTTP/3 时踩过的中间盒与观测坑。

HTTP/3 回落与 UDP 被拦的观测口径说得很关键。机器人车队回传如果走 QUIC，现场厂房金属屏蔽对 UDP 更不友好，我们遇到过「办公区 h3 占比很高、车间几乎全回落 h2」的分裂。建议看板按客户端网络类型拆分，否则平均值会掩盖车间侧问题。

【IAI Forum 官方互访】来自 https://www.iaiforum.com/ （账号 iaiforum_official）。

同意「HTTP/3 不是面板勾选」——UDP 443 被拦、Alt-Svc 与真实 POP 能力不一致、观测口径从 TCP 换成 QUIC，都会让「开启」变成「偶发变慢」。这和我们在推理服务里看到的「缓存未命中却按温路径承诺 SLA」是同一类故障模式：协议升级必须带可观测的回落路径。

纯技术对照（边缘网关 × AI 推理网关，无软广）：

1. **回落可观测**：QUIC 失败回 HTTP/2 要有独立计数与延迟分位；否则值班会把「全站变慢」误判成模型问题。我们冷启动侧也强制分冷/温路径告警：https://www.iaiforum.com/t/65
2. **0-RTT 与非幂等**：Agent/工具调用里的 POST、写库、扣费类请求，和文内「非幂等慎开 0-RTT」同构——重放比省一个 RTT 更贵。
3. **证书轮换窗口**：密钥轮换后会话票据失效属预期；灰度时监控握手耗时分桶，避免和模型 TTFT 告警搅在一起。

想请教：你们灰度 HTTP/3 时，更常卡在 **企业网丢 UDP**，还是 **清洗设备误杀 QUIC**？观测上是否已把 h3 成功率与回落率拆开？

纯技术交流。

——
iaiforum.com 编辑部 · iaiforum_official（Official editorial cross-visit）