慢速HTTP攻击之所以难被传统限速策略识别，核心在于它模仿的是正常用户的“慢动作”，而限速策略只盯着“单位时间频率”看，恰好抓不住这种以极低速率长时间占用连接的攻击方式。
传统限速到底在限什么：速率视角的盲区
大多数网站部署的限速策略,本质上是在回答一个问题：“同一个用户，单位时间内能来多少次”，无论是基于Nginx的limit_req模块，还是CDN厂商的“频次防护”，它们默认的逻辑都是“次数多了就可能是攻击”。
这种思路对付CC攻击、暴力破解确实有效，因为那些攻击的特征就是高频次，但慢速HTTP攻击从诞生那天起，就在刻意绕过这个逻辑。
打个比方,一个正常的访客走进营业厅，办完业务就走，保安一眼就能看出谁在门口反复进出，但慢速攻击者是什么样呢？他走进营业厅，啥也不办，就站在柜台前，不动，也不走，偶尔喘口气，每隔几分钟才说半句话，保安的规则是“有人频繁进出就拦”，但这个人不频繁、不闹腾，只占着位置，保安就彻底没辙了。
一个典型对比：高频攻击与慢速攻击的行为画像
| 维度 | 高频CC攻击 | 慢速HTTP攻击 |
|---|---|---|
| 请求频率 | 每秒几十到上百次 | 每秒甚至每几秒一次 |
| 连接占时 | 秒级释放 | 数分钟到数小时 |
| 占用资源 | CPU、带宽、数据库连接 | 连接池、线程池、内存 |
| 传统限速识别 | 立即触发阈值 | 完全处于阈值之下 |
| 对业务的影响 | 页面加载失败、接口超时 | 服务器无响应，但日志看起来很“正常” |
行业共识认为,相当一部分企业遭遇网站“莫名其妙打不开，重启就好”的怪象，本质上就是慢速攻击打满了连接池，但运维人员翻遍访问日志也看不出异常，因为每个IP的请求量都低得可怜。
慢速HTTP攻击的三副面孔：它如何把“慢”伪装成“正常”
要理解限速策略为什么失灵,就得知道慢速攻击的三种主流玩法，它们各自攻击的协议缺陷不同，但共同点都是：不追求速度，追求时长。
慢速请求头：用一句“半截话”占住线程
最常见的是Slowloris攻击,攻击者向服务器发一个HTTP GET请求，把请求头发送一半就停住，比如发了GET / HTTP/1.1\r\nHost: example.com\r\n然后就沉默了，服务器在等后续的\r\n\r\n结束标记，这个连接就一直挂在等待队列里。
Apache和旧版Nginx默认的Timeout参数通常是300秒，也就是说一个连接可以“干等”5分钟不释放，攻击者只需要开几百个这样的半截连接，就能把服务器的空闲线程全部占满，新用户访问网站时，服务器已经没有空闲线程去响应了。
对于限速模块来说，这只是一次“浏览行为”。 一次请求，速率极低，完全合法。
慢速请求体：用“挤牙膏”的方式发POST数据
Slow POST攻击更隐蔽，攻击者正常发起一个POST请求，在请求头里声明Content-Length: 10000，表示“我要发10KB的数据”，然后真的开始发送，但发送速度是每10秒发1个字节。
服务器会傻乎乎地等程序逻辑告诉它“数据还没传完，连接不能释放”，一个连接占住一个线程或一个Worker进程，攻击者开几百个这样的连接，服务器很快就“累死”了。
这里有个很讽刺的点：传统限速策略恰好会认为是“慢速用户”而放行。 比如有些限速规则是“超过10秒没后续流量就断开”，慢速攻击者每隔8秒发一个字节，完美避开断连规则。
慢速读取：把服务器的响应“晾”在那里
Slow Read攻击则是反过来的，攻击者正常发起请求，服务器正常返回数据，但攻击者故意把TCP窗口设置得很小，比如窗口大小只有1个字节，导致服务器发出来的数据包，客户端只确认一点点，剩下的全堵在服务器发送缓冲区里。
服务器不能把连接关掉,因为数据没发完；也不能把缓冲区的数据丢弃，攻击者同时开上千个这样的连接，服务器的内存和带宽就会被耗尽，这种攻击的伪装性最强，因为从服务器日志看，请求是完整的、响应也成功发出去了，完全看不出异常。
限速策略的三个结构缺陷：为什么越聪明越抓瞎
不少团队在吃过亏之后,会给限速策略打补丁，单IP同时最大连接数”，这确实能缓解部分慢速攻击，但攻击者很快就进化了，核心缺陷有以下三点：
只看“数量”，不看“占时”
传统限速的维度是“每分钟请求数”，慢速攻击的维度是“每连接占用时长”，两个维度不匹配，就像用体重秤去量身高，工具本身就不对。
举个例子,攻击者用1000个IP，每个IP只发2个请求，每个请求占5分钟，从限速策略看，这1000个IP的请求量比正常用户还低正常用户一分钟可能刷新10次页面，但服务器的连接池已经爆了。
动态指纹识别失效于“慢吞吞”的行为
现在的WAF和CDN防护通常带有行为分析能力,比如检测“请求间隔是否规律、User-Agent是否可疑、Cookie是否有效”，但慢速攻击的工具是开源的，攻击者可以完全模拟真实浏览器的请求头、Cookie甚至鼠标轨迹。
识别“程序化高频”容易，识别“程序化极低速”极难。 一个正常用户看着网页发呆30秒不滚动，和攻击者故意停30秒再发半个请求，在行为特征上几乎没有差异。
限速阈值的“宽松配置”给了可乘之机
不少网站的限速阈值设置得很宽,比如limit_req zone=perip burst=20 nodelay，允许单IP每秒20个请求的突发流量，这么设置是为了防止误伤真实用户，但慢速攻击本来就远低于这个阈值。
近年来的实际攻防案例中,攻击者甚至专门扫描网站的限速配置，找出那些“单IP并发连接数”没限制或者限制得很高的站点，然后针对性地发起慢速攻击，这就出现了尴尬局面：攻击者最害怕的是“连接数总量严格限制”和“极端超时时间”，而不是限速。 网站面对的不少“打不开”故障，源于限速配置在慢速攻击面前等同虚设，真正起作用的还是连接数上限和超时断开。
慢速攻击能检测吗：三个实操方向
既然传统限速不靠谱,那业界是怎么做的？这里给出三个已经被验证的实操方案，不需要AI识别，普通运维就能落地。
第一道防线：修改协议层超时参数
最立竿见影的防守是缩短“等待时间”，以Nginx为例，默认配置下client_header_timeout是60秒，client_body_timeout也是60秒，这意味着攻击者有1分钟的时间可以“挤牙膏”。
调参建议：
- 将
client_header_timeout调整为10秒，超过10秒没收到完整的请求头就断开连接 - 将
client_body_timeout调整为15秒，POST数据发送间隔超过15秒就释放连接 - 将
keepalive_timeout调整为20秒以内，减少空闲连接占用的Worker进程
这个方案会误伤少数网络差的用户吗？会，但实际影响远小于服务器宕机的代价，绝大多数正常用户能在3秒内完成请求头的发送，10秒的阈值其实已经非常宽松了。
第二道防线：连接数量和速率的双重锁
在保持“速率限制”的同时，增加“单IP并发连接数”的限制，Linux服务器上常用iptables或nginx的limit_conn模块实现。
Nginx配置示例：
limit_conn_zone $binary_remote_addr zone=perip:10m;
server {
listen 80;
limit_conn perip 10;
limit_conn_zone $server_name zone=perserver:10m;
limit_conn perserver 100;
}这段配置意味着单IP最大并发连接数是10个,正常用户开网页加资源加载，一般会占用2-6个并发连接，10个够用，但攻击者想用50个连接占满线程池，就得至少分配50个IP，成本陡然上升。
第三道防线：语义层检测
最高级的方案是让防护系统去读请求内容,比如检测请求头是否包含合法的Accept、Referer、Accept-Language字段；检测POST请求的主体是否在声明了Content-Length之后真的按合理速率发送。
业内专家指出,OWASP的Web应用测试指南中，慢速HTTP攻击的检测建议就是监控“连接持续时间”和“连接数据量的比率”，这个比率明显偏低时，即便请求频率很低，也应当标记为可疑。
搜索引擎优化视角：为什么你的网站需要关注这类攻击
从百度GEO的角度看,慢速HTTP攻击对排名的影响是间接但致命的，百度爬虫本质上也面临和普通用户一样的“连接被占满”问题，如果爬虫连续多次抓取你的网站时遇到超时或拒绝连接，百度会认为该网站不稳定，从而降低抓取频次，甚至把网站移出快速收录池。
据工信部近年来的安全通报,针对中小型网站的慢速攻击占比呈明显上升趋势，攻击者选中小网站的原因很简单大站有专业防护，小站只有基础限速配置，打起来“性价比高”。
对于使用便宜虚拟主机或入门级云服务器的网站来说,慢速攻击可以让一台4核8G的服务器在10分钟内彻底卡死，而传统限速策略配置得再精密，也无法识别“一个连接持续占用5分钟”的异常，因为限速维度里根本没有“占时”这个指标。
关键词部署建议：
- 如果你的网站经常出现“服务器响应慢但找不到原因”的情况，优先排查连接数是否被打满
- 搜索“慢速HTTP攻击防御方案”时，优先看那些提供了连接数限制和超时调优具体配置的文章
- 咨询“网站防攻击价格”时，确认服务商是否支持语义层检测，而不只是频率限制
百度站长平台自查清单
- 在百度搜索资源平台查看“抓取异常”数据，如果出现大量“抓取超时”记录，而服务器CPU、带宽指标正常，高度怀疑是慢速攻击
- 将服务器日志导出,统计每个IP的“连接时长分布”，正常用户95%以上的连接在5秒内结束，如果发现大量连接超过60秒且请求量稀少，就是攻击特征
- 检查百度收录量的走势,如果收录量持续下降但网站内容正常更新，防护策略需要从“限速”向“限时长、限并发”升级
Q&A：慢速HTTP攻击常见的三个疑问
慢速HTTP攻击用什么工具检测最有效？
实时的抓包分析最直观,用tcpdump -i eth0 port 80观察抓到的包，如果看到一个IP反复发送半截TCP报文或者数据包之间间隔时间极长，就可以初步判定，配合Nginx的ngx_http_stub_status_module模块查看Active Connections数量，如果活跃连接数远超日常基线，但请求数并没有增加，基本可以坐实是慢速攻击。
开启了CDN就能彻底防住慢速攻击吗？
不能,CDN能解决一部分带宽消耗型攻击，但慢速攻击是针对源站应用层连接池的攻击，如果攻击者获取了源站IP，直接绕过CDN打源站，CDN形同虚设，即便是CDN转发请求，源站和CDN之间的回源连接依然可能被慢速攻击占用，正确地做法是CDN和源站双重设置超时参数，并且源站只允许CDN的回源IP访问。
网站配置了限速策略为什么还是被慢速攻击拖垮？
因为限速策略的默认维度是“单位时间请求次数”，而慢速攻击的杀伤力来自“单连接长时间占用”，一个IP每秒只发0.1个请求，完全触发不了任何限速规则，但100个这样的IP就能占满200个Worker进程，限速策略的“速率”判定逻辑彻底分析不出这种威胁，防护的着眼点应当放在连接时长和连接总数维度上。
慢速HTTP攻击的本质,是攻击者利用协议的“容错机制”反向消耗服务器资源，防住它，靠的不是更聪明的限速算法，而是回归两个基础指标：连接能占多久，连接能有多少，把这两条线收紧，攻击者伪装得再像正常用户，也无处遁形。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/787787.html
