Nginx upstream长连接池深度由keepalive指令决定，表示每个worker进程缓存的空闲长连接最大数量；需配合proxy_http_version 1.1和proxy_set_header Connection ''才能生效，缺一不可。
没有 keepalive_conns 这个 Nginx 配置项。你可能混淆了参数名——Nginx 中控制 upstream（后端）长连接池深度的核心指令是 keepalive，而非 keepalive_conns。
upstream 长连接池深度由 keepalive 决定
在 upstream 块中配置的 keepalive N，表示：每个 worker 进程为该 upstream 缓存的**空闲长连接最大数量**。它直接定义了连接池的“宽度”，也就是池子能同时保留多少条待复用的后端连接。
- 设为
keepalive 64→ 每个 worker 最多缓存 64 条空闲后端连接 - 若 Nginx 启动了 4 个 worker，则该 upstream 全局最多可持有约 256 条空闲连接（不考虑负载均衡分发偏差）
- 该值过小（如默认未配时为 0），Nginx 每次请求都新建后端连接，高频场景下必然触发大量 TCP 握手、TLS 协商和 TIME_WAIT 堆积
keepalive_requests 和 keepalive_timeout 是“使用规则”，不是“池深”
keepalive_requests 和 keepalive_timeout 不扩大池子容量，而是决定池中单条连接能否被持续复用：
- keepalive_requests M：单条空闲连接最多转发 M 次请求后，必须从池中移除（哪怕刚处理完第 M 次就断）
- keepalive_timeout T：空闲连接在池中最多保留 T 秒，超时即清理
- 二者共同防止连接“又老又闲”，但不增加池子本身能装多少连接
如何真正消除高频建连：三步协同调优
只调大 keepalive 不够，需与下游行为、协议支持、后端能力对齐：
-
第一步：设合理的 keepalive 值
参考后端单实例承载力 × 0.7，例如 TomcatmaxConnections=200→ 设keepalive 120；K8s 下单 Pod QPS 约 1k，建议 64–128 -
第二步：确保协议通路畅通
在location块中必须有：proxy_http_version 1.1;proxy_set_header Connection '';
否则 Nginx 仍会默认发Connection: close，后端无法复用 -
第三步：验证连接是否真复用
压测时执行：ss -tnp | grep :8080 | wc -l（假设后端端口 8080）
稳定后数值应贴近你设的keepalive值，而非随并发线性增长
常见误配与后果
以下组合会导致“看似配了 keepalive，实则无效”：
- 只在 upstream 写了
keepalive 100，但 location 里没加proxy_http_version 1.1→ 后端收不到 HTTP/1.1 请求，拒绝复用 - 后端服务（如 Spring Boot）未开启持久连接，响应头带
Connection: close→ Nginx 主动丢弃该连接，池子形同虚设 -
keepalive设得过大（如 1000），但后端 maxConnections 只有 200 → 连接被后端 RST，Nginx 日志出现upstream prematurely closed connection
