## 症状现象
CC 攻击来临时，带宽曲线往往正常，CPU 与连接数却先异常：负载升高，网站响应变慢直至超时；连接状态里大量相同地址的请求堆积；日志里出现高频、间隔均匀的访问，来源分散但行为高度一致，浏览器标识与来路信息高度雷同。与流量型攻击把带宽打满不同，CC 打的是应用层的处理能力，表面看像流量正常的服务过载。
## 定位过程
先看访问日志按请求路径聚合，找出被集中访问的接口，通常是搜索、登录、动态查询这类高消耗入口。再按来源聚合，判断是少量地址高频还是大量地址低频，前者好拦，后者接近真实用户分布，需要靠行为特征区分。接着核对请求特征：无脚本执行能力的客户端、固定间隔、不带常规头部、会话不维持，都是机器流量的痕迹。顺云监控告警里的连接数与响应时间曲线是第一入口，异常拐点先从这两条线看。
## 解决方法
分层处置，从外到内。第一层在接入侧限速，对单个来源与单个会话的请求频率设阈值；第二层在应用层验证，插入验证码或脚本挑战，让无执行能力的请求无法通过；第三层对确认的攻击特征做精准封禁，动作要快、范围要窄。若流量规模超过自身处理能力，切换到高防接入，由清洗中心在源头吸收。
## 预防建议
日常先做好容量基线，知道正常高峰长什么样，异常才一眼可辨。高消耗接口加缓存与限流，登录与搜索类路径默认带频控。留一份应急预案，写清切换高防的触发条件与操作步骤，被攻击时按预案执行而不是临场发挥。事后复盘同样重要：攻击结束后整理时间线，记录入口特征、处置动作与生效时间，把有效的拦截特征固化成常驻规则。每次攻击都是一次真实的攻防测试，消化得越充分，下一次的响应越从容。