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
不复杂但容易忽略：优化目标不是让数字变大，而是让连接生命周期贴合真实访问节奏——用户没动作时及时释放，有动作时刚好复用。
