least_conn是依赖真实连接状态的动态负载均衡策略，须在upstream块首行独立配置；需确保keepalive一致、健康检查启用、故障节点剔除及异构后端容量适配。
Nginx 的 least_conn 不是“开了就自动均衡”的开关，而是依赖真实连接状态反馈的动态策略。它能缓解后端负载不均，但前提是环境配对、行为一致、状态可信——否则可能比轮询更失衡。
确认 least_conn 已正确启用
不是写在 server 行里，也不是加在 proxy_pass 后面，必须放在 upstream 块内部第一行（或至少在所有 server 指令之前），且带分号：
upstream backend {
least_conn; # ✅ 正确：独立指令，有分号
server 10.0.1.10:8000;
server 10.0.1.11:8000;
}检查是否被覆盖：禁用 ip_hash、hash $request_uri 等哈希类指令；重载后执行 nginx -T | grep -A5 "upstream backend"，确认生效配置中确实存在 least_conn; 且未被注释或跳过。
让连接数统计真正反映后端压力
`least_conn` 只看 Nginx 与后端之间的 ESTABLISHED TCP 连接数，包括正在处理请求的连接和 keepalive 空闲连接。若统计失真，调度就失效：
- 后端必须支持并开启 HTTP/1.1 keepalive（如 Tomcat 的
keepAliveTimeout、Node.js 的server.keepAliveTimeout），避免每次响应都发Connection: close - 在 upstream 中启用连接池：
keepalive 32;（推荐 16–64），让 Nginx 复用连接，使活跃连接数稳定可比 - 避免 keepalive 值过大（如设成 200）：空闲连接长期滞留会虚高连接数，误导调度；长连接密集场景可调低至 16
- 用命令验证一致性：ss -tn src :80 | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr 查 Nginx 本机到各后端的 ESTAB 连接数，对比
stub_status中的 Active connections 是否接近
确保故障节点不参与比较
`least_conn` 本身不剔除故障节点，它只在“健康节点池”里挑连接最少的。如果某台后端偶发超时或卡死却没被隔离，它连接数可能始终偏低（因连接快速失败重建），反而被持续打满：
- 每个
server行必须配max_fails=2 fail_timeout=15s，避免默认的max_fails=1导致频繁震荡摘除 - 启用主动健康检查（需编译 health_check 模块）：
health_check interval=3s fails=2 passes=2 match=ok;，配合 match 块校验状态码和关键响应头 -
proxy_next_upstream至少包含error timeout http_500 http_502，确保后端过载返回 502 时立刻切走，不堆积请求 - 查 error.log：高频出现
connect() failed或connection timed out集中在某 IP，说明该节点网络或服务异常，需排查而非仅调 Nginx
适配异构后端的能力差异
当后端性能明显不同时，纯 least_conn 无法体现承载力差异。它不支持 weight 直接加权，但可通过以下方式间接控制：
- 用
max_conns设置软性容量上限：高性能节点设max_conns=2000，普通节点设max_conns=800。一旦达到上限，Nginx 自动跳过，相当于“能力越强，越能承接新连接” - 多节点连接数相同时，least_conn 会 fallback 到加权轮询——所以仍可保留
weight（如server ... weight=3;），它虽不影响主逻辑，但在并列最小值时起作用 - 压测时重点看 P95 延迟变化：若 least_conn 生效，慢节点被隔离或分流后，整体延迟应明显收敛，而非某几台持续高延迟
