keepalive_timeout需按业务场景差异化配置：web页面推荐15–30秒，移动端api设5–15秒，websocket代理阶段设5–20秒、通信阶段靠proxy_read_timeout控制，内网长连接可设60–300秒并监控连接数。
keepalive_timeout 不是通用参数，不同业务场景下它的取值逻辑和影响完全不同。配置前必须明确当前服务类型、客户端行为特征以及上下游链路能力，否则容易引发连接中断、资源堆积或复用失效。
Web 页面与静态资源加载
用户打开页面后会密集请求 HTML、CSS、JS、图片等资源，通常在几秒内完成。此时连接复用价值最高，但空闲期也短。
- 推荐设为 15–30 秒：足够覆盖滚动加载、点击跳转等连续操作，又避免连接长期空闲
- 可配合 location 块细化：比如 /static/ 下设为 10 秒，/api/ 下设为 45 秒
- 注意浏览器默认行为：Chrome/Firefox 一般尊重 Keep-Alive 响应头，IE 或旧版 Edge 实际复用上限常为 60 秒
移动端 API 接口服务
App 客户端通常自带连接池，但可能因后台休眠、网络切换导致连接异常；请求节奏较稳定，但对建连延迟敏感。
- 推荐设为 5–15 秒：兼顾弱网下握手容错，同时加快空闲连接释放，防止文件描述符耗尽
- 若使用 OkHttp 或 Retrofit，需确认其连接池 maxIdleConnectionTime ≤ Nginx 的第一个 timeout 值
- 避免设为 60 秒以上：移动端频繁切网或锁屏后，长连接反而变成无效占用
WebSocket 代理场景
keepalive_timeout 对 WebSocket 连接本身无持续控制力，但它会影响升级前的握手阶段及代理链路中未升级的空闲连接。
- 第一阶段（HTTP 握手）：建议设为 5–20 秒，略小于后端服务的 connection-timeout（如 Spring Boot 的 server.tomcat.connection-timeout）
- 第二阶段（WebSocket 通信）：真正起作用的是 proxy_read_timeout，应设为 300–1800 秒，并确保后端也启用心跳检测
- 必须配合 proxy_set_header Connection $connection_upgrade 和 map 指令清除干扰头，否则 Upgrade 失败
内网服务与长周期连接
如 SSE（服务端推送）、IoT 设备保活、管理后台轮询等，连接需长时间维持，但流量稀疏。
- 可设为 60–300 秒，甚至更高（如 keepalive_timeout 300 290）
- 务必同步监控 ss -tnpo | grep :port | grep ESTAB 数量，防止 worker 进程 fd 耗尽
- 若后端是 Node.js 或 Go，默认可能关闭 keep-alive，需显式设置 server.keepAliveTimeout 或 http.Server.IdleTimeout
