keepalive_timeout优化核心是平衡空闲连接复用收益与资源占用风险：首参数控制Nginx等待新请求的最长时间，次参数仅作客户端响应头提示；需按场景设定合理区间（如静态资源60–120秒、移动端15–30秒），并同步调优keepalive_requests、client_header_timeout等配套参数，结合curl和ss命令验证实际复用效果。
keepalive_timeout 优化的核心，是让 Nginx 与客户端之间空闲连接既不“早夭”，也不“赖着不走”。它不是越大越好，而是要匹配真实请求节奏和系统承载能力——设短了，握手开销压垮 CPU；设长了，文件描述符被占满，新连接直接被拒。
先看清楚两个参数分别管什么
keepalive_timeout 后面可以跟一个或两个数字：
- 第一个值（必填）：Nginx 主动关闭空闲连接前等待新请求的秒数，比如 keepalive_timeout 60 表示最多等 60 秒
- 第二个值（可选）：写进响应头 Keep-Alive: timeout=XX 的提示值，仅作客户端参考，不影响 Nginx 自身行为，建议比第一个值小一点，比如 keepalive_timeout 60 55
按场景选合理区间，别套模板
静态资源加载多、浏览器批量请求频繁 → 复用价值高，可设 60–120 秒
移动端 API 或弱网环境 → 客户端可能休眠或切换网络 → 推荐 15–30 秒
内网微服务调用或 SSE 流式接口 → 连接本就该长期维持 → 可设 60–300 秒
高并发网关或资源受限节点 → 必须快速释放连接 → 建议 ≤ 15 秒，同时配好 keepalive_requests
必须同步调的几项配置
单改 keepalive_timeout 效果有限，这几项得一起动：
- keepalive_requests：默认 100，容易造成连接反复重建；API 场景建议 500–1000，前端整页加载类可设到 2000
- client_header_timeout / client_body_timeout：这两个值必须 ≤ keepalive_timeout，否则请求还没读完连接就被关了
- worker_connections 和系统 ulimit：比如设了 keepalive_timeout 60 且并发高，就得确保 ulimit -n ≥ worker_processes × worker_connections，不然连接在 accept 阶段就被丢弃
验证是不是真生效了
别只改完就上线，要看实际行为：
- 用 curl -I https://your.site/ 查响应头，确认有 Connection: keep-alive 和 Keep-Alive: timeout=XX
- 用 ss -tnpo | grep :80 | grep ESTAB | wc -l 观察活跃连接数是否稳定增长而非持续飙升
- 查 nginx error log，重点看有没有 “upstream prematurely closed connection” 或 “client timed out” 类错误，那是超时不匹配的典型信号
