least_conn算法需配合keepalive连接复用、健康检查及正确配置位置才能生效；必须置于upstream块首行，不可与ip_hash等共存，且需启用proxy_http_version 1.1和stub_status验证。
要让 least_conn 算法真正把请求发给当前活跃连接数最少的后端节点，关键不是“写上 least_conn”就完事，而是确保它的运行环境能准确反映真实负载压力。它本身只看 Nginx 与后端之间已建立、尚未关闭的 TCP 连接数，不感知 CPU、内存或响应时间。如果连接复用不足或健康状态未同步，统计值就会失真，算法也就失效。
least_conn 必须放在 upstream 块开头
它不是 http 块的全局指令，也不能写在 server 或 location 里。错误位置会直接导致 Nginx 启动失败，报错类似 "least_conn directive is not allowed here"。正确写法是：
- 紧接在
upstream 名称 {之后，作为该块的第一条指令 - 同一 upstream 中不能和
ip_hash、hash等策略共存 - 不接受任何参数，写成
least_conn;即可，多一个空格或分号外字符都可能报错
启用 keepalive 复用连接，让连接数有意义
默认情况下，Nginx 每次请求都新建并关闭 TCP 连接，这时每个后端的活跃连接数始终接近 0 或 1，least_conn 就退化为随机分配。必须开启连接池，让连接真正“活”起来：
- 在 upstream 块中添加
keepalive 32;（数字表示每个 worker 进程最多缓存的空闲长连接数） - 在 proxy_pass 对应的 location 中，显式启用 HTTP/1.1 并清空 Connection 头：
proxy_http_version 1.1;<br>proxy_set_header Connection '';
- 否则后端可能主动断连，keepalive 形同虚设
配合健康检查，避免把请求发给“假闲”节点
least_conn 不判断后端是否可用。如果某台服务器已宕机但网络未断开，它仍可能被选中（因为连接数为 0），最终返回 502/503。必须叠加基础健康机制：
- 使用
max_fails=3 fail_timeout=30s参数标记异常节点（例如：连续 3 次超时后，30 秒内不再转发） - 若用商业版或 OpenResty，可配
health_check实现主动探活 - 注意：健康检查和 least_conn 是正交机制，可同时启用，互不影响
验证是否真正在按连接数调度
不能只看配置有没有语法错误，得确认行为符合预期：
- 开启
stub_status模块，在某个 location 中配置location /nginx_status { stub_status; }，访问该地址可实时查看各 upstream 的 active 连接数 - 用
curl -I配合并发压测（如 ab 或 wrk），再比对各后端 access log 中的请求分布——在流量波动时，连接数少的节点应持续收到更多新请求 - 观察日志中是否有大量 502 错误集中在某台后端，这往往说明健康检查没起作用，least_conn 在往“死节点”导流
