应改用 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 到后端的活跃长连接数”，不是瞬时请求数。没有长连接，它就失去意义：

Nginx Config Linter

对 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 被长期占满却无法恢复