max_conns 并非即设即生效的过载保护，需满足 Nginx ≥ 1.11.5 且 upstream 启用 least_conn 或 ip_hash；否则在 round_robin 下无效，且依赖 keepalive、合理设值与运行时验证。
max_conns 不是“一设就灵”的过载保险丝，它只在特定条件下真正起作用——用对了能缓冲瞬时洪峰，用错了可能毫无感知甚至误导容量判断。
必须满足的两个生效前提
这个参数不会自动拦截请求，缺一不可：
- Nginx 版本 ≥ 1.11.5（开源版从 1.11.5 起支持；旧版本或部分定制编译版可能仍不识别）
- upstream 必须启用 least_conn 或 ip_hash 算法——round_robin（默认轮询）完全忽略 max_conns
为什么单设 max_conns 常常无效
常见失效场景背后有明确机制原因：
- 没配 keepalive：Nginx 默认用短连接，每次请求新建 TCP 连接、响应后立即关闭。连接生命周期太短，max_conns 统计的“并发连接数”很难持续达到阈值，限流形同虚设
- 后端自身瓶颈不匹配：比如 Tomcat 的 maxConnections=100，但 Nginx 的 max_conns 设为 150，多余请求仍会打过去，触发 Connection refused 或线程池排队超时
- worker_processes > 1 时误读数值：max_conns 是**每台 upstream server 的单 worker 视角连接上限**，多个 worker 可能同时向同一后端建连，实际并发可能略高于设定值（但不会成倍放大）
真正起保护作用的配置组合
要让 max_conns 成为可靠的微服务“连接闸门”，需配套落地：
- 在 upstream 块中启用长连接复用：keepalive 64;（建议 32–128，根据后端连接池大小调整）
- 在 proxy location 中显式开启 HTTP/1.1 长连接：proxy_http_version 1.1; + proxy_set_header Connection '';
- max_conns 值参考后端实测吞吐：压测找到响应时间陡升或错误率跳变的并发点，设为该值的 80%～90%，例如后端稳定支撑 200 并发，max_conns 可设 160～180
- 升级到 Nginx 1.23.3+ 后，可叠加 queue=10 timeout=30s，让超额请求排队等待而非直接拒绝，提升成功率
验证是否真正在工作
光配不看等于没配。关键要看运行时指标：
- 启用 nginx_stub_status 或 nginx-module-vts，观察各 upstream server 的 Active connections 是否稳定在 max_conns 附近波动
- 对比开启前后，后端的 ESTABLISHED 连接数、TIME_WAIT 数量、GC 频率及错误日志中的 connection reset / refused 次数
- 用 ab 或 wrk 对 Nginx 施加阶梯式并发压力（如 50→200→400），检查后端错误率是否在 max_conns 设定值之后明显抬升
