keepalive_timeout是控制Nginx与客户端空闲连接关闭时机的关键参数，设太短导致频繁重连增加握手开销，设太长则空闲连接占用文件描述符和内存；需按业务场景（如静态资源10–30秒、移动端5–25秒）设定，并协同keepalive_requests和upstream keepalive调优。
keepalive_timeout 不是“让连接变快”的开关，而是决定空闲连接能留多久的关键阀值——设得太短，连接反复重建；设得太长，连接空占资源。它不控制传输过程，只管“发完响应后，等多久没人来就关掉”。效果好坏，全看是否贴合真实请求节奏。
太短：握手开销压垮响应速度
比如设为 5 秒，而用户加载完图片后 8 秒才点登录按钮，那第一条连接刚建好就被关了，第二次请求只能重连：
- TCP 三次握手 + 四次挥手频繁触发，首字节时间（TTFB）明显拉高
- HTTPS 下每次重连都重做 TLS 握手（除非会话复用生效），CPU 占用上升
- 内核 TIME_WAIT 状态激增，可能快速耗尽本地端口或 conntrack 表项
- 移动端 App 或小程序批量请求后休眠几秒，复用率趋近于零
太长：空闲连接悄悄吃光资源
设成 300 秒，但客户端实际 20 秒就断开了，或中间 WAF 已在 60 秒回收连接，Nginx 却还在傻等：
- 每个空闲连接占用一个文件描述符（fd），worker 进程容易报 “Too many open files”
- socket 结构、SSL 上下文、缓冲区持续驻留内存，累积消耗不可忽视
- nginx_stub_status 中 Waiting 状态过高，说明大量连接挂着却没人用
- 企业网关、NAT 设备常有更短的空闲回收策略（如 2–5 分钟），Nginx 设再长也无意义
按业务场景设合理值
没有万能数字，必须匹配流量特征和客户端行为：
- 静态资源服务（CDN、图床）：用户并行加载 JS/CSS/图片，空闲期短 → 推荐 10–30 秒
- 移动端 API 或小程序后端：弱网易中断、App 常后台休眠 → 推荐 5–25 秒
- 常规 Web 页面（含 HTML+资源）：浏览器默认行为较稳定 → 可用默认 65 秒
- 长轮询、SSE 或内网低频系统：需确认链路透传且客户端持续心跳 → 可设 60–300 秒，但务必验证
必须联动配置，单调无效
keepalive_timeout 只是链条一环，要真正起效，得同步调这几项：
- keepalive_requests：限制单连接最大请求数（建议 50–1000），防止单连接异常霸占资源
-
upstream keepalive：开启后端连接池（如
keepalive 32;），搭配proxy_http_version 1.1;和proxy_set_header Connection ''; -
客户端与中间链路：用
curl -v看响应头是否有Connection: keep-alive，检查 CDN、WAF 是否透传
