业务侧给每个连接设置合理的超时时间，主要缓解的是慢速连接型攻击，也就是那些利用TCP/IP协议机制、靠长时间占用连接不放手来拖垮服务器资源的攻击方式。这类攻击不靠海量流量，而是靠“赖着不走”，让服务器的连接池、线程池、内存被一点点耗尽，超时设置就是给这些“赖着不走”的连接设定一个最后期限，到点就清理，让服务器资源得以释放。
慢速连接型攻击为何最怕“时间红线”
攻击者的算盘：用最少流量拖垮最多资源
业内专家指出,慢速攻击的核心理念是“以慢打快”，攻击者不需要高带宽，只需要建立大量连接，然后让每个连接都处于“半死不活”的状态，比如发送一个HTTP请求头，每个字段间隔几十秒，服务器就得一直留着这个连接等待后续数据，如果服务器没有超时限制，这些恶意连接会积压成山，最终把可用的并发连接数全部占满，正常用户连不上来。
业务侧的超时设置,等于给服务器装了一个“清道夫”定时器，它告诉服务器：“等够X秒，对方还没完整说话，就挂断。” 这个机制直接击碎了攻击者的如意算盘，因为攻击者必须持续保持连接活跃才能占用资源，而超时让这种占用有了成本上限。
默认配置往往是“帮凶”
很多服务器框架和中间件出厂默认的HTTP请求头超时时间是几十秒甚至几分钟，这个时间远远超过了正常用户敲键盘、点链接、传表单的节奏，统计显示，大多数正常HTTP请求在1-3秒内就会完成，就算网络慢，10秒也顶天了，默认值设这么长，本意是照顾极端弱网环境，但正好被慢速攻击利用。
如果业务侧主动把超时时间压缩到一个合理区间,比如请求头超时10秒、请求体超时15秒，就会带来两个直接效果：
- 攻击者建立连接的成本变高,因为每个连接没活多久就被掐断，要持续施压就必须更高频地建立新连接。
- 攻击者的源IP和指纹特征会更快暴露,因为频繁地连接、断开、再连接，触发安全设备的频率限制和行为分析的阈值。
业务侧设置合理超时，具体能缓解哪类连接型攻击
第一类：Slowloris慢速请求头攻击
这是最经典的一类慢速连接攻击,攻击者打开很多连接，然后只发送一部分HTTP请求头，剩下的字段像挤牙膏一样，每隔几十秒吐一点，服务器收不到完整的请求头，就永远不能给客户端返回响应，只能干等着，如果不设超时，服务器会为这些半截子请求保存大量内存和文件描述符。
业务侧在反向代理层（比如Nginx）或者应用容器（比如Tomcat）里设置“请求头读取超时时间”，通常建议在10-15秒，一旦连接在这个时间内没凑齐请求头，直接无情断开，Slowloris攻击的“慢”策略就彻底失效。
第二类：慢速POST请求体攻击
这类攻击走的是另一个极端,攻击者发送了完整的请求头，服务器开始接收POST请求体，但请求体的大小被声明得很大（比如几十MB），实际发送却以每秒1字节的速度进行，服务器为了接收这个庞然大物，就得一直占用连接和内存等待。
缓解这类攻击的业务侧超时策略需要两手抓,关键参数如下：
- 设置“请求体读取超时时间”，或者在业务代码里设置Socket的读超时，比如从建立连接到读取数据之间，超过20秒无数据到达就抛异常并关闭连接。
- 为POST请求的Content-Length设一个业务上限，比如不超过2MB，超过的直接返回413状态码，不给慢速投递留机会。
第三类：慢速读响应攻击
攻击者不慢发送,改慢接收，他正常发出一个请求，服务器处理完后开始返回响应，但他就是慢慢读，甚至干脆不读，导致服务器的发送缓冲区被撑满，连接被长时间占住。
业务侧应对慢速读攻击的核心手段是设置“客户端读取超时时间”，同时压缩合理的读取速度预估，比如Nginx的client_body_timeout和send_timeout参数，一个管接收，一个管发送。send_timeout设置为30秒以内，可有效缓解这种“只占不读”的慢速读攻击。
行业共识认为,连接型攻击的本质是状态资源耗尽，超时机制是对这类攻击最通用、成本最低的釜底抽薪手段，因为它不依赖额外的安全设备，纯配置层面就能生效。
实操落地：业务侧超时设置的“黄金组合”
统一分层配置原则
在业务侧配置超时,要遵循TCP层、中间件层、应用层三层联动的思路，只调一层往往效果会打折扣：
| 层级 | 名称 | 推荐值（值域区间） | 作用 |
|---|---|---|---|
| TCP层 | tcp_keepalive_time | 30-60秒 | 探测死链，回收半开连接 |
| 中间件层 | 请求头超时时间 | 10-15秒 | 阻止Slowloris头部攻击 |
| 中间件层 | 请求体超时时间 | 15-30秒 | 阻止慢速POST攻击 |
| 中间件层 | 发送响应超时时间 | 30-60秒 | 阻止慢速读攻击 |
| 应用层 | Socket读超时 | 15秒 | 业务兜底，防止长占连接 |
| 应用层 | Socket写超时 | 15秒 | 业务兜底，防止发送阻塞 |
Nginx与Tomcat的配置示例
以最常见的业务集群为例,Nginx作为统一入口，配置如下：
http {
client_header_timeout 10s; # 等待请求头超时
client_body_timeout 15s; # 等待请求体超时
send_timeout 30s; # 发送响应给客户端的超时
keepalive_timeout 30s; # 长连接存活时间
}
server {
listen 80;
limit_conn_zone $binary_remote_addr zone=addr:10m;
limit_conn addr 10; # 每IP并发连接数限制
}对于后端Java应用,以Tomcat为例，处理连接型攻击的主要超时参数是：
connectionTimeout（默认60秒），主要控制等待URI和请求头的超时时间，建议调整为10000毫秒（10秒）。socketBufferSize，根据具体业务调整读写缓冲区大小。
配置完成后,使用slowhttptest工具进行验证测试，在服务器上执行压测命令，观察连接数变化和拒绝响应情况。
实测命令行示例：
slowhttptest -c 1000 -H -i 10 -r 100 -t GET -u http://yourdomain.com -x 24 -p 3
当超时配置生效时,攻击过程中错误连接数会显著上升，服务器可用连接数维持稳定，不再被逐渐耗尽。
云环境与多节点架构下的超时联动
在云环境下,业务侧的泄露防护不能只做一层，如果一个Web应用通过负载均衡服务（如简米云SLB、酷番云CLB）对外提供服务，还要注意负载均衡的
空闲超时时间必须小于后端服务器的超时时间，否则负载均衡已经断开连接，后端服务器还在傻等，白占资源。
配置顺序上,建议遵循“连接入口超时小于源站超时”的原则，从上到下逐级收紧，典型的链路是：CDN节点（60秒）→负载均衡（30秒）→Nginx入口（15秒）→应用容器（10秒），每一层的超时时间比外层更短，确保无论哪一层主动清理连接，资源都能及时释放。
业务侧超时的边界与取舍
超时设置并非越短越好,设置过短会误伤正常用户，比如在弱网环境下的正常用户，或者需要上传较大文件的业务场景，2026年，随着移动端设备增多和网络环境复杂化，这个问题更值得关注。
设置合理超时,本质上是把攻击者的成本拉到比攻击收益还要高的位置，你不需要让服务器变成“钢铁侠”，只需要让它对那些不正常的行为“没耐心”，把连接就收的规则变成这样：“有话快说，有数据快传，超过时限就滚蛋。”
Q&A：关于业务侧设置合理超时与连接型攻击的常见问题
问：业务侧设置超时会不会影响用户上传大文件？
答：会，所以需要把“请求头超时”和“请求体读取超时”区分开，请求头超时收紧到10秒，主要拦截的是建立连接后不发完整头部的情况，对于正常的大文件上传，只要客户端持续发送数据，请求体读取超时就不会触发，如果业务确实需要支持超长上传，可以对特定URL路径定义独立的宽松超时规则，不使用全局默认值。
问：只依赖业务侧超时，不买高防IP能挡住慢速连接型攻击吗？
答：对于中小规模的慢速攻击，超时设置是最有效的第一道防线，能挡住相当一部分脚本小子和低端流量攻击，但如果攻击者用大量肉鸡分布式的发起每秒成千上万个连接建立请求，超时机制只能清理已建立的连接，无法阻止新连接的持续涌入，此时仍需要在高防或云清洗设备上配置速率限制和畸形包过滤规则，配合业务侧超时一起形成纵深防御。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/652890.html
