应改用 least_conn 负载策略并配合 keepalive 使用，因为 round_robin 忽略 max_conns；需在 upstream 中配置 least_conn 和 keepalive，为 server 设置 max_conns，并启用健康检查与长连接相关指令。
不能靠轮询本身限制单个后端的最大连接数。Nginx 默认的 round_robin 策略完全忽略 max_conns 参数，所以直接写 server 10.0.1.10:8080 max_conns=20; 在轮询配置里是无效的。
改用 least_conn 负载策略
这是最常用且有效的替代方案。least_conn 会把新请求优先分发给当前活跃连接数最少的节点，同时它也真正识别并执行 max_conns 限制：
- 在 upstream 块中显式声明
least_conn; - 为每个 server 设置
max_conns，例如：server 10.0.1.10:8080 max_conns=50; - 超出该值的请求不会发往此节点，而是交给其他还有余量的后端
必须搭配 keepalive 使用
max_conns 控制的是“Nginx 到后端的活跃长连接数”，不是瞬时请求数。没有长连接，它就失去意义：
- 在 upstream 块中添加
keepalive 64;（数值建议设为max_conns的 1–2 倍） - 在 location 中启用 HTTP/1.1 长连接：
proxy_http_version 1.1;和proxy_set_header Connection ''; - 避免后端因短连接频繁建连而误判负载
验证是否生效
光改配置不等于起作用，得看实际连接分布：
- 开启 stub_status 模块，访问
/nginx_status查看各 upstream server 的Active connections - 用自定义日志格式记录
$upstream_addr，压测后统计各后端 IP 出现频次，确认没出现明显倾斜或超限 - 观察错误日志：若某节点持续被跳过，
error.log中可能出现no live upstreams或连接拒绝提示
配合健康检查防失效
仅靠 max_conns 不足以应对所有异常场景：
- 加上
max_fails=2 fail_timeout=15s，让 Nginx 主动剔除响应慢或失败的节点 - 设置
proxy_next_upstream error timeout http_500 http_502 http_503 http_504，确保错误响应能重试其他节点 - 避免因某个后端卡死、不释放连接，导致
max_conns被长期占满却无法恢复
