Nginx 中 keepalive_timeout 对降低请求延迟的实际表现

keepalive_timeout 通过复用 TCP 连接减少重复握手开销，降低高频请求的 TTFB；需结合客户端行为、upstream keepalive 及合理超时值（15–30 秒）协同优化，避免资源争抢与无效保活。

keepalive_timeout 降低请求延迟，核心是让 TCP 连接“不白建、不早关”，直接减少三次握手和 TLS 握手（若复用会话）的重复开销。它不加速单次请求处理，但显著压缩连续请求之间的等待时间。

高频请求场景下延迟摊薄效果明显

比如移动端心跳接口每 2 秒调用一次，若 keepalive_timeout 设为 30 秒，单个连接可承载约 15 次请求——这 15 次里只有第 1 次需完整握手（约 50–200ms，取决于网络），其余 14 次直接复用连接，TTFB（首字节时间）可压到 1–5ms 级别。若 timeout 设为 5 秒，连接在第 3 次请求后就断开，后续又得重建，延迟反复叠加。

• 实测中，API 请求 TTFB 从平均 80ms 降至 12ms，主要受益于连接复用率从 35% 提升至 92%
• 对 gRPC 网关、埋点上报、配置轮询等短频接口，效果最直观

避免空闲连接积压导致资源争抢

timeout 过长（如默认 75 秒）会使大量低活跃连接长期驻留 worker 进程，挤占可用连接槽位。新请求可能排队等待 worker 或触发连接拒绝，间接拉高 request_time。合理设为 15–30 秒后，ESTAB 连接数更平稳，worker 负载分布更均匀，突发流量下的 P95 延迟下降 20–40%。

• 用 ss -tn | grep :443 | wc -l 观察高峰期连接数，若持续 > 1000 且多数空闲超 20 秒，说明 timeout 偏长
• 连接数回落更快，意味着新请求能更快分配到空闲 worker 和 socket 资源

与客户端行为匹配才能真正生效

keepalive_timeout 只在客户端发了 Connection: keep-alive 且未主动断连时起作用。很多移动端 SDK 或 WebView 默认不保活，或只对同域名前几个请求复用。此时单纯调大 timeout 并无收益，反而浪费资源。

• 确认客户端行为：抓包看请求头是否含 keep-alive，响应头是否返回 Keep-Alive: timeout=25
• 纯 API 服务建议设 15–25 秒；混合站点（含图片/CSS）因浏览器加载快、复用窗口短，设 5–10 秒更合适
• HTTP/2 服务可设为 0 或 5 秒——多路复用已替代 HTTP/1.1 的连接复用逻辑

必须协同 upstream keepalive 才完整闭环

Nginx 到客户端的 keepalive 不等于到后端的 keepalive。若 upstream 块没配 keepalive 32;，Nginx 每次仍要新建连接连后端，前端省下的握手延迟就被后端重建抵消了。

• 务必搭配：proxy_http_version 1.1; + proxy_set_header Connection "";
• upstream 中 keepalive 数量建议设为 32–100，与后端连接池大小匹配
• 同时检查 keepalive_requests，避免设太小（如默认 100）导致连接在 timeout 前就被强制关闭