慢速HTTP请求攻击缓解与超时设置，关键不是把所有连接一律切断，而是避免客户端用极慢的速度发送请求、长期占住服务端资源。初次配置时，先区分请求超时与并发连接限制：前者限制连接等待多久，后者限制同时容纳多少连接。两项需要结合正常访问和业务负载调整。
先认清慢请求占用的是什么
在HTTP/1.1场景中，客户端可能逐步发送请求头，迟迟不结束；也可能声明较大的请求体，却长时间只传少量数据。连接未完成前，反向代理或应用服务器仍可能为它保留连接、缓冲区或处理资源。这类慢连接与短时间涌入大量完整请求不同：单个请求速率低，但连接持续时间长。
HTTP/2允许多个流复用一条连接，因此只数TCP连接未必能代表实际请求压力。部署了反向代理时，还要分别检查代理与后端应用的连接、请求和超时设置，不能只看其中一层。
先设置两类超时，再限制并发
分别限制请求头和请求体等待时间
请求头超时用于限制收到完整请求头之前的等待；请求体超时则针对请求内容的接收过程。不要把它们与连接空闲超时或后端响应超时混为一谈。比如，在线表单通常不需要数分钟才送完几个字段；而大文件上传、弱网移动端请求可能需要更长时间，应按路由或业务类型单独设置。
作为初始评估范围，可先将普通交互请求的请求头时限设为约5至15秒，并为请求体设置约30至120秒的观察起点。它们不是通用安全值：上传体积、客户端网络质量、代理链路和服务器性能都会改变合理范围。若产品确实支持长时间上传，应针对上传路径放宽，而非让所有请求共享最长时限。
并发限制要留出正常流量空间
并发连接上限控制同一时刻可占用的连接数量。上限过高，慢速请求仍可能堆积；上限过低，正常用户会遇到排队或连接失败。可以先从服务容量和正常高峰的连接数估算，再留出余量，观察连接占用、排队、错误率和CPU、内存变化后逐步调整。每IP限制也要谨慎：企业出口、校园网络或运营商网络可能让许多真实用户共用一个公网IP。
按步骤落地并验证
- 盘点请求类型：记录普通页面、API、上传接口各自的请求头大小、请求体规模及正常完成时间。
- 分层设置时限：先配置请求头与请求体超时；后端响应超时单独处理，避免把慢后端误判为慢客户端。
- 设定并发边界：分别检查反向代理和应用服务器的连接上限、排队容量及每客户端限制，确认限制没有只在一层生效。
- 小步验证：在测试环境或低风险时段，用正常请求、延迟发送请求和合法上传分别验证；逐项调整，检查超时日志、连接数及业务错误率。
- 持续复核：上线后关注被超时拒绝的请求是否集中于特定路径或网络环境，再调整对应规则，不要仅凭连接数升高就全局缩短时限。
以HAProxy为例，配置中的请求处理超时与客户端连接超时承担不同作用；实际参数名称、作用范围及版本行为应以所用版本文档为准。慢速HTTP请求攻击缓解与超时设置最好先在预发布环境核对，再逐步应用到生产流量，并确认代理与后端的限制能够相互配合。
常见问题
超时设得越短越安全吗？
不是。过短会误伤弱网用户、合法上传或较慢的业务处理。应按请求类型设置，并通过日志验证。
限制每个IP的连接数就够了吗？
不够。攻击流量可能来自多个地址，且多个正常用户也可能共用一个IP。应同时设置超时、总并发边界并监控异常模式。
为什么代理设了超时，应用仍可能受影响？
代理与应用服务器可能保留不同的连接和请求资源。检查两层配置、连接复用及超时传递方式，确认请求不会在后端继续占用资源。
归纳起来，慢速HTTP请求攻击缓解与超时设置应从识别请求类型开始：先区分请求头、请求体和后端等待，再设置适合业务的时限与并发连接上限，最后依据运行数据逐步校准。
