keepalive_timeout本身不提升连接管理效率，它仅决定空闲连接的“静默容忍期”；真正实现复用与资源优化需合理设值（如api接口15–25秒、混合站点5–10秒）并协同配置keepalive_requests、client_header_timeout和send_timeout等参数。
keepalive_timeout 本身不提升连接管理效率，它只是决定空闲连接能“挂”多久。真正让连接复用起来、减少握手开销、释放资源及时，靠的是合理设值 + 配套动作协同生效。
明确作用边界：只管前端空闲期
这个参数只控制 Nginx 与客户端（浏览器、App、CDN）之间连接在“响应发完后、下个请求还没来”这段时间的等待上限。它不影响：
- 正在传输数据的连接（不计时）
- Nginx 与后端服务之间的连接（那是 upstream keepalive 干的事）
- TLS 会话复用或 HTTP/2 多路复用机制
设为 60 秒，意思是：只要客户端 60 秒内再发一个请求，连接就继续用；超时没动静，Nginx 主动关掉。它不是总寿命，而是“静默容忍期”。
按场景设值：没有通用最优，只有匹配真实行为
移动端用户切后台、弱网中断、App 自身保活策略严苛，浏览器加载 JS/CSS 后可能停顿数秒——这些都决定了 keepalive_timeout 不能照搬桌面端默认值。
- 纯 API 接口（App 后端）：15–25 秒。覆盖常见请求间隙，避免连接长期空占 worker 进程 fd
- 含静态资源的混合站点：5–10 秒。移动端资源加载快，复用窗口短，过长反而挤占新连接槽位
- 启用 HTTP/2 的服务：可设为 0 或 5 秒。HTTP/2 连接由客户端主导生命周期，Nginx 不必强留
- 内网管理后台或 SSE 流式服务：60–300 秒。连接稳定、客户端持续活跃，延长复用收益更明显
必须搭配的两个关键项
单设 keepalive_timeout 不足以实现高效连接管理，还需同步配置：
- keepalive_requests：限制单个连接最多处理多少次请求。默认 100 偏保守，API 网关可调至 500–1000；高安全要求环境可降至 50，防止单连接异常卡死
- client_header_timeout 和 send_timeout：移动端常见请求头上传慢或响应下发卡顿，若只调大 keepalive_timeout 却忽略这两项，连接可能在传输中途被误杀
例如弱网上传大图，client_header_timeout 建议设 30 秒；动态生成大文件响应，send_timeout 建议设 60 秒。
验证是否真起效：看连接状态，不是看配置行数
改完配置别急着上线，先观察实际连接行为：
- 用 ss -tn | grep :443 | wc -l 查高峰期 ESTABLISHED 连接数。若持续远超并发请求数，说明空闲连接滞留过多
- 用 curl -v https://your-domain/ 检查响应头是否有 Connection: keep-alive，且无 Connection: close
- 结合 access_log 中的 $request_time 和 $upstream_response_time，识别“快请求 + 长空闲”模式，再针对性调整
