keepalive_timeout不直接影响单次请求速度，但决定连续请求能否复用连接：设太短（5–10秒）致频繁重连、ttfb增加50–200ms；设太长（300秒）则空闲连接堆积、耗尽fd与内存；推荐静态资源30–45秒、api服务15–30秒，并须协同keepalive_requests与upstream keepalive调优。
keepalive_timeout 不直接影响单次请求的处理速度，但它显著影响连续请求的整体响应效率——关键在于连接是否复用、何时复用、能否稳定复用。
空闲超时太短：重连开销拖慢感知速度
设为 5–10 秒这类低值时，用户浏览器加载完 HTML 后紧接着请求 JS、CSS、图片等资源，很可能在第二、第三个请求发出前，Nginx 已关闭连接。结果是：
- 每个后续请求都触发完整 TCP 三次握手 + TLS 握手（HTTPS 下尤为明显），首字节时间（TTFB）平均增加 50–200ms；
- 移动端弱网环境下，握手失败率上升，部分请求需重试，用户侧出现“卡顿”或“加载慢”反馈；
- 内核 TIME_WAIT 状态激增，本地端口快速耗尽，高并发下新连接被拒绝，表现为偶发性 502 或连接超时。
空闲超时太长：资源堆积反向抑制吞吐
设为 300 秒甚至更高，看似“更愿意等待”，实际会带来隐性延迟：
- 大量空闲连接长期驻留，占用 worker 进程的文件描述符（fd）和内存，当 fd 接近 ulimit 上限时，新请求排队等待可用连接，造成服务端排队延迟；
- Nginx 的 active connections 中 waiting 状态数持续偏高，说明连接“挂着但没干活”，CPU 和内存被无效占用，真实请求的调度优先级下降；
- 中间设备（如企业防火墙、WAF、LVS）通常有更短的空闲回收策略（常见 60–120 秒），Nginx 设再长也徒增堆积，反而加剧资源争抢。
按业务节奏匹配才真正提速
合理值能让多数连续请求落在同一连接上，省掉建连开销，又不滞留无用连接：
- 静态资源服务（CDN、图床、前端托管）：用户并行加载密集，空闲间隔短 → 推荐 30–45 秒；
- App / 小程序后端 API：移动网络不稳定、客户端自身 keep-alive 超时常为 60–120 秒 → 推荐 15–30 秒；
- 后台管理系统：操作间隔长、复用率天然低 → 可设 10–20 秒，避免空等；
- 长轮询或 SSE 场景：需确认链路透传且客户端持续心跳 → 可设 60–120 秒，但必须验证客户端行为，而非盲目拉长。
单靠 timeout 不够，必须协同调优
它只是连接复用链条的一环，脱离配套配置谈“提速”效果有限：
- keepalive_requests 建议设为 50–1000（如 timeout=30s 时配 100，timeout=60s 时可配 200），防止单连接承载过多请求导致异常长驻；
- upstream keepalive（如 keepalive 32）+ proxy_http_version 1.1 + proxy_set_header Connection ''，确保 Nginx 到后端也复用连接，避免后端成为瓶颈；
- 用 ss -tn | grep :443 | grep ESTAB | wc -l 和 nginx stub_status 监控 waiting 数与连接趋势，比单纯改配置更有说服力。
