http/3在nginx中需客户端、链路与服务端协同，关键在于平滑降级；须配置alt-svc头、双监听（tcp+udp）、强制tlsv1.3，并验证回落是否生效。
HTTP/3 在 Nginx 中不是“全有或全无”的开关，而是一套需要客户端、网络链路和服务端协同工作的协商机制。真正关键的不是“配没配 HTTP/3”，而是“降级是否平滑、用户是否无感”。浏览器不支持、防火墙拦截、UDP 丢包、中间设备干扰——这些都可能让 QUIC 连接失败，此时必须自动回落到 HTTP/2 或 HTTP/1.1，否则页面白屏、资源加载中断。
浏览器端自动协商与 Alt-Svc 头是降级起点
HTTP/3 升级依赖服务器主动声明能力。Nginx 必须通过响应头明确告知浏览器：“我支持 h3，可用端口是 443，有效期 24 小时”。配置必须严格：
- add_header Alt-Svc 'h3=":443"; ma=86400'; —— 引号、空格、等号、冒号缺一不可；ma 值建议设为 86400（24 小时），避免频繁重协商
- 该头需在所有 HTTPS 响应中统一返回（包括 301/302、静态资源、API 接口），不能只加在 HTML 主文档上
- 若使用 CDN 或反向代理，需确认它未过滤或覆盖 Alt-Svc 头；Cloudflare 等厂商默认透传，但自建 Nginx 前置层常会丢失
服务端双监听 + TLS 强制约束保障回退通道
Nginx 不提供“http3 on”这类开关，启用靠的是监听指令组合。降级能否生效，取决于 TCP 和 UDP 两套路径是否并存且互不干扰：
- 必须同时配置两行 listen：
listen 443 ssl http2;（保底 TCP 路径）
listen 443 quic reuseport;（QUIC 入口） - SSL 必须强制 TLSv1.3：ssl_protocols TLSv1.3; —— HTTP/3 不支持 TLS 1.2 及以下，但 HTTP/2 仍可兼容旧客户端
- 禁用中间盒降级：ssl_conf_command Options -no_middlebox_degradation;，防止某些网络设备因识别不到传统 TCP 握手而主动干扰
验证降级是否真实有效：关掉 QUIC 再测一次
配置写对 ≠ 实际可用。最可靠的验证方式是人为制造 QUIC 失效，观察是否自动切回 HTTP/2：
- 临时注释掉 nginx.conf 中的 listen 443 quic reuseport; 行，执行 nginx -s reload
- 用 Chrome 打开开发者工具 → Network → 刷新页面 → 查任意请求的 Protocol 字段，应显示 h2 或 http/1.1
- 恢复 QUIC 配置后，再次刷新，Protocol 应变为 h3，且页面加载时间明显缩短（尤其弱网模拟下）
- 注意：Firefox 默认不启用 HTTP/3，需访问 about:config 开启 network.http.http3.enabled；Safari 用户需 macOS 14+ 且开启实验性功能
中间链路与客户端兼容性兜底策略
即使 Nginx 和浏览器都支持，公网路径上的干扰仍可能导致 QUIC 连接失败。这时需从部署侧做容错：
- 云服务器安全组、本地防火墙、企业出口网关，必须放行 UDP 443 入向流量；仅开放 TCP 443 是常见疏漏
- 老旧 CDN、WAF 或运营商设备可能静默丢弃 QUIC 包。若发现部分区域用户始终无法触发 h3，可考虑在 DNS 层按地域灰度：将特定 IP 段解析到关闭 QUIC 的备用 Nginx 实例
- 前端可通过 JavaScript 检测当前连接协议：
if (navigator.connection?.protocol === 'h3') { /* 加载 QUIC 优化资源 */ } else { /* 加载兼容性 fallback 脚本 */ }
