必须配齐proxy_http_version 1.1、proxy_set_header Connection ''和upstream keepalive三项配置，缺一不可；否则连接无法复用，后端仍频繁建连断连。
要在 Nginx 中真正实现后端连接复用、降低建连开销，关键不是只加 keepalive 32，而是让协议版本、请求头控制和连接池配置三者协同生效。漏掉任一环节，连接池就形同虚设，QPS 上升时连接数仍会线性增长。
必须配齐的三项基础配置
这三项缺一不可，否则 upstream 的 keepalive 指令完全不生效：
-
启用 HTTP/1.1 协议：在
location块中添加proxy_http_version 1.1;。HTTP/1.0 默认关闭持久连接，不设此项，Nginx 仍向上游发短连接请求。 -
清空 Connection 请求头：加上
proxy_set_header Connection '';（注意是空字符串，不是"keep-alive"）。否则 Nginx 可能将客户端传来的Connection: close转发给后端，导致连接被主动中断。 -
在 upstream 块中声明 keepalive 数值：例如
keepalive 64;，表示每个 worker 进程最多缓存 64 个空闲连接到该 upstream。若你有 4 个 worker，理论最大空闲连接数就是 256，不是全局总数。
合理设置单连接生命周期
只控制连接数量不够，还要管好每条连接“活多久”和“干多少活”，避免堆积或过早释放：
-
keepalive_timeout：建议设为 20–45 秒，且必须小于后端服务的空闲超时（如 Tomcat 的
connectionTimeout）。若 Nginx 想复用，后端已关，复用就会失败并退化为短连接。 - keepalive_requests：默认仅 100，高并发 API 场景下易引发高频建连；建议调至 500–2000。React 类前端一次完整页面加载可能发起数十个请求，设 2000 可覆盖整条链路。
按后端能力反推连接池大小
keepalive 数值不能凭经验拍脑袋定，需结合后端承载力与 Nginx worker 分布来计算：
- 假设后端单实例最大连接数为 2000，Nginx 有 4 个 worker，按 70% 安全水位估算：
2000 × 0.7 ÷ 4 ≈ 35，那么keepalive 32或48更稳妥。 - 若后端返回响应头含
Connection: close（常见于错误响应、调试开关开启、WAF 干预），Nginx 会立即释放该连接，无法复用。务必检查后端日志和实际响应头。 - 负载策略建议改用
least_conn或hash $remote_addr，缓解长连接场景下连接倾斜问题——避免某台后端被“粘住”，其他节点空闲。
注意 HTTPS 后端的特殊处理
若后端本身是 HTTPS，不推荐直接 proxy_pass https://。这会导致 Nginx 无法复用 TLS 连接，每次请求都重建握手，失去连接池意义。
推荐架构是：客户端 ⇄ Nginx（HTTPS 终止） ⇄ 后端（HTTP + keepalive）。即 Nginx 解密 HTTPS 流量后，以明文 HTTP/1.1 协议转发，并启用完整的 upstream 连接池。
如确需直连后端 HTTPS，则需额外配置 proxy_ssl_* 系列指令（如 proxy_ssl_verify off、proxy_ssl_session_reuse on），但调试复杂、复用效率低，生产环境极少采用。
