keepalive_timeout 不提升传输效率，而是决定客户端空闲连接保持时长；仅作用于 Nginx 与客户端间，不影响后端；设太短导致复用失败、延迟升高，设太长引发资源堆积；需按场景设值：移动端 API 推荐 15–25 秒，混合站点 5–10 秒，HTTP/2 可设 0 或 5 秒，内网或 SSE 接口 60–300 秒，高并发网关 ≤5 秒。
keepalive_timeout 本身不直接“提升”传输效率，而是为连接复用创造前提条件——设得合理，连接才可能被复用；设得不当，复用就无从谈起。
明确作用对象：只管客户端连接，不管后端
这个参数仅控制 Nginx 与客户端之间空闲连接的等待时长，和 upstream（后端）完全无关。它定义的是：响应发完后，Nginx 愿意等下一个请求多久。期间有新请求，计时器重置；超时没动静，就断开。
它不影响正在传输的数据，也不干预 TLS 握手或 HTTP/2 多路复用。想优化到后端的连接效率，必须单独配置 upstream keepalive、proxy_http_version 1.1 等指令。
设太短：复用机会被人为掐断
- 比如设成 5 秒，而 App 加载完资源后 8 秒才发登录请求，首条连接已被关闭，第二条只能新建：三次握手 + TLS 协商重复触发
- HTTPS 下延迟明显升高，TTFB 上涨，CPU 开销增加
- 内核 TIME_WAIT 连接激增，可能快速耗尽本地端口或 conntrack 表项
- 移动端尤其明显——系统后台回收、中间设备静默断连，会让低 timeout 彻底失效
设太长：空闲连接堆积，反拖慢系统
- 设 300 秒，但客户端实际 20 秒就断开了，或 WAF 已在 60 秒回收连接，Nginx 却还在傻等
- 每个空闲连接占用一个文件描述符（fd），worker 进程容易 hit “Too many open files”
- socket 结构、SSL 上下文、缓冲区持续驻留内存，累积不可忽视
- nginx_stub_status 中 Waiting 状态偏高，说明大量连接“挂着却没人用”
按场景给建议值，不是越长越好
没有通用最优值，必须贴合真实流量节奏和终端行为：
- 纯移动端 API 服务：15–25 秒。覆盖 App 短频请求间隙，避免后台休眠后空占资源
- 含静态资源的混合站点：5–10 秒。移动端加载快、复用窗口短，过长反而挤占新连接槽位
- 启用 HTTP/2 的服务：可设为 0 或 5 秒。HTTP/2 自带多路复用，连接生命周期由客户端主导更合理
- 内网服务或 SSE 流式接口：60–300 秒。客户端持续复用，适合长连接保持
- 高并发网关或 CDN 边缘节点：≤5 秒。快速回收，防文件描述符耗尽
