Nginx 从 1.25.0 版本起支持 HTTP/3，但仅限终结 QUIC 连接，不能反向代理 HTTP/3 上游；必须满足版本、内核、UDP 443 放行、TLSv1.3 强制、BoringSSL/quictls 等硬性条件，并配置双监听与 Alt-Svc 响应头。
目前 Nginx 支持 HTTP/3，但仅限于终结（terminating）客户端发来的 QUIC 连接，不能作为 HTTP/3 客户端去代理上游服务。它把 QUIC 请求解包后，仍用 HTTP/1.1 或 HTTP/2 转发给后端。想提速，关键不是“全链路 HTTP/3”，而是让客户端快速、稳定地连上 Nginx。
必须满足的硬性前提
HTTP/3 不是加一行配置就能跑起来的协议，以下条件缺一不可：
- Nginx 版本 ≥ 1.25.0（主线版），且编译时启用了
--with-http_v3_module和--with-stream_quic_module - Linux 内核 ≥ 5.4（推荐 ≥ 5.7），保障 UDP socket 性能与稳定性
- 防火墙必须放行 UDP/443 端口——这是最常被忽略、导致 QUIC 完全失效的关键点
- SSL 库建议用 BoringSSL 或 quictls；OpenSSL 3.2+ 可运行但功能受限，不支持部分 QUIC 高级特性
- TLS 必须强制为 TLSv1.3，并禁用中间盒降级：
ssl_conf_command Options -no_middlebox_degradation - 证书有效即可（如 Let’s Encrypt），TCP 与 UDP 共用同一套证书路径
核心配置写法要准确
启用靠的是语法细节，不是开关指令。最小可行配置需包含：
- 两行监听共存：
listen 443 ssl http2;（保底兼容旧客户端）和listen 443 quic reuseport;（启用 QUIC） - 没有
http3 on;指令——Nginx 官方配置中不存在该语法，属常见误解 - 必须添加响应头：
add_header Alt-Svc 'h3=":443"; ma=86400';，浏览器依赖此头决定是否发起 HTTP/3 请求，引号、空格、大小写都需严格匹配 - 可选调优参数：
quic_max_idle_timeout 30s;、quic_initial_max_data 16m;，非必需但有助于高并发场景
如何验证是否真正生效
别信默认 curl 输出，它不识别 HTTP/3：
- Chrome 中访问站点后，打开
chrome://net-internals/#quic，搜索域名，看到 “Active” 状态即表示已走 QUIC - 开发者工具 → Network → 点开任意请求 → Headers → 查看
Alt-Svc响应头是否存在且格式正确 - 终端验证需用支持 QUIC 的 curl：
curl -I --http3 https://yourdomain.com（需提前编译含 quiche 的版本）
生产环境更推荐分层架构
把协议处理与流量调度解耦，比强求 Nginx 全栈支持更可靠：
-
Caddy 2.7+：开箱支持 HTTP/3 终结、自动证书管理、健康检查；通过
reverse_proxy将解包后的请求以 HTTP/1.1 或 HTTP/2 转发至 Nginx 集群 -
Envoy v1.26+：启用
quic_transport_socket监听 UDP 443，后端 cluster 指向 Nginx 实例；熔断、可观测性、路由策略远超 upstream 模块 - 双监听 + DNS 轮询（轻量级）：Nginx 自身终结 HTTP/3，后端仍用标准 upstream 做 TCP 层负载均衡；由 DNS 或 L4 负载器（如 HAProxy TCP mode）分发 UDP 流量
不复杂但容易忽略。
