max_conns需与keepalive、least_conn算法及后端承载力协同生效，仅在Nginx≥1.11.5、启用长连接、使用least_conn/ip_hash且worker独立计数时才拦截流量，否则形同虚设。
不能靠单设 max_conns 筑起保护墙，它只是 upstream 层面一个“连接数守门员”，必须和长连接、负载算法、后端承载力对齐，否则形同虚设。
max_conns 生效的硬性门槛
这个参数不是写上就起作用。它只在四个条件全部满足时才真正参与流量拦截：
- Nginx 版本 ≥ 1.11.5（旧版本直接忽略该指令）
- upstream 使用
least_conn或ip_hash算法（round_robin完全不检查） - 启用了
keepalive长连接（例如keepalive 64;），否则短连接生命周期太短，压根打不满限制 - 每个 worker 进程独立计数——若开了 4 个 worker，实际并发可能接近
max_conns × 4，不是绝对上限
为什么常设了却拦不住压测流量？
常见失效场景背后是配置错位或认知偏差：
- 没配
keepalive：Nginx 每次请求都新建 TCP 连接又马上断开，max_conns始终处于“空闲”状态，瞬时洪峰照样穿透 - 后端真实瓶颈更低：比如 Spring Boot 应用线程池最大 200，你却给 Nginx 配
max_conns 500，多余请求发过去只会触发 Connection refused 或超时排队 - 它不感知 CPU、GC、锁竞争等真实压力：连接数没超限，但后端已卡死，
max_conns对此毫无反应
真正能落地的自我保护组合
把 max_conns 变成一道有效防线，需搭配三项关键动作：
-
启用并调优长连接：upstream 内加
keepalive 64;；location 中补上proxy_http_version 1.1;和proxy_set_header Connection ''; -
固定用 least_conn 算法：它既按活跃连接分发，又严格校验
max_conns，比ip_hash更适合保护型场景 -
值要基于压测拐点来定：比如后端单实例在并发 300 时响应时间开始明显上升，
max_conns就设为 240～270（80%～90%），留出缓冲余量
进阶：让超限请求排队而非直接丢弃
开源版 Nginx ≥ 1.23.3 支持 queue=10 timeout=30s 指令，可让超出 max_conns 的请求进入内存队列等待空闲连接，避免大量 502/503。注意：
– 队列容量不宜过大，否则积压导致整体延迟飙升
– 必须配合合理的 timeout，防止请求无限等待
– 队列本身不解决后端过载，只是把“拒绝”变成“可控等待”
