nginx官方不支持加权最小连接数算法，least_conn不接受weight参数且会静默忽略；其逻辑是优先选连接数最少者，相同时才按weight轮询；可通过max_conns模拟容量感知调度，并需keepalive、健康检查和http/1.1长连接协同生效。
Nginx 官方不支持“加权最小连接数”（Weighted Least Connections）这一原生算法。least_conn 指令本身不接受 weight 参数，也不能与 weight 同时出现在同一 upstream 块中——若混用，weight 会被静默忽略，配置仍能加载，但权重失效。
为什么不能直接加权
least_conn 的设计逻辑是纯比较：只取当前活跃连接数最少的后端；当多个后端连接数相同时，才退回到 weight 做加权轮询。也就是说：
– 连接数不同 → 严格按 least_conn 选最小者，weight 不参与决策
– 连接数相同 → 在这批“并列最少”的节点间，按 weight 做第二层分发
如何模拟加权最小连接效果
虽然没有 weight= 参数，但可通过 max_conns 实现等效的容量感知调度：
- 高性能节点设更高 max_conns：例如 server 10.0.1.10:8000 max_conns=2000; 表示它最多可承载 2000 条并发连接，调度器在连接未达限时会持续接纳请求
- 普通节点设更低 max_conns：例如 server 10.0.1.11:8000 max_conns=800; 一旦连接数达到 800，该节点即被剔出 least_conn 选择池
- max_conns 数值可看作“能力上限”的量化表达，比 weight 更贴近真实负载边界，尤其适合 CPU/显存受限型服务（如 AI 推理）
必须配套的关键配置
仅靠 max_conns + least_conn 仍不足以稳定生效，还需以下三项支撑：
- 启用 keepalive 复用：在 upstream 块中添加 keepalive 32;，避免短连接导致连接数瞬时归零、算法退化为随机
- 开启被动健康检查：每个 server 行加上 max_fails=2 fail_timeout=15s，防止故障节点因连接数低而持续被误选
- 强制 HTTP/1.1 长连接：在 proxy_pass 所在 location 中配置 proxy_http_version 1.1; 和 proxy_set_header Connection '';，确保后端真正复用连接
验证是否按预期工作
别只检查语法是否通过，重点观察行为：
- 压测时访问 /nginx_status，确认各 backend 的 Active connections 是否随流量增长而趋于差异分布（如高 max_conns 节点连接数明显更高）
- 用 curl -I 或 Nginx access_log 中的 $upstream_addr 字段，核对请求是否优先落在 max_conns 更大的节点上
- 若发现某节点长期空闲，检查其是否因网络延迟高、健康检查失败或后端未正确关闭连接导致连接泄漏
