least_conn通过实时统计各后端活跃连接数实现异构集群动态负载倾斜：强节点响应快、连接释放早、连接数低而被优先选中，弱节点反之；其依赖keepalive、健康检查、超时配置优化，并受多进程独立计数限制。
Nginx 的 least_conn 本身不直接感知服务器硬件差异，但能通过连接数这一客观指标，自然适配异构集群——性能强的机器连接数增长慢、维持低水平，性能弱的机器连接数上升快、更快被“跳过”，从而实现无需人工调权的动态负载倾斜控制。
least_conn 在异构集群中如何起作用
- 它统计的是 Nginx worker 与每个后端建立的当前活跃 TCP 连接数（即已握手完成、尚未关闭的连接）
- 异构服务器响应快慢不同：强节点处理完请求快、连接释放早；弱节点响应拖沓、连接长期挂起
- 新请求进来时，Nginx 比较各节点当前连接数，自动选最小值 → 弱节点连接数稍高就大概率被跳过，强节点持续承接更多新连接
这种机制不需要你提前知道哪台 CPU 更强、内存更多，只要它们真实承载能力有差异，least_conn 就会通过连接堆积速度反映出来。
配合关键配置提升异构适配效果
-
keepalive N：在 upstream 中启用连接池（如keepalive 32），减少反复建连开销，让连接数变化更平滑、统计更稳定 - 健康检查必须开启：用
max_fails和fail_timeout主动剔除宕机或假死节点，避免无效参与 least_conn 计算 - 合理设置超时参数：
-
proxy_connect_timeout控制建连等待上限 -
proxy_read_timeout防止慢响应长期占连接（尤其对弱节点） -
proxy_next_upstream error timeout http_500支持失败重试，增强容错
-
注意 Nginx 多进程模型下的统计局限
- 每个 worker 进程独立维护自己的连接计数，不是全局共享变量
- 在超高并发（如单机万级连接）且 worker 数较多时，可能出现短暂选择偏差
- 实际生产中影响有限；若需强一致性，可考虑 OpenResty + shared dict 手动聚合，但多数场景没必要
不需要权重，但可以谨慎叠加
-
least_conn本身不兼容weight参数（Nginx 会忽略 weight） - 若某台机器确实存在不可绕过的硬瓶颈（如磁盘 I/O 极差），可配合
max_conns限流：-
server 192.168.1.10:8080 max_conns=50; - 超过 50 个活跃连接后，该节点不再接收新请求，哪怕它当前连接数最少
-
不复杂但容易忽略
