keepalive_timeout本质是平衡复用收益与资源压力，需按业务设合理值：移动端15–30秒、静态资源10–60秒、微服务5–15秒、内网/SSE可至60–300秒，并必须联动keepalive_requests、upstream keepalive等协同调优。
高并发下 Nginx 长连接超时时间的取舍，本质是平衡“复用收益”和“资源压力”——不是越长越好，也不是越短越稳，关键看连接生命周期的真实行为。
keepalive_timeout：空闲多久关，得比客户端更“忍让”
这个值决定 Nginx 主动关闭空闲连接的时间。它必须略小于客户端（如 App、浏览器、SDK）实际维持 Keep-Alive 的能力，否则 Nginx 先断，客户端会收到 RST 或 502/504。
- 主流浏览器默认只守约 60 秒左右，设为 15–30 秒 是多数 API 服务的安全选择
- 移动端或自研 SDK 若明确支持长连接且设为 120 秒，Nginx 可配 90–110 秒，留出缓冲
- 超过 180 秒需谨慎：worker_connections 容量有限，空闲连接堆积易引发端口耗尽或 TIME_WAIT 暴增
- 低于 10 秒可能造成频繁 TCP 握手，尤其在 TLS 复杂场景下 CPU 开销明显上升
keepalive_requests：一条连接最多干几票
它不控制连接存活时长，而是限制单条长连接能承载的请求数上限，防止单连接老化、内存泄漏或状态累积。
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
- 纯 JSON API、无状态轻量接口，可设 500–2000，提升复用率
- 若上游服务存在连接泄漏风险（如旧版 Java 应用未正确释放 DB 连接），建议压到 50–150，强制轮转
- 日志中频繁出现
"client closed connection while waiting for request"，往往是该值过高 + 网络抖动叠加所致 - 注意：达到此数后连接不会立即断开，仍受 keepalive_timeout 约束，只是不再接受新请求
upstream keepalive：后端连接池不能“光喊口号”
客户端连 Nginx 的长连接再好，如果 Nginx 到后端始终新建连接，整体收益就打对折。
- 必须显式启用：
upstream xxx { keepalive 32; }，数值建议为后端单实例最大并发连接数的 1/4 到 1/2 - 配套设置
proxy_http_version 1.1和proxy_set_header Connection ''，避免透传Connection: close - upstream 块内可单独设
keepalive_timeout 60s，应与后端服务（如 Spring Boot 的 server.tomcat.connection-timeout）对齐，避免单方面断连 - 若后端是 Go net/http，默认 keep-alive 是永久的，此时 Nginx 的 upstream keepalive_timeout 就成了唯一控制点
验证是否真生效，不能只看配置
调完参数不验证，等于没调。重点确认三点：
- 用
ss -ant | grep :443 | wc -l对比调优前后 ESTABLISHED 连接数趋势，看是否明显下降但 QPS 不跌 - 开启
stub_status，观察Active connections和Reading/Writing/Waiting分布，Waiting 长期 > 80% 说明空闲连接积压 - 抓包看 TCP 层：同一 client IP:port 是否复用发送多个 HTTP 请求；响应头是否有
Keep-Alive: timeout=30
