least_conn通过conns/weight归一化比值选最小值节点，多节点相同时退至加权轮询；需配合健康检查、keepalive及max_conns配置才能生效。
Nginx 的 least_conn 本身不直接支持权重计算，但它可以和 weight 参数共存，并在逻辑上形成“带权最小连接”的效果——不是靠 least_conn 主动加权，而是通过归一化比较（conns / weight）实现更合理的连接倾斜。
关键在于：Nginx 在执行 least_conn 时，会把每个 server 的当前活跃连接数除以其 weight，得到一个“相对负载值”，再选这个值最小的节点。高权重节点允许承载更多连接，低权重节点即使连接数少，也可能因分母小而被优先避开。
least_conn 和 weight 是怎么一起工作的
- 每次新请求到来，Nginx 遍历所有健康、未超限的 upstream server
- 对每个 server，计算
当前活跃连接数 ÷ weight（weight 默认为 1） - 选取该比值最小的 server；若多个比值相同，则退回到加权轮询顺序
例如：
-
server A: weight=4, conns=8→8/4 = 2.0 -
server B: weight=2, conns=3→3/2 = 1.5 -
server C: weight=1, conns=1→1/1 = 1.0
→ 选 C，哪怕它绝对连接数最少，也符合“归一化后最空闲”
配置写法与注意事项
-
least_conn必须写在upstream块内，且不能和ip_hash、hash等指令共用 -
weight写在server行后面，和max_fails、fail_timeout等并存无冲突 - 示例配置：
upstream backend {
least_conn;
server 192.168.1.10:8080 weight=4;
server 192.168.1.11:8080 weight=2;
server 192.168.1.12:8080 weight=1 max_fails=3 fail_timeout=30s;
}
- 不要误以为
least_conn会“按权重分配连接数上限”，它只是用 weight 做归一化参考 - 如果某 server 达到
max_conns（需显式配置），它会被跳过，不参与 least_conn 计算
实际效果更稳的配套建议
- 启用健康检查：靠
max_fails/fail_timeout或health_check主动剔除异常节点，避免 least_conn 把请求打向已假死但连接未断的服务 - 配合
keepalive连接池：减少频繁建连开销，让 least_conn 统计的连接数更真实反映后端压力 - 避免混用
ip_hash：它会强制会话绑定，使 weight 和 least_conn 全部失效
不复杂但容易忽略
