keepalive_requests通过为每条http/1.1长连接设置硬性请求数上限，达限即发connection: close并确定性关闭连接，从而防范因连接过度复用导致的资源耗尽、上下文污染等隐藏通道风险。
通过设置 keepalive_requests 可以有效预防长连接中因过度复用形成的隐藏通道漏洞。这类漏洞不依赖协议层攻击，而是利用合法的 HTTP/1.1 Keep-Alive 机制，让单条 TCP 连接长期存活、反复承载请求，从而绕过基于时间或频次的常规防护（如限流、超时断连），甚至为内存泄漏、上下文污染或协程栈堆积提供温床。
为什么长连接会成为隐藏通道
当客户端持续复用同一条连接发送请求（例如浏览器预加载、Node.js Agent 复用、或恶意脚本循环调用），Nginx 若不限制请求数上限，该连接可能存活数分钟甚至更久。期间它始终占用 worker 进程的连接槽位、内存 buffer、SSL session 缓存，还可能被 Lua 模块、OpenResty cosocket 或自定义中间件绑定状态——这些资源不会随单个请求结束而自动释放，形成“静默累积”。攻击者可借此缓慢耗尽内存、干扰事件循环，或构造侧信道探测后端行为。
keepalive_requests 的防御逻辑
该指令强制为每条活跃 keep-alive 连接设置一个硬性请求数上限。达到阈值后，Nginx 在响应头中写入 Connection: close，并在当前请求处理完毕后立即关闭连接。这不是延迟释放，而是确定性切断：
- 计数从第一个请求开始，每个完整响应（无论 2xx/4xx/5xx）都 +1
- 仅对 HTTP/1.1 启用 keep-alive 的连接生效，HTTP/2 不适用（需用 http_v2_max_requests）
- 与 keepalive_timeout 是“或”关系：任一条件满足即断连，覆盖高频耗尽与低频空转两类风险
推荐配置策略
没有通用值，需按业务特征设定，并配合监控验证：
- 静态资源服务（JS/CSS/图片）：设为 50–100，匹配单页加载请求数，避免连接滞留
- API 网关或前后端分离接口：建议 1000–3000，兼顾复用效率与连接轮转节奏
- 高敏感管理后台或登录接口：可压至 10–30，快速回收，降低上下文残留窗口
- 绝对不要设为 0：这会禁用 keep-alive，退化为短连接，显著增加握手和 TIME_WAIT 开销
必须协同的关键配置
单独设置 keepalive_requests 效果有限，需与以下机制联动：
- keepalive_timeout 应设为请求平均间隔的 1.5–2 倍（例如 QPS=100，则 timeout≈2–3s），防止 timeout 先于 requests 触发，使计数失效
- reset_timedout_connection on：对已超时但未关闭的僵死连接强制重置，堵住异常保活路径
- 在 OpenResty 场景中，可在 log_by_lua* 中读取 $connection_requests，对临近阈值的连接主动 ngx.exit(444)，实现更精细控制
- 启用 nginx_stub_status 或 Prometheus + nginx-vts-exporter，监控 Active connections 中 Waiting 连接数及单连接请求数分布，确认是否在预期阈值附近截断
