keepalive_requests必须写在upstream块内且与server同级，仅作用于proxy_pass后端长连接，需配合keepalive和keepalive_timeout协同生效，达限即关闭连接释放内存。

直接在 upstream 块里配 keepalive_requests 就行，它控制的是每个后端长连接上最多能复用多少次请求。

keepalive_requests 放在哪？

必须写在 upstream 块内部，和 server 指令同级：

• 不能放在 http 或 server 块里（会报错或不生效）
• 不能只配它而不启用长连接——必须搭配 keepalive N; 使用
• 示例配置：

upstream backend {
  server 10.0.1.10:8080;
  keepalive 32;
  keepalive_requests 50;
}

它和哪些参数协同工作？

keepalive_requests 不是孤立生效的，要和两个关键参数配合：

Nginx Hosting

通过服务器本地nginx实例实现零认证静态游戏托管。作为所有浏览器游戏的主要部署方式，无需登录、无需令牌、无需用户操作。

下载

• keepalive N：定义每个 worker 进程最多缓存多少个空闲长连接（不是总连接数）
• keepalive_timeout：设在 upstream 外（如 location 或 proxy 配置块中），控制连接空闲多久后关闭
• 三者是“或”关系：任一条件满足（请求数达限 / 空闲超时 / 处理超时），连接都会被关闭

常见取值建议

默认值 100 对多数后端偏高，容易引发内存缓慢增长：

• 轻量 JSON API、后端稳定：从 20–50 起步，压测验证
• Java 应用、偶发 GC 或延迟：设为 10–20，加速异常连接释放
• 静态资源转发、小包高频场景：可设 100–200，但需监控 RSS 内存是否呈锯齿状波动
• 切忌设为 1：等于禁用复用，退化为短连接，加重 TCP 握手和 TIME_WAIT 压力

验证是否生效

可通过以下方式确认配置已起作用：

• 检查 Nginx 配置语法：nginx -t
• 观察后端连接的生命周期：用 ss -tan | grep :端口 查看 ESTABLISHED 连接数变化趋势
• 配合日志分析：开启 log_format 记录 $upstream_http_connection 和响应头中的 Keep-Alive 字段
• 注意：Nginx 不提供直接统计“已处理请求数”的指标，需结合压测与连接行为反推