least_conn不支持weight，仅基于活跃连接数选择后端；替代方案包括：①nginx 1.17.5+用random two（支持weight且选连接少者）；②openresty+lua动态调权；③分层设计+硬件匹配weight+max_conns限流。
Nginx 的 least_conn 本身不支持直接与权重（weight）混合使用——它只关心后端连接数最少的节点，完全忽略 weight 设置。但你可以通过组合使用 least_conn 和 ip_hash、hash 或更关键的是：**用 least_conn + slow_start + 合理的健康检查 + 手动容量预估** 来逼近“加权最小连接”的效果；若真需严格按权重影响连接分配比例，应改用 hash 或 random 等支持 weight 的算法。
为什么 least_conn 不读 weight？
Nginx 官方明确说明：least_conn 调度器仅比较当前活跃连接数（active connections），不参与任何权重计算。即使你写了：
upstream backend {
least_conn;
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=1;
}这段配置中 weight 对 least_conn 完全无效。Nginx 会把两个节点视为同等优先级，只选此刻连接数更少的那个。
替代方案一：用 random with two parameters（推荐，Nginx 1.17.5+）
如果你的 Nginx ≥ 1.17.5，可用 random 指令配合 two 参数实现“带权重的随机选择”，再结合 least_conn 的思想做二次筛选（实际是模拟加权最小连接）：
-
random two：先随机挑两个上游服务器，再从中选连接数更少者 - 它天然支持
weight，且能缓解单点过载 - 配置示例：
upstream backend {
random two;
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 weight=2;
}该方式在保持权重导向的同时，引入了连接数反馈，比纯 least_conn 更均衡，也比纯 weight 更抗突发流量。
替代方案二：用 hash + 自定义变量模拟“连接感知”（高级用法）
若必须强依赖连接数 + 权重，可借助 Nginx 的 sticky 模块（需编译）或 OpenResty + Lua 实现动态权重调整：
- 用 Lua 统计各 upstream server 的实时连接数（通过
ngx.shared.DICT或外部指标服务） - 根据连接数反向调整每个 server 的有效权重（如连接越多，临时降低其被选中的概率）
- 再用
hash $dynamic_key consistent做调度
这已超出原生 Nginx 能力，属于定制化负载均衡，适合有较强运维和开发能力的团队。
务实建议：分层设计 + 容量对齐
多数场景下，与其硬套“加权最小连接”，不如从架构层面优化：
- 让不同权重的机器硬件规格（CPU/内存/网卡）与 weight 匹配（例如 weight=3 的机器性能 ≈ weight=1 的三倍）
- 启用
max_conns限制每台服务器最大并发连接，防止某台过载拖垮集群 - 配合
health_check主动剔除异常节点，比静态权重更可靠 - 日志中记录
$upstream_addr和$upstream_connect_time，定期分析真实负载分布
这样即使使用纯 least_conn，也能在实际运行中自然体现“高配机器承接更多连接”的效果。
