least_conn能缓解压力不均但需四大前提：后端状态可感知、连接复用真实、调度依据可靠、健康检查与keepalive配置完备，否则仅是摆设。
直接用 least_conn 能缓解压力不均，但光加这一行配置远远不够。它真正起效的前提是：后端状态可感知、连接复用真实、调度依据可靠。
为什么 least_conn 常常“不起作用”
不是算法失效，而是环境没配齐，导致 Nginx 看不到真实的负载：
- 宕机或卡死的节点未被及时剔除，仍参与 least_conn 比较，新请求持续打过去失败重试
- 后端每请求新建连接（无 keepalive），活跃连接数瞬间归零，least_conn 变成伪随机分发
- 某台机器响应慢但未超时，连接长期占用却因 max_fails 缺失未被隔离，连接数越堆越高
- 客户端强制关闭连接、后端未正确释放 socket，造成连接泄漏，统计值失真
必须配齐的四个关键项
缺一不可，否则 least_conn 就只是个摆设：
- upstream 中显式声明 least_conn：不能依赖默认或混在其他策略里
-
每个 server 配 max_fails 和 fail_timeout：例如
server 10.0.1.10:8080 max_fails=2 fail_timeout=15s;，让被动健康检查能生效 -
启用 proxy_next_upstream 错误兜底：至少包含
error timeout http_500 http_502，确保后端过载返回 502 时自动切走 -
upstream 开启 keepalive 并与后端对齐：如
keepalive 32;，同时后端服务（如 Tomcat、Node.js）也要开启连接池并设置合理最大空闲数
验证是否真正在“最少连接”
别只看日志里转发到哪台，要确认底层连接分布是否符合预期：
- 开启
stub_status，访问/nginx_status查看各 upstream server 的Active connections - 在 log_format 中加入
$upstream_addr和$upstream_connect_time，观察同一时段内各节点连接建立耗时与分布比例 - 用
ss -tan | grep :8080 | grep ESTAB | wc -l在后端机器上实时核对 ESTABLISHED 连接数，对比 Nginx 统计是否一致 - 压测时关注 P95 延迟变化——若 least_conn 生效，慢节点被隔离后整体延迟应明显收敛
进阶调优建议
当基础配置已稳定，还可进一步适配业务特征：
- 后端性能差异大时，保留 weight：如 CPU 强两倍的机器设
weight=2，least_conn 在连接数接近时倾向多分请求 - 对长连接密集场景（WebSocket、gRPC），适当降低
keepalive值（如 16），提升连接数更新灵敏度 - 若发现某节点长期连接数为 0，检查其网络路径、防火墙策略，或是否存在后端主动拒绝复用的行为
- 避免和
ip_hash或hash $request_uri混用——least_conn 只在 upstream 内部生效，哈希类策略会覆盖其逻辑
