max_conns 不能严格限制单节点连接数，仅在满足nginx≥1.11.5、upstream用least_conn或ip_hash、每server明确设max_conns、至少两台后端、https配keepalive等条件下才生效，需配合queue、后端限流及健康检查协同使用。
max_conns 不能“严格限制”单节点连接数，它只在特定组合下形成一层可预期的连接数约束。想靠它防雪崩，必须把它放进完整链路里协同调优，而不是单独设个数字就完事。
确保 max_conns 生效的硬性前提
这个参数不是开关，是条件触发器。缺以下任一条件，它就等于没写：
- Nginx 版本 ≥ 1.11.5（2026年主流版本都满足，但旧定制编译版仍需验证）
- upstream 必须用 least_conn 或 ip_hash；round_robin 完全不读取该值
- 每个 server 行明确写出 max_conns=N（N=0 表示不限制）
- upstream 至少定义两台后端服务器（单节点时 max_conns 不触发排队或拒绝逻辑）
HTTPS 场景下必须配套的长连接配置
HTTPS 默认启用 TLS 握手开销大，短连接会让 max_conns 形同虚设。必须强制走复用通道：
- 在 upstream 块中加 keepalive 64（建议设为后端连接池上限的 1/2～1/3，例如 Tomcat maxConnections=200，则 keepalive 设 32～64）
- 在 proxy location 中启用 HTTP/1.1 长连接：proxy_http_version 1.1 + proxy_set_header Connection ''
- 禁用 Nginx 自动关闭空闲连接：keepalive_requests 1000（避免频繁重建 TLS 连接）
让连接数真正可控的关键协同项
max_conns 只数“已建立的出向 TCP 连接”，不感知后端是否忙、响应是否慢。要让它逼近“严格限制”，得补上这几块：
- queue 指令（Nginx ≥ 1.23.3）：写成 server 192.168.1.10:443 max_conns=180 queue=8 timeout=20s。超出连接上限的请求进入内存队列，而非直接返回 502，降低瞬时洪峰冲击
-
后端自身限流兜底：Tomcat 设
maxConnections=200且acceptCount=50；Spring Boot 加server.tomcat.max-connections=200。max_conns 值应略低于该值（如设 180），留缓冲余量 -
主动健康检查联动：配
max_fails=2 fail_timeout=10s，配合proxy_read_timeout 15s。一旦后端响应变慢或超时，快速摘除节点，避免流量继续压入已疲软的实例
验证是否真起作用的实操方法
改完配置不等于生效，必须看运行时数据：
- 开启 nginx_stub_status，访问
/nginx_status，观察目标 server 的Active connections是否稳定在max_conns × 0.8～0.95区间波动 - 在 access_log 中加入
$upstream_connect_time $upstream_header_time $upstream_response_time，压测时看连接建立是否延迟突增、响应时间是否阶梯式上升 - 对比前后端指标：用
ss -s或netstat -ant | grep :443 | wc -l查后端 ESTABLISHED 连接数，确认未突破其 maxConnections 上限
