慢速CC攻击能在高防场景下存活，根本原因是它把攻击频率藏进了正常用户的访问节奏里，单看QPS曲线几乎看不出问题，必须靠连接层、应用层、业务层三条线交叉比对，才能把它从真实流量里摘出来。
慢速CC攻击为什么能穿过高防：它骗的是频率阈值，不是流量阈值
高防设备判断一个IP是不是攻击源，最常用的依据是单位时间内的请求数，传统CC靠并发堆量，几百上千QPS砸过来，阈值一碰就报警，清洗策略立刻生效，慢速CC反过来做减法：每个IP一分钟只发几次请求，间隔随机化，并且模拟完整的TCP握手、正常的User-Agent、甚至带上真实的Cookie和Referer，单IP看过去,跟一个正在翻页浏览的用户没有区别。
传统CC与慢速CC的节奏对比
| 维度 | 传统CC | 慢速CC |
|---|---|---|
| 单IP请求频率 | 高频，秒级多请求 | 低频，分钟级数次 |
| IP池规模 | 较小，集中 | 很大，分散且常轮换 |
| 请求间隔 | 固定或接近固定 | 随机抖动，模仿人工 |
| 连接方式 | 短连接为主 | 长连接复用明显 |
| 触发告警的方式 | 频率阈值 | 几乎不触发频率阈值 |
为什么QPS曲线看起来是平的
因为攻击者把总量摊薄到了大量源IP上，假设有几千个IP同时工作，每个IP每分钟只打两三次，聚合起来的QPS可能只比平时高一点点，落在正常波动的区间里，这种情况下，频率类规则基本失效，真正露馅的地方在连接状态和上。
高防服务器慢速CC攻击怎么检测：三层交叉观察法
这是实操中最可靠的路子，不要指望单一指标命中,让三层信号互相印证。
第一层 连接层：盯住半连接和空闲长连接
慢速CC为了省成本，经常保持大量长连接不释放，或者在半连接阶段拖时间,登录服务器执行：
ss -ant state syn-recv | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20，看半连接是否集中在少数网段ss -ant | awk '{print $1}' | sort | uniq -c，对比ESTABLISHED与TIME_WAIT的比例netstat -anp | grep :443 | awk '{print $6}' | sort | uniq -c
正常业务下，连接状态分布是相对均匀的，如果出现大量ESTABLISHED但业务日志里没有对应请求，说明连接建立了却不干活,这是慢速CC的典型画像。
第二层 应用层：从日志里找”慢”的特征
Nginx日志里加上$request_time和$upstream_response_time两个字段,很多问题一眼就能看出来：
- 请求间隔的方差极小，机器味很重
- User-Agent、Referer高度雷同，或者干脆为空
- 访问路径高度集中在少数几个动态接口，比如登录、下单、抽奖、验证码校验
- 同一参数组合被不同IP反复提交
用一条命令粗筛：
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -50
再看这些高频IP的请求时间分布：
grep "1.2.3.4" access.log | awk '{print $4}' | cut -d: -f1-2 | uniq -c
如果某个IP在每一分钟都稳定出现两三次，持续几十分钟,人工用户很难做到这种规律性。
第三层 业务层：账号和参数的异常关联
这一层最容易被忽略，但对慢速CC最有效，攻击者通常不是为了刷流量，而是为了打穿某个业务逻辑，比如撞库、刷验证码、抢券,观察点包括：
- 同一接口在短时间内收到大量参数结构相同、值不同的请求
- 登录失败率在某个接口上突然抬升
- 同一批Session或Token被大量不同IP复用
- 业务侧的成功率异常低，失败集中在特定错误码
把这三层的信号叠在一起,误判率会大幅下降。
游戏高防场景下慢速CC攻击有哪些典型特征
游戏业务对延迟极度敏感,慢速CC在这里的表现和普通网站不太一样。
登录服和战斗服的表现差异
登录服是重灾区，攻击者用大量低速IP反复请求登录接口和排队接口，制造假登录，拖慢真实玩家的进入速度，战斗服则更多表现为房间创建请求被刷、匹配队列被灌入无效玩家，这类攻击的特点是单个请求成本极低,但业务侧的资源消耗很高。
行业共识认为，游戏场景下判断慢速CC，应该优先看”单位时间内的无效业务动作数”，而不是单纯的请求数，一个创建房间的请求如果十次有九次参数非法,那它本身就该被拦截。
高防IP和高防CDN哪个防慢速CC攻击更有效
这是被问得最多的问题之一，结论是：单靠任何一个都不够，慢速CC需要组合拳。
高防IP的优势在传输层和网络层，擅长扛大流量、清洗SYN Flood和UDP反射，对低频应用层攻击的识别粒度偏粗，高防CDN贴近业务侧，能看到完整的HTTP语义，适合做请求特征、频率、人机校验这类应用层判断,但它的清洗能力依赖源站回源策略。
建议的组合部署路径
- 流量入口走高防IP，先挡掉大流量和协议层攻击
- 业务域名接高防CDN，开启基于URI的频率限制和Bot管理
- 源站做二次校验，Nginx层配置
limit_req和limit_conn兜底 - 关键接口加人机验证，验证码或行为校验按风险等级动态触发
一个可直接落地的Nginx片段：
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
location /api/login {
limit_req zone=login burst=3 nodelay;
limit_conn addr 10;
}注意限速值要结合真实业务峰值来定,定得太死会误伤正常用户。
高防机房慢速CC攻击防护价格大概在什么区间
价格这块没有统一标准，跟防护带宽、清洗能力、是否包含应用层策略定制直接相关，近年来市场上基础高防IP的月费从几百元到数千元不等，带应用层CC防护和定制规则的服务通常要贵出一截，游戏、金融这类对延迟和清洗精度要求高的行业，往往会选择独享防护资源,成本自然更高。
选购时该问清楚的几个问题
- 清洗是否包含应用层，还是只做流量层
- 慢速CC这类低频攻击有没有专门的检测策略
- 规则调整是自助还是需要工单，响应时效多久
- 计费是按保底带宽还是按实际清洗流量
价格差异背后其实是检测能力的差异,光比数字意义不大。
从发现到处置的具体操作路径
发现异常之后，动作要快,但不要一上来就全量封IP。
- 先确认信号，三层指标里至少两层同时异常,再判定为攻击。
- 圈定范围，用
awk统计出请求最集中的URI和参数特征,确认攻击面。 - 临时限速，对目标接口加
limit_req，先压住频率,观察业务影响。 - 加校验，对可疑IP段或可疑会话触发人机验证,把机器流量筛掉。
- 联动高防，把特征提交给高防侧做规则下发,做长期拦截。
- 复盘，记录攻击时间窗、源IP分布、被攻击接口,补充到监控规则里。
整个过程里，最忌讳的是只看QPS就下结论,慢速CC恰恰是QPS最正常的攻击类型。
关于高防场景慢速CC攻击的常见问题
慢速CC攻击和高防设备的频率阈值冲突吗
不冲突，但阈值管不住它，频率阈值是为高频攻击设计的，慢速CC刻意把单IP频率压在阈值以下，所以需要补充连接状态、请求间隔方差、业务参数相似度这类维度，业内专家指出，把检测重心从”量”转向”质”,是应对低频攻击的基本方向。
高防服务器上慢速CC攻击怎么和正常爬虫区分
看目的和行为边界，正常爬虫通常遵循robots协议，访问路径分散，请求间隔有自然波动；慢速CC集中在少数高价值接口，参数结构高度重复，且往往伴随登录失败率上升，业务侧的失败率指标,比流量侧指标更有说服力。
中小业务有必要上完整的高防加CDN组合吗
看暴露面，如果只有单一登录入口和少量API，源站加Nginx限速配合云厂商的基础高防通常够用；如果业务涉及交易、账号资产或有明显竞争对手，组合部署更稳妥，成本与风险敞口匹配即可,不必追求顶配。
慢速CC不是靠某一个神奇规则拦住的，而是靠连接、日志、业务三层信号持续对照出来的，把这三层监控做扎实，比反复调高防阈值有用得多。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/783969.html
