keepalive_timeout 不直接提升吞吐量，而是通过调节连接复用效率间接决定吞吐上限；需结合业务节奏、客户端行为与系统资源匹配设置，同时联动 upstream keepalive 和 keepalive_requests 才能有效优化。
keepalive_timeout 本身不直接提升吞吐量，但它通过影响连接复用效率，间接决定吞吐上限——设得太短，重连开销吃掉 CPU 和网络资源；设得太长，空闲连接挤占文件描述符和内存，新请求被拒绝。真正有价值的不是调单个值，而是让它与业务节奏、客户端行为和系统资源形成匹配。
匹配业务请求节奏
用户发请求的间隔，决定了连接“值得留多久”。留得比实际间隔长，是浪费；留得比间隔短，等于没复用。
- 静态资源（HTML/JS/CSS/图片）：浏览器通常并行加载，后续请求密集且间隔短，设 30–45 秒 能覆盖多数复用窗口
- 移动端 API（App、小程序）：弱网下连接易被中间设备切断，客户端自身超时常为 60–120 秒，Nginx 设 15–30 秒 更稳妥
- 后台管理系统：用户点击间隔可能达数分钟，连接复用率低，10–20 秒 即可，避免无效驻留
- 长轮询或 SSE 场景：需确认客户端持续发送心跳且链路透传 keep-alive，可设 60–300 秒，但必须实测验证
防止资源耗尽反拖垮吞吐
高并发下，每个空闲连接都占用一个文件描述符（fd）和内存。worker 进程的 fd 上限由 worker_connections 和系统 ulimit -n 共同限制。一旦被空闲连接占满，新请求直接失败，吞吐断崖下跌。
- Waiting 状态连接数持续高于活跃请求数，说明大量连接在“空等”，是典型的 timeout 过长信号
- 出现 “Too many open files” 错误或
netstat -an | grep ESTABLISHED | wc -l持续接近 worker_connections 值，就要立刻压低 timeout - 对高并发网关类服务，≤ 5 秒 是安全起点，配合
reset_timedout_connection on快速回收异常连接
必须联动 upstream keepalive 才见效
只优化客户端到 Nginx 的 keepalive_timeout，对反向代理场景吞吐提升有限。后端连接才是瓶颈所在。
- upstream 块中必须加
keepalive N（如keepalive 32），否则 Nginx 默认每次请求都新建后端连接 - Nginx 的
keepalive_timeout必须比后端服务（如 Tomcat、Spring Boot）的 keepalive timeout 小 5–15 秒，否则连接会被后端先断，Nginx 白维护 - 搭配
proxy_http_version 1.1和proxy_set_header Connection ''，确保 HTTP/1.1 keep-alive 请求头正确传递
配合 keepalive_requests 控制连接生命周期
单个连接承载请求过多，容易因大文件下载中断、后端异常等原因导致连接僵死；太少又频繁重建。它和 timeout 共同构成连接释放的双重条件。
- 推荐设为 100–1000，静态服务可略高（如 500），API 服务建议保守些（如 100–300）
- 若 timeout=30s，requests=100，则平均每个请求间隔需 ≤ 0.3 秒才能充分利用；若实际间隔更长，requests 可适当调低
- 避免设为 0（无限）或过大（如 100000），否则可能让一条连接长期滞留，违背 timeout 初衷
