least_conn算法仅统计Nginx与后端间当前活跃TCP连接数，含处理中请求和keepalive空闲连接，不考虑CPU、内存等；先过滤不可用节点，再选连接数最小者，多节点相同时启用加权轮询。
least_conn 算法只统计 Nginx 与后端服务器之间当前已建立、尚未关闭的 TCP 连接数，不涉及 CPU、内存或响应时间等其他指标。
只算“活着”的 TCP 连接
这个连接数指的是 Nginx 的 worker 进程与某个 upstream server 当前维持的活跃连接总数，包括：
- 正在传输请求/响应的连接（如处理中 HTTP 请求）
- 处于 keepalive 状态的空闲连接（只要没超时断开，就算在内）
它不是请求数，也不是并发线程数，更不是后端应用内部的连接池大小——Nginx 完全不感知这些。
keepalive 连接会计入，且影响显著
如果你配置了 upstream keepalive 100，每个 worker 最多会为该后端缓存 100 条空闲连接。这些连接虽然没在传数据，但仍被计入“活跃连接数”。这意味着：
- keepalive 值设得过大，可能让某台后端“账面连接数”虚高，导致 least_conn 避开它，即使它实际很空闲
- keepalive 值太小，则复用率低，连接频繁重建，least_conn 就退化为近似轮询
调度前先过滤不可用节点
least_conn 不是盲目比数字。它执行三步筛选：
- 先剔除状态为
down、backup或健康检查失败的节点 - 再在剩余可用节点中，比较它们各自的活跃连接总数
- 取最小值；若多个节点并列最少，则在这些节点中启用加权轮询（此时 weight 才起作用）
不统计后端自身连接状态
Nginx 不会去查后端进程开了多少 socket、用了多少线程、CPU 是否打满。它只维护自己 outbound 连接这一层的状态。所以：
- 后端宕机但连接尚未超时断开时，它的连接数可能仍显示为 0，least_conn 仍可能选它——必须配健康检查（
health_check或max_fails/fail_timeout）来及时剔除 - 后端应用是否开启 HTTP Keep-Alive、是否复用连接，直接影响 least_conn 的效果，但 Nginx 不强制也不校验这点
