必须配齐proxy_http_version 1.1、proxy_set_header Connection ""和upstream keepalive三项配置，缺一不可；否则连接无法复用，后端仍频繁建连断连。
要让 Nginx 的 upstream keepalive 真正提升后端长连接复用效率，不能只加一行 keepalive 32。必须让协议版本、请求头控制、连接池参数三者严格对齐，否则配置形同虚设。
必须配齐的三项基础设置
这三项缺一不可，漏掉任意一个，连接就无法复用：
-
upstream 块中声明 keepalive 数值：例如
keepalive 48;，表示每个 worker 进程为该 upstream 中每台后端最多缓存 48 个空闲长连接；它必须写在upstream { }块内，且只能出现在http块下，嵌套在server或location中会报错。 -
location 中启用 HTTP/1.1：加上
proxy_http_version 1.1;。Nginx 默认向上游发 HTTP/1.0 请求，而 HTTP/1.0 不支持持久连接，不设这行，keepalive 完全无效。 -
清空 Connection 请求头：加上
proxy_set_header Connection "";（注意是空字符串）。否则 Nginx 可能透传客户端带的Connection: close，导致后端主动断连。
合理设置连接池生命周期参数
仅控制连接数量不够，还要管好单个连接的“寿命”，避免过早释放或长期滞留：
- keepalive_requests：建议设为 500～1000。默认 100 太保守，高并发 API 场景下容易让连接刚复用几次就被关闭；设太高（如超 5000）可能引发后端状态堆积，尤其 Java 应用。
-
keepalive_timeout：建议设为 20～30 秒，且必须比后端空闲超时小 5～10 秒。例如 Tomcat 的
connectionTimeout=60s，Nginx 就设keepalive_timeout 30s;；若设成 60s，Nginx 想复用时，后端早已关闭连接。
按后端能力反推 keepalive 数值
这个值不是拍脑袋定的，要结合后端单实例承载力和 Nginx worker 数量计算：
- 公式参考：
keepalive ≈ 后端单实例稳定并发 × 0.6～0.8 ÷ worker_processes - Tomcat（
maxConnections=200）、4 个 worker → 推荐keepalive 32或48 - Node.js / Go 轻量服务，单实例稳撑 1000 并发、8 个 worker → 可设
keepalive 96 - 盲目设过大（如 1000+）易触发文件描述符耗尽，或被后端 RST 重置。
验证是否真正生效
配置写完不等于跑通，必须实测确认：
- 在 Nginx 机器上执行：
ss -tan | grep :8080 | grep ESTAB | wc -l（把:8080替换为你的后端端口），压测中连接数应稳定在worker_processes × keepalive附近，而不是随 QPS 持续上涨。 - 对比开启前后：后端
TIME_WAIT数量是否明显下降、P95 延迟是否降低、建连耗时是否减少。 - 检查后端响应头是否含
Connection: keep-alive；若返回close或缺失，说明后端未配合，或中间有 WAF、负载均衡器干扰。
