keepalive_timeout 的核心是精准匹配请求节奏，控制 nginx 与客户端连接的空闲等待窗口（非总寿命），需协同 keepalive_requests、client_header_timeout、send_timeout 及系统参数调优，合理取值依业务场景而定。

keepalive_timeout 实现高效连接保持，关键不是“设大”，而是让 Nginx 在客户端连接空闲时，既不浪费资源，也不过早断连——它靠的是精准匹配请求节奏 + 协同机制配合 + 分层超时控制。

它只管前端连接，不碰后端

keepalive_timeout 作用对象是 Nginx 与客户端（浏览器、App、CDN）之间的连接，定义的是：一次响应结束后，Nginx 愿意等待下一个请求的最长时间。

• 它不影响后端建连开销（那是 upstream keepalive 的事）
• 它不决定连接总寿命，只控制“空闲等待窗口”
• 超时后 Nginx 发 FIN 关闭连接；若配了 reset_timedout_connection on，则发 RST 立即回收 socket

合理取值要贴合业务真实节奏

默认 75 秒太宽泛，容易导致空闲连接堆积；设为 0 则彻底禁用 keep-alive，反而增加握手压力。常见场景推荐：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• 面向浏览器的 Web 页面（含静态资源）：30–60 秒
• 移动端 API 或高频小请求服务：15–25 秒
• 纯 HTTP/2 服务：可设为 0 或 5 秒（多路复用下连接由客户端主导）
• 高并发网关或资源受限环境：≤ 10 秒

必须和 keepalive_requests 配合使用

单靠时间控制防不住“低频但持续”的连接霸占：

• keepalive_requests 100 表示单个连接最多处理 100 次请求，用完即断
• 它和 keepalive_timeout 是“双保险”：任一条件满足就关闭连接
• 常规 Web 服务建议设 1000–2000；API 网关或安全敏感入口可设 50–100

要协同其他超时与系统参数才真正高效

• client_header_timeout 和 send_timeout 得同步调优：移动端弱网下，请求头上传慢或响应下发卡顿，若它们太短，连接会在传输中途被误杀
• reset_timedout_connection on 必须开启：避免超时后仅发 FIN 留下 TIME_WAIT，RST 才能快速释放 socket
• Linux 内核 tcp_fin_timeout 建议设为 30–60 秒（不能低于 RFC 规定的 60 秒，否则影响连接可靠性）

不复杂但容易忽略：高效不是参数堆叠，而是让 Nginx 的连接生命周期节奏，贴合真实用户行为和网络条件。