keepalive_timeout 的优化价值在于平衡连接复用与资源消耗，合理设为15–45秒可减少tcp/tls握手、降低延迟、节省cpu和fd资源，并需配合keepalive_requests、upstream keepalive及reset_timedout_connection才能发挥最大效果。
keepalive_timeout 的优化价值不在“设大就快”，而在于让连接复用真正发生——既不让它太早断，也不让它空耗资源。它对性能的提升是间接但关键的：减少 TCP 握手和 TLS 协商次数，从而降低延迟、节省 CPU、缓解端口与文件描述符压力。
直接降低首字节时间（TTFB）和网络延迟
客户端发起第二个请求时，若前一个连接还在 keepalive 状态，就能复用已有 TCP 连接。这意味着：
- 跳过三次握手（约 1–3 RTT），尤其在跨地域或移动网络中效果明显
- 避免重复 TLS 握手（完整握手耗时可达 100ms+），即使启用会话复用，也需额外交互
- 减少内核 TIME_WAIT 状态堆积，避免端口耗尽导致新连接失败
缓解服务器资源压力
每个空闲连接都占用一个文件描述符（fd）、内存缓冲区和 SSL 上下文。合理设置 timeout 可防止无效驻留：
- 设为 15–30 秒（API 场景）或 30–45 秒（静态资源）后，连接数更贴近真实并发，worker 进程 fd 不易触顶
- Waiting 状态连接大幅减少，nginx_stub_status 中 Active connections 更健康
- 内存 RSS 增长平缓，避免因连接堆积触发 OOM 或被系统 kill
配合其他机制才能释放全部价值
单独调这个参数，效果有限。必须同步落地三项配套：
- keepalive_requests：防止单连接无限承载，建议设为 100–1000，与 timeout 形成“时间+次数”双退出
- upstream keepalive：后端连接池（如 keepalive 32;）+ proxy_http_version 1.1 + proxy_set_header Connection ''，否则前端复用再好，后端仍频繁建连
- reset_timedout_connection on：超时后发 RST 而非 FIN，加速 socket 回收，对抗慢速攻击或僵死连接
不同场景下的收益差异明显
不是所有服务都靠它提效，但以下场景改善最直观：
- App 小程序后端：用户批量请求后休眠几秒，timeout 设 15s 比 75s 复用率高 3 倍以上，TTFB 下降 20%+
- CDN 边缘节点：JS/CSS/图片并发加载密集，30s timeout 让单连接平均承载 8–12 次请求，握手开销摊薄至可忽略
- 高频轮询接口：每 3 秒一次心跳，30s timeout 支持复用 10 次，比每次重连节省 90% 握手成本
