引言
CC 攻击是中小企业网站最常遇到、也最难分辨的攻击方式：它不需要大带宽，几十台肉鸡甚至一台高配服务器就能把网站打瘫。本文集中解答关于 CC 攻击识别的高频问题：CC 攻击和正常流量高峰怎么区分、有哪些典型特征、怎么用 Nginx 日志和命令快速验证、发现之后第一步该做什么。
Q：什么是 CC 攻击？和正常的流量高峰怎么区分？
CC 攻击（Challenge Collapsar）是一种 HTTP 层攻击，攻击者模拟大量”看起来正常”的请求，持续请求网站中消耗资源最高的页面（动态页、搜索页、数据库查询接口），把服务器的 CPU、连接数或数据库连接池耗尽。它和正常流量高峰的核心区别在于：流量上涨了，但真实访客没有变。正常高峰的特点是访问分散、页面多样、有来有回；CC 攻击的特点是请求高度集中、行为机械、只请求少数几个 URL。
Q：CC 攻击有哪些典型特征？
出现以下情况基本可以判定是 CC 攻击，而不是流量高峰：
- 请求高度集中在少数 IP：TOP 10 的 IP 占了总请求量的一半以上；
- URL 高度集中：反复请求同一个动态页、搜索接口或带参数的页面；
- Referer 和 UA 异常：大量请求 UA 为空、重复，或 Referer 缺失；
- 访问时段异常：凌晨三四点出现远超日常的请求量；
- 带宽不高但资源暴涨：入口带宽正常，CPU、php-fpm、MySQL 却被打满，这是 CC 区别于流量型 DDoS 的关键点；
- 只请求不点击：没有 CSS/JS/图片等静态资源请求，说明访问者根本没有”渲染页面”。
Q：怎么从 Nginx 日志快速确认被 CC 攻击了？
三组命令就能看清楚。第一组，统计访问量最高的 IP：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20第二组，统计被请求最多的 URL：
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20第三组，按秒统计请求量，看是否存在瞬时尖峰：
awk '{print $4}' /var/log/nginx/access.log | cut -d: -f2-4 | uniq -c | sort -rn | head -20如果 少数 IP 对少数 URL 产生了每秒几十上百次的连续请求，基本可以确认是 CC 攻击。建议拉取攻击时段前后的日志对比，而不是只看当前时刻。
Q：单个 IP 请求量多少算异常？会不会误判？
没有绝对标准，和业务类型有关。一般而言，普通企业站点单个 IP 每分钟持续产生几百次以上请求、且集中在同一 URL，就非常可疑。但要注意两种误判场景：
- NAT 出口：公司、学校、运营商出口是大量用户共享一个 IP，请求量天然偏高。判断方法是看该 IP 的 URL 离散度——真实 NAT 出口的访问页面多样，攻击则高度单一；
- 搜索引擎蜘蛛：百度、谷歌蜘蛛也会高频抓取。验证方法见下一节。
Q：服务器出现什么症状要怀疑是 CC 攻击？
结合服务器表现和连接数一起看。典型症状包括：php-fpm 进程占满 CPU、网站间歇性 502/504、MySQL 连接数暴涨报 “too many connections”。用这条命令查看 80/443 端口的连接来源分布：
netstat -an | grep -E ':80|:443' | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20如果 单个 IP 维持着几十上百条 ESTABLISHED 连接，而服务器负载同步暴涨，这就是 CC 攻击的典型画面。也可以配合 top、mysqladmin processlist 确认资源消耗点在动态处理层而非带宽层。
Q：确认被 CC 攻击后，第一步该做什么？
第一步是限流降损，而不是逐个封 IP——攻击 IP 会随时更换，手动封禁永远慢一步。Nginx 自带的限流模块足够应急：
http {
limit_req_zone $binary_remote_addr zone=cc_zone:10m rate=10r/s;
server {
location / {
limit_req zone=cc_zone burst=20 nodelay;
limit_req_status 429;
}
}
}rate=10r/s 表示单 IP 平均每秒最多 10 个请求，burst=20 允许短暂突发。改完执行 nginx -t && nginx -s reload 生效。对于确实确认的恶意 IP，再配合 deny 精准封禁：
deny 203.0.113.45;注意不要封大段网段，容易误伤运营商 NAT 出口背后的真实用户。
Q：用 CDN 或 WAF 能自动识别 CC 攻击吗？
可以，这也是应对 CC 攻击最省力的方式。自建限流只能按 IP 频率一刀切，而专业 WAF 的 CC 防护基于频率统计 + 行为分析 + 人机挑战三层判断：对可疑访问弹出 JS 挑战或验证码，正常用户无感知通过，脚本攻击则无法通过。同时 WAF 部署在边缘节点，攻击流量不会打到源站，源站带宽和连接资源不受影响。对于没有专职运维的中小企业站，接入百度云防护这类带 CC 防护的 WAF，比在服务器上反复调 iptables 规则更稳妥。
Q：还有什么补充建议？
- 先备份日志再轮转：logrotate 可能在你分析前就把攻击日志清掉了，排查前先
cp一份； - 区分 CC 和恶意采集：两者表现相似，采集更在意全站遍历，CC 更在意打资源，处置方式不同；
- 给动态页做静态化缓存：把高频动态请求转成静态输出或加页面缓存，能显著抬高攻击成本；
- 保留攻击证据：日志截图、连接记录在后续报案或向机房申请协助时都有用；
- 平时演练：限流规则、封禁流程提前配置好并测试过，攻击发生时才不会手忙脚乱。