upstream keepalive_timeout 是 nginx 1.15.3+ 中控制 nginx 到后端空闲长连接存活时长的参数，仅作用于 upstream 连接池，需在 upstream 块内配置且依赖 keepalive、http/1.1、connection 头等前提，建议设为 20–45 秒并严格小于后端超时值。
upstream keepalive_timeout 是 Nginx 1.15.3+ 中控制「Nginx 到后端服务」空闲长连接存活时长的关键参数，它不作用于客户端连接，只影响 upstream 连接池中那些暂无请求转发的空闲连接能保留多久。配错会导致连接提前关闭（复用率低）或长期滞留（资源浪费、后端主动踢断）。
keepalive_timeout 的定位与生效前提
这个参数必须写在 upstream 块内，且仅在以下条件全部满足时才起作用：
- upstream 已启用
keepalive N（定义连接池容量） - proxy 层已设置
proxy_http_version 1.1 - proxy 层已设置
proxy_set_header Connection '' - 后端服务响应头含
Connection: keep-alive（HTTP/1.1 默认行为），且其自身空闲超时（如 Tomcat 的connectionTimeout）严格大于该值
若缺少任一环节，Nginx 将退化为短连接，keepalive_timeout 完全不参与决策。
合理取值范围与设置逻辑
建议设为 20–45 秒，核心依据是“小于后端、大于网络抖动”：
- 必须小于后端服务的 keepalive 空闲超时（例如：Tomcat
connectionTimeout="60000"→ 60s，Nginx 就应设 ≤55s；Node.jsserver.keepAliveTimeout = 75000→ 75s，Nginx 可设 60s） - 避免过短（如 ss -tan | grep :port | wc -l 显示 ESTABLISHED 数剧烈波动
- 避免过长（如 >60s）：空闲连接积压，可能被后端单方面关闭（触发 RST），Nginx 日志出现
upstream prematurely closed connection
实际配置示例与常见误区
upstream api_backend {
server 10.0.2.5:8080;
server 10.0.2.6:8080;
keepalive 64; # 每 worker 缓存最多 64 个空闲连接（每台后端）
keepalive_timeout 30s; # 空闲连接在池中最多保留 30 秒
keepalive_requests 1000; # 单连接最多转发 1000 次请求（防状态累积）
}
⚠️ 注意：
-
keepalive_timeout 30s和http块里的keepalive_timeout 60s完全无关，后者管的是浏览器→Nginx 这一段 - 不要写成
keepalive_timeout 30;（缺单位），Nginx 会报错或按毫秒解析，导致连接几毫秒就被回收 - Windows 与 Linux 下行为一致，无需额外适配
验证是否按预期工作
- 观察连接数稳定性：持续压测时，执行
ss -tan | grep :8080 | grep ESTAB | wc -l，数值应在keepalive × worker_processes的 60%~90% 区间小幅浮动（如 2 台后端 + 4 个 worker + keepalive 64 → 理论上限 512，实测维持在 300~450 属正常） - 抓包确认复用：
tcpdump -i any port 8080 -nn -c 100，若连续请求间无重复 SYN，说明连接确实在复用
不复杂但容易忽略
