启用upstream keepalive可显著提升TPS，因复用空闲连接避免频繁建连开销；需在upstream块配keepalive数量、proxy_pass上下文清空Connection头，并确保后端支持HTTP/1.1 keepalive。
开启 Nginx 作为 HTTP 代理时的 upstream keepalive，能显著减少连接建立开销，提升后端服务的吞吐能力（TPS），尤其在高并发、短请求场景下效果明显。
为什么 upstream keepalive 能提升 TPS
Nginx 默认对每个请求都新建一条到 upstream 的 TCP 连接（HTTP/1.1 默认不复用），频繁的三次握手、TLS 握手（如启用 HTTPS）和连接释放会成为瓶颈。启用 keepalive 后，Nginx 会复用与后端服务器的空闲连接，避免重复建连，降低延迟、节省系统资源（如 TIME_WAIT 套接字、文件描述符），从而支撑更高并发请求量。
关键配置项说明与推荐写法
需在 upstream 块 和 proxy_pass 上下文 中协同配置：
-
upstream 中启用 keepalive：
upstream backend {<br> server 127.0.0.1:8080;<br> keepalive 32;<br>}
→ 表示该 upstream 最多缓存 32 个空闲长连接；建议从 16–64 开始调优，不宜过大（避免后端连接数失控） -
关闭请求头中的 Connection: close：
proxy_http_version 1.1;<br>proxy_set_header Connection '';
→ 强制使用 HTTP/1.1 并清空 Connection 头，让后端知道可复用连接 -
可选：设置超时控制空闲连接生命周期：
keepalive_timeout 60s;<br>keepalive_requests 1000;
→ 分别控制单个 keepalive 连接最大空闲时间和最多处理请求数（防长连接僵死）
验证是否生效的常用方法
配置生效后，可通过以下方式确认 keepalive 是否起作用：
- 检查 Nginx error.log 中是否有
upstream sent too big header或upstream prematurely closed connection类报错（可能因后端不支持 keepalive 导致连接异常中断） - 用
ss -tan | grep :8080 | wc -l观察 Nginx 到后端的 ESTABLISHED 连接数是否稳定在较低水平（如几十个），而非随 QPS 线性增长 - 用 tcpdump 抓包观察 TCP 层是否出现大量 SYN/SYN-ACK 循环（未启用 keepalive 的典型特征）
- 对比压测前后 TPS 和平均延迟变化（如 wrk / ab 工具），通常延迟下降 10%–40%，TPS 提升 20%–100%+（取决于后端响应时间与网络 RTT 比例）
注意事项与常见坑点
keepalive 不是“一配就灵”，需结合实际环境谨慎调整：
- 后端服务必须支持 HTTP/1.1 keepalive（如 Tomcat、Spring Boot 内嵌容器默认支持；某些老旧 CGI 或脚本服务可能不支持）
- 若后端启用了连接池（如数据库连接池），Nginx 的 keepalive 不影响其内部池行为，但可减少其接受新连接的压力
- HTTPS upstream 场景下，TLS 握手复用同样受益；但注意 SSL session reuse 配置（如
ssl_session_cache shared:SSL:10m;）也应开启以进一步优化 - 避免 upstream 中混用 keepalive 和非 keepalive server（例如部分 server 后加
max_fails=0 fail_timeout=0却没统一 keepalive 设置），可能导致连接复用失效
