Nginx的max_conns限流生效需同时满足：版本≥1.11.5、upstream启用least_conn或ip_hash、启用keepalive并透传HTTP/1.1长连接头；数值应设为后端真实承载力（如Tomcat maxThreads）的70%～90%，并配合keepalive数量限制、queue排队及健康检查方可落地生效。

max_conns 不是开箱即用的“保护开关”，它只在精准匹配运行环境时才真正起效。关键在于让 Nginx 主动感知并尊重后端的真实承载边界，而不是靠参数本身硬拦。

必须满足的三个硬性前提

缺一不可，否则配置等于没写：

• Nginx 版本 ≥ 1.11.5：低于此版本会直接忽略 max_conns，不报错也不生效
• upstream 必须启用 least_conn 或 ip_hash：round_robin（默认策略）完全不检查该参数
• 必须启用 keepalive 并正确透传长连接头：否则短连接下连接瞬生瞬灭，max_conns 统计失真，限流形同虚设

数值设定不能拍脑袋

max_conns 值要对齐后端真实瓶颈，不是越高越好，也不是越低越安全：

• 参考 Tomcat 的 maxThreads 或 Spring Boot 的 server.tomcat.max-connections，设为该值的 70%～90%
• 若后端使用连接池（如 HikariCP），需预留至少 20% 连接给内部 DB 调用，避免 max_conns 占满导致数据库连接失败
• 压测时观察响应时间拐点——比如并发到 180 时 P95 延迟陡升，max_conns 可设为 140～160

配套动作决定防护是否落地

单设 max_conns 是脆弱的，必须组合使用：

• 启用上游连接复用：upstream backend { keepalive 32; }，且 keepalive 数量 ≤ max_conns，否则空闲连接堆积会绕过限制
• 显式开启 HTTP/1.1 长连接：proxy_http_version 1.1; + proxy_set_header Connection '';
• 加入排队机制（Nginx ≥ 1.23.3）：queue 50 timeout=10s;，让超额请求等待而非直接 503，提升成功率
• 绑定健康检查：max_fails=2 fail_timeout=15s;，配合 proxy_next_upstream error timeout http_503;，自动规避已过载节点

验证它真正在工作

配完不验证，等于没配。重点看三项运行时指标：

• 通过 nginx_stub_status 或 nginx-module-vts 查看 upstream 各 server 的 Active connections 是否稳定在 max_conns 附近波动，而非持续冲高
• 登录后端服务器，执行 ss -ant | grep :8080 | grep ESTAB | wc -l，确认 ESTABLISHED 连接数未明显突破 max_conns × worker 数量
• 对比开启前后，后端日志中 Connection refused、connection reset by peer 及 GC 频次是否显著下降