Nginx主线版本原生不支持HTTP/3，因其依赖的OpenSSL在3.2前无QUIC API，且QUIC基于UDP需重写网络栈；官方暂未将其纳入短期路线图。
目前 Nginx 官方主线版本（截至 1.25.x）**原生不支持 HTTP/3 或 QUIC**，无法通过简单配置启用。要实现 Nginx 反向代理下提供 HTTP/3 服务，必须借助外部支持 QUIC 的组件（如 nginx-quic 分支或 OpenResty + quiche），或采用“前端 QUIC 终结 + 后端 HTTP/1.1 或 HTTP/2 转发”的混合架构。
为什么标准 Nginx 不支持 HTTP/3？
Nginx 主线长期依赖 OpenSSL，而 OpenSSL 在 3.2 版本前不提供 QUIC API 支持；HTTP/3 底层基于 QUIC（UDP 协议），与传统基于 TCP 的 HTTP/1.x 和 HTTP/2 架构差异大，需重写网络栈和 TLS 集成逻辑。
- 官方明确表示：HTTP/3 不在短期路线图中，优先级低于其他功能
- 社区存在多个实验性分支（如 quictls/nginx），但非稳定生产推荐
- 即便编译了 QUIC 支持，Nginx 仍无法直接反向代理 HTTP/3 上游——它只支持终结 QUIC 连接，后端通信仍为 HTTP/1.1 或 HTTP/2
可行方案：用 Caddy 或 Envoy 做 QUIC 入口，Nginx 作后端代理
更成熟、低风险的实践是将 HTTP/3 终结交给专精此协议的服务器，再由其以 HTTP/1.1 或 HTTP/2 转发给 Nginx：
- Caddy 2.7+：开箱支持 HTTP/3，配置简洁，自动管理证书，可 proxy_pass 到本地 Nginx（http://127.0.0.1:8080）
-
Envoy（v1.26+）：通过
quic_transport_socket启用 HTTP/3 监听，配合 upstream cluster 指向 Nginx - Nginx + nginx-quic（实验分支）：仅建议测试环境使用，需手动编译 BoringSSL 或 quictls，且不兼容多数第三方模块
若坚持使用 nginx-quic 分支，关键配置要点
以 quictls/nginx 为例（基于 Nginx 1.25 + QUIC 补丁）：
- 编译时指定
--with-http_v3_module --with-openssl=...，且 OpenSSL 必须为 quictls 分支（非标准版） - 监听配置需同时开启 HTTP/2 和 H3：
listen 443 ssl http2 quic; ssl_protocols TLSv1.3; # QUIC 必须强制 TLS 1.3，且禁用所有降级选项 ssl_conf_command Options -no_middlebox_degradation;
- HTTP/3 不支持 header rewrite 等部分指令；proxy_pass 到上游时，Nginx 仍用 HTTP/1.1 发起连接（无法透传 HTTP/3）
验证 HTTP/3 是否生效
不要依赖 curl（默认不支持 H3），改用以下工具确认：
-
curl -I --http3 https://yourdomain.com（需编译含 quiche 的 curl） - 浏览器访问后，在开发者工具 → Network → Header 查看
alt-svc字段是否含h3= - Wireshark 抓包过滤
udp.port == 443，检查 QUIC handshake（Initial、Handshake 包）
不复杂但容易忽略：HTTP/3 不是“打开开关就加速”，它对弱网、高丢包场景优势明显，但在内网或稳定网络中性能提升有限；真正影响体验的是首屏加载、TLS 握手延迟和连接复用效率。先确保 TLS 1.3、OCSP Stapling、Brotli 压缩等基础优化已就位，再考虑引入 HTTP/3。
