keepalive_timeout用于控制Nginx与客户端间空闲连接的最长等待时间（5～60秒为佳），仅影响前端连接，不作用于后端；设太短增握手开销，太长致资源占用，需配合keepalive_requests及upstream keepalive协同调优。

调优 keepalive_timeout 是控制客户端与 Nginx 之间长连接生命周期的关键动作，它不直接节省后端握手开销（那是 upstream keepalive 干的事），但能显著减少客户端反复建连带来的 TCP 握手和 TLS 协商压力，尤其在移动端、弱网或高频小请求场景下效果明显。

明确作用范围：只管“前端连接”，不管后端

keepalive_timeout 仅作用于 Nginx 与客户端（浏览器、App、CDN 等）之间的连接。它定义的是：一次请求响应结束后，连接空闲多久没新请求，Nginx 就主动关闭它。

这个参数对后端服务无影响——后端建连开销靠 upstream keepalive 解决，两者必须分开配置、协同使用。

合理取值区间：5～60 秒是常见有效带

太短（如 1–2 秒）：连接频繁断开重连，失去复用意义，反而增加握手次数；
太长（如 300 秒以上）：大量空闲连接长期占用 worker 进程的文件描述符和内存，可能触发 Too many open files 错误。

• 常规 Web 页面（含图片/CSS/JS）：设为 15–30 秒，足够覆盖用户连续点击、滚动加载等行为
• API 接口网关或 App 后端：可设为 5–15 秒，因请求节奏更紧凑，且客户端通常自带连接池
• 低频管理后台或内网系统：可放宽至 45–60 秒，资源压力小，复用收益更稳

配合 keepalive_requests 防止单连接霸占资源

即使连接没超时，也不能让它无限处理请求。否则一个恶意或异常客户端可能长期占用一个连接，挤占其他用户资源。

• 默认值 100 偏保守，适合大多数场景
• 高并发静态资源服务（如 CDN 边缘节点）：可调高至 500–1000
• 强安全要求或已知存在慢客户端的环境：可适当降低至 50，加快连接轮转

注意：keepalive_requests 触发时会立即断连，不受 keepalive_timeout 约束。

别忘了检查上游和客户端链路

单边调优无效。需同步确认：

• 后端服务是否支持 HTTP/1.1 Keep-Alive（如 Spring Boot 默认开启，Node.js 需显式设置 server.keepAliveTimeout）
• 前端是否有负载均衡器或 CDN？它们可能覆盖或禁用 Keep-Alive，需检查其配置（如 AWS ALB 默认启用，但超时可能比 Nginx 更短）
• 用 curl -v http://your-domain/ 查看响应头是否含 Connection: keep-alive，确认机制生效