keepalive_timeout核心作用是控制nginx与客户端空闲http连接最长保持时间，平衡复用收益与资源消耗；首参数为服务端等待新请求的秒数，次参数为响应头中提示客户端的timeout值。
keepalive_timeout 的核心作用是控制 Nginx 与客户端之间空闲 HTTP 连接的最长保持时间，目标是在复用收益和资源消耗之间取得平衡。设太短，连接频繁重建，徒增 TCP 握手和 TLS 开销；设太长，大量空闲连接占用 worker 进程的文件描述符与内存，高并发下易触发 Too many open files 错误。
理解两个参数的实际含义
keepalive_timeout 接受一个或两个数值：
- 第一个值（必填）：Nginx 在响应发送完毕后，等待下一个请求的最长时间（单位：秒）。超时即主动关闭连接。
- 第二个值（可选）：写入响应头 Keep-Alive: timeout=XX 的提示值，仅作客户端参考，不影响 Nginx 自身行为。
例如：keepalive_timeout 30 25; 表示 Nginx 最多等 30 秒新请求，同时告诉客户端“建议你在 25 秒内复用这个连接”。
按业务类型选择合理区间
不同流量特征决定不同的取值逻辑，不能一概而论：
- 静态资源服务（如 CDN、图片/JS/CSS 加载）：用户常批量请求，复用价值高 → 推荐 60–120 秒
- API 网关或移动端后端：网络不稳定、请求间隔不规律 → 推荐 15–30 秒
- 微服务间高频调用（如健康检查 + 业务请求混合）：需快速释放连接避免堆积 → 推荐 5–15 秒，并必须配合 keepalive_requests 50–100
- 低带宽环境（如弱网 App、2G/卫星链路）：建连开销占比极高 → 推荐 15–30 秒，重点提升单连接复用率，摊薄头部传输成本
必须同步调整的关键配置
单独改 keepalive_timeout 效果有限，以下几项需联动校准：
- keepalive_requests：限制单连接最大请求数，默认 100。防止异常客户端长期霸占连接，建议与 timeout 协同设置（如 timeout=15s 时，requests 可设为 50）
- upstream keepalive：若用 proxy_pass，必须在 upstream 块中显式配置 keepalive 32; 和 keepalive_timeout 30s;，否则前端复用再好，到后端仍会频繁建连
- client_header_timeout / client_body_timeout：这两项必须 ≤ keepalive_timeout，否则可能因读取超时提前关闭连接，导致“假空闲”误判
- worker_connections 与系统限制：确保 ulimit -n 和 net.core.somaxconn 足够支撑预期长连接数，否则连接会在 accept 阶段被丢弃
验证是否生效的实用方法
上线后别只看配置，要观测真实行为：
- 用 curl -I https://your.site/ 查响应头，确认含 Connection: keep-alive 和 Keep-Alive: timeout=XX
- 监控指标 nginx_http_current_connections{state="keepalive"}，观察空闲连接数是否稳定在合理区间（突增或持续高位说明 timeout 过长）
- 检查错误日志中 "client closed connection" 出现频次——若明显增多，可能是 timeout 小于客户端实际复用周期
- 用 ss -s | grep "tcp" 或 netstat -an | grep :443 | grep ESTABLISHED | wc -l 辅助判断连接水位
