慢速HTTP攻击的关键不在请求数量，而在于客户端以很低的速度发送请求，长时间占用服务器连接和处理资源。选择慢速HTTP请求攻击缓解与超时设置时，先判断资源耗在哪里：请求头迟迟不完整、请求体上传缓慢，还是连接空闲不释放。只缩短一个超时值，可能挡不住其他类型的慢速请求，也可能误伤正常用户。
先分清五种超时分别管什么
这五种策略不是互相替代的开关。Nginx 提供请求头、请求体和 keep-alive 相关超时指令；Apache HTTP Server 的 mod_reqtimeout 可限制读取请求头、请求体所用的时间及传输速率。不同版本、代理层和应用服务器的具体选项与默认值可能不同，部署前应核对对应文档。
1. 请求头完成时限
限制服务器等待客户端发送完整请求头的时间，主要针对连接建立后缓慢逐行发送头部的情况。Nginx 的 client_header_timeout 和 Apache 的 mod_reqtimeout 可用于相应控制。时限设得较短，释放连接更快；但网络延迟高、移动网络不稳定或头部确实较大的合法请求，也更容易失败。应依据日志中的实际耗时设置，而不是直接套用极低值。
2. 请求体读取时限
用于限制上传内容接收过程中的等待。注意，Nginx 的 client_body_timeout 通常约束两次读取之间的等待，不等同于整个上传必须在该时长内结束；Apache 可通过 mod_reqtimeout 的请求体速率规则进一步限制慢速传输。前者实现简单，后者更能识别持续低速发送，但对低带宽用户和大文件上传的影响也更明显。
3. 空闲连接超时
keep-alive 允许多个请求复用一条连接，减少重复握手；请求结束后长期闲置的连接则会占用连接槽位。调低空闲超时能更快回收资源，代价是短时间内连续访问时可能增加建连开销。它主要处理“请求之间的等待”，不能代替请求头或请求体读取超时。
4. 最低传输速率
如果客户端在较长观察窗口内持续传输，却低于设定的最低速率，可中止读取。这比单纯等待一个固定时长更能区分持续慢传和短暂网络停顿；但速率阈值越高，越可能误伤拥塞网络、远距离连接及大文件上传。应按请求阶段分别评估，并给合法上传留出余量。不要把短暂的零速率直接等同于攻击。
5. 请求总时限
为从接收请求到完成处理设置绝对截止时间，可以防止请求持续缓慢推进、不断刷新单次读取计时器。它适合有明确响应时限的普通接口；对长时间报表、流式响应、文件处理等任务，统一的短总时限可能造成中断。应用自身的处理截止时间、反向代理等待上游的时间和客户端等待时间应相互协调，避免资源已释放但客户端仍在等待，或代理先于应用取消请求。
按场景选，不要只看一个数字
面对大量未完成请求，优先检查请求头完成时间和并发连接占用；上传接口则重点评估请求体时限与最低速率；空闲连接偏多时再调整 keep-alive。若使用 CDN、负载均衡器或反向代理，逐层确认超时生效位置：边缘层可能先断开连接，源站却仍在处理；反过来，源站先超时也可能导致代理返回错误。
超时值没有适用于所有站点的固定答案。可先从现有日志或监控中观察请求耗时、上传大小、连接空闲时间和超时错误。普通交互请求可从秒级到几十秒的候选范围评估；大文件上传或复杂处理可能需要更长窗口。该范围只是排查起点，实际取值应结合网络条件、业务时限、请求大小上限及各层配置验证。
安全上线的四个步骤
- 按路径和方法分类，区分普通接口、上传、流式响应及长任务，不用同一规则覆盖全部请求。
- 记录请求头、请求体、空闲连接和处理耗时的分布，同时关注并发连接数与超时日志。
- 先调整最可能被占用的阶段；在测试环境验证慢速发送、正常低带宽访问和大文件上传，再小范围上线。
- 观察连接占用是否下降，并检查 408、499、504 等状态码变化及用户端失败反馈；出现误伤时按路径放宽，而非整体关闭保护。
HTTP/2 可在一条连接上承载多个并发请求，因此只限制连接数未必足以限制请求占用。超时策略之外，还应结合请求体大小限制、并发控制和容量监测。稳妥的慢速HTTP请求攻击缓解与超时设置，是让各层时限一致、按业务类型分级，并用运行数据持续校正。
常见问题
超时设得越短，防护越好吗？
不是。过短会误伤高延迟用户、上传和长任务，应按请求类型及实测耗时留出余量。
请求体超时能限制整个上传时长吗？
不一定。部分服务器的请求体超时只限制读取间隔；要限制总时长，应另设绝对截止时间或速率规则。
只在应用服务器设置超时够不够？
通常不够。CDN、负载均衡器、反向代理和应用各自都可能持有连接或处理请求，应逐层核对限制与日志。
哪些请求不宜套用普通接口时限？
大文件上传、流式响应和耗时任务通常需要单独策略；可采用专用路径、异步处理或更长的明确截止时间。
