要真正压榨后端API网关吞吐红利，关键在于让keepalive连接池“稳、准、快”复用：需显式启用upstream keepalive池，配置proxy_http_version 1.1和空Connection头，合理设置keepalive_requests与keepalive_timeout，并验证生效。
要真正压榨后端 API 网关的吞吐红利，关键不是堆配置，而是让 keepalive 连接池“稳、准、快”地复用——稳在不中断，准在不浪费，快在不等待。默认配置下 Nginx 从不复用 upstream 连接，所有请求都新建 TCP，这是吞吐瓶颈的根源。
必须显式启用 upstream keepalive 池
仅靠 client 到 Nginx 的 keep-alive 没用，upstream 连接池需手动开启：
- 在
upstream块内加keepalive 64;（建议 32–200，按后端实例数×1.5 估算） - 禁用默认 close 行为：location 中必须写
proxy_http_version 1.1;和proxy_set_header Connection ''; - 确认后端支持 HTTP/1.1 长连接（如 Spring Boot 默认 OK，但 Tomcat 的
connectionTimeout建议 ≥ 30s）
keepalive_requests 要匹配真实请求节奏
它不是越大越好，而是看“一个连接平均能干多少活”：
- 高频轻量 API（如移动端轮询、微服务间调用）：设为 1000–3000，覆盖 2–6 分钟请求流，握手开销降约 90%
- gRPC（HTTP/2）后端：可设 5000–10000，但需同步检查服务端
max_concurrent_streams和客户端是否启用多连接 - 老旧 Java 应用（如 Tomcat maxKeepAliveRequests=100）：必须 ≤ 后端值，否则报
upstream prematurely closed connection
keepalive_timeout 必须比后端更短
它和 keepalive_requests 是并列退出条件，谁先到谁生效：
- 高频场景推荐 15–30 秒：足够覆盖请求间隙，又避免空挂占位
- 若后端设了 idle_timeout=60s，Nginx 最多设 45s；设成 60s 反而可能卡在 CLOSE_WAIT
- 云厂商 SLB 或 LB 层若有更短空闲超时（如 60 秒），Nginx 配置再优也白搭，需一并排查
验证是否真生效，别只看配置
调完不验证 = 白调：
- 用
ss -tan | grep :8080 | wc -l对比高峰连接数，应明显低于调优前 - Nginx 日志加
$upstream_connect_time $upstream_header_time，观察建连耗时是否稳定下降 - 抓包或查响应头，确认后端返回含
Connection: keep-alive，且无意外Connection: close
