keepalive_requests是防范恶意客户端长期霸占连接的直接手段，通过“请求计数”强制连接在处理完固定请求数（如200次）后立即关闭，无论是否空闲，配合keepalive_timeout形成双退出机制，堵死慢速攻击、死循环请求等异常占用路径。
keepalive_requests 是防范恶意客户端长期霸占连接的直接手段——它不靠等待空闲超时，而是用“请求计数”强制轮换，让每个连接干完活就退场，避免被慢速攻击、死循环请求或异常客户端无限占用。
为什么恶意客户端能卡住长连接
恶意或异常客户端可能表现为：持续发送极低频请求（如每分钟1次）、故意拖延响应、不按规范关闭连接，甚至伪造 User-Agent 规避检测。当 keepalive_requests 设为 0 或过大时，Nginx 会允许这类连接长期驻留，导致：
- worker 进程连接槽位被占满，新用户无法建立连接
- 文件描述符耗尽，出现 "Too many open files" 错误
- 空闲连接堆积，waiting 状态连接数长期高位，stub_status 显示异常
- 真实业务请求被挤出，表现为延迟突增、503 频发
keepalive_requests 如何主动切断恶意占用
该参数不是被动等待，而是主动控制生命周期：
- 设为固定值（如 200），表示该连接最多处理 200 次请求，第 200 次响应后立即发送 Connection: close 并关闭连接
- 无论此时连接是否空闲、是否还有后续请求意愿，都强制退出——恶意客户端无法靠“只发不收”或“拖时间”续命
- 配合 keepalive_timeout（建议设为 15–30 秒），形成双退出机制：任一条件先满足即断连，堵死所有空转路径
生产环境推荐配置策略
针对不同风险等级场景，设定有区分的阈值：
- 高风险暴露面（如公网 API 网关、登录接口）：keepalive_requests 设为 50–100，快速轮换，防止单连接被反复试探或打洞
- 常规 Web 服务（含 React/Vue 单页）：设为 1000–2000，覆盖一次完整会话，又不给异常行为留余地
- 已知存在慢客户端或老旧设备的场景：可进一步降至 200–500，并启用 reset_timedout_connection on 加速异常连接清理
- 绝对避免设为 0——这等于放弃主动防御，把连接寿命完全交给客户端行为决定
必须同步检查的配套项
单靠 keepalive_requests 不足以闭环防护，还需确认：
- 客户端未显式发送 Connection: close（否则 keepalive 不生效，该参数无作用）
- 前端或中间 LB（如 CDN、WAF）未覆盖或禁用 Keep-Alive 头
- 日志中是否频繁出现 "client closed connection while waiting for request" ——若大量出现，说明 timeout 过短，需与 requests 值协同调整，而非单纯压低后者
- 通过 ss -tnp | grep :443 | grep ESTAB | wc -l 观察活跃连接数是否稳定，而非随时间持续缓慢上升
