max_conns需与least_conn/ip_hash、keepalive及Nginx≥1.11.5协同生效，仅设参数无效；必须启用长连接、匹配负载策略并满足版本要求才能真正限制单个后端并发连接数。
max_conns 不能单独起作用，它必须和 upstream 的负载策略、连接复用机制、Nginx 版本协同配置，才能真正限制单个后端节点的并发连接数。
max_conns 生效的硬性前提
这个参数写在 server 行里，但不会自动拦截请求。必须同时满足以下三点：
- Nginx 版本 ≥ 1.11.5（开源版已支持，旧版本直接忽略该参数）
- upstream 使用 least_conn 或 ip_hash 算法（默认 round_robin 完全不检查 max_conns）
- 启用了 keepalive 连接池（例如
keepalive 64;），否则短连接下连接瞬时建立又释放，max_conns 几乎无法形成实际约束
正确配置示例
以下配置将每台后端服务器的并发连接严格控制在 180 以内：
upstream backend {
least_conn;
keepalive 64;
server 10.0.1.10:8080 max_conns=180;
server 10.0.1.11:8080 max_conns=180;
server 10.0.1.12:8080 max_conns=180;
}
server {
location /api/ {
proxy_pass http://backend;
proxy_http_version 1.1;
proxy_set_header Connection '';
}
}
注意：proxy_http_version 和 Connection 头必须显式设置，否则长连接无法复用，max_conns 就失去意义。
设值建议与避坑要点
max_conns 不是拍脑袋定的数字，要结合后端真实能力来设定：
- 参考后端应用的线程池上限或连接池容量（如 Tomcat 的
maxThreads=200），max_conns 建议设为该值的 80%～90%，留出缓冲余量 - 若使用 Nginx 1.23.3+，可叠加
queue=10 timeout=30s，让超额请求排队等待，而不是直接拒绝 - 多个 worker 进程会各自维护连接计数，实际总连接数略高于设定值，但不会成倍放大；不必刻意调低 max_conns 来“补偿”
- 它只统计 TCP 连接数，不感知 CPU、内存、响应延迟等真实负载，需配合监控一起看效果
验证是否真正生效
改完配置不等于就起作用了，得靠运行时数据确认：
- 启用
stub_status，访问/nginx_status查看各 upstream server 的 Active connections 是否稳定在 max_conns 附近波动 - 在 access_log 中加入
$upstream_connect_time和$upstream_addr，观察连接建立是否变慢、是否频繁切换后端地址 - 压测时对比前后端错误率（Connection refused / timeout）和平均响应时间拐点，确认限流在预期阈值处触发
