HTTP慢速连接攻击的超时参数调优，重点不是把所有等待时间一律调短，而是限制连接长期占用资源，同时给正常客户端留出完成请求的时间。可从请求头超时、请求体超时、空闲连接回收等十个要点逐项检查；具体取值应结合服务器负载、网络状况和业务请求大小验证。
先分清需要调的超时
慢速请求可能卡在不同阶段：客户端迟迟没有发完请求头、请求体传输间隔过长，或请求完成后仍占着空闲连接。超时参数应对应具体阶段。还要区分“整段请求的总时限”和“相邻数据之间允许的空档”：例如 Nginx 的 client_body_timeout 主要限制连续两次读取请求体之间的等待时间，并不等于整个上传过程的总时长。
十大常见调优要点
1. 收紧请求头超时
检查 Nginx 的 client_header_timeout 或 Apache HTTP Server 的请求读取设置。普通网页接口可先在约 5—15 秒范围内评估；若客户端网络较慢、请求头较大，应结合实际请求分布留出余量。
2. 限制请求体读取间隔
通过 client_body_timeout 等参数限制请求体传输中的长时间停顿。小型表单和常规 API 可先测试约 10—30 秒的空档阈值；大文件上传不宜直接套用，应另行评估上传链路和客户端网络。
3. 设定请求整体时限
单次读取间隔短，不代表整个请求不会拖得很久。若业务需要限制总处理时长，可在应用、网关或负载均衡层设置整体期限，并确认它不会误杀合法长任务。
4. 缩短空闲 keep-alive
连接复用能减少重复建连开销，但空闲连接长期保留会占用资源。Nginx 的 keepalive_timeout 可从约 5—15 秒测试；连接复用收益较高的服务可适当放宽，并观察并发连接数。
5. 控制代理等待上游的时间
反向代理的读取超时应匹配后端接口的正常耗时。以 Nginx 的 proxy_read_timeout 为例，它通常约束从上游连续读取数据之间的等待；如果业务会长时间无输出，应区分这类接口，而不是全站统一延长。
6. 检查请求头最小速率
Apache HTTP Server 的 mod_reqtimeout 可配置请求头和请求体读取时间，也可结合 MinRate 限制过慢的数据输入。启用前先核对模块是否加载，并用正常慢速客户端验证，避免低带宽用户频繁收到超时错误。
7. 不要忽略最大请求体限制
超时不能替代大小限制。对不需要大上传的接口，应设置合理的请求体上限；确有文件上传需求时，按业务允许的文件尺寸配置，并同步检查应用层限制。
8. 协调网关与应用的参数
如果前置负载均衡器比应用更早断开，请求会在到达后端前失败；若应用超时更短，则网关可能继续等待无效连接。逐层记录连接、请求和响应的超时，明确由哪一层先终止。
9. 限制并发占用并观察连接状态
超时之外，还应检查每个客户端可建立的并发连接上限，以及服务器的文件描述符、工作进程和连接池容量。调参后观察活动连接、超时错误和正常请求延迟，不能只凭页面是否恢复判断。
10. 分阶段发布并回退
先在测试环境或少量实例调整，再逐步扩大范围。若超时错误明显增加、上传中断或正常请求延迟恶化，立即回退到已记录的配置，并按请求类型重新划分阈值。
可执行的检查顺序
- 确认流量经过哪些层：例如 HAProxy、Nginx 和应用服务器，并列出各层实际生效的参数。
- 按请求头、请求体、空闲连接、上游等待分类，记录当前值与对应错误日志。
- 先调整最相关的一项，使用正常请求和受控的慢速请求验证连接能否按预期释放。
- 查看超时数量、连接占用、请求成功率及延迟变化；稳定后再调整下一项。
- 保存修改前后的配置和回退方案，避免多个参数同时变化而无法定位原因。
HTTP慢速连接攻击的超时参数调优应以分层、分阶段和可回退为原则。先找出连接被占用的具体阶段，再为不同请求设置合适期限，并持续核对正常客户端是否受到影响。
常见问题
超时时间越短越安全吗？
不一定。过短可能中断慢速网络下的正常请求；应按请求类型和实际耗时评估。
只改反向代理够不够？
不一定。还需检查负载均衡器、应用服务器和连接池，避免某一层仍长期保留连接。
调低请求体超时会影响上传吗？
可能。大文件或不稳定网络更容易出现传输间隔，需单独测试上传场景。
如何判断调整有效？
对比调整前后的连接占用、超时日志、正常请求成功率和延迟，并确认异常请求能及时释放资源。