max_conns是防止后端被连接压垮最有效的第一道防线，需满足nginx≥1.11.5、least_conn或ip_hash算法、至少两台server三个前提；须结合keepalive长连接与queue柔性排队才能稳定生效。

直接在 upstream 块中为每台后端服务器设置 max_conns，是防止节点被连接压垮最有效的第一道防线。它不依赖应用层改造，生效快、控制准，但必须满足前提条件才能真正起作用。

确保生效的三个硬性前提

这个参数不是写上就管用：

• Nginx 版本必须 ≥ 1.11.5（开源版已支持，无需商业许可）
• upstream 必须使用 least_conn 或 ip_hash 算法；round_robin、hash、random 等策略完全忽略该参数
• upstream 至少配置两台 server；单节点部署时 max_conns 不触发限流逻辑

合理设定数值：贴着后端真实承载力来配

设太高等于没设，设太低会人为制造瓶颈。关键参考点是后端服务的实际并发处理上限：

• Java 应用（如 Tomcat）：参考其 maxThreads 或线程池核心数，max_conns 建议设为该值的 70%～90%
• Go/Node.js 等轻量服务：观察其稳定运行时的活跃 goroutine 或 event loop 负载，留出 20% 余量
• 若后端启用了数据库连接池（如 HikariCP），要预留部分连接给内部 DB 调用，不能把全部额度都分给 Nginx

必须搭配 keepalive 和长连接才稳定生效

如果只设 max_conns 却没开长连接，Nginx 默认用短连接——建完就断，连接数瞬时冲高又回落，max_conns 很难被持续触达，形同虚设：

• 在 upstream 块中加：keepalive 64;（数值建议为后端连接池大小的 1/2～1/3）
• 在对应 location 中启用 HTTP/1.1 长连接代理：proxy_http_version 1.1; 和 proxy_set_header Connection '';
• 避免后端因频繁握手、TIME_WAIT 积压而提前拒绝新连接

增强容错：用 queue 实现柔性排队（推荐）

默认情况下，当某台后端达到 max_conns 上限时，Nginx 直接返回 502，用户体验差。升级到 Nginx 1.23.3+ 后，可启用 queue 缓冲突发流量：

• 配置示例：server 192.168.1.10:8080 max_conns=150 queue=10 timeout=30s;
• queue=10 表示最多允许 10 个请求排队等待空闲连接
• timeout=30s 是排队最大等待时间，超时返回 503，比硬拒绝更可控