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;
}

这样配置后：

Obsidian (Linux)

操作 Obsidian 库（纯 Markdown 笔记），并通过 notesmd-cli 实现自动化。

下载

• 正常情况下，新请求总是发给当前活跃连接数最少的那台机器
• 如果两台机器连接数都是 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 进程级近似值，非全局精确，但在常规并发下足够指导分流