Nginx轮询仅均分请求数量，不感知延迟，需依赖超时、健康检查、重试及故障隔离机制（如proxy_read_timeout、proxy_next_upstream、max_fails）来规避慢节点；优化可选least_conn或权重调度。
Nginx 默认轮询（Round Robin）本身不感知延迟，也不会主动规避高延迟节点——它只按顺序发请求，不管后端响应快慢。所以高延迟节点会持续被轮到，拖累整体响应，甚至引发雪崩。真正起作用的是配合它的健康检查与超时机制，而非轮询算法本身。
轮询不等于“平均分配质量”，只是“平均分配次数”
轮询只保证请求数量均等，不保证处理质量。比如三台后端：A（P95=100ms）、B（P95=800ms）、C（P95=120ms），轮询仍会给B同样多的请求，结果大量请求卡在B上，用户侧看到的就是整体延迟飙升。
必须靠超时 + 重试 + 故障隔离来补足
-
proxy_connect_timeout控制建连阶段是否及时放弃不可达节点 -
proxy_read_timeout决定Nginx等后端响应多久，超时即中断并触发重试 -
proxy_next_upstream error timeout http_500 http_502 http_503 http_504让超时或错误自动转向下一个节点 -
max_fails=2 fail_timeout=15s表示连续两次失败就将该节点标记为不可用，15秒内不再分发请求
这些配置组合起来，才能让轮询“看起来聪明”：不是绕开慢节点，而是快速失败、快速切换、快速恢复。
高延迟节点容易被误判为“宕机”，需合理设参
如果 proxy_read_timeout 设得太短（比如仅1s），而实际后端P95是1.2s，就会频繁触发重试和摘除，造成健康节点被误踢；设得太长（如60s），又会让用户白白等待。建议取值为：后端P95耗时 + 2–4秒缓冲，再结合日志中 $upstream_response_time 分布调整。
更优替代方案：least_conn 或带权重的动态调度
- 对长连接或响应时间差异大的场景，
least_conn更合适——它选当前活跃连接最少的后端，天然避开已堆积请求的慢节点。 - 若后端性能差异明显，用
weight手动调低慢节点权重（如server 192.168.1.102 weight=1;），比依赖轮询更可控。 - 配合
max_conns（如max_conns=500;）可硬性限制单节点并发上限，防止单点过载。
不复杂但容易忽略
