慢速攻击为什么专挑“超时”下手
服务器超时设置过长，等于给慢速攻击留了一扇不关的门攻击者用极低速率维持大量半开连接，靠的正是你迟迟不肯断开的超时宽容。业内专家指出，慢速攻击并非靠流量洪峰冲垮服务，而是靠“拖”字诀耗尽连接池，超时参数就是这场拉锯战里最关键的裁判哨。
慢速攻击的典型代表是Slowloris和Slow HTTP POST，前者每隔十几秒才发一个HTTP头字段，后者把Content-Length报得很大却每次只传几个字节，它们的共同点是：单连接速率低到几乎不触发流量告警，但只要服务器愿意等，连接就一直挂着，连接池容量是有限的，当几百上千个这样的“僵尸连接”占满名额，正常用户连TCP握手都排不上队。
从攻击成本看,这种打法极其廉价，一个普通宽带终端就能维持数百个慢连接，不需要僵尸网络，不需要大带宽，防守方若把client_header_timeout、keepalive_timeout这类参数设成60秒甚至300秒，等于主动拉长每个攻击连接的“寿命”，近年来多起针对中小型网站的勒索型DDoS事件中，慢速攻击占比明显上升，而受害方事后排查往往发现超时配置仍停留在默认或“拍脑袋”的高值。
服务器超时时间设置多少合适
不同超时参数的安全边界
超时参数不是越短越好,短到误伤正常用户同样麻烦，行业共识认为，超时值应当“贴着业务真实耗时走”，而不是照搬默认配置，下面这张表可以作为调优起点：
| 参数（以Nginx为例） | 常见默认/高值 | 建议安全区间 | 设置过长的后果 |
|---|---|---|---|
client_header_timeout |
60s | 10–15s | 慢速头发攻击轻松挂住连接 |
client_body_timeout |
60s | 10–15s | Slow POST攻击可长期占用 |
keepalive_timeout |
75s | 5–15s | 空闲连接堆积，连接池被蚕食 |
send_timeout |
60s | 10–30s | 慢读攻击拖住响应通道 |
reset_timedout_connection |
off | on | 超时连接不释放资源 |
需要说明的是,静态资源站点可以把keepalive_timeout压到5秒左右，而需要长轮询的API服务则应单独为特定location放宽，而不是全局调高，一刀切的高超时，是慢速攻击最喜欢的“懒政配置”。
哪些业务场景必须特殊对待
文件上传接口的client_body_timeout如果压到10秒，大文件传输会被误杀，正确做法是按location单独配置，并配合client_body_buffer_size和client_max_body_size做精细控制，同理，WebSocket长连接需要独立于普通HTTP请求的超时策略，用proxy_read_timeout单独管理，别让它污染全局的keepalive_timeout。
慢速HTTP攻击与超时设置的关系到底有多紧密
把慢速攻击想象成一场“占座游戏”：服务器是自习室，连接是座位，超时是保安清场的间隔，座位有限，攻击者每隔一会儿往桌上放一支笔，证明“我还在这儿”，保安清场间隔越长，空座位被假读者占得越久，超时设置就是清场间隔，设成300秒，等于告诉攻击者“你慢慢来”。
从协议层看,慢速攻击利用的是HTTP over TCP的“半开”状态，TCP连接建立后，服务器在等待完整请求期间必须保留该连接的状态信息socket、缓冲区、进程或线程资源，这个保留时长由超时参数决定，超时越长，单位攻击连接消耗的“资源×时间”乘积越大，攻击者只需要维持连接不断开，服务器自己就会把资源耗光。
实测中,一台默认client_header_timeout 60s的Nginx，面对每秒新建20个慢连接的攻击流，大约几分钟内活跃连接数就会逼近worker_connections上限，若把该值降到10秒，同样攻击强度下连接周转率提高数倍，攻击者必须成倍增加并发才能达到同样效果，成本立刻上去，防御慢速攻击，缩短超时是最便宜、最立竿见影的一环，比堆带宽清洗划算得多。
实操：把超时参数调成慢速攻击的“紧箍咒”
Nginx侧的关键配置路径
打开nginx.conf的http块，先收紧全局值，再对特殊路径做例外：
http {
client_header_timeout 10s;
client_body_timeout 12s;
keepalive_timeout 10s;
send_timeout 15s;
reset_timedout_connection on;
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 20;
limit_req_zone $binary_remote_addr zone=reqperip:10m rate=10r/s;
}
reset_timedout_connection on让超时连接直接发RST释放，而不是走完四次挥手，回收更快。limit_conn和limit_req是超时之外的二级闸门，单IP并发连接数和请求速率双限，慢速攻击源很快会被挡在门外，改完用nginx -t校验，再nginx -s reload平滑生效。
Apache与系统层的配合
Apache的Timeout指令默认60秒，建议压到15–30秒；KeepAliveTimeout设5–10秒并确认KeepAlive On，同时检查Linux的net.ipv4.tcp_fin_timeout（默认60秒）可适度调低到15–30秒，让FIN_WAIT状态更快回收，用ss -s或netstat -an | grep SYN_RECV | wc -l观察半开连接数量，调优前后对比一目了然。
验证是否生效
改完后用curl -v --limit-rate 1 http://你的域名/模拟慢速请求，观察连接在预期秒数内被服务端断开，再抓一次tcpdump看是否有RST包发出，生产环境建议先在预发环境跑一遍，确认大文件上传、视频拖拽等正常业务不受影响，再灰度上线。
别让超时配置成为攻击者的“帮凶”
慢速攻击的可怕之处在于它安静、廉价、难告警，超时设置过长则是这种攻击能够“赖着不走”的制度性漏洞，把超时压到业务可承受的下限，配合连接数和速率限制，才能在资源被拖垮之前把僵尸连接清出去，配置这件事没有一劳永逸，业务形态变了、流量结构变了，超时值就该跟着复核。
Q&A：服务器超时设置与慢速攻击防御常见疑问
问：超时设短了会不会误伤正常用户？
答：会，所以要按业务真实耗时来定，普通页面请求的头部传输通常在1秒内完成，10–15秒的client_header_timeout对正常用户绰绰有余，真正需要放宽的是大文件上传、长轮询和WebSocket，这些应通过独立location或独立server块单独配置，而不是把全局值拉高。
问：只调超时参数就能防住慢速攻击吗？
答：不够，但它是第一道也是成本最低的闸门，超时负责缩短单个连接的占用时长，limit_conn和limit_req负责限制单IP的连接与请求规模，两者叠加才能把攻击成本抬到攻击者不划算的水平，只调超时而不限并发，攻击者加大并发数仍可能压满连接池。
问：服务器超时设置过长导致慢速攻击得逞的典型表现是什么？
答：典型表现是CPU和带宽都不高，但新用户请求持续超时或无法建立连接，ss -s显示大量ESTABLISHED或CLOSE_WAIT连接，且来源IP分散、单连接流量极低，此时如果超时参数仍在60秒以上，基本可以判定慢速攻击正在利用超时宽容消耗连接资源。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/786590.html
