keepalive_timeout控制nginx与客户端空闲http连接最长保持时间，首参数为服务端等待新请求的秒数，次参数为响应头中提示客户端的timeout值；设太短致频繁重建连接增加开销，设太长则空闲连接占用文件描述符与内存，高并发下易触发too many open files错误。
keepalive_timeout 本身不主动“提升”效率，而是为连接复用创造必要条件——设得合理，客户端才可能在同一个 TCP 连接上发多个请求；设得不当，复用根本不会发生。
它只管“空闲多久就关”，不决定连接能否建立
这个指令定义的是：Nginx 发完响应后，愿意等待下一个请求的最长时间。期间只要客户端再发请求，计时器就重置，连接继续复用；超时没动静，就主动断开。
- 它不影响正在传输或处理中的连接，只作用于“静默期”
- 它不控制 TLS 握手、HTTP/2 多路复用或会话票据等机制
- 它只作用于 Nginx 与客户端之间，对后端（upstream）连接完全无效
设太短：复用机会被人为掐断
比如设成 5 秒，而页面加载完 JS 后隔 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、图片/JS/CSS）：60–120 秒，用户常批量请求，复用价值高
- API 网关或移动端后端：15–30 秒，网络不稳定、请求间隔不规律
- 微服务间高频调用：5–15 秒，并必须配合 keepalive_requests 50–100
- 低带宽环境（弱网 App、2G/卫星链路）：15–30 秒，重点摊薄建连头部成本
