慢速CC攻击之所以难识别，是因为它把“攻击”伪装成了“正常访问”：利用极低的请求速率和真实的浏览器行为，绕过传统阈值检测，让防护设备误以为是一群手速慢的真实用户。
慢速CC攻击识别难点在哪里
慢速CC攻击,本质上是把“量”的堆叠换成“时间”的消耗，攻击者控制少量肉鸡或一台云主机，对目标服务器发送HTTP请求，但连接建立后不急着发完数据，或者发一小部分就停住，把服务器的连接池、线程池占满，由于单看每个连接都极其正常，传统WAF和防火墙的“每秒请求数”阈值完全失效。
流量特征与正常用户几乎重合
普通DDoS是洪流,每秒成千上万个包，特征一眼可见，慢速CC则是涓涓细流，每个IP的请求频率可能只有每5秒一次，甚至更低，互联网上真实用户的操作行为，比如阅读文章、填写表单、观看视频，其产生的请求间隔与慢速CC攻击几乎重合，行业共识认为，纯粹依赖速率阈值的防护方案，对慢速CC的检出率相当低，误报率反而居高不下。
连接维持时间异常被“正常业务”掩盖
慢速CC攻击单条TCP连接可以存活数分钟到数十分钟,此时服务器会一直为它分配文件描述符和内存缓冲区，如果网站有长轮询、WebSocket或大文件上传等业务场景，“连接时间中位数偏长”这个特征也会被混淆，管理员打开netstat -an，看到的是一大堆ESTABLISHED状态的连接，无法快速区分哪个是正常用户，哪个是攻击者。
攻击源IP分散且轮换频繁
现代慢速CC攻击很少用固定IP,攻击者倾向于使用代理池、住宅IP池或定时更换源IP的Botnet，即使你封禁了当前的一批IP，下一波攻击会立刻换上新IP，单纯依赖IP黑名单，实际上是“打地鼠”，疲于奔命且护不住核心业务。
慢速CC攻击的识别思路：从源头特征反向排查
既然不能只看速率,就得换思路，慢速CC攻击有一个绕不开的死穴：它必须维持连接并持续发送数据，否则无法消耗资源，这就导致它在连接行为和数据包特征上存在逻辑漏洞。
关注“请求不完整”的比例
正常浏览器访问网页,会一次性发送完整的HTTP请求头（含UA、Accept、Cookie等），慢速CC攻击的典型做法是发送GET / HTTP/1.1之后，故意不发送Host头，或者只发送一半的请求头，然后停住等待，这种畸形半开连接在正常业务流量中比例极低。
实操中,可以在Nginx或LB层记录所有未发送完整请求头的连接数，如果此类连接在总连接数中占比超过一定基线（比如常态下是1%，攻击时可能飙升到30%以上），基本可以判断正在遭受慢速CC攻击，这个基线的设定建议以最近7天的业务流量为参考，不需要精确计算，多观察几天就能看出规律。
用“平均请求速率”替代“峰值请求速率”
传统CC攻击的识别看瞬时QPS,慢速CC攻击则要看单位时间（60秒或300秒）内每个IP的累计请求次数，例如用户每10秒发一次请求，一分钟就是6次，如果某个IP在一分钟内发起了超过10次请求，即使每次速率都不高，它依然比正常用户更可疑，更有效的做法是计算同一IP的请求间隔方差真实用户点击有停顿、有思考，间隔值波动大；慢速攻击的请求间隔往往是固定值（如每隔4秒一次），方差极小。
慢速CC攻击处置办法：四层渐进式治理
识别到攻击后,处置顺序很重要，不建议一上来就封IP，误伤太大，按以下层级渐进式操作，能把业务影响降到最低。
第一层：连接层快速过滤（秒级生效）
- 在Nginx的
http块中调整client_header_timeout和client_body_timeout，建议从默认的60秒缩短到10秒，慢速攻击的连接通常在10秒内发不完数据，会被主动断开，而正常用户几乎不会卡在发送请求头这一步超过10秒。 - 配置
limit_conn_zone限制单IP连接数，例如每个IP最多同时保持50个连接，这里需要注意，如果公司出口IP是NAT，会把很多真实用户挤到一个IP上，限制值应适当放宽到200以上，或对内网IP段单独放行。 - 启用
limit_req_zone限制单IP每秒请求数，但速率阈值要给到正常峰值流量的2-3倍，避免误杀。
此层操作对基于TCP协议的慢速CC（如Slowloris）非常有效，配置后观察5分钟，若ESTABLISHED连接数明显回落，说明攻击被压制。
第二层：协议层智能校验（分钟级生效）
如果连接层过滤后,连接数依然高居不下，说明攻击可能已经模拟了完整的HTTP请求，此时需要引入协议校验逻辑，推荐使用开源工具或云WAF的“协议完整性检查”功能。
- 校验请求头是否包含必要的
Host、User-Agent、Accept-Language字段，缺失率超过30%直接拉黑。 - 对同一IP发起的请求,校验其
User-Agent是否在短时间内频繁变化，正常用户不会每秒钟切换UA，攻击工具却经常随机生成UA。 - 校验TCP窗口大小,部分老式攻击工具使用固定的TCP窗口值，与真实操作系统的动态窗口调整策略不一致，这类特征可以作为评分项加入黑名单判定逻辑。
此阶段建议配合Nginx的access_log分析脚本，提取请求头字段做统计，确认攻击指纹后再动规则，避免误封搜索引擎爬虫或支付回调。
第三层：应用层人机识别（半小时级生效）
对于前两层仍未能拦截的高级慢速攻击,需要引入JS挑战或Cookie验证，原理很简单：发送一段JavaScript到客户端，执行后生成动态Cookie，下次请求带上Cookie才被放行，真实浏览器会自动执行JS，而绝大多数攻击工具基于HTTP库编写，不执行JS。
- 优先对所有可疑IP启用JS挑战,而非全站启用，降低对GEO爬虫的影响。
- 百度、谷歌的爬虫不执行JS，因此需要将搜索引擎官方IP段加入白名单，避免网站从搜索结果中消失。
如果业务涉及APP或API接口,JS挑战不适用，可改用“客户端证书校验”或“设备指纹采集”，实现成本稍高，但防护效果更持久。
第四层：长效防护策略配置
处置完成后,建议开启基于行为分析的防护模式，相比前面几层的被动防御，行为分析能主动捕捉慢速CC攻击的微小异常，直角坐标法下效果更直观，具体配置分以下几步：
- 设定网站的“正常访问图基线”，包括访问路径长度、停留时长、页面深度，比如正常用户通常访问2-5个页面然后离开，攻击者可能只在某个特定URL（如登录接口）反复徘徊。
- 对非正常路径的访问触发验证码或跳转至减速页面。
- 持续调整基线,每两个星期更新一次，让防御策略跟上业务变化。
慢速CC攻击与普通CC攻击区别对比
| 对比维度 | 慢速CC攻击 | 普通CC攻击 | 大流量DDoS攻击 |
|---|---|---|---|
| 请求速率 | 极低，单个IP每分钟1-10次 | 较高，单个IP每秒数十次 | 极高，每秒百万级请求 |
| 单条连接持续时间 | 非常长，可达几分钟到几十分钟 | 短，请求完即断开 | 短，高频并发 |
| 流量占用 | 很小，几乎不占带宽 | 中等，可能占用几百Mbps | 极大，轻松打满Gbps级带宽 |
| 防护设备识别难度 | 极高，特征与正常用户几乎一致 | 中等，速率特征明显 | 低，流量特征一目了然 |
| 主要攻击目标 | 服务器连接池、线程池、数据库连接数 | 业务API、查询接口、搜索接口 | 整个网络链路、机房带宽 |
从表中可以看出,慢速CC攻击主要消耗的是服务器的“并发处理能力”，而非带宽资源，多数情况下，服务器CPU和内存使用率不高，但网站表现非常卡顿，这正是“服务资源耗尽”的典型特征。
慢速CC攻击防护方案选型与成本考量
了解识别和处置方法后,选购防护方案时心里就有底了，这里整理几个选型思路：
- 如果是自建机房的单机或小集群,优先使用开源方案（Nginx + Fail2Ban + ModSecurity），成本只有服务器维护费用，但需要有一定技术能力进行调优。
- 如果业务部署在云上,可以开启云WAF的“Bot管理”模块，简米云、酷番云的WAF都支持自定义Bot策略，设置专用检测模板针对慢速连接，开通费用按QPS计费，具体可以咨询云厂商的价格页面。
- 如果对可用性要求极高（如支付、竞价类业务），建议使用高防IP + 源站前置WAF的组合，虽然防护成本高一些，但能避免攻击穿透多层防护导致业务挂掉。
业内专家指出,企业选择防护方案时最大的误区是只看带宽防御能力，而忽略了应用层的连接防护能力，一个100Gbps的高防包，如果处理不了慢速连接耗尽，依然是摆设。
慢速CC攻击的未来趋势与应对
近年来,慢速CC攻击开始借助AI工具生成动态请求负载，请求间隔趋于随机化，与真实用户行为差异进一步缩小，HTTP/2的多路复用特性，也被利用来在一个TCP连接中挂载多个慢速流，使得连接数维度上的检测也面临失效，应对这个趋势，需要将识别重心前移到语义层分析请求路径的组合是否合理，以及访问行为是否符合业务逻辑，防御慢速CC攻击，本质是一场欺骗与反欺骗的博弈，唯一不变的原则是理解每一行访问日志背后的业务意图，而非数字本身。
关于慢速cc攻击识别与处置的常见疑问
Q：慢速CC攻击和DDoS攻击有什么区别？
A：两者最直接的区别在于资源消耗类型，DDoS攻击消耗的是带宽和SYN队列，通向服务器的路被堵死；CC攻击消耗的是应用连接和执行资源，路是通的但服务窗口被占满，慢速CC攻击作为CC攻击的变种，进一步隐藏了流量特征，让攻击看起来更像正常访客的犹豫不决。
Q：云厂商的CC防护服务值得购买吗？
A：对于有明确业务收入或对可用性有要求的站点，值得，云厂商的防护池优势在于带宽规模巨大，且WAF规则库会实时同步全网攻击样本，比自建规则库更新更快，但需要注意，购买前务必确认防护套餐中是否包含“连接数防护”和“慢速攻击检测”能力，有部分便宜套餐只防御大流量DDoS，对慢速CC毫无办法。
Q：如何验证防护策略是否真的有效？
A：在做处置前，先记录攻击状态下服务器的ESTABLISHED连接数、CPU占用率和请求平均响应时间三个指标，防护策略上线后，观察同一组指标是否恢复到攻击前的正常水平，同时用curl模拟慢速请求，向自己的服务器发送一个30秒不发数据的请求头，看能否在超过设定的10秒超时后被服务端断开，如果断开成功，说明超时策略生效。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/792959.html
