nginx代理场景下keepalive_timeout需小于后端空闲超时（如tomcat connectiontimeout）并预留10秒缓冲，同时必须与upstream keepalive连接池、proxy_http_version 1.1及proxy_set_header connection ""三者对齐，否则易引发连接堆积、502/504或上游枯竭。
合理设置 Nginx 代理场景下的 keepalive_timeout，关键不是单独调大或调小，而是让它和后端服务、连接池、协议头三者对齐——否则容易出现连接堆积、502/504、或上游连接枯竭。
先看后端实际能撑多久
这个值必须小于后端服务的空闲超时（比如 Tomcat 的 connectionTimeout、Node.js 的 server.keepAliveTimeout），通常建议留出 10 秒缓冲：
- 后端设为 60 秒 → Nginx
keepalive_timeout设为 50 秒 - 后端设为 30 秒 → Nginx 设为 20 秒
- 后端未明确配置？查默认值：Spring Boot 2.3+ 默认是 60 秒，Tomcat 9 默认是 20000 毫秒（即 20 秒）
再配 upstream 的 keepalive 连接池
仅改 keepalive_timeout 不起作用。upstream 块中必须显式启用长连接池，并控制容量：
- 写法示例：
upstream backend { server 10.0.1.10:8080; keepalive 120; } - 数值不能拍脑袋：按后端单实例最大并发连接数 × 0.6～0.8 计算。例如后端
maxConnections=200，Nginx 有 4 个 worker，就设keepalive 120–160 - 值太大 → 后端拒绝新连接；太小 → 频繁建连，CPU 和 TIME_WAIT 上升
别忘了协议头和单连接请求数
这两项不配，HTTP/1.1 复用根本不会生效：
- 在
location块中加：proxy_http_version 1.1;和proxy_set_header Connection ''; - 同步调整
keepalive_requests：默认 100 太保守，生产建议设 1000–5000；设太低会反复断连，太高又可能复用到已被后端关闭的“僵尸连接”
验证是否真正跑通
上线后不能只看配置写了没，要抓真实信号：
- 用
curl -I https://your.api/查响应头：确认含Connection: keep-alive和Keep-Alive: timeout=XX - 执行
ss -tnpo | grep :443 | grep ESTAB | wc -l观察连接数趋势：稳定在合理范围（比如并发 500 时 ESTABLISHED 在 600–800 是健康的） - 若发现大量连接卡在
CLOSE_WAIT或TIME_WAIT，大概率是上下游超时没对齐
