keepalive_timeout 优化的实质,是让 Nginx 与客户端之间的连接“既不早断、也不久留”——它不加速单次传输,但能显著减少重复建连带来的握手延迟和资源开销,尤其在弱网、移动端或高频小请求场景下效果直接可见。
明确作用对象:只管前端,不管后端
这个参数只控制 Nginx 和浏览器、App、CDN 等客户端之间的空闲等待时间,和后端服务完全无关。想优化 Nginx 到后端(如 Spring Boot 或 Node.js)的连接复用,得靠 upstream keepalive、proxy_http_version 1.1 和后端自身的 keep-alive 配置,三者缺一不可。
常见误区是把 keepalive_timeout 调大来“提升后端性能”,结果只是徒增 Nginx 的 ESTABLISHED 连接数,甚至触发 Too many open files 错误。
按场景选值:没有统一最优,只有匹配业务
-
常规 Web 页面(含 JS/CSS/图片):设为 30–45 秒。足够覆盖用户点击、滚动加载、预加载等连续行为,又避免空闲连接滞留过久
-
移动端 API 接口:推荐 10–20 秒。App 切后台易被系统回收连接,弱网下长空闲反而无效,短些更贴合真实终端行为
-
HTTP/2 服务:可设为 0 或 5 秒。HTTP/2 天然支持多路复用,连接生命周期由客户端主导,Nginx 不必强留
-
高并发网关或 CDN 边缘节点:建议 ≤ 10 秒。快速释放连接槽位,防止文件描述符耗尽,配合 keepalive_requests=500–1000 使用更稳
必须配套设置:防止单连接霸占或中途中断
仅调 keepalive_timeout 不够,还需协同以下两项:
-
keepalive_requests:限制单个连接最多处理请求数,默认 100。设为 200–500 更适合静态资源分发;设为 50 可加快异常连接轮转,适合安全敏感或已知慢客户端环境
-
client_header_timeout 和 send_timeout:移动端上传卡顿或响应下发慢时,keepalive_timeout 不起作用。应同步设 client_header_timeout 30s(防弱网传头慢)、send_timeout 60s(防动态内容生成卡住)
验证是否真生效:看连接行为,不是看配置数值
别只改完就认为优化完成,重点观察实际表现:
- 用 ss -tn | grep :443 | wc -l 查高峰期 ESTABLISHED 连接数,若持续远超并发请求数,说明空闲连接堆积
- curl -v 访问接口,确认响应头含 Connection: keep-alive,且 Keep-Alive: timeout=xx 中的 xx 值与你配置一致
- 结合 access_log 中的 $request_time 和 $upstream_response_time,识别出“请求快但空闲长”的模式,再针对性下调 timeout
不复杂但容易忽略:优化目标不是让数字变大,而是让连接生命周期贴合真实访问节奏——用户没动作时及时释放,有动作时刚好复用。