慢速HTTP请求攻击缓解与超时设置，关键不是把所有超时压到最低，而是尽早识别长期不完整或停滞的请求，同时给正常网络和业务操作留出余地。把超时设得过短，可能让移动网络用户、远距离访问者或上传大文件的用户频繁失败；设得过长，则会让连接和处理资源被占用更久。
先分清超时在限制什么
一个请求从建立连接到处理完成，可能经过连接建立、发送请求头、发送请求体和等待响应等阶段。对应的超时含义不同，不能用一个很短的数值包办所有防护。
- 连接超时：限制建立连接所需的等待时间。它针对的是连接建立阶段，不代表请求内容已经发送完毕。
- 请求头超时：限制客户端发送完整请求头的时间。慢速请求攻击常利用缓慢、间歇地发送请求头来维持连接，因此这一项尤其重要。
- 读取空闲超时：限制连接在一段时间内没有新数据时可持续等待多久。它通常按“无数据的间隔”计时，不一定等同于整个请求的总时长。
- 请求体与响应超时：大文件上传、较慢的后端处理都可能需要更长时间，应按业务类型分别评估。
短超时不等于更安全：三个常见误区
误区一：所有请求共用一个极短上限
短文本提交和文件上传的传输特征差异很大。若统一设置很紧的总超时，慢速攻击可能被挡住，合法上传也可能中断。应优先限制请求头完成时间，再为确有需要的请求体设置独立规则。
误区二：只看请求总时长
总时长长，不一定代表攻击：用户可能在上传文件，后端也可能正在处理耗时任务。反过来，请求持续有少量数据到达，也可能让单纯的空闲超时一直不触发。结合请求是否完整、字节到达间隔、连接数和来源行为判断，比只看一个总时长更可靠。
误区三：超时设好就万事大吉
超时只能回收等待过久的连接，不能替代连接并发限制、速率限制和容量监控。HAProxy 等代理软件提供不同阶段的超时控制；实际配置项和默认值会受版本、配置方式及部署结构影响，调整前应核对所用版本的文档，并确认前后端不会因规则不一致产生意外断连。
更稳妥的设置与验证步骤
- 先按请求类型分类。区分普通页面请求、短数据提交和文件上传等场景；不要把它们的请求体超时混为一谈。
- 先设置请求头完成期限。选一个能覆盖正常客户端发送请求头的时间范围，再根据日志观察超时比例和连接持续时间调整。没有适用于所有网站的固定秒数。
- 为请求体、空闲和后端响应分别定界。依据文件大小、网络环境和后端处理时间设置；对允许长时间上传的路径，使用单独规则，并限制可接受的连接数或上传速率。
- 加入并发和速率控制。按单个来源、账户或业务路径设置合理边界，避免某一来源长期占满连接。共享出口网络可能让多个正常用户表现为同一来源，应防止过严限制造成误伤。
- 小范围上线并复核。观察超时记录、活跃连接数、请求完成率和后端错误；遇到合法请求被拒绝，先判断对应阶段和路径，再针对性放宽，而不是整体取消保护。
把防护放进整体容量管理
稳健的慢速HTTP请求攻击缓解与超时设置，通常要同时考虑代理层、应用层和业务路径。对外提供长时间操作的服务，可以让前端尽早确认接收任务，再由后端异步处理；对必须保持连接的场景，则应明确连接上限和空闲回收规则。防护是否有效，要看资源占用是否受控、合法请求是否仍能完成，而不是看超时数字有多小。
常见问题
请求超时越短，攻击者越难占用连接吗？
通常能缩短部分连接的占用时间，但过短会误伤正常用户，也可能无法覆盖持续发送少量数据的情形，应配合请求头期限和连接限制。
空闲超时和请求总时长有什么区别？
空闲超时关注一段时间内是否有新数据；总时长限制整个请求从开始到结束的时间。两者针对的问题不同。
能否直接照搬其他站点的超时值？
不建议。网络延迟、请求类型、文件大小和后端性能都会影响合适范围，应先查看自身日志，再逐项调整并验证。
