max_conns 是仅在 Nginx ≥1.11.5 且负载算法为 least_conn 或 ip_hash 时生效的软性连接数约束，限制主动发起的并发到后端连接数，需配合 keepalive、queue、健康检查及分层限流才接近硬限效果。
max_conns 不是“硬性限压开关”，它只在特定条件下构成一层连接数层面的软性约束。 真正想硬性限制后端节点压力上限，不能单靠 max_conns，必须配合负载策略、连接复用、健康检查和外部限流模块协同实现。
max_conns 的真实作用边界
该参数写在 upstream 的 server 行中，例如：
upstream backend {
server 10.0.1.10:8080 max_conns=150;
}
但它仅在以下两个前提同时满足时才起效：
- Nginx 版本 ≥ 1.11.5（低版本直接忽略）
- 当前使用的负载均衡算法为 least_conn 或 ip_hash；round_robin 完全不读取该值
它限制的是“Nginx 主动发起并保持的、到该后端 server 的并发出向连接数”，不是请求量，也不是后端真实处理中的线程/连接池占用——如果后端 Tomcat 的 maxConnections=100，而 Nginx max_conns=150，超量连接仍可能触发 Connection refused。
让 max_conns 发挥接近“硬限”效果的关键配置
要让它真正挡住过载流量，需切断短连接路径，强制走长连接通道，并让连接数可被准确计数：
- 在 upstream 块中启用 keepalive，例如：keepalive 64;（建议设为 max_conns 的 30%~50%，避免空闲连接长期占位）
- 在 location 中启用 HTTP/1.1 长连接代理：proxy_http_version 1.1;
proxy_set_header Connection ''; - 搭配 queue 指令（Nginx 开源版 ≥ 1.23.3 或 Nginx Plus）实现排队缓冲，避免直接丢弃请求：server 10.0.1.10:8080 max_conns=150 queue=5 timeout=10s;
更可靠的硬性限压组合方案
仅靠 max_conns 无法感知响应延迟、CPU 占用或错误率上升。生产环境推荐分层控制：
- **上游入口级限流**：用 limit_conn（按 IP 或 server 维度限制并发连接总数）或 limit_req（按请求速率限流，支持漏桶+突发缓冲）
- **后端实例级保护**：在应用层设置连接池上限（如 Tomcat 的 maxConnections、Spring Boot 的 server.tomcat.max-connections），并开启主动拒绝（如 reject-count > 0）
- **Nginx 主动健康检查 + fail_timeout**：配合 max_fails=2 fail_timeout=15s，快速摘除已响应迟缓或超时的节点
- **监控闭环**：通过 nginx_stub_status 或 nginx-module-vts 实时查看各 server 的 active connections，确认是否稳定在 max_conns × 0.8～0.9 区间
典型误用场景与规避方式
常见失效情况包括：
- 用了 round_robin 负载策略 → 改用 least_conn; 并验证生效
- 没配 keepalive，仍走短连接 → 每次请求新建连接，max_conns 几乎无意义
- 后端本身未做熔断或降级 → 建议在应用侧接入 Sentinel 或 Hystrix，与 Nginx 形成双保险
- max_conns 设得比后端真实吞吐高 → 应基于压测结果设定，建议取拐点值的 80%
