nginx upstream keepalive本质是复用与后端的tcp连接，需按worker数×后端承载能力合理设n值（如tomcat建议32–64），并严格配套proxy_http_version 1.1和proxy_set_header connection ""才能生效。
在 Nginx 的 upstream 块中配置 keepalive 指令，本质是复用与后端（如 Tomcat、Go HTTP Server、gRPC 服务等）建立的 TCP 连接，避免频繁握手/挥手开销，提升吞吐、降低延迟。调优关键不是“设得越大越好”，而是匹配后端承载能力、请求特征与连接生命周期。
理解 keepalive 的三个核心参数含义
keepalive N;（必须放在 upstream 块内）只控制**每个 worker 进程维护的空闲长连接池大小**，不是总连接数，也不影响连接是否启用 HTTP/1.1 keep-alive 协议头。
-
N 是 per-worker 空闲连接上限：若 Nginx 有 4 个 worker，
keepalive 32最多缓存 4×32 = 128 条空闲连接（仅限该 upstream） -
连接复用需客户端+代理+后端三方协同：Nginx 要主动发
Connection: keep-alive（默认开启），后端也必须支持并保持连接不立即关闭 - 空闲连接超时由后端决定：Nginx 不主动 kill 空闲连接，但当后端先 close（如 timeout=60s），Nginx 下次复用时会探测失败并自动剔除
根据后端特性设定合理的 keepalive 数值
盲目设高（如 1000）易导致后端连接数暴涨、端口耗尽或 TIME_WAIT 淤积；设太低（如 4）则池子形同虚设，频繁建连。
- 若后端是单机 Java 应用（如 Spring Boot + Tomcat），默认 maxConnections=200，建议
keepalive设为 32～64，留出余量给其他 upstream 或突发流量 - 若后端是轻量 Go/Node.js 服务，连接处理快、内存占用低，可设 128～256，尤其适合高 QPS 小包场景
- 对接 gRPC（HTTP/2），由于多路复用特性，单连接承载能力强，
keepalive 32通常已足够，重点应调http2_max_requests和后端 stream 复用策略
配套必须启用的 upstream 和 location 配置
仅写 keepalive N 不生效——它只是“池子容量”，还需显式开启连接复用行为：
- 在
upstream中加：keepalive_timeout 60s;（非必需但推荐，明确空闲连接最长保留时间） - 在
location或server块中，确保有：proxy_http_version 1.1;和proxy_set_header Connection '';（清空客户端传来的 Connection 头，避免干扰） - 禁用
proxy_buffering off;可能导致连接无法复用（因响应未完整读取就释放连接），建议保持 buffering 开启
验证与观测调优效果
不要只看配置是否写对，要确认连接是否真被复用：
- 查 Nginx 连接统计：
ss -tan | grep :<backend_port> | wc -l</backend_port>（对比调优前后 ESTAB 连接数变化） - 开启 Nginx stub_status（需编译时含 http_stub_status_module），观察
Active connections和Reading/Writing/Waiting分布 - 后端侧抓包或日志：检查是否有大量
FIN/ACK频繁出现；或观察连接创建频率（如 Tomcat 的connectionCreatedCountJMX 指标）是否下降 - 压测对比：用 wrk / hey 对比相同 QPS 下的 avg latency 和 CPU usage，复用率提升通常带来 5%～20% 延迟下降
