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，确认机制生效
