Nginx中keepalive N表示每个worker对upstream每台后端服务器最多缓存N个空闲长连接，需按后端并发能力反推合理值，并配合keepalive_requests、keepalive_timeout及proxy_http_version 1.1等参数协同生效。
“keepalive_conns”不是 Nginx 官方参数名，正确指令是 keepalive N，它控制的是每个 worker 进程为 upstream 中**每台后端服务器**缓存的空闲长连接数。调优它的核心目标，是让高频请求尽可能复用已有 TCP 连接，从而消除反复握手、TLS 协商和 TIME_WAIT 堆积带来的性能损耗。
先搞清 keepalive 的真实含义
很多人误以为 keepalive 64 表示“最多连 64 条”，其实它表示：
- 单个 Nginx worker 进程，对 upstream 里定义的每一台 server（比如 10.0.1.10:8080），最多保留 64 个已建立、当前空闲、可立即复用的连接；
- 活跃请求仍会新建连接，超出 keepalive 数的部分不会被拒绝，只是不进池子；
- 若 upstream 有 2 台 server、Nginx 启了 4 个 worker，则理论最大空闲连接数是 4 × 2 × 64 = 512 —— 这个总数必须 ≤ 后端单实例能稳定承载的并发连接上限。
按后端能力反推合理 keepalive 值
不能拍脑袋设数字，要结合后端单实例的健康并发能力来算：
- 公式：keepalive ≈ （后端单实例最大健康连接数 × 安全系数）÷ Nginx worker 进程数；
- 安全系数建议取 0.6～0.8，留出缓冲应对慢响应或突发流量；
- 例如：后端是 Spring Boot + Tomcat，默认 maxConnections=200，Nginx 有 4 个 worker → keepalive ≈ 200 × 0.7 ÷ 4 = 35 → 可设为 32 或 48；
- 再如：后端是 Go Gin，单实例稳撑 1000 并发，部署 8 个 worker → keepalive ≈ 1000 × 0.75 ÷ 8 ≈ 94 → 设 96 更稳妥。
配套参数必须同步生效
只配 keepalive 不起作用，必须和以下两项联动，构成完整复用链路：
- keepalive_requests M：单个 keepalive 连接最多转发多少次请求后主动关闭。默认 100 太保守，高频短连接业务（如心跳、轮询）建议设 1000–5000；
- keepalive_timeout T：空闲连接在池中保留多久（秒）。关键原则是必须比后端的空闲超时短至少 5 秒（如 Nginx 设 25s，Tomcat connectionTimeout 至少 30s）；
- 高频场景下推荐组合：keepalive_requests 2000 + keepalive_timeout 15–30s，实现“次数+时间”双控，防止单连接僵而不死或用几次就扔。
别漏掉 proxy 层的关键三件套
即使 upstream 配好了 keepalive，如果 proxy_pass 层没打通，连接照样无法复用：
- 在 location 块中必须加：proxy_http_version 1.1;
- 必须加：proxy_set_header Connection '';（清空客户端可能传来的 Connection: close）；
- 确保后端响应头含 Connection: keep-alive，而不是 close —— 抓包或 curl -v 可验证。
