least_conn 是基于当前活跃TCP连接数的负载均衡算法，不感知CPU或响应时间；需配置keepalive和健康检查才能生效。
least_conn 不是“预测”或“感知”低负载，而是每次请求来临时，直接统计 Nginx 当前与各后端保持的活跃 TCP 连接数，选其中数值最小的那个节点转发。
它只看连接数，不看 CPU 或响应时间
least_conn 统计的是 Nginx worker 进程与后端服务器之间已建立、尚未关闭的长连接数量。它完全不读取后端的 CPU 使用率、内存占用、请求处理耗时等指标。也就是说，哪怕某台后端 CPU 已 99%，只要它当前和 Nginx 的活跃连接数最少，新请求仍可能被分过去。
- 适合场景：请求处理时长差异大（比如有的接口 20ms，有的要 3s）
- 不适合场景：单纯想按真实资源水位调度（这时需配合外部监控+动态 upstream 或用 Nginx Plus 的 least_time）
- 注意：宕机或健康检查失败的节点会被自动剔除，不参与 least_conn 比较
多个节点连接数相同时，按权重轮询选一个
如果两台服务器当前活跃连接数都是 5，Nginx 就不会随机挑，而是参考你在 server 行里配置的 weight 值，走加权轮询逻辑——weight 越高，被选中的概率越大。但前提是连接数必须严格相等，否则 weight 不影响“最少连接”这个首要判断。
- 例如：
server a:8080 weight=3;和server b:8080 weight=1; - 当两者连接数同为 0 → a 更大概率被选中
- 当 a 连接数为 1、b 为 0 → 一定选 b，weight 不起作用
要让连接数统计真实有效，必须配 keepalive
默认情况下，Nginx 每次 proxy_pass 都新建短连接，请求结束立刻断开。这样每个后端的活跃连接数几乎总是 0 或 1，least_conn 失去意义。启用连接池才能复用连接，使连接数真正反映服务压力。
- 在 upstream 块中加：
keepalive 32;（建议值 16–100，视并发量调整） - 在 location 中加：
proxy_http_version 1.1;和proxy_set_header Connection ''; - 否则后端可能主动关闭长连接，导致 keepalive 失效
健康检查需单独配置，least_conn 不自带
least_conn 自身不检测后端是否存活。若某台服务器网络不通但连接数仍显示为 0，它可能持续把请求发过去，造成失败。必须额外配置健康检查机制：
- 简单方式：用
max_fails=3 fail_timeout=30s配合被动探测 - 主动方式：用
health_check interval=5s fails=2 passes=2（需 Nginx Plus 或开源版 1.19+ + ngx_http_upstream_hc_module） - 两者都应与 least_conn 共存，缺一不可
