Nginx轮询在高吞吐代理中需结合主动健康检查、keepalive连接池优化、合理权重与least_conn兜底，并通过日志和监控验证调度均衡性。
在高吞吐量 Web 代理场景下，Nginx 的轮询（round-robin）调度本身简单可靠，但默认配置容易成为性能瓶颈。关键不在于“是否启用轮询”，而在于如何让轮询真正适配高并发、低延迟、连接复用强的现代后端服务。
后端健康检查必须开启
纯轮询不感知节点状态，一旦某台上游服务器卡顿或响应变慢，请求仍会持续分发过去，导致整体延迟飙升甚至雪崩。建议搭配主动健康检查：
- 使用 health_check 指令（需 stream 或 http 模块支持），设置间隔（如
interval=3s）、失败阈值（fails=2）和恢复阈值（passes=2） - 配合 max_fails 和 fail_timeout 实现快速摘除，例如：
max_fails=3 fail_timeout=10s - 避免仅依赖 passive 检查（如 5xx 返回码），应主动发送轻量探测请求（如 GET /health）
连接复用与 keepalive 需精细控制
高吞吐下，频繁建连/断连开销远超调度本身。轮询效果受限于 upstream 连接池效率：
- 在 upstream 块中启用 keepalive 32（保持空闲连接数），并确保后端支持 HTTP/1.1 keep-alive 或 HTTP/2
- 客户端侧设置 proxy_http_version 1.1 和 proxy_set_header Connection ""，显式清除 Connection: close 头，防止连接被意外关闭
- 避免 upstream 中混用 HTTP/1.0 和 HTTP/1.1 后端，否则 keepalive 行为不一致，连接池利用率骤降
权重与动态负载需谨慎补充
纯轮询在硬件配置不均或后端处理能力波动时易失衡。但盲目加权反而削弱自动适应性：
- 若后端实例规格不同（如 4C8G 与 8C16G），可设初始权重（
weight=1vsweight=2），但不宜超过 3 倍差距 - 更推荐结合 least_conn 作为兜底策略（在 server 块中添加
least_conn参数），尤其适用于长连接或响应时间差异大的场景 - 避免在高吞吐下依赖第三方模块（如 nginx-upstream-check）做复杂负载评估，其自身可能成为瓶颈
日志与监控要覆盖调度行为
轮询看似无状态，但实际分发偏差会暴露配置或网络问题：
- 启用 $upstream_addr 和 $upstream_response_time 记录到 access_log，便于分析各节点请求分布与耗时离散度
- 通过 stub_status 或第三方 exporter（如 nginx-vts）监控
upstream servers active/idle数量，及时发现连接池枯竭 - 定期采样检查
upstream_cache_status（若启用缓存），确认轮询未因缓存命中率差异造成后端流量倾斜
