keepalive_timeout直接决定nginx空闲连接复用能力，设太短致频繁重连增加握手开销，太长则空闲连接堆积耗尽fd与内存；需按场景设5–300秒并联动keepalive_requests、upstream keepalive等协同调优。
keepalive_timeout 直接决定 Nginx 是否以及多久能复用客户端连接。它不控制连接总时长，只管“空闲多久就关”——收到请求重置计时器，无新请求超时即断开。设得不合理，要么白耗资源，要么白增开销。
太短：重连开销压垮性能
空闲等待时间过短，客户端还没来得及发第二个请求，连接就被关了：
- TCP 三次握手 + 四次挥手频繁触发，延迟明显上升，尤其在高延迟网络（如移动、跨地域）中更显著
- HTTPS 下每次重连都需完整 TLS 握手（除非会话复用生效），CPU 占用和首字节时间（TTFB）双双升高
- 内核 TIME_WAIT 状态激增，可能快速耗尽本地端口或连接跟踪表项（如 iptables conntrack）
- 移动端 App 或小程序常批量请求后休眠几秒，若 timeout 设为 5s，大量连接刚建立就关闭，复用率趋近于零
太长：空闲连接吃光资源
空闲连接长期挂起，看似“随时可复用”，实则悄悄拖垮系统：
- 每个连接占用一个文件描述符（fd），worker 进程 fd 数上限（由 worker_connections 和 ulimit -n 控制）很快被占满，新连接被拒绝，报错 “Too many open files”
- 内存持续增长：每个连接保留在内存中的 socket 结构、缓冲区、SSL 上下文等累积消耗不可忽视
- 活跃连接数（Active connections）中 Waiting 状态过高，说明大量连接处于空闲待命态，但实际复用率低，属无效驻留
- 企业网关、WAF 或 NAT 设备往往有更短的连接空闲回收策略（如 2–5 分钟），Nginx 设 300s 也无意义，反而加剧堆积
按场景设合理值，效果才真实
没有万能值，必须匹配业务流量节奏和客户端行为：
- 静态资源服务（CDN、图床、前端资源）：用户并发加载 JS/CSS/图片，空闲期短，复用密集 → 推荐 30–45 秒
- API 接口（App、小程序后端）：弱网易中断，中间设备干扰多，客户端自身超时常为 60–120s → 推荐 15–30 秒
- 后台管理系统或低频内网服务：用户操作间隔长，连接复用率天然低 → 可设 10–20 秒，避免空等
- 长轮询或 SSE 场景：需确认客户端持续心跳且链路透传 keep-alive → 可设 60–300 秒，但必须同步验证客户端行为
单调 keepalive_timeout 不够，必须联动
它只是连接复用链条上的一环，单独调整收效有限：
- 搭配 keepalive_requests：防止单连接无限承载请求（如大文件下载中途断连），建议设为 50–1000，与 timeout 协同（例：timeout=30s 时 requests=100）
- upstream keepalive 必须显式开启：proxy_pass 到后端时，仅 client 端复用没用，还需 upstream 块中配置 keepalive 32; + proxy_http_version 1.1; + proxy_set_header Connection '';
- 检查 client_header_timeout / client_body_timeout：这两项必须 ≤ keepalive_timeout，否则请求头/体慢速上传可能被误判为空闲而提前关闭连接
- 关注客户端与中间链路：用 curl -v 观察是否出现 “left intact”，或抓包看多个请求是否共用同一 TCP 流；若响应头缺失 Keep-Alive: timeout=，说明上游或 WAF 已静默清除
