Nginx upstream模块不支持HTTP/3上游代理，因其基于TCP连接池和HTTP/1.x/2帧解析，未实现QUIC流复用、UDP socket管理及ALPN透传；当前生产方案均为HTTP/3终结+HTTP/1.1或HTTP/2回源。
Nginx 负载均衡层本身不支持 HTTP/3 上游代理，它只能终结 QUIC 连接，无法将 HTTP/3 请求原样转发给后端服务。当前所有稳定生产环境中的“Nginx + HTTP/3”组合，本质都是HTTP/3 终结 + HTTP/1.1 或 HTTP/2 回源，负载均衡逻辑仍运行在 TCP 层。
为什么 Nginx 的 upstream 不能代理 HTTP/3？
这不是配置遗漏，而是协议与架构层面的限制：
- Nginx 的
ngx_http_upstream_module设计基于 TCP 连接池和 HTTP/1.x 或 HTTP/2 的帧解析，没有实现 QUIC 流（stream）的复用、丢包重传、连接迁移等语义 - QUIC 基于 UDP，而 upstream 模块不管理 UDP socket 生命周期，也不支持 ALPN 协商透传或 h3-29/h3-Q050 等 QUIC 版本协商
- 即使使用 nginx-quic 分支，
proxy_pass https://backend仍会降级为 TLS over TCP；proxy_pass http3://...在官方主线中不存在该协议方案
可行的分层负载均衡架构
把协议处理与流量调度解耦，是当前最成熟、低风险的路径：
-
Caddy 作为 QUIC 入口：Caddy 2.7+ 原生支持 HTTP/3 终结、自动证书、健康检查；通过
reverse_proxy将解包后的请求以 HTTP/1.1 或 HTTP/2 转发至 Nginx 集群，Nginx 专注做缓存、鉴权、动静分离与后端负载均衡 -
Envoy 作为边缘网关：Envoy v1.26+ 启用
quic_transport_socket监听 UDP 443，配合cluster指向 Nginx 实例；其可观测性、熔断、路由策略远超 Nginx upstream，适合微服务边界 -
双监听 + DNS 轮询（轻量级）：Nginx 自身终结 HTTP/3（
listen 443 quic reuseport），后端用标准 upstream 做 TCP 层负载均衡；客户端直连 Nginx 节点，靠 DNS 或 L4 负载均衡器（如 MetalLB、HAProxy TCP mode）分发 UDP 流量
Nginx 自身启用 HTTP/3 终结的关键配置
若你选择让 Nginx 承担 QUIC 终结角色（即前端负载节点），需确保以下最小集合全部到位：
- 使用 Nginx ≥ 1.25.0 主线版，编译时启用
--with-http_v3_module和--with-stream_quic_module - 操作系统内核 ≥ 5.4（提升 UDP socket 性能），防火墙放行
UDP/443（常被忽略） - SSL 库建议 BoringSSL 或 quictls；强制
ssl_protocols TLSv1.3，禁用降级：ssl_conf_command Options -no_middlebox_degradation - server 块中必须同时存在两行监听：
listen 443 ssl http2;（兼容旧客户端）和listen 443 quic reuseport;（启用 QUIC） - 添加标准 Alt-Svc 头：
add_header Alt-Svc 'h3=":443"; ma=86400';；不要写http3 on;（非官方指令）
验证与可观测性要点
别依赖 curl 默认行为——它多数版本不识别 HTTP/3：
- Chrome 访问后打开
chrome://net-internals/#quic，搜索域名，看到ESTABLISHED状态且 version 为Q050或Q051才算成功 - 终端验证用支持 quiche 的 curl：
curl -I --http3 https://yourdomain.com，并检查响应头含Alt-Svc - Linux 下执行
ss -u -n | grep :443，确认有 UDP socket 处于ESTAB状态 - 注意：Alt-Svc 头仅提示客户端“可尝试升级”，是否真正走 QUIC 还取决于网络路径（中间设备是否拦截 UDP）、客户端能力及 TLS 协商结果
