keepalive_timeout通过减少重复建连开销间接提升响应速度，需按业务场景设为15–25秒（高频api）、5–10秒（混合站点）、30–45秒（静态资源）、60–120秒（内网长轮询），并同步配置upstream keepalive、keepalive_requests及客户端兼容性。
keepalive_timeout 本身不直接提升响应速度，而是通过减少重复建连开销间接加快整体响应——关键在于让连接“刚好够用，不多留”。设太短，每次请求都重握手；设太长，空闲连接占资源、挤占新连接槽位。真正起效的前提是：客户端支持复用、后端也保持长连接、Nginx 配置协同到位。
按业务节奏匹配超时值
不同场景的请求间隔差异大，统一设 65 秒反而拖慢：
- 高频 API（如 App 心跳、实时推送）：设 15–25 秒。足够覆盖每 2–5 秒一次的调用间隙，避免反复建连，又不让连接在后台休眠时长期滞留；
- 混合站点（HTML + JS/CSS/图片）：设 5–10 秒。移动端加载快、复用窗口短，过长 timeout 会卡住 worker 连接池；
- 静态资源服务（CDN、图床）：设 30–45 秒。浏览器并行加载资源密集，稍长一点利于复用；
- 内网长轮询或 SSE 场景：可设 60–120 秒，但必须确认客户端持续发心跳、中间设备不截断，否则只是白等。
必须同步调优的三项配套
单改 keepalive_timeout 效果有限，以下三项缺一不可：
- upstream keepalive 池要打开：在 upstream 块中加 keepalive 32;，并配 proxy_http_version 1.1; 和 proxy_set_header Connection '';，否则 Nginx 到后端仍是短连接；
- keepalive_requests 要调大：默认 100 太小，高频场景建议设为 1000–5000，避免连接刚建好就因请求数满被强制关闭；
- 客户端与中间链路要兼容：检查响应头是否有 Connection: keep-alive；企业网关、某些 CDN 可能静默关闭长连接，此时 Nginx 端设再长也无效。
用真实指标验证是否见效
别只看配置文件生效，重点观察运行态：
- 用 ss -tn state established | grep :443 | wc -l 查 ESTABLISHED 连接数——调优后应更平稳，不再峰值冲高后缓慢回落；
- 在 access_log 中加入 $connection_requests，筛选 connection_requests=1 的请求比例——下降说明复用率提升；
- 监控 nginx_stub_status 中 Waiting 状态数——过高代表空闲连接堆积，需进一步压低 timeout 或检查上游响应节奏。
移动端和 HTTP/2 场景要特别处理
移动网络特性决定不能照搬桌面配置：
- App 切后台后系统常主动回收 socket，iOS 尤其严格，API 接口建议设 15 秒以内；
- 启用 HTTP/2 时，keepalive_timeout 可设为 0 或 5 秒——多路复用由客户端控制，Nginx 不必强留连接；
- 配合调大 client_header_timeout（建议 30 秒）和 send_timeout（建议 60 秒），避免弱网下传输未完成就被误杀。
