nginx轮询本身不感知请求积压，需依赖健康检查、max_fails/fail_timeout剔除慢节点、max_conns限制并发、三类超时切断等待链及必要时切换least_conn算法协同防控。
Nginx 的轮询调度本身不主动应对请求积压，它只是按顺序分发新请求。真正缓解积压，靠的是围绕轮询配置的一系列协同机制——健康检查快速剔除慢节点、连接控制限制并发、超时策略防止阻塞、以及必要时切换更适配的算法。
轮询不感知积压，但能配合机制规避恶化
轮询只数请求次数，不管后端是否已堆积大量未完成任务。一台响应变慢的服务器，在轮询下仍会持续收到新请求，积压只会加剧。所以不能依赖轮询“自动调节”，而要靠外部配置把它变成“可干预的分发通道”。
用 max_fails + fail_timeout 主动跳过慢节点
这是最直接有效的积压防控手段。当某台后端因负载高、GC卡顿或锁竞争导致响应延迟，连续失败（如超时或返回 502/504）达到阈值，Nginx 就暂时将其从轮询队列中移出：
- server 192.168.1.10:8080 max_fails=2 fail_timeout=10s;
- 表示 10 秒内失败 2 次，即暂停调度 10 秒
这样避免把新请求继续压向已积压的节点，给它喘息和恢复的机会。
用 max_conns 限制单节点并发连接数
尤其适用于动态接口或长耗时请求（如导出、转码）。即使轮询分到该节点，若当前活跃连接已达上限，Nginx 会排队或返回 503，而不是强行转发：
- server 192.168.1.10:8080 weight=1 max_conns=50;
- 配合后端应用层超时设置（如 Spring Boot 的 server.tomcat.connection-timeout），形成双重保护
小内存或低配机器特别需要这项配置，否则一个慢请求就能拖垮整台服务。
收紧三类超时，切断无效等待链
积压常源于“等不到结果却一直占着连接”。必须明确每个环节的等待边界：
- proxy_connect_timeout 2s：建连不能拖，避免卡在 TCP 握手
- proxy_send_timeout 15s：发完请求后，后端得及时收走数据
- proxy_read_timeout 30s：等待响应总时长，略高于业务 P95 耗时即可
过长的 proxy_read_timeout 是积压温床，尤其对长轮询或流式接口，应严格按实际业务设定。
必要时换 least_conn，让调度贴近真实负载
如果积压反复出现在某些节点，且日志显示它们活跃连接数远高于其他节点，说明轮询已失衡。此时应改用 least_conn 算法：
- upstream backend { least_conn; server ...; server ...; }
它每次选当前活跃连接最少的后端，对长连接、耗时差异大的动态请求更公平。可与 max_conns 和 weight 共存，兼顾能力与实时负载。
不复杂但容易忽略
