nginx截至2026年5月仅支持http/3终结（客户端↔nginx），不支持http/3反向代理；需nginx≥1.25.0、linux内核≥5.4、udp 443放行、boringssl/quictls、tlsv1.3，并配置listen 443 quic reuseport与add_header alt-svc。
截至 2026 年 5 月，Nginx 主线版本（如 1.25.x 至最新发布的 1.30.0）已提供对 HTTP/3 的实验性终结支持，但不支持 HTTP/3 反向代理。它能接收并解包客户端发来的 QUIC 连接，但后端通信仍必须使用 HTTP/1.1 或 HTTP/2。这意味着：HTTP/3 仅作用于“客户端 ↔ Nginx”这一跳，无法透传至上游服务。
实验性支持的硬性前提
Nginx 启用 HTTP/3 不是加一行配置就能生效，以下条件缺一不可：
-
Nginx 版本 ≥ 1.25.0，且编译时明确启用了
--with-http_v3_module和--with-stream_quic_module - 操作系统内核 ≥ 5.4（推荐 ≥ 5.7），确保 UDP 性能与 socket 选项稳定
- 防火墙必须放行 UDP 443 端口——这是最常被忽略、导致 QUIC 完全不可用的关键点
- SSL 库需兼容 QUIC：BoringSSL 或 quictls 是首选；OpenSSL 3.2+ 可用但功能受限，且不支持部分高级 QUIC 特性
-
TLS 强制为 TLSv1.3，并禁用降级机制：
ssl_protocols TLSv1.3;+ssl_conf_command Options -no_middlebox_degradation;
核心配置要点（非可选）
正确配置不是“开启 HTTP/3”，而是让客户端发现并成功建立 QUIC 连接。关键指令如下：
- 监听必须同时存在两行：
listen 443 ssl http2;（保底兼容旧客户端）和listen 443 quic reuseport;（启用 QUIC） -
没有
http3 on;指令——这是常见误解。Nginx 官方配置语法中不存在该指令，启用靠的是quic关键字 -
add_header Alt-Svc 'h3=":443"; ma=86400';必须添加，且路径、引号、空格需严格匹配，浏览器依赖此头决定是否发起 HTTP/3 请求 - 证书路径对 TCP 和 UDP 共用同一套，无需额外配置
为什么不能反向代理 HTTP/3 上游？
Nginx 当前架构未实现 HTTP/3 作为 client 发起请求的能力。即使你配置了 proxy_pass https://upstream:443，实际发出的仍是 HTTP/1.1 或 HTTP/2 请求（取决于 upstream 配置）。QUIC 终结后，协议降级是必然行为。社区分支（如 nginx-quic）也未突破此限制，仅支持终结。
若业务需要全链路 HTTP/3，应采用分层架构：
- 前端用 Caddy 2.7+ 或 Envoy 1.26+ 终结 QUIC，并以 HTTP/2 转发给 Nginx
- Nginx 专注静态资源、负载均衡与缓存，不参与传输层协议选择
- 避免在生产环境使用 nginx-quic 分支——它依赖非标准 OpenSSL 补丁，与多数第三方模块（如 Lua、njs）不兼容，稳定性未经大规模验证
验证是否真正生效
别依赖 curl -I 默认输出，它不识别 HTTP/3：
- Chrome 浏览器访问后，打开
chrome://net-internals/#quic，搜索域名，看到 Active 状态即表示连接已走 QUIC - 开发者工具 → Network → 任一请求 → Headers → 查看响应头中是否存在格式正确的
Alt-Svc - 终端验证需用支持 QUIC 的 curl：
curl -I --http3 https://yourdomain.com（需自行编译含 quiche 的版本） - Wireshark 抓包过滤
udp.port == 443，观察是否存在 QUIC handshake 包（如 Initial、Handshake）
