least_conn 不支持 weight 参数，但连接数相等时会自动回退到按 weight 加权轮询；配置需在 upstream 中同时声明 least_conn 和带 weight 的 server，不可写作 least_conn weight=2。
least_conn 本身不直接支持 weight 参数参与连接数计算，但 Nginx 在 least_conn 策略下有明确的 fallback 机制：当多个后端的活跃连接数相等时，会自动退回到按 weight 加权轮询分配请求。所以“结合”不是靠语法叠加，而是靠这个隐含行为实现的。
配置写法（标准且有效）
只需在 upstream 块中同时声明 least_conn 和带 weight 的 server，无需额外关键字：
upstream app_backend {
least_conn;
server 192.168.1.10:8080 weight=3;
server 192.168.1.11:8080 weight=1;
server 192.168.1.12:8080 weight=2;
}
这样配置后：
- 正常情况下，新请求总是发给当前活跃连接数最少的那台机器
- 如果两台机器连接数都是 5，另一台是 6，那么请求会在前两台之间按 weight=3:1 分配
- 如果三台连接数完全相同（比如都是 0），则严格按 weight=3:1:2 的比例分发
为什么不能写成 least_conn weight=2？
Nginx 官方语法不支持这种写法。least_conn 是一个独立指令，它不接受参数；weight 是 server 指令的属性，只在 fallback 场景生效。强行混写会导致配置解析失败或被忽略。
验证是否真起作用
光 reload 成功不代表策略生效，要实测行为：
- 开启 stub_status：在某个 server 块里加
location /nginx_status { stub_status; } - 用压测工具（如 wrk 或 ab）发起一批长连接请求（比如 HTTP/1.1 keepalive）
- 反复访问
/nginx_status，观察各后端的 Active connections 是否趋于接近——越接近说明 least_conn 主逻辑在起效；若长期明显不均但权重比稳定，则可能 fallback 频繁，需检查后端响应时间或连接复用情况
适用场景提醒
这种组合适合后端节点硬件能力不同、又存在长连接或响应时间波动的混合环境：
- 例如：一台 16C32G（weight=3）、两台 8C16G（weight=1 和 2），同时跑 WebSocket 服务
- 若全是短平快 API 且响应极稳定，纯轮询反而更简单可控
- 注意：Nginx 开源版的连接数统计是 worker 进程级近似值，非全局精确，但在常规并发下足够指导分流
