慢速HTTP请求攻击缓解与超时设置，关键不是把所有时间都调到最短，而是让每项超时对应明确的等待阶段。阈值过宽，连接可能被慢速发送占住；阈值过窄，移动网络波动、较大的合法请求也可能失败。以下数值是常见起始范围，最终应结合业务请求大小、网络情况和服务器实现验证。
先分清六项参数各管什么
- 请求头读取超时：限制客户端发送完整请求头所需时间。可先从约5至15秒评估；头部通常较短，长时间缓慢补齐没有必要持续占用连接。
- 请求体读取超时：限制服务端接收请求正文的等待时间。短文本或小型表单可从约15至60秒起步；大文件上传应单独配置更长时限，不能照搬小请求的阈值。
- 连接空闲超时：限制一条持久连接在两次请求之间保持空闲的时间。约5至30秒可作为初始测试区间，调短能释放闲置连接，但可能增加重新建连的开销。
- 上游连接超时：限制代理或网关连接后端服务的等待时间。网络路径较短、服务在同一环境时可从约1至3秒观察；跨网络部署通常需要结合实际延迟放宽。
- 上游响应超时：限制连接后端后等待响应数据的时间。交互式页面可先评估约15至60秒；报表、长轮询等场景需要单独识别，不能简单按普通页面设置。
- 总请求时限：限制一次请求从开始到结束的总耗时。它能补上各阶段超时各自未超限、整体却拖得很久的缺口，可依据业务目标设置，例如交互请求约30至90秒，再通过测试调整。
各软件对“超时”的定义并不完全相同：有的计算整个阶段，有的只计算连续无数据的间隔。因此，慢速HTTP请求攻击缓解与超时设置不能只看参数名称，还要核对文档中的计时方式。
配合时避免两个常见漏洞
间隔超时不等于总时限
如果请求体读取超时只在“长时间没有新数据”时触发，客户端每隔一小段时间发送一点数据，就可能反复刷新计时。应同时设置总请求时限；在实现支持时，还可对请求体的最低传输速率或分段读取时长设限。最低速率要留出网络抖动空间，不宜只按理想网络估算。
前后端时限要留出余量
入口的上游响应超时若短于后端正常处理时间，会让用户提前收到失败；若明显长于入口总时限，则连接可能被无意义地保留。可把上游连接超时设得较短，把响应时间按业务处理上限配置，并让入口总时限覆盖必要的排队与传输时间。各层超时应逐层核对，避免外层先断开、内层仍继续工作。
按步骤落地并验证
- 先按请求类型分类：普通页面、小型提交、文件上传、长轮询分别记录合理的正文大小和处理时长。
- 查看服务端、负载均衡器与应用框架的参数文档，确认每项计时是阶段总长还是空闲间隔，并找出默认值。
- 先收紧请求头和空闲连接时限；再为请求体、上游连接、上游响应和总请求时限设定初始值。大文件或长任务使用独立路由与策略。
- 在测试环境逐步模拟延迟发送、正常慢网、上传中断和后端变慢，检查连接是否按预期释放，以及合法请求是否被误拒。
- 上线后观察超时错误、活动连接数、请求时长分布和后端负载。一次只调整少数相关参数，保留回退方案，再根据实际记录微调。
也可以在应用入口增加并发限制、请求大小限制和异常连接告警；它们不能替代超时，但能减少单一连接策略失效时的影响。最终目标不是让所有请求都快，而是让等待有边界、合法长请求有专门通道。
常见问题
请求头超时调到几秒才安全？
没有通用安全值。可从约5至15秒测试，并根据客户端网络和请求头大小调整；重点是阻止长时间缓慢补齐，而非追求最低数字。
文件上传能否沿用普通请求体超时？
通常不宜。应按允许的文件大小、预期带宽和业务期限设置独立规则，并配合总时限或传输速率检查。
只设置总请求时限够不够？
不够。分阶段超时能更快发现请求头停滞、连接后端失败等问题；总时限负责限制整体耗时，两者应配合使用。
做好慢速HTTP请求攻击缓解与超时设置，需要先理解每项参数的计时边界，再按请求类型验证阈值。保持阶段限制、总时限与业务例外相互配合，才能兼顾连接资源保护和正常请求成功率。
