必须配齐proxy_http_version 1.1、proxy_set_header connection ''和upstream keepalive三项配置，缺一不可；还需合理设置keepalive_timeout（20–45秒）、keepalive_requests（500–2000）并匹配后端承载能力与负载策略，否则连接无法复用。
要让 Nginx 高效管理后端连接池，核心不是简单加一行 keepalive，而是让协议版本、请求头控制、连接池配置和后端行为四者严格对齐。漏掉任一环节，连接就无法复用，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 分布来计算：
- 若后端单实例平均并发连接数约 20，worker_processes 为 4，建议设
keepalive 32或更稳妥。 - 若后端返回响应头含
Connection: close（常见于错误响应、调试开关开启、WAF 干预），Nginx 会立即释放该连接，无法复用。务必检查后端日志和实际响应头。 - 负载策略建议改用
least_conn，缓解长连接场景下连接倾斜问题——避免某台后端被“粘住”，其他节点空闲。
HTTPS 后端的特殊处理
若后端本身是 HTTPS，不推荐直接 proxy_pass https://。这会导致 Nginx 无法复用 TLS 连接，每次请求都重建握手，失去连接池意义。
- 推荐架构是：客户端 ⇄ Nginx（HTTPS 终止）⇄ 后端（HTTP + keepalive）。即 Nginx 解密 HTTPS 流量后，以明文 HTTP/1.1 协议转发，并启用完整的 upstream 连接池。
- 如确需直连后端 HTTPS，则需额外配置
proxy_ssl_*系列指令（如proxy_ssl_verify off;），但复用效率和调试难度显著上升，实际中极少需要。
