慢速HTTP攻击难被传统限速策略识别的根本原因只有一个：它攻击的不是带宽和请求速率，而是连接资源与超时机制，传统限速盯着“每秒请求数”和“流量峰值”，慢速攻击却用极低速率、超长连接、不完整请求慢慢耗死服务器。
慢速HTTP攻击和CC攻击有什么区别？别再只看流量大小
很多运维第一次遇到慢速HTTP攻击时,会误判成CC攻击或者误以为服务器配置不够，两者在流量模型上完全不同。
CC攻击的流量特征
- 短时间内发起大量完整HTTP请求
- 请求频率高,单IP可能在几秒内打出数百次请求
- 带宽占用明显上升,CPU和内存飙升
- 日志中会出现海量200或502状态码
慢速HTTP攻击的流量特征
- 每个连接只发送不完整的请求头或请求体
- 每隔几秒甚至十几秒才发送一个字节
- 带宽占用极低,CPU无明显波动
- 连接数缓慢上升,但长时间不释放
用一句话总结：CC攻击是“一群人在门口疯狂敲门”，慢速HTTP攻击是“一群人进入大厅后站着不动，也不说来意，把通道全部占满”。
传统限速策略默认在防CC，不是防慢速
传统限速模块通常配置如下规则：
- 单IP每秒请求数超过阈值就封禁
- 单IP并发连接数超过阈值就拒绝
- 总带宽超过阈值就启用清洗
慢速HTTP攻击完美绕开这些规则,它每秒请求数极低，单IP连接数可能只有几十个，带宽更是几乎为零，传统策略看不到异常，因为异常发生在时间维度和请求完整度上，而不是瞬时速率上。
为什么慢速HTTP攻击怎么防护总是失效？传统限速的四个盲区
慢速HTTP攻击怎么防护总失效,根本原因不在工具不够贵，而在防护模型本身存在盲区。
限速只看瞬时速率，不看连接持续时间
绝大多数限速算法计算的是“每秒请求数”或“每秒字节数”，一个连接持续10分钟，每20秒发一个字节，平均速率低到可以忽略不计，如果封禁阈值是单IP每秒超过50个请求，这种攻击每个连接的“请求速率”几乎等于0，永远不会触发规则。
连接数阈值设得太高，单IP限制形同虚设
Nginx默认的worker_connections通常为1024或更高,Apache默认MaxRequestWorkers也有数百，慢速攻击者从多个IP各开几十个连接，单IP连接数可能只有20个，远低于单IP并发限制，但几百个IP加起来，很快占满服务器全局连接数。
业内专家指出，多数运维只关注单IP并发，却忽略了全局空闲连接超时和最小传输速率，这恰好是慢速攻击最爱的缝隙。
限速策略基于完整请求，慢速请求根本不被计数
WAF和部分限速模块有一个共同逻辑：只有收到完整HTTP请求头后，才进入规则匹配和计数，慢速攻击发送的是不完整请求头，WAF认为请求尚未到达，直接不处理，于是攻击流量在应用层“隐身”了。
超时时间过长，计时器被反复重置
Nginx默认的client_header_timeout可能是60秒或更长,Apache的Timeout默认也是60秒，慢速攻击者只要在超时前发送一个字节，计时器立即重置，传统策略检查的是“有没有超时”，而不是“每秒至少收到多少字节”，这正是慢速HTTP攻击难被传统限速策略识别的核心矛盾。
网站打开慢是不是慢速HTTP攻击？用三个命令快速判断
网站打开慢不一定是慢速HTTP攻击,但如果你观察到连接数异常、请求头不完整、数据包间隔规律，就要高度怀疑。
第一步：查看连接状态分布
在服务器上执行：
netstat -an | awk '{print $6}' | sort | uniq -c | sort -nr如果出现大量ESTABLISHED且数量接近上限,同时流量并不高，就要继续排查。
第二步：统计单IP占用连接数
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20如果某些IP连接数不算特别高,但整体连接总数异常，说明攻击者可能使用了分布式慢速攻击。
第三步：抓取一个可疑连接观察数据包间隔
tcpdump -i eth0 host 可疑IP -nn -vv -c 100观察是否每隔几秒才收到几个字节,并且HTTP请求头始终不完整，例如一直停留在“GET / HTTP/1.1”后缺少空行。
和正常网站打开慢的场景对比
正常网站打开慢常见原因包括：
- 数据库慢查询,响应时间长达数秒
- CDN回源不稳定,静态资源加载慢
- 带宽跑满,下载速度下降
- 后端应用死锁,连接无法释放
慢速HTTP攻击的特征则是：
- 请求头或请求体不完整
- 连接数持续增长且不释放
- 数据传输速率极低但有规律
- 日志中极少出现完整请求记录
如果你在北京服务器上排查时发现连接数缓慢上涨、带宽却一直平稳，建议优先怀疑慢速HTTP攻击，而不是急着升级带宽。
高防IP价格能防慢速攻击吗？选型时先看这几个参数
很多站长遇到攻击后会问：高防IP价格贵的就能防慢速攻击吗？答案是不一定。
高价高防不等于慢速清洗
多数高防IP按大流量DDoS攻击计费,清洗设备主要处理SYN Flood、UDP Flood、CC攻击等，慢速HTTP攻击的流量极小，可能只有几十KB级别，抗D设备默认不会触发清洗策略，结果就是你花了高防IP的价格，慢速攻击依然能穿透。
选型必须确认的四个能力
- 是否支持L7层慢速连接检测,能识别不完整请求头
- 是否允许自定义最小接收速率,例如每秒最少500字节，低于则断开
- 是否支持连接超时时间配置,例如5秒内没有完成请求头就断开
- 是否提供全局连接数限制,按域名或源站连接数硬限制
地域部署与防护效果
北京服务器遭遇慢速HTTP攻击时,建议选择在北京及周边有节点的高防服务，地域近可以减少清洗回源延迟，但地域本身不决定防护能力，真正起作用的是服务商在L7层是否配置了慢速检测规则，行业共识认为，慢速HTTP攻击的防护必须放在应用层会话管理上，而不是依赖大流量清洗设备。
实操：从配置层缓解慢速HTTP攻击
防护慢速HTTP攻击的核心思路只有两条：缩短超时时间和设置最小传输速率。
Nginx配置调整
在http块或server块中写入：
client_header_timeout 5s;
client_body_timeout 10s;
client_max_body_size 10m;
limit_conn_zone $binary_remote_addr zone=perip:10m;
limit_conn perip 10;说明：
- client_header_timeout 表示服务器读取客户端请求头的超时时间，慢速攻击每隔几秒发一个字节，超过5秒未完成请求头就会断开。
- client_body_timeout 控制请求体读取超时，可适当放宽到10秒，避免影响正常文件上传。
- limit_conn 限制单IP并发连接数，建议根据业务实际调整。
Apache配置调整
Apache需要启用mod_reqtimeout模块,配置示例：
RequestReadTimeout header=5-10,MinRate=500 body=10-20,MinRate=500含义：读取请求头阶段，超过5到10秒且接收速率低于500字节/秒就断开；读取请求体阶段同样限制。
使用反向代理做第一道过滤
在源站前面部署Nginx或OpenResty,只允许完整请求头进入后端，对不完整请求头直接返回444或断开连接：
server {
listen 80;
client_header_timeout 3s;
client_body_timeout 3s;
limit_conn_zone $binary_remote_addr zone=conn_limit:10m;
limit_conn conn_limit 5;
location / {
proxy_pass http://backend;
}
}这样慢速攻击连接在3秒内无法完成请求头,就会被直接断开。
监控与临时封禁
定期执行以下命令查看可疑IP：
netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head如果确认某个IP在进行慢速攻击,可临时用iptables封禁：
iptables -A INPUT -s 攻击IP -j DROP但要注意,分布式慢速攻击的IP较多，逐个封禁效率低，最终还是要靠应用层超时和速率限制。
慢速HTTP攻击的防护重点不在流量，而在时间
传统限速策略之所以看不见慢速HTTP攻击,是因为它把“异常”定义为“流量太大、请求太快”，慢速HTTP攻击恰好反过来，用极小流量、极慢速度、极长连接制造资源耗尽，只要连接超时和最小接收速率没有在应用层强制生效，任何昂贵的防护设备都可能被这类攻击绕过，真正有效的防护，是把“每秒至少收到多少字节”和“请求头必须在几秒内完成”焊死在服务器配置里。
Q&A
慢速HTTP攻击难被传统限速策略识别的原因是什么？
传统限速策略基于瞬时速率、带宽峰值和完整请求计数，慢速HTTP攻击以不完整请求头、超长连接、极低数据传输速率的方式，绕开了这些检测维度，它不是没有流量，而是流量小到低于阈值、时间长到超过常规超时，传统策略在时间维度和请求完整度上没有布防。
慢速HTTP攻击怎么防护才能有效？
有效防护需要同时做到三点：缩短请求头和请求体的超时时间，例如Nginx配置client_header_timeout为5秒；设置最小接收速率，低于阈值就断开；限制单IP并发连接数和全局空闲连接数，将这些配置放在应用层，而不是依赖大流量清洗设备。
高防IP能防慢速HTTP攻击吗？
不一定,高防IP主要针对大流量DDoS攻击，慢速HTTP攻击流量极小，默认清洗策略不触发，需要确认服务商是否支持L7慢速连接检测，并测试其能否对不完整请求头主动断连，防护能力取决于L7规则配置，而不是高防IP价格本身。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/637351.html
