nginx的least_conn不直接支持weight，仅在连接数相等时按weight加权分配；max_conns更真实体现节点承载力，配合健康检查与合理keepalive设置才能确保加权最小连接数效果。
Nginx 的 least_conn 本身不直接支持 weight 参数，但可以通过组合配置实现“加权最小连接数”的效果——即在连接数相同时启用权重分流，同时用 max_conns 体现节点实际承载能力差异。
least_conn 和 weight 的关系不是并列，而是分层生效
least_conn 每次选节点时，先看实时活跃连接数；只有当多个后端连接数完全相等时，才在这些节点中按 weight 做加权轮询。所以 weight 不影响“谁更闲”，只影响“都一样闲时怎么分”。
- weight 只在 fallback 场景下起作用
- 连接数不同 → 直接选最少的那个，weight 被忽略
- 连接数相同 → 在这批节点里按 weight 分配新连接
例如：
upstream backend {
least_conn;
server 10.0.1.10:8000 max_conns=2000; # 高配，能扛更多连接
server 10.0.1.11:8000 weight=2 max_conns=1200;
server 10.0.1.12:8000 weight=1 max_conns=800;
}
三台机器当前连接数都是 5 → 后续请求按 2:1 的比例分给第二、三台（第一台没 weight，按默认 weight=1 算）。
用 max_conns 实现更真实的“加权”能力控制
max_conns 是比 weight 更贴近物理资源的加权方式：它限制单个后端可接受的最大并发连接数，超出后该节点会被 least_conn 自动跳过（即使连接数显示最少）。
- 高性能节点设更高
max_conns，让它自然承接更多连接 - 普通节点设较低值，避免被过度调度
-
max_conns和健康检查配合使用，才能防止故障节点继续收流量
建议搭配：
-
max_fails=3 fail_timeout=30s做基础健康检查 - 或启用
health_check模块做主动探测
keepalive 设置影响加权效果的真实性
keepalive N 开启连接复用后，空闲长连接也会计入活跃连接总数。如果某台机器 keepalive 连接池长期满载（比如设了 100 却只用了 10 条），它的“账面连接数”会虚高，导致 least_conn 错判。
- 推荐
keepalive 16–64，根据后端 QPS 和平均响应时间调整 - 后端需开启 HTTP Keep-Alive，并设置合理超时（如
keepalive_timeout 75s） - 过大的 keepalive 值会让“连接数最少”失去参考价值
验证是否真正生效
- 开启
stub_status模块，访问/nginx_status查看各 upstream server 的Active connections - 对比
Active connections数值变化趋势，确认是否向低连接数节点倾斜 - 模拟长请求（如压测接口返回 10s 延迟），观察连接堆积是否明显缓解
不复杂但容易忽略
