keepalive_timeout作用于HTTP/1.1应用层连接管理逻辑，而非传输层或TLS层；它控制Nginx空闲连接的可复用时长，需与客户端策略、upstream配置及keepalive_requests协同调优。
keepalive_timeout 不是“让连接变长”的开关，而是 HTTP/1.1 持久连接生命周期中的关键节拍器——它决定 Nginx 在空闲状态下最多等待多久来复用一个已有 TCP 连接。这个参数直接影响协议栈各层的协同效率，优化得当能显著降低握手开销、提升吞吐，但设错反而引发资源淤积或连接中断。
它作用于 HTTP 协议栈的哪一层？
不是传输层（TCP keepalive），也不是 TLS 层，而是HTTP/1.1 应用层连接管理逻辑：Nginx 根据该值主动维护“空闲连接队列”，控制连接何时从“可复用”状态转入“待关闭”状态。整个过程与客户端行为、后端能力、操作系统资源紧密耦合。
客户端侧连接复用效率取决于 timeout 与浏览器策略的匹配
浏览器默认复用连接，但有自己的保活窗口（如 Chrome 通常为 5–60 秒，移动端 WebView 更短）。若 Nginx keepalive_timeout 设为 90 秒，而客户端在 20 秒后就关闭了连接，那额外的 70 秒毫无意义，还占着文件描述符。
- 建议值需参考主流客户端行为：
- 普通 Web 页面：60～65 秒（兼容旧浏览器上限，也匹配多数 CDN 策略）
- 移动 App 接口：5～15 秒（App 后台休眠快，长连接易成僵尸）
- 内网调用或 SSE 场景：可设 120～300 秒，但必须确认客户端持续发心跳或请求
与 upstream 长连接形成两级独立控制，不能混为一谈
Nginx 到客户端（frontend）和 Nginx 到后端（upstream）是两套完全隔离的 keepalive 管理机制：
-
keepalive_timeout只管前者（进来的连接） -
upstream { keepalive N; }才管后者（出去的连接池）
两者不自动同步。若前端 timeout 设 60 秒，而后端服务只支持 30 秒 keep-alive，Nginx 可能还在等请求，后端却已断连，导致upstream prematurely closed connection错误。
必须配合 keepalive_requests 才算完整闭环
单靠 timeout 无法防止单连接累积过多请求引发内存泄漏或响应延迟。例如：
- 若
keepalive_timeout 60;但keepalive_requests 0;，连接可能承载数百次请求，缓冲区不断膨胀 - 推荐设为
keepalive_requests 100;（或 50～1000 区间），让连接在请求数达限时主动退出，比单纯等超时更可控
实际效果要看连接状态分布，不是数字本身
调优后要验证是否真提升了复用率：
- 查
nginx_stub_status：关注Waiting数值——持续偏高说明大量连接空闲未被复用 - 用
ss -tnpo | grep :80 | grep ESTAB | wc -l对比峰值并发，若 ESTABLISHED 远高于 QPS × 平均响应时间，大概率存在堆积 - 检查 error log 是否出现
Connection reset by peer或recv() failed，这是上下游 timeout 不对齐的典型信号
本质上，keepalive_timeout 是 HTTP 协议栈中一个轻量但高敏感的协调点——它不创造性能，只释放协议本就具备的复用能力；调得准，省下的是 TCP 握手、TLS 协商、内核 socket 状态维护的综合开销；调得偏，换来的是内存、fd、CPU 的隐性浪费。
