keepalive_timeout作用于客户端连接，不直接管理upstream连接池，但需与后端keep-alive超时对齐（如后端60s则nginx设55s），避免502错误或复用失败；websocket场景建议10–20s以保障握手完成。
keepalive_timeout 在 Nginx 中本身不直接管理 TCP 连接池，它作用于客户端连接（即前端到 Nginx），与 upstream 连接池（Nginx 到后端）无关。但它的配置会间接影响连接池的稳定性与复用效果，尤其在协议协商、资源竞争和错误连锁反应中起关键作用。
它不控制连接池，但决定连接池能否“活下来”
Nginx 的 upstream 连接池由 upstream { keepalive N; } 显式启用，其生命周期受三要素共同约束：
proxy_http_version 1.1proxy_set_header Connection ''- 后端实际支持并维持长连接
而 keepalive_timeout 若设置不当，会在上游连接尚未复用前就“误杀”链路：
- 若
keepalive_timeout大于后端 keep-alive 超时（例如 Nginx 设 90s，后端只维持 60s），后端可能先关闭连接，Nginx 却仍认为连接可用 → 下次复用时触发upstream prematurely closed connection或502 Bad Gateway - 若
keepalive_timeout过小（如 ≤10s），客户端频繁重连，导致 Nginx worker 进程短时间内新建大量 upstream 连接请求，冲垮连接池初始化节奏，空闲连接来不及缓存就被挤出
对 WebSocket 场景：影响握手阶段的连接可用性
WebSocket 升级发生在 HTTP 层，keepalive_timeout 控制的是升级请求发出后、响应返回前的空闲等待窗口：
- 设为 5s：弱网用户可能在发送 Upgrade 请求后卡顿，Nginx 先断连 → 握手失败
- 设为 60s：虽保握手，但若后端响应慢或网络抖动，Nginx 会持续占用该连接直到超时，阻塞后续请求排队
此时真正保长连接的是 proxy_read_timeout，但 keepalive_timeout 是第一道守门人——它必须留足时间让 Upgrade 成功完成。
配置建议：与上下游对齐，而非孤立调大
- 普通 HTTP 反向代理：设为 55–60 秒，比后端
keep-alive-timeout小 5–10 秒（如 Spring Boot 设server.tomcat.keep-alive-timeout=60，Nginx 就设keepalive_timeout 55;） - WebSocket 业务：设为 10–20 秒，确保足够完成 HTTP 握手，又不拖慢连接周转
- 不要设为 0 或过高（如 300s）：前者彻底禁用复用；后者易造成 worker 进程连接堆积，fd 耗尽风险上升
注意：检查连接复用是否生效，不能只看配置，要结合 ss -t | grep :80 观察端口复用、curl -v 看响应头 Connection: keep-alive、以及后端 ss -s | grep time_wait 是否明显下降。
