慢速攻击在抗CC场景里难以被识别，核心原因是它主动降低请求速率和连接频率，把自己伪装成正常业务访问，从而躲过大多数基于阈值和速率统计的防护规则。
普通CC攻击像一群人同时撞门,动静大、频率高，抗CC设备很容易抓到特征，慢速攻击不同，它像少数人靠在门上慢慢推，门不会响但一直被占用，一个连接可以挂几十秒甚至几分钟，每个请求的数据包发送极慢，服务器在等待完整请求时资源被消耗，下面从行为差异、检测盲区、价格能力和地域因素展开。
慢速CC攻击和普通CC攻击区别在哪
| 对比项 | 普通CC攻击 | 慢速CC攻击 |
|---|---|---|
| 请求频率 | 高，每秒几十到上千次 | 低，每秒不到一次 |
| 连接时长 | 短，请求完成即释放 | 长，单连接可保持数十秒至几分钟 |
| 带宽占用 | 可快速占满出口带宽 | 低，带宽曲线平稳 |
| 单IP特征 | 明显，请求密度高 | 不明显，分散且低频 |
| 资源消耗点 | 服务器CPU、带宽 | 服务器连接池、线程、内存 |
| 检测难度 | 较低，速率阈值即可触发 | 较高，需分析连接行为和传输速率 |
普通CC攻击依靠高频请求触发限速规则,但慢速攻击的每个连接请求量很小，传统基于“每分钟请求数”的规则几乎看不到异常，这是抗CC场景里最尴尬的地方攻击正在进行，但监控面板上一切正常。
抗CC场景下慢速攻击为什么能绕过常规规则
连接保持时长超过阈值但不触发告警
多数抗CC设备默认限制单IP连接数和请求速率,但对连接时长不敏感，慢速攻击利用HTTP协议允许客户端缓慢发送请求的特性，比如在HTTP头中每隔十几秒发送一个字节，或者使用慢速POST让服务器一直等待请求体，一个连接能挂很久，而连接数指标可能没超限，因为攻击者不会同时发起几千个连接，而是用少量连接长时间占用。
据OWASP公开资料显示,Slowloris这类慢速HTTP攻击工具通过建立大量半开连接，每个连接只发送不完整的请求头，就能耗尽服务器的并发连接池，这种攻击的流量速率极低，常规的速率统计完全失效。
请求频率低于限速基线
假设抗CC设备设置“单IP每秒超过50次请求即封禁”，普通CC攻击一进来就会触发，慢速攻击把频率降到每秒0.5次甚至更低，远低于阈值，但每个请求的数据包发送极慢，服务器为了接收完整请求会一直保持线程，攻击者用大量分散的IP各自发送低频请求，整体上服务器连接池被逐渐填满，而单个IP没有任何异常。
源IP分布广泛且无明显聚集特征
慢速攻击常通过代理、肉鸡或云函数分散来源，单个IP的请求量小、间隔长，传统基于IP黑名单和速率统计的规则很难命中，因为攻击IP和正常用户在数值上几乎没有区别，北京这样的大型机房每天有海量正常访问，攻击流量混在其中，更难区分。
抗CC慢速攻击检测方法为何更容易失效
基于固定阈值的速率检测失效
速率检测的核心逻辑是“超过一定频率就判定异常”，慢速攻击的频率远低于正常用户的点击速度，固定阈值无法覆盖，把阈值调低又会导致大量正常用户被误封，这是所有抗CC场景面临的共同难题。
基于连接数的检测被长连接拖垮
抗CC设备通常限制单IP最大并发连接数,比如每个IP最多50个并发，慢速攻击者不追求高并发，而是用20个连接每个保持10分钟，连接数指标始终在限制之内，但服务器侧的可用连接资源已经被消耗，这种攻击方式混淆了“连接数”和“有效连接资源”两个概念。
基于行为分析的模型训练数据不足
行业共识认为,慢速攻击样本远少于普通CC攻击样本，导致有监督学习模型的识别率不高，正常用户的慢速访问可能因为网络状况差，攻击者的慢速访问则是有意控制节奏，两者在特征空间里有较大重叠，行为分析需要长时间会话级数据，而很多抗CC服务只保存分钟级聚合数据，缺乏细粒度支撑。
抗CC服务价格差异是否决定慢速攻击识别上限
抗CC服务价格从低到高,能力分层明显，低价位服务通常只提供基础的IP速率限制和黑名单，对慢速攻击基本无效，中高价位方案会增加深度包检测、连接状态机和会话行为基线，能把慢连接超时压到很短。
基础版抗CC服务常见策略
- 基于单IP请求速率限制
- 基于URL访问频率限制
- 基于User-Agent和Referer黑名单
- 固定连接超时时间
这些策略对普通CC攻击有效,但对慢速攻击无效，因为攻击者可以完美匹配所有静态规则。
进阶版抗CC服务的关键能力
- 慢连接超时动态调整：如果客户端10秒内未发完请求头，直接断开
- 请求体传输最小速率限制：每秒低于500字节就断开
- 会话级行为基线：学习正常用户的请求间隔和连接时长分布
- 连接状态机检测：识别半开连接、慢速POST、慢速读取响应等异常状态
价格差异决定了是否具备会话级检测能力,部署在北京等核心节点的抗CC服务，由于正常流量基数大，对检测精度的要求更高，低价方案更容易被慢速攻击穿透。
北京机房抗CC场景下慢速攻击更难被识别的具体原因
北京作为国内骨干网核心节点,数据中心密集，金融、政务、互联网企业集中，正常业务流量本身就包含大量慢速访问，比如视频上传、文件同步、API轮询，慢速攻击者会刻意模仿这些业务特征，把攻击流量混入合法流量中。
从运维角度看,北京机房的出口带宽大、连接数高，慢速攻击造成的资源消耗不会立即表现为带宽告警，当服务器响应变慢时，最先被怀疑的是业务代码问题，而不是攻击，这种延迟发现的过程给了攻击者更长的持续攻击窗口。
北京地区的抗CC服务部署密度高,不同服务商之间的策略差异大，部分客户为了节省成本选择基础版方案，面对慢速攻击时几乎无感知，另一个因素是地域风控：攻击者常选择北京节点发起攻击，因为本地正常流量大，基于地域的访问频次统计更难建立精确基线。
实操：如何在抗CC设备上手动配置慢速攻击检测
Nginx层参数调整
在http或server块中加入以下配置：
client_header_timeout 10s;
client_body_timeout 10s;
send_timeout 10s;
keepalive_timeout 30s;将头部和请求体读取超时从默认的60秒压缩到10秒,可以加快释放被慢速占用的连接，再配合请求速率限制：
limit_req_zone $binary_remote_addr zone=slow_limit:10m rate=1r/s;
limit_req zone=slow_limit burst=3 nodelay;这里rate=1r/s表示单IP每秒最多1个请求，超出部分立即拒绝，虽然是速率限制，但把突发容忍设为burst=3可以拦截短时突发，对慢速攻击也有一定压制。
Apache层参数调整
编辑httpd.conf或虚拟主机配置：
Timeout 60
RequestReadTimeout header=5-10,MinRate=500 body=10-20,MinRate=500
MinRate=500表示每秒最少接收500字节，低于这个速率持续超过设定时间就直接断开，这个参数专门针对慢速POST和慢速头攻击。
在WAF上配置会话速率规则
- 设置“单个会话超过30秒且请求数少于5次”触发断开或验证码
- 对“传输中数据包间隔超过10秒”的连接进行标记
- 启用“慢速HTTP攻击防护”模块，设置请求头最小接收速率
抓包辅助验证
用tcpdump抓取一个慢速连接的完整过程：
tcpdump -i eth0 'tcp[13] & 2 != 0' -s0 -w slow_http.pcap
然后使用Wireshark过滤tcp.stream eq 0，观察该连接的时序，如果出现大量ACK但数据负载很少，且间隔超过10秒，基本可判定为慢速攻击，确认后把该特征反写进WAF规则即可持续防护。
手动配置只能解决部分问题,慢速攻击的变种很多，攻击者会调整超时时间和传输速率来绕过固定参数，更可靠的做法是把超时压缩、最小速率限制和会话行为基线配合使用，让检测不再依赖单一指标。
Q&A：慢速攻击在抗CC场景中为什么难识别及检测方法常见问题
慢速攻击在抗CC场景中为什么比大流量攻击更难识别？
大流量攻击特征明显,带宽和包速率瞬间飙升，防护设备容易在数秒内触发告警，慢速攻击流量平稳、请求间隔长，与正常用户行为高度相似，多数防护系统在发现异常前连接已被耗尽，它攻击的是服务器的连接管理机制，而不是带宽资源。
抗CC慢速攻击检测方法有哪些常见组合？
主要有三种组合：一是超时压缩加最小速率限制，直接切断慢速连接；二是会话行为基线，对比正常用户的请求间隔和连接时长；三是连接状态机检测，识别半开连接、慢速POST等异常状态，实践中通常先启用前两种作为基础策略，再视情况引入状态机分析，WAF设备里一般能找到对应的模块开关。
北京地区部署抗CC服务后如何验证慢速攻击是否被拦截？
可以使用curl的--limit-rate参数模拟低速上传请求：
curl --limit-rate 100K -X POST -d "data=slow" http://目标域名/test
如果连接在10秒内被服务器主动关闭,说明最小速率规则已生效，若连接保持超过30秒仍未被断开，需要检查超时参数和WAF策略是否正确加载。