关键是要主动限制单个连接的生命周期，keepalive_requests是核心参数；设为0会导致连接对象长期驻留内存、空闲连接占用资源、掩盖真实问题；推荐值依场景设为1000–5000，并需协同keepalive_timeout、reset_timedout_connection等参数优化。
要避免长连接无限期复用引发的内存缓慢增长，关键不是禁用 keepalive，而是**主动限制单个连接的生命周期**——keepalive_requests 正是实现这一控制的核心参数。设为 0（不限制）会显著增加风险，而合理设值可兼顾复用效率与资源稳定性。
为什么 keepalive_requests = 0 容易导致内存缓慢增长
当 keepalive_requests 设为 0 时，Nginx 允许客户端在同一个 TCP 连接上持续发送请求，不设次数上限。这看似“高效”，但实际带来隐患：
- 连接对象及相关上下文（如 SSL session 缓存、header 解析缓冲、流状态等）长期驻留内存，难以被及时回收
- 老旧或异常客户端可能维持空闲连接数小时，连接虽无流量，却持续占用 worker 进程的连接槽位和内存
- 掩盖真实连接管理问题，例如客户端未正确关闭连接、后端响应异常中断等，使问题延迟暴露
推荐配置值与依据
不追求“最大”，而追求“够用且可控”：
- React 静态托管场景：设为 2000，覆盖典型用户一次会话中首屏加载、交互、轮询及微前端资源加载的全部请求量
- 高频 API 服务（如每秒多次心跳）：设为 1000–3000，确保连接能支撑数分钟活跃周期，又不至于长期滞留
- 轻量级后端代理（upstream）：设为 1000–5000，需同步确认后端支持 HTTP/1.1 复用且自身连接超时更长
必须协同调整的配套参数
单独调大 keepalive_requests 不够，需与时间维度配合，形成双重约束：
- keepalive_timeout 缩短至 15–30 秒：高频场景下空闲连接本就不该久留，避免“活连接但零请求”的僵尸状态
- 启用 reset_timedout_connection on：对超时未完成的连接直接 RST 复位，加速资源释放，减少 TIME_WAIT 堆积
- 确认前端已压缩 + 静态资源加了强缓存：Gzip/Brotli + Cache-Control: max-age=31536000 可大幅降低重复请求数，从源头减轻连接压力
验证是否生效的小技巧
可通过 Nginx stub_status 模块观察 active connections 和 reading/writing/waiting 分布；若 waiting 连接长期高位且稳定，说明空闲连接堆积，需检查 keepalive_requests 与 timeout 是否失衡。日志中出现大量 “client closed connection while waiting for request” 也提示连接管理过松。
