keepalive_timeout并非越大越高效，需按业务类型设15–25秒（移动端）、30–60秒（静态资源）、5–15秒（微服务）、60–300秒（内网/sse），并协同keepalive_requests与upstream keepalive配置。
keepalive_timeout 不是设得越大越高效，关键在于让连接“刚好够用、及时释放”——既覆盖典型请求间隙，又不堆积空闲连接。真正提升长连接效率，靠的是它和 keepalive_requests、upstream keepalive 的协同，而不是单点调大。
按业务类型选合理区间
不同流量模式对复用窗口要求差异很大：
- 移动端 API 或 App 后端：15–25 秒。用户操作不连续，后台常被系统回收，设太长反而占着连接槽位；
- 静态资源服务（CDN、图片/JS/CSS）：30–60 秒。浏览器通常批量加载，复用率高，稍长一点更稳；
- 微服务间高频调用：5–15 秒。请求节奏密、延迟敏感，连接应快速轮转，避免单点积压；
- 内网管理后台或 SSE 推送：60–300 秒。客户端长期在线，可适当延长，但需确认后端也支持同等超时。
必须同步配好 keepalive_requests
只调 keepalive_timeout 不够，若单连接不限请求数，一个慢请求或异常响应就能卡死整个连接：
- 默认值 100 偏保守，API 场景可设为 200–500；
- 高并发静态服务（如边缘节点）可设到 1000–5000；
- 若日志中频繁出现 “client closed connection while waiting for request”，说明连接老化，可尝试降到 50–100 强制轮转。
注意两个参数的实际作用
keepalive_timeout 支持一个或两个数值：
- 第一个值（必填）：Nginx 等待下一个请求的最长时间，超时即关闭连接；
- 第二个值（可选）：写入响应头 Keep-Alive: timeout=XX，仅作客户端参考，不影响 Nginx 行为；
- 例如 keepalive_timeout 30 25; 表示 Nginx 最多等 30 秒，同时告诉客户端“建议你在 25 秒内复用”。
别忘了上游和客户端链路
前端连得再好，到后端断开也没用：
- 确保 upstream 块启用 keepalive 32;，并配 proxy_http_version 1.1; 和 proxy_set_header Connection '';；
- 检查后端是否真支持长连接（如 Spring Boot 要设 server.tomcat.keep-alive-timeout=60）；
- 用 curl -v 查响应头是否有 Connection: keep-alive，确认机制生效。
