keepalive_timeout核心是平衡连接复用效率与资源占用：首值设服务器等待新请求的最长时间，次值为响应头中供客户端参考的timeout提示；静态资源宜60–120秒，API服务15–30秒，高并发后台5–15秒并配keepalive_requests。
在 Nginx 的 http 块中设置 keepalive_timeout，核心是平衡连接复用效率与服务器资源占用。设得太短，客户端频繁重建连接，增加 TLS 握手和 TCP 开销；设得太长，空闲连接长期占着 worker 进程的文件描述符和内存，尤其在高并发下易触发 too many open files 错误。
理解 keepalive_timeout 的两个参数含义
keepalive_timeout 接受一个或两个值：
- 第一个值（必选）：服务器在发送完响应后，保持连接打开、等待新请求的最长时间（秒）；
- 第二个值（可选）：写入到响应头 Keep-Alive: timeout=XX 的提示值，供客户端参考（不影响 Nginx 自身行为）。
例如：keepalive_timeout 65 60;
表示 Nginx 最多等待 65 秒新请求，同时告诉客户端“建议你 60 秒内复用这个连接”。
常见场景下的推荐取值策略
-
静态资源服务（如 CDN、图片站）：用户常批量请求 CSS/JS/图片，复用价值高。可设为
60–120秒，兼顾复用率与连接回收速度。 -
API 服务（尤其是移动端）：客户端网络不稳定，但单次请求间隔不规律。建议
15–30秒，避免空等，也减少因弱网导致的连接滞留。 -
高并发低延迟后台服务：如微服务间调用，连接数极易成为瓶颈。建议
5–15秒，并配合keepalive_requests限制单连接请求数（如100），主动释放。
必须同步调整的关联配置
仅调 keepalive_timeout 不够，还需检查以下项是否匹配：
-
worker_connections：确保每个 worker 能承载预期的长连接数（连接数 ≈ 并发请求数 × 平均连接存活时间 ÷ 平均请求处理时长）； -
events.use：使用epoll（Linux）或kqueue（BSD）以高效管理大量空闲连接； -
client_header_timeout和client_body_timeout：应 ≤keepalive_timeout，防止客户端慢速发包时连接被错误地当作 keepalive 空闲连接保留； -
上游服务的 keepalive 设置：若用
proxy_pass，需在upstream块中配keepalive N;并确保后端也支持长连接，否则前端长连接无意义。
验证与观测方法
上线后通过以下方式确认效果：
- 用
curl -I http://your.site/xxx查看响应头是否含Connection: keep-alive和Keep-Alive: timeout=XX； - 监控 Nginx 指标：
nginx_http_current_connections{state="active"}和nginx_http_current_connections{state="keepalive"}（需启用 stub_status 或 Prometheus exporter）； - 抓包观察 TCP 层：正常长连接在无数据时只有周期性 ACK 或 TCP keepalive 探测包，不会立即 FIN；
- 压测时关注
time_wait状态连接数增长趋势，突增可能意味着keepalive_timeout过短或客户端未复用。
