要用好upstream的keepalive需配齐三项：upstream中keepalive N设定每worker每后端空闲连接数；location中proxy_http_version 1.1启用HTTP/1.1；proxy_set_header Connection ""清除Connection头。
要用好 upstream 的 keepalive 处理大量后端连接，核心不是堆高数值，而是让 Nginx 连接池、HTTP 协议行为、后端服务响应三者对齐。配错一个环节，连接就无法复用，反而增加开销。
必须配齐的三项基础配置
单独写 keepalive 32 没用，这三项缺一不可：
-
upstream 块中声明连接池大小：例如
keepalive 64;，表示每个 worker 进程对每台后端最多缓存 64 个空闲长连接；若你有 4 个 worker 和 2 台后端，理论最大空闲连接数是 4 × 2 × 64 = 512 -
location 中启用 HTTP/1.1：加
proxy_http_version 1.1;，HTTP/1.0 不支持持久连接，不设这行，keepalive 形同虚设 -
清空 Connection 请求头：加
proxy_set_header Connection "";，否则客户端传来的Connection: close可能被透传给后端，导致其主动断连
按后端能力反推 keepalive 数值
这个值不能拍脑袋定，得根据后端单实例真实承载力来算：
- 先确认后端最大稳定并发数，比如 Tomcat 的
maxConnections=200，Go 服务的MaxIdleConnsPerHost或 Node.js 的默认连接上限 - 取安全系数 0.6～0.8，再除以 Nginx 的
worker_processes数量
例如：后端 maxConnections=2000，Nginx 有 4 个 worker → 2000 × 0.7 ÷ 4 ≈ 35，可设keepalive 32或48 - 设太小（如 8）会导致连接池频繁耗尽、复用率低；设太大（如 512）可能压垮后端或触发系统级限制（如 ulimit -n）
搭配 timeout 和 requests 控制连接生命周期
只设连接数不管“寿命”，容易出现僵死连接或过早释放：
-
keepalive_timeout：建议 20～45 秒，必须比后端空闲超时短至少 5 秒（如 Tomcat
connectionTimeout=60000ms，Nginx 就设keepalive_timeout 55s） - keepalive_requests：默认 100 太保守，生产环境推荐 500～1000；高频小请求可设更高，防止单连接长期占用却无实际收益
- 注意：这两个参数从 Nginx 1.15.3+ 才完全支持，老版本（如 1.12）只认
keepalive，不自动限制请求数和超时
验证是否真的复用成功
别只看配置文件，要从连接状态和流量行为确认效果：
- 在 Nginx 机器上执行：
ss -tan | grep :后端端口 | grep ESTAB | wc -l，压测中连接数应稳定在worker_processes × keepalive附近，而不是随 QPS 持续上涨 - 抓包观察连续请求是否复用同一源端口 → 目标端口组合；若反复出现 SYN/SYN-ACK，说明未复用
- 检查后端响应头是否含
Connection: keep-alive，且没有Connection: close；若有，可能是后端错误响应、WAF 干预或调试开关开启
