Nginx的keepalive_timeout应按业务请求节奏设为合理区间：静态资源20–30秒、API接口10–20秒、后台系统15–25秒；必须同步配置keepalive_requests 100、reset_timedout_connection on和client_header/body_timeout 15s，并通过ss命令和Waiting状态验证复用效果。
Nginx 的 keepalive_timeout 设太高会堆积空闲连接，吃光文件描述符和内存；设太低又会让客户端频繁重连，白白增加 TCP 握手和 TLS 协商开销。真正“不浪费资源”的值，不是固定数字，而是匹配你业务实际请求节奏的合理区间。
静态资源服务（如 CDN、前端 JS/CSS/图片）
- 用户通常一次加载多个资源，请求密集但空闲期短
- 推荐设为 20–30 秒
- 理由：足够覆盖浏览器并行加载 + 滚动预加载行为，又比默认 65 秒更快释放 fd 和内存
- 示例：用户打开页面后 5 秒内发完 8 个请求，之后基本静默 → 30 秒超时足够，再长就是闲置
API 接口服务（App、小程序、微服务调用）
- 请求节奏快、单次响应快（平均 < 100ms），但客户端可能批量发完就休眠
- 推荐设为 10–20 秒
- 理由：移动端 SDK 通常自带连接池，且弱网下重试间隔常在 1–5 秒；设 20 秒可复用 3–5 次请求，再长易积压无效连接
- 注意：若客户端自身超时是 60 秒，Nginx 设 20 秒没问题；但若它只坚持 15 秒，你就该同步设成 12–15 秒
后台管理系统或低频内网服务
- 用户操作间隔长（如点击菜单后隔几十秒才点下一步）
- 可设为 15–25 秒
- 不建议超过 30 秒：这类场景本身复用率低，盲目拉长 timeout 只会抬高
Waiting连接数，占用 worker 资源却没收益
必须同步配置的三项，否则 timeout 再合理也白搭
keepalive_requests 100;
防止单连接无限承载请求（比如异常客户端持续发小包），建议保持默认或设为 100–500，与 timeout 协同（例：timeout=20s 时 requests=200 是安全上限）reset_timedout_connection on;
超时后直接发 RST，跳过四次挥手，让 socket 和内存立刻回收 —— 这才是真正“不浪费”的关键动作client_header_timeout 15s; client_body_timeout 15s;
避免因读取请求头/体超时早于 keepalive 超时，导致连接被误杀；三者应大致对齐，防止逻辑冲突
验证是否真的不浪费资源，看两个指标：
-
ss -tn state established '( dport = :80 )' | wc -l在业务空闲期是否明显回落 - Nginx 状态页中
Waiting数长期高于Active connections的 60%，说明大量连接空转未复用，timeout 就偏长了
