keepalive_timeout控制nginx与客户端空闲连接最长等待时间（5～60秒为佳），设太短增握手开销，太长致资源占用，仅作用于前端连接，需配合keepalive_requests及upstream keepalive协同调优。
keepalive_timeout 本身不直接“提升”复用效率，而是通过控制空闲连接的存活时长，为复用创造条件——设得合理，连接才可能被复用；设得不当，复用就无从谈起。
它只管“空闲多久就关”，不决定连接能否建立
这个指令定义的是：Nginx 在发完响应后，愿意等待下一个请求的最长时间。期间只要客户端再发请求，计时器就重置，连接继续复用；超时没动静，就主动断开。
- 它不影响 TLS 握手、HTTP/2 多路复用或会话票据（session ticket）等机制
- 它也不控制连接总寿命，只管“静默期”——传输中或正在处理请求的连接不会被它中断
- 它只作用于 Nginx 与客户端之间，对 upstream（后端）连接完全无效
设太短：复用机会被人为掐断
比如设成 5 秒，而 App 加载完 JS/CSS 后要等 8 秒才发登录请求，那第一条连接刚建好就被关了，第二条请求只能新建连接：
- TCP 三次握手 + 四次挥手频繁触发，延迟上升
- HTTPS 下每次重连都重做 TLS 握手（除非会话复用生效），CPU 和 TTFB 都升高
- 内核 TIME_WAIT 激增，可能快速耗尽本地端口或 conntrack 表项
- 移动端或小程序批量请求后休眠的行为，会让复用率趋近于零
设太长：连接空占资源，反而拖慢系统
比如设成 300 秒，但客户端实际 20 秒就断开了，或者中间 WAF 已在 60 秒回收连接，Nginx 却还在傻等：
- 每个空闲连接占用一个文件描述符（fd），worker 进程容易 hit “Too many open files”
- socket 结构、SSL 上下文、缓冲区持续驻留内存，累积不可忽视
- 活跃连接数里 Waiting 状态偏高，说明大量连接“挂着却没人用”
- 企业网关、云 LB 等设备常有更短的空闲回收策略，Nginx 设再长也白搭
按场景设值，复用才真实发生
没有通用最优值，必须匹配流量节奏和客户端行为：
- 静态资源服务（CDN、图床）：用户并发加载多资源，空闲期短 → 推荐 30–45 秒
- API 接口（App、小程序）：弱网多、间隔不规律 → 推荐 15–30 秒
- 后台管理系统或内网服务：操作间隔长、复用天然低 → 可设 10–20 秒
- 长轮询或 SSE：需确认客户端心跳透传 → 可设 60–300 秒，但必须验证链路是否真支持
