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，反而增加握手压力。常见场景推荐：
- 面向浏览器的 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 的连接生命周期节奏，贴合真实用户行为和网络条件。
