要真正压榨后端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

大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！