max_conns 是 nginx upstream 中限制单个后端节点并发 tcp 连接数的参数，通过控制连接入口间接保护后端线程池，需结合后端线程上限、keepalive 长连接及 queue 排队机制闭环配置，并以压测数据驱动调优。
max_conns 是 Nginx upstream 中用于限制**单个后端节点并发 TCP 连接数**的关键参数，但它本身不直接控制后端线程池，而是通过“掐住连接入口”来间接防止后端线程池被打满。真正起效的前提是：它必须和后端真实承载能力对齐，并配合长连接、合理队列等机制落地。
明确 max_conns 的作用边界
它只统计 Nginx 主动发起并维持的 TCP 连接数量，不感知后端 CPU、内存、线程是否耗尽。也就是说：
- 如果后端 Tomcat 的 maxThreads=200，但 Nginx 的 max_conns=300，多余 100 个连接仍会打过去，大概率触发线程池排队超时或 Connection refused
- 如果没配 keepalive，每个请求都新建连接，连接生命周期极短，max_conns 很难持续达到阈值，限流基本失效
- worker_processes > 1 时，每个 worker 独立计数，实际总连接数略高于设定值（比如设 160，两个 worker 可能建出 170+），但不会翻倍，无需过度调低
让 max_conns 真正保护线程池的操作要点
关键不是单独设一个数字，而是形成闭环配置：
- 参考后端线程池上限定值：例如 Tomcat 的 maxThreads=200，建议 max_conns 设为 160～180（80%～90%），留出缓冲应对突发或慢请求
- 强制启用长连接复用：upstream 块中加 keepalive 64（值按后端连接池大小调整，常见 32–128）；proxy location 中加 proxy_http_version 1.1 和 proxy_set_header Connection ''
- 升级 Nginx 并启用排队机制：Nginx ≥ 1.23.3 时，在 upstream server 行追加 queue=10 timeout=30s，让超额请求排队等待而非直接丢弃，提升成功率
压测中验证与调优方法
不要凭经验拍脑袋设值，要靠压测数据驱动：
- 先对后端单独压测，找到响应时间明显上升或错误率陡增的并发点（如 P95 延迟突破 500ms 或 5xx 错误率＞1%）
- 把该并发值乘以 0.8～0.9 作为 max_conns 初始值，再在 Nginx 侧压测验证
- 观察 Nginx 的 upstream_addr 日志和 upstream_status，确认拒绝是否发生在 max_conns 达限时，而非因后端主动 reset
- 配合监控看后端线程池活跃数（如 Tomcat 的 currentThreadsBusy）、数据库连接数、GC 频率等，排除其他瓶颈干扰
