防御slowloris类攻击的关键是收紧四类超时（client_header_timeout、client_body_timeout、send_timeout、keepalive_timeout）并启用reset_timedout_connection，使慢连接在几秒内被识别释放，而非依赖调高worker_connections；后者仅定义单worker最大连接数，不设防且默认值易被耗尽。
防御 Slowloris 类慢速连接攻击，worker_connections 本身不是直接的防护参数，但它决定了单个 worker 进程能容纳多少“挂起连接”。一旦慢速连接大量堆积，就会迅速耗尽这个上限，导致新用户无法建立连接——此时你看到的是 502/504 或连接拒绝，而不是带宽打满。真正起效的是**配合超时控制，让慢连接在几秒内被识别并释放**，从而把 worker_connections 留给真实请求。
worker_connections 的定位与常见误区
它定义每个 worker 进程可管理的最大并发连接数（含客户端、上游、keepalive 等）。默认值通常为 512 或 1024，在未调优的 Nginx 中极易被几百个 Slowloris 连接占满。
- 设得过高不等于更安全：若超时没收紧，只是延长了服务崩溃的时间点，反而掩盖问题
- 设得太低会提前触发连接拒绝，但不能阻止攻击者持续建新连接
- 关键不在“堆数量”，而在“控生命周期”——让每个连接要么快速完成，要么快速断开
四类超时协同压缩慢连接生存窗口
仅调 worker_connections 没用，必须搭配以下四个 timeout 指令，形成分阶段拦截：
-
client_header_timeout 5–10s：从 TLS 握手完成后第一个 HTTP 字节开始计时，到完整请求头（含
\r\n\r\n）收完为止。Slow Headers 攻击在此阶段被截断，返回 408 - client_body_timeout 5–10s（上传场景可放宽至 300s）：只管“两次数据到达间隔”，不看总上传时间。防攻击者声明大 Content-Length 却每分钟只发 1 字节
- send_timeout 8–12s（流式响应如 SSE 可设至 60–300s）：Nginx 往客户端写响应时，两次 write() 调用之间的空闲上限。防 Slow Read 卡住连接
- keepalive_timeout 5–8s + reset_timedout_connection on：长连接空闲超时后直接发 RST 断连，避免 TIME_WAIT 堆积，快速回收 socket 和 worker slot
MPM 与系统级联动才能真正扛住
超时生效的前提是 Nginx 能及时调度、处理、释放连接。这需要底层支撑：
- 确保
worker_processes auto;或按 CPU 核数设置，避免单核瓶颈 - 检查系统文件描述符限制：
ulimit -n至少 ≥worker_processes × worker_connections × 2 - 在高并发 HTTPS 场景下，建议
worker_connections设为 4096–10240，而非盲目堆到数万——前提是上述超时已收紧，否则只是给攻击者更多“挂机位” - 启用
reuseport（Linux 3.9+）可提升 accept() 效率，缓解连接洪峰冲击
验证是否真起效的实操方式
别只看配置写了没，要观察行为是否改变：
- 用
curl -v --limit-rate 10 http://your-site/模拟慢速头，确认 5–10 秒内返回 408 - 查 error_log 是否出现
client timed out或client sent invalid header - 压测中监控
netstat -ant | grep :443 | wc -l和ss -s，ESTAB 连接数应平稳，无缓慢爬升趋势 - 观察
nginx_status中 Active connections 下 Reading 状态是否长期低于 10%（正常业务多为 Waiting 或 Writing）
