缓冲区限额本身不直接防御slowloris，真正起效的是连接级资源限制机制；需收紧请求头/体缓冲区大小、配合超时与连接数限制，并由反向代理统一管控。
缓冲区限额本身不是直接防御 Slowloris 的核心手段，真正起作用的是**连接级资源限制机制**，其中“请求头缓冲区大小”和“请求体缓冲区大小”是关键控制点。Slowloris 不靠填满缓冲区，而是靠长期占用连接槽位；但合理设置缓冲区限额能配合超时与连接数限制，切断其维持连接的路径。
限制请求头缓冲区大小，阻断 Slow Headers 攻击
Slowloris 最常用的是 Slow Headers 变种：攻击者持续发送不完整的 HTTP 头（如每 10–30 秒发一个 X-a: b\r\n），永远不发终止符 \r\n\r\n，让服务器一直等待完整头部。
此时，若服务器为每个连接分配过大的请求头缓冲区（如默认 8KB），虽不被填满，却会延长等待窗口。应主动收紧：
- Apache：通过
LimitRequestFieldSize（默认 8190）设为 2048 或更小，并配合LimitRequestFields限制字段数量（如 50） - Nginx：用
client_header_buffer_size设为 1k，large_client_header_buffers设为 2 2k（即最多 2 个大缓冲区，各 2KB） - Spring Boot（Tomcat）：通过
server.tomcat.max-http-header-size=2048限制头部总长
一旦攻击者尝试发送超长或过多字段，服务器会立即返回 400 Bad Request 并关闭连接——这比等超时更高效。
限制请求体缓冲区与读取行为，抑制 Slow Body/Slow Read
对于 Slow POST 或 Slow Read 类变种，攻击者发送完整头部后，缓慢上传大 body 或极慢读响应。此时缓冲区限额需配合读取策略：
- 禁用无限制 body 缓存：Nginx 中关闭
client_body_buffer_size自动扩容，设固定值（如128k），并启用client_max_body_size防止超大上传 - 强制流式处理：后端应用（如 Spring WebFlux、Node.js Stream）避免将整个 body 加载进内存；用流式解析 + 超时中断（如
readTimeout） - Tomcat 设置
maxSwallowSize（默认 -1 即不限）为较小值（如2048），防止攻击者故意中断上传后服务器仍试图吞掉剩余数据
缓冲区限额必须与超时联动才有效
单独调小缓冲区不能阻止 Slowloris，因为攻击者根本不会触发溢出——他只发几个字节。真正起效的是：在缓冲区未满、连接未闭合的前提下，用超时机制强制终结“停滞态”。
- 所有服务器都应启用 初始请求头读取超时（如 Nginx
client_header_timeout 15s，Tomcatconnection-timeout=10000） - 该超时必须 早于缓冲区耗尽所需时间——例如，若攻击者每 20 秒发一次头字段，你的超时就绝不能设成 60 秒
- 缓冲区限额的作用是：让超时更容易被触发（小缓冲区意味着更少数据就能进入“可判定停滞”状态），并降低单连接内存开销
反向代理层统一收口，隔离真实缓冲行为
把缓冲区限额和连接管理交给前置代理（如 Nginx、Traefik、Cloudflare），比依赖后端应用更可靠：
- Nginx 默认不缓存请求体到磁盘，且能对每个连接独立设
client_header_timeout和client_body_timeout - 启用
proxy_buffering off可避免反向代理自身成为 Slow Read 的受害者 - 结合
limit_conn指令限制单 IP 连接数（如limit_conn addr 10），从源头压缩攻击面
这样，真实应用服务器只需专注业务逻辑，无需暴露原始缓冲配置，整体防御更健壮。
