Nginx upstream轮询在HTTP/1.1下最稳定，HTTP/2下因连接复用易致负载倾斜，需least_conn等策略缓解，HTTP/3上游代理不支持，轮询无意义。
Nginx 的 upstream 轮询（round-robin）调度本身不感知协议版本，它只负责在 TCP 连接层面分发请求。真正影响轮询行为是否“有效”或“合理”的，是后端协议类型、连接复用机制以及 Nginx 对该协议的处理能力。
简单说：轮询能用，但用得对不对，取决于你代理的是 HTTP/1.1、HTTP/2 还是 HTTP/3 —— 因为每种协议对连接生命周期、复用粒度和错误恢复的处理完全不同。
HTTP/1.1 代理：轮询最稳定、最直观
Nginx 的默认轮询在 HTTP/1.1 场景下表现最佳，原因在于：
- 每个请求通常独占一个短连接（除非启用
keepalive） - 后端服务响应后连接可快速释放，Nginx 能及时回收并分配给下一个请求
-
least_conn、ip_hash等策略也在此场景下语义清晰
建议配置要点：
-
显式开启连接池复用（提升吞吐）：
upstream backend { server 10.0.1.10:8080; server 10.0.1.11:8080; keepalive 32; # 每个 worker 保持最多 32 个空闲连接 } location / { proxy_pass http://backend; proxy_http_version 1.1; proxy_set_header Connection ''; proxy_set_header Upgrade $http_upgrade; } 若后端支持长连接，配合
keepalive_timeout和keepalive_requests控制复用深度，避免单节点连接堆积。
HTTP/2 代理：轮询仍可用，但需注意连接复用放大效应
HTTP/2 天然支持多路复用，一个 TCP 连接可承载数十甚至上百并发流。Nginx 作为反向代理时：
-
proxy_http_version 2.0会启用 HTTP/2 上游通信（要求后端支持 h2 over TLS） - 但轮询调度对象仍是「连接」，不是「流」——即一个后端节点一旦被选中建立连接，后续大量流可能持续复用该连接，导致负载倾斜
常见问题：
- 首次请求触发新建连接 → 被轮询到 A 节点
- 接下来 100 个并发请求复用该连接 → 全部打到 A，B/C 闲置
- 表面看轮询均匀，实际流量严重不均
缓解方式：
- 启用
least_conn替代纯轮询（按活跃连接数而非请求数） - 限制单连接并发流数（后端控制更有效，Nginx 无原生
http2_max_concurrent_streams上游级参数） - 在上游块中添加健康检查与慢启动，避免新节点被瞬间压垮
HTTP/3（QUIC）代理：Nginx 不支持上游 HTTP/3，轮询无实际意义
这是关键限制：Nginx 的 upstream 模块完全不支持 http3:// 或 quic:// 协议。
-
proxy_pass https://backend无论怎么写，都走 TLS over TCP，不会变成 QUIC -
proxy_pass http3://backend在官方主线中不存在，也不被解析 - 所有“Nginx + HTTP/3”生产部署，都是 Nginx 终结 QUIC（监听
quic reuseport），再以 HTTP/1.1 或 HTTP/2 转发给后端 → 此时轮询作用于 TCP 层，与 QUIC 无关
换句话说：
✅ Nginx 可以用轮询调度后端 HTTP/1.1 或 HTTP/2 服务（无论前端是 HTTP/1.1、HTTP/2 还是 HTTP/3）
❌ Nginx 无法用轮询调度 HTTP/3 后端，因为根本不能发起 HTTP/3 上游请求
若真需 HTTP/3 回源，必须换网关（如 Envoy、Caddy）或采用双层架构（Caddy 终结 QUIC → Nginx 集群做 TCP 层轮询）。
实际选型建议：按协议层级分层决策
- 前端协议（客户端 → Nginx）：决定用户体验（HTTP/3 终结可加速首屏）
- 中间协议（Nginx → 后端）：决定运维可控性与负载均衡效果
- 推荐组合：
- 客户端 HTTP/3 → Nginx（QUIC 终结）→ 后端 HTTP/2（轮询有效，连接复用可控）
- 客户端 HTTP/2 → Nginx（HTTP/2 代理）→ 后端 HTTP/2（需配合
least_conn或连接数限流） - 客户端 HTTP/1.1 → Nginx（HTTP/1.1 代理）→ 后端 HTTP/1.1（轮询最稳，适合传统应用）
不复杂但容易忽略。
