CC攻击是站长遇到最多的攻击类型之一。很多人开了 WAF 之后网站照样被打崩，于是怀疑 WAF 没用。本文用问答形式讲清楚：为什么 WAF 会漏放 CC 请求、哪些手法天生难拦、以及 Nginx 限流、API 接口防护、日志分析等可以直接落地的应对配置。
Q：WAF 明明开着，为什么 CC 攻击还是把网站打崩了？
原因主要有三类。第一，WAF 的核心能力是规则匹配，擅长拦 SQL 注入、WebShell 这类”内容恶意”的请求，而 CC 攻击的请求内容往往完全合法，只是数量超标，规则层面无从下手。第二，CC 攻击通常模拟正常浏览器行为，带完整 Cookie 和 Referer，特征检测很难区分真人和攻击。第三，很多 WAF 默认没有开启频率限制，或者阈值设得太宽松，等于只装了门、没有限流。
Q：哪些 CC 手法天生就难被 WAF 拦截？
- 低速率慢速攻击：每个 IP 每秒只发一两个请求，但占着连接不放（如 Slowloris），流量特征不明显；
- 随机化请求：URL 加随机参数、User-Agent 随机轮换，规则难以命中；
- 海量代理 IP：攻击来自肉鸡或代理池，单 IP 请求量不高，按 IP 封禁效果差；
- 完整握手模拟：用真实浏览器内核发请求，JS 挑战、验证码都可能被绕过。
Q：IP 分散的 CC 攻击怎么提前发现？
关键是看日志聚合特征，而不是逐条看请求。典型 CC 攻击的日志表现为：URI 高度集中在少数几个接口、请求总量远超正常水位、来源 IP 数量激增。用下面的命令快速统计来源 IP：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -20再统计被请求最多的 URI：
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -rn | head -10如果某几个 URI 的请求占比超过一半，且来源 IP 高度分散，基本可以判定是 CC 攻击。
Q：Nginx 限流怎么配，才能兜住漏进来的 CC 请求？
WAF 之后再加一层 Nginx 限流是最实用的兜底手段，参考配置：
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;
limit_conn_zone $binary_remote_addr zone=connperip:10m;
server {
location / {
limit_req zone=perip burst=20 nodelay;
limit_conn connperip 20;
limit_req_status 429;
}
}其中 rate=10r/s 是单 IP 平均请求速率上限，burst=20 允许的突发排队量，limit_conn 限制单 IP 并发连接数。阈值要按业务正常峰值调试，设太低会误伤真实用户。
Q：静态页面和动态接口要分开防护吗？
必须分开。静态资源可以放相对宽松的限流，因为 CDN 会承担大部分回源压力；动态接口（登录、搜索、下单）才是 CC 攻击的主要目标，应该收紧阈值，并叠加验证码或登录态校验。攻击者最常用的手法就是打搜索接口和登录接口——这类接口后端开销大，少量请求就能拖垮数据库。
Q：API 接口被 CC 怎么办？
接口路径单独收紧限流：
location /api/ {
limit_req zone=perip burst=5 nodelay;
limit_req_status 429;
}除了限流，API 还应加三道防线：签名校验（请求参数带时间戳和签名）、Token 频控（按账号维度限流，不只按 IP）、异常拦截（同账号高频请求直接封禁会话）。纯 IP 限流对走代理池的攻击效果有限，账号维度限频才是关键。
Q：攻击发生时，日志重点看哪几个字段？
重点五个字段：来源 IP、请求 URI、User-Agent、状态码、响应时长。状态码里出现大量 499/502/504 说明后端已经过载；响应时长整体飙升说明连接池耗尽。把这几个字段和限流阈值对照着调，比盲目加规则有效得多。
Q：还有什么补充建议？
CC 防护的本质是分层：WAF 规则拦内容攻击，限频组件控请求速率，CDN 分流静态压力，高防节点抗大流量，四层各管一段。如果你的 WAF 只能做规则匹配、没有 CC 限频能力，建议接入带智能限频的高防 CDN 或 WAF 产品；同时提前准备好应急脚本（一键切换限流配置、一键上报封禁 IP），攻击来的时候才不会手忙脚乱。