keepalive_timeout本质是空闲等待时长，非连接总寿命；它决定nginx发完响应后为下一个请求等待多久，有新请求则重置计时器，超时无动静即断开。
keepalive_timeout 的本质是“空闲等待时长”，不是连接总寿命。它只决定 Nginx 发完响应后，愿意为下一个请求多等多久；期间有新请求就重置计时器，超时没动静就主动断开。调得准，连接才真正被复用；调不准，要么白建连接，要么白占资源。
按业务节奏设值，别套通用数字
静态资源（JS/CSS/图片）加载密集、间隔短，用户常在几秒内连续发起多个请求，适合设 30–45 秒；API 接口尤其移动端，网络不稳定、中间设备（NAT/WAF）易静默断连，客户端自身保活也常设 60 秒以内，推荐 15–30 秒；后台系统或低频内网服务，用户操作稀疏，设 10–20 秒 更省资源。长轮询或 SSE 场景可设 60–300 秒，但必须验证客户端是否真会持续发心跳。
必须配套启用的三项关键机制
- keepalive_requests：限制单连接最多处理请求数（默认 100），建议设为 50–1000。防止单个连接因异常请求（如大文件中断）长期滞留，形成“假活跃”连接。
-
upstream keepalive：在 upstream 块中开启连接池，例如
keepalive 32;。它和 client 侧 timeout 无关，但需配合proxy_http_version 1.1;和proxy_set_header Connection '';才生效。 - reset_timedout_connection on：启用后，超时直接发 RST 而非 FIN，跳过 TIME_WAIT，内核立刻回收 socket。对慢速攻击或弱网残留连接特别有效。
验证是否真起作用，而不是改了就完事
光看配置没用，要盯运行指标：
– 用 ss -tn | grep :443 | grep ESTAB | wc -l 观察 ESTABLISHED 连接数趋势，调低 timeout 后应明显回落；
– 看 nginx stub_status 中的 Waiting 状态数，持续偏高说明空闲连接堆积；
– 开启日志变量 $connection_requests，分析单连接平均承载请求数，若远低于 keepalive_requests 设定值，说明复用率低；
– 检查 error log 是否频繁出现 upstream prematurely closed connection 或 Connection reset by peer，常是上下游 timeout 错位所致。
全链路超时必须对齐，否则白调
Nginx 与客户端、Nginx 与后端、后端自身三段超时要形成安全区间：
– 客户端收到的 Keep-Alive 提示（第二个参数）应略小于 Nginx 自身关闭时间（第一个参数），例如 keepalive_timeout 30 25;；
– proxy_read_timeout 应 ≤ keepalive_timeout 第一个值，且 严格小于 后端服务的连接超时（如 Tomcat 的 connectionTimeout）；
– 若中间有 LVS、云负载均衡或 WAF，它们的空闲超时也必须 ≥ Nginx 的 keepalive_timeout，否则连接会在半路被截断。
