keepalive_timeout的作用是控制nginx与客户端间空闲连接的等待时长，设得太短导致频繁握手增加开销，太长则空连接堆积占用资源；需按场景取值（如静态资源10–30秒、移动端api 5–15秒），并配合keepalive_requests及上下游超时对齐。
keepalive_timeout 不是“越长越好”，也不是“越短越省”，它的作用很具体：控制 Nginx 与客户端之间空闲连接的等待时长。设得合理，才能让真实请求复用连接；设得失当，不是白耗资源，就是徒增握手。
它只管“静默期”，不管连接总寿命
这个值定义的是：一次响应结束后，Nginx 愿意保持该连接打开、等待下一个请求的最长时间。期间只要有新请求进来，计时器就重置；超时没动静，就主动断开。传输中或正在处理请求的连接不受影响，TLS 握手、HTTP/2 多路复用也和它无关。
设太短，复用机会被硬砍掉
比如设成 5 秒，而用户点击按钮后隔 8 秒才发 API 请求，那第一条连接早已关闭，第二条只能新建：
- TCP 三次握手 + 四次挥手频繁触发
- HTTPS 下重复 TLS 协商，CPU 和首字节时间（TTFB）双双上升
- 移动端 App 切后台再唤醒，几乎无法复用
设太长，空连接在那儿“占坑”
比如设成 300 秒，但实际客户端 20 秒就断了，或中间 WAF 已在 60 秒回收连接：
- 每个空闲连接占用一个文件描述符（fd），worker 进程容易 hit “Too many open files”
- SSL 上下文、缓冲区持续驻留内存，累积可观
-
nginx_stub_status中 Waiting 状态偏高，说明大量连接挂着没人用
按场景给推荐值，不是拍脑袋
- 静态资源服务（CDN 边缘、图片站）：10–30 秒 —— 快速释放，节省 fd
- 常规 Web 页面（含 JS/CSS/HTML）：30–60 秒 —— 覆盖页面内连续加载节奏
- 移动端 API 接口：5–15 秒 —— 匹配 App 休眠行为和弱网中断特性
- 内网服务或 SSE 流式接口：60–300 秒 —— 客户端长期保活，复用收益明确
- 高并发网关（QPS 过万）：≤5 秒 —— 防止连接堆积拖垮 worker 进程
必须配合 keepalive_requests 一起用
单靠 keepalive_timeout 不够防异常。keepalive_requests 100 表示：哪怕连接没超时，处理满 100 个请求也强制断开。这能防止恶意客户端或慢请求长期霸占连接。
- 默认 100 适合大多数 Web 场景
- CDN 或静态资源节点可提到 500–1000
- 安全要求高的后台系统可降到 50，加快轮转
别忘了链路两端都要对齐
Nginx 设了，不等于就能复用：
- 客户端（浏览器/App）要支持
Connection: keep-alive，且没被中间 LB 或 CDN 强制关闭 - 用
curl -v https://yoursite.com查响应头，确认有Connection: keep-alive，没有close - 若上游有云负载均衡（如 AWS ALB、阿里云 SLB），它的空闲超时必须 ≥ Nginx 的
keepalive_timeout，否则连接会在半路被掐断
不复杂但容易忽略：优化不是堆参数，而是让 Nginx 的连接节奏贴合真实流量行为。
