keepalive_timeout的核心目标是平衡连接复用与资源释放，推荐高频api场景设为15–30秒，需同步确保客户端支持长连接、upstream启用keepalive及合理配置keepalive_requests。
调优 keepalive_timeout 的核心目标，是让连接“足够久以复用，又不过久以积压”，从而减少重复 TCP 握手带来的延迟损耗。它不控制 TLS 握手复用，但直接影响底层 TCP 连接能否被下一个请求接着用——如果超时太短，连接还没等来第二个请求就被关了，等于白建；太长，则空闲连接占着 worker、端口和内存，反而拖慢整体响应。
明确 keepalive_timeout 的作用边界
这个参数只管“空闲多久就断开”，和请求处理时长、TLS 会话有效期、客户端是否发 Keep-Alive 头都无关。它生效的前提是：客户端已发送 Connection: keep-alive（HTTP/1.1 默认行为），且服务端未主动关闭连接。一旦设置为 30 秒，意味着从上一个响应结束起，若 30 秒内没新请求，Nginx 就会发 FIN 关闭该 TCP 连接。
高频 API 场景推荐值：15–30 秒
对每秒数次调用的接口（如心跳、轮询、gRPC 网关后端）：
- 设为 15–30 秒 能覆盖典型请求间隔，比如每 2 秒一次心跳，30 秒内可复用 15 次，大幅摊薄握手成本
- 避免设成 60 秒或更高——高频场景本就不该长期空闲，过长 timeout 反而导致连接池僵化、worker 被无效连接卡住
- 不能低于 5 秒——否则像移动端弱网重传、微服务间小抖动，都可能让连接在请求到达前就被回收
必须同步检查的配套配置
单独调大 timeout 没用，以下三点缺一不可：
-
客户端必须支持并保持长连接：确认没显式加
Connection: close；Python requests、curl、OkHttp 默认符合，但某些嵌入式 SDK 或旧版 Android WebView 需手动开启 -
反向代理场景需显式启用 upstream keepalive：Nginx 默认不复用到后端的连接，必须在 upstream 块里加
keepalive 32;，并配proxy_http_version 1.1;和proxy_set_header Connection ''; -
与 keepalive_requests 协同调整：若 timeout 设为 30 秒，但
keepalive_requests 100（默认值），那每 100 次请求就强制断连——哪怕连接才用了 5 秒。建议同步设为keepalive_requests 1000–5000
验证是否真正生效
别只看配置文件，要观察真实连接行为：
- 用
ss -tn state established | grep :443 | wc -l查当前活跃连接数，对比调优前后是否更稳定（非剧烈波动） - Nginx 日志中加入
$connection_requests和$request_time，筛选出connection_requests=1的请求——这类就是新建连接，比例下降说明复用提升 - 抓包看 TCP 层：连续请求是否复用同一 source port；若每次 request 都触发 SYN，则说明 keepalive 没走通
不复杂但容易忽略：keepalive_timeout 是 TCP 层复用的“守门员”，但它守不住 TLS 握手损耗——那得靠 ssl_session_timeout 和 ssl_session_cache 来管。
