least_conn算法按实时活跃tcp连接数分配请求，仅统计nginx与后端间已建立未关闭的连接（含keepalive空闲连接），忽略cpu、响应时间等指标；连接数相同时启用加权轮询；依赖被动/主动健康检查或手动标记剔除故障节点；keepalive设置影响调度精度，建议设为16–64。
least_conn 算法在每次有新请求到达时，实时比较所有健康后端的活跃 TCP 连接数，把请求发给当前连接数最少的那个节点——它不预测、不估算，只看此刻“手头上还有几个活儿没结束”。
只统计活跃连接，不看其他指标
它统计的是 Nginx 与后端之间已建立、尚未关闭的 TCP 连接总数，包括正在处理请求的连接和 keepalive 空闲连接。CPU 使用率、响应时间、内存占用等完全不参与判断。
- 一个后端正处理 3 个耗时 10 秒的报表请求，连接数就是 3
- 另一个后端刚完成请求但维持着 20 条 keepalive 空闲连接，连接数就算作 20
- 连接数为 0 的节点优先级最高，哪怕它硬件配置稍弱
调度前先过滤不可用节点
least_conn 不会把请求分给宕机或失联的机器，但它本身不负责发现故障——必须依赖额外机制提前筛掉问题节点：
- 被动健康检查：配合 max_fails 和 fail_timeout，连续失败指定次数后临时摘除
- 主动健康检查：使用 health_check（Nginx Plus）或第三方模块定期探测 /health 接口
- 手动标记：用 down 或 backup 显式排除节点
连接数相同时按权重轮询
当多个后端活跃连接数完全一样（比如都是 2），least_conn 就不再起主导作用，转而启用加权轮询逻辑：
- server 配置中的 weight 值重新生效
- weight 越高，被选中的概率越大
- 这保证了在负载均衡“打平”的状态下，仍能按预期比例分配流量
keepalive 设置直接影响调度精度
upstream 中的 keepalive 指令设置空闲连接池大小，这些连接会计入活跃连接总数：
- keepalive 100 表示每个 worker 最多复用 100 条空闲连接到同一后端
- 值设得过大，会让某台后端“账面连接数”虚高，导致 least_conn 误判
- 建议根据并发量和后端连接保持能力合理设置，常见值为 16–64
