max_conns用于限制Nginx到单台后端服务器的出向并发连接数，仅在least_conn或ip_hash策略、Nginx≥1.11.5、启用keepalive时生效，需配合proxy_http_version 1.1等配置协同使用。
max_conns 不是“一设就灵”的全局限流开关，它只在特定条件下约束 Nginx 到某台后端服务器的**出向并发连接数**，核心目标是防止单台后端被突发流量压垮。用错场景或缺少配套配置，它基本不生效。
max_conns 的生效前提很明确
这个参数写在 upstream 的 server 行里，但不会自动起作用：
- 必须使用 least_conn 或 ip_hash 负载均衡策略；round_robin（默认）完全忽略它
- Nginx 版本不能低于 1.11.5；旧版本直接无视该参数
- 必须配合 keepalive 指令（如
keepalive 64;），否则短连接下连接瞬时建立又释放，max_conns 几乎无法形成实际限制
为什么单独设 max_conns 往往没效果？
常见误区是把它当成后端的“安全阀”，但它的作用机制有天然局限：
- 它只数 Nginx 主动发起的 TCP 连接，不感知后端真实负载（CPU、内存、线程池是否打满）
- 若后端 Tomcat 的
maxConnections=200，而 Nginx 的 max_conns 设为 300，仍可能把超量请求推过去，导致 Connection refused - 没有 keepalive 时，每个 HTTP 请求都新建连接，max_conns 很难持续达到上限，形同虚设
真正落地的配置组合
要让 max_conns 发挥保护作用，需和几个关键配置协同：
- 在 upstream 块中启用长连接：
keepalive 64; - 在 proxy location 中声明 HTTP/1.1 和清除 Connection 头：
proxy_http_version 1.1;+proxy_set_header Connection ''; - 选用支持的负载策略，例如：
least_conn;（推荐）或ip_hash; - 搭配 queue（Nginx 开源版 1.23.3+ 或 Plus）缓存超额请求，避免直接丢弃：
server 192.168.1.10:8080 max_conns=200 queue=10 timeout=30s;
怎么验证它是不是真在工作？
光改配置不行，得看数据：
- 开启
stub_status，访问/nginx_status查看各 upstream server 的 Active connections 数值 - 用自定义日志格式记录
$upstream_connect_time和$upstream_response_time，观察连接建立是否变慢、响应是否延迟突增 - 压测时对比设置前后后端的错误率（Connection refused / timeout）和平均响应时间拐点
