max_conns 是 Nginx upstream 中需协同负载策略、长连接与排队机制才生效的连接防护机制；仅在版本≥1.11.5、least_conn/ip_hash、至少两台server、显式配置max_conns=N时触发限流，须结合keepalive、queue等参数合理设值。

要防止大流量冲击下后端节点被连接压垮、彻底锁死，max_conns 是 Nginx upstream 中关键的连接数防护机制，但它不是独立生效的开关，必须和负载策略、长连接、排队逻辑协同配置才真正起作用。

确保基础前提全部满足

max_conns 只在以下条件同时成立时才开始计数并限流：

• Nginx 版本 ≥ 1.11.5（开源版已支持，无需 Plus）
• upstream 使用 least_conn 或 ip_hash 算法（round_robin、hash、random 等完全不识别该参数）
• upstream 至少定义了两台 server（单节点时 max_conns 不触发限流）
• 每个 server 行中明确写出 max_conns=N（默认值 0 表示不限制）

数值设定要贴合后端真实承载力

设得太高等于没设，设得太低又会误伤正常流量。建议参考后端服务的实际瓶颈：

• Java 应用（如 Tomcat）：取 maxThreads 的 70%～90%，例如线程池上限为 200，max_conns 可设 140～180
• Go/Node.js 等轻量服务：观察其连接处理峰值，预留 20% 余量
• 若后端启用了数据库连接池（如 HikariCP），需额外预留部分连接给内部调用，避免 max_conns 把所有连接都占满

必须搭配 keepalive 和 HTTP/1.1 长连接

没有长连接，max_conns 几乎无效——短连接建了就断，Nginx 很难持续达到上限，也无法稳定复用连接。

• 在 upstream 块中添加：keepalive 64;（数值建议为后端连接池大小的 1/2～1/3）
• 在对应 location 中启用代理长连接：
  

  proxy_http_version 1.1;<br>
    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，比 502 更明确表达“暂时不可用”
• 注意：queue 仅在 least_conn 下有效，且排队发生在 Nginx 内存中，不增加后端压力