nginx 不支持 http/3 透传，仅能作为 quic 终结点，将客户端 quic 连接解包为 http/1.1 或 http/2 后通过 tcp 转发至后端；其负载均衡完全基于解包后的 http 字段，需配合 listen 443 quic reuseport、ssl_protocols tlsv1.3 及 upstream 配置实现。
Nginx 无法将 HTTP/3（QUIC）流量原样分发到后端服务器——它不支持 QUIC 透传，也不提供 proxy_pass http3:// 这类指令。所谓“HTTP/3 配合负载均衡”，实际是让 Nginx 充当 QUIC 终结点，把客户端的 UDP/443 QUIC 连接解包为 HTTP/1.1 或 HTTP/2，再通过 TCP 转发给上游服务。后端看到的永远是传统 HTTP 流量，不是 QUIC。
Nginx 在 HTTP/3 架构中的真实角色
- ✅ 接收并终结客户端的 QUIC 连接（需启用
listen 443 quic reuseport;和 TLS 1.3） - ✅ 处理 0-RTT、连接迁移、加密握手等 QUIC 特性
- ✅ 将解包后的请求按标准 HTTP 协议转发（默认 HTTP/1.1；若 upstream 支持且配置了
http2，可走 HTTP/2） - ❌ 不转发
:scheme=h3、alt-svc头或任何 QUIC 流元信息 - ❌ 不支持基于 QUIC 流 ID、路径优先级或无序交付特征做路由决策
实现 HTTP/3 入口 + 后端负载均衡的关键配置
Nginx 的负载均衡逻辑完全基于解包后的 HTTP 请求字段，与是否启用 HTTP/3 无关。你只需确保：
- 在
upstream块中定义后端服务器组，并选择合适策略 -
server块同时监听 HTTP/3（QUIC）和 HTTP/2 over TLS（TCP），实现平滑降级 - 补充必要头信息，使后端能识别原始协议与客户端真实信息
http {
upstream app_backend {
least_conn;
server 10.0.1.10:8080 weight=3;
server 10.0.1.11:8080;
server 10.0.1.12:8080 backup;
}
server {
listen 443 ssl http2;
listen 443 quic reuseport;
ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
ssl_protocols TLSv1.3;
# 强制 QUIC 终结后仍保留协议标识供后端参考
proxy_set_header X-Original-Proto $scheme;
proxy_set_header X-Request-Protocol "h3"; # 若来自 QUIC，$scheme 是 https，但可额外标记
location / {
proxy_pass http://app_backend;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
}
替代方案：需要真正 QUIC 分发时该怎么做
如果业务强依赖后端直连 QUIC（例如微服务间低延迟通信、IoT 设备端到端 h3 路由），Nginx 不适用。此时应换用：
-
Caddy 2.7+：原生支持
reverse_proxy到h3://上游，可做 QUIC 终结 + 透传或重封装 -
Envoy 1.26+：通过
quic_transport_socket和http3_protocol_options实现 QUIC 上游代理 - 自研边缘网关：基于 quiche 或 MsQuic 构建，控制 QUIC 流粒度路由（如按 ALPN、SNI、路径前缀）
Nginx 的定位很清晰：它是面向终端用户的现代协议入口，不是 QUIC 网络层的中继设备。把 QUIC 终结放在边缘，把负载均衡留在应用层，是当前最稳定、最易运维的架构选择。
