keepalive_timeout需按业务类型设定：静态资源30–45秒、移动端api 15–25秒、pc web 60–75秒、sse/长轮询≥3600秒，并配合keepalive_requests（如1000）及upstream keepalive配置。
在 server 块中设置 keepalive_timeout 就是控制客户端到 Nginx 的连接空闲超时阈值，但“合理”不等于设大或设小，而是要匹配业务行为、客户端特性与资源压力三者的平衡。
按业务类型选基础值
同一个值无法通吃所有场景，需区分流量特征：
- 静态资源服务（图片/JS/CSS）：页面加载阶段请求密集，之后迅速空闲，设 30–45 秒 足够复用，又不积压
- 移动端 API 接口：App 切后台后 NAT 网关常静默断连，过长保活反而无效，推荐 15–25 秒
- 常规 PC Web 站点：浏览器默认保活策略约 60–65 秒，设 60–75 秒 兼容性最稳
- SSE 或长轮询服务：需维持单向连接，必须 ≥ 3600 秒（1 小时），并同步调高 proxy_read_timeout
必须搭配 keepalive_requests 使用
只改 timeout 不调 requests，容易让一个连接被异常请求长期占用。两者构成“双杀机制”，任一先触发即断连：
- 默认 keepalive_requests 100 太保守，现代前端（如 React/Vue 单页）建议设 1000
- 网关类服务可设 800–1000；若后端连接池较小，可降至 300–500 防压垮
- 示例写法：keepalive_timeout 30s 30s; + keepalive_requests 1000;
注意响应头和客户端兼容性
第二个参数（如 30s）会写入响应头 Keep-Alive: timeout=30，但实际效果有限：
- Firefox、Konqueror 会参考该值；IE/Edge 完全忽略，仍按自身策略（约 60–65 秒）断连
- 不要设为 0，那会彻底禁用 Keep-Alive，每次请求都重建 TCP
- 也不必强求 header_timeout 和 timeout 一致，服务端生效值才是关键
别漏掉 upstream 侧的长连接配置
server 块只管前端连接，反向代理到后端仍需单独配，否则前端 keepalive 白开：
- upstream 块中加 keepalive 32;（每个 worker 缓存 32 个空闲连接）
- 对应 location 中必须有 proxy_http_version 1.1; 和 proxy_set_header Connection '';
- 否则 Nginx 默认用 HTTP/1.0 短连接，前端复用完全失效
