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 作为反向代理时：

Nginx Hosting

通过服务器本地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（轮询最稳，适合传统应用）

不复杂但容易忽略。