Q：CC攻击和DDoS攻击本质上有什么区别？
两者经常被混为一谈，但攻击层面完全不同。DDoS（分布式拒绝服务）是流量型攻击，工作在网络层（L3/L4），目标是用海量数据包或连接请求直接打满服务器带宽、耗尽连接表，典型手法如 SYN Flood、UDP Flood。CC攻击是应用层攻击（L7），攻击者模拟正常用户的 HTTP 请求持续访问网站，流量可能不大，但会耗尽服务器的 CPU、内存、数据库连接等计算资源。
- 攻击目标：DDoS 打带宽和连接数，CC 打应用处理能力
- 流量特征：DDoS 流量巨大、协议单一，CC 流量偏小、内容像正常浏览
- 关系：CC 本质上属于应用层 DDoS 的一种，只是习惯上单独称呼
Q：CC攻击为什么比大流量DDoS更难防？
大流量 DDoS 特征明显，运营商或高防节点在流量层面清洗即可。CC 攻击的难点在于每个请求看起来都和真实用户几乎一样：
- 请求内容合法，URL、Header 都符合业务逻辑，无法简单按协议拦截
- 源 IP 高度分散，攻击者常用代理池、肉鸡轮换来源，封 IP 封不完
- 攻击频率可以压得很低，比如每个 IP 每秒只请求 2 次，但几千个 IP 叠加就能打垮数据库
- 防护需要理解业务，纯网络设备无法判断”这个请求是恶意刷接口还是正常访问”
Q：怎么判断网站是被CC攻击了还是被DDoS了？
先看症状，再看日志。症状层面：ping 丢包严重、带宽被打满、整个 IP 不通，大概率是流量型 DDoS；带宽正常、能 ping 通，但网站打开慢、报 502/504，服务器 CPU 和数据库连接数飙升，大概率是 CC 攻击。
日志层面，用 access.log 快速定位异常来源和异常 URI：
# 统计请求量最高的前 20 个来源 IP
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20
# 统计被请求最多的前 20 个 URI
awk '{print $7}' access.log | sort | uniq -c | sort -rn | head -20
# 查看某一秒内的请求密度（判断是否高频集中）
awk '{print $4}' access.log | cut -d: -f1-4 | uniq -c | sort -rn | head如果某个或某批 IP 集中请求同一动态接口（如搜索、查询、登录），基本可以确认是 CC 攻击；如果日志都来不及写、流量统计直接爆表，则是 DDoS。
Q：CC攻击常见的攻击手法有哪些？
- 高频请求攻击：单 IP 或少量 IP 以极高频率刷新动态页面，快速耗尽处理能力
- 低速率慢速攻击：每个 IP 频率很低以规避限流阈值，但用大量 IP 叠加总量
- 资源消耗型攻击：定向请求大文件下载、模糊搜索、复杂查询等高开销接口
- 随机参数绕缓存：URL 后附加随机字符串，让 CDN 和页面缓存全部失效，每次请求都回源打到数据库
Q：Nginx 层怎么防CC攻击？
基础手段是 limit_req 限流 + limit_conn 限并发，配置如下：
http {
# 单 IP 每秒最多 10 个请求
limit_req_zone $binary_remote_addr zone=cc:10m rate=10r/s;
# 单 IP 最多 20 个并发连接
limit_conn_zone $binary_remote_addr zone=conn:10m;
server {
# burst 允许 20 个突发排队，nodelay 表示不延迟直接处理
limit_req zone=cc burst=20 nodelay;
limit_conn conn 20;
limit_req_status 503;
limit_conn_status 503;
}
}关键参数：rate=10r/s 控制单 IP 频率，burst 控制突发容忍度。对搜索、查询、登录等高开销接口，建议在单独的 location 里设置更严格的阈值：
location /search {
limit_req zone=cc burst=5 nodelay;
proxy_pass http://backend;
}Q：防火墙层能做什么？
iptables 可以限制单 IP 并发连接数并封禁确认的攻击源：
# 单 IP 并发连接超过 50 直接丢弃
iptables -I INPUT -p tcp --dport 80 -m connlimit --connlimit-above 50 -j DROP
# 封禁确认的攻击 IP
iptables -I INPUT -s 203.0.113.10 -j DROP注意：CC 攻击的源 IP 往往是代理池，逐个手工封禁效率太低。建议配合 fail2ban 之类的自动化工具，按日志中的请求频率自动封禁，并设置合理的解封时间。
Q：什么时候需要上WAF或高防CDN？
本地限流的上限就是那台服务器的处理能力。当攻击源 IP 达到数千上万个，或者服务器已经被打到自顾不暇时，本地配置救不了，需要把清洗环节前移到云端：
- 边缘清洗：WAF/CDN 节点在源站之前承接流量，CC 限频、人机验证、JS 挑战都在边缘完成
- 隐藏源站：源站防火墙只放行 CDN 回源网段，攻击流量直接摸不到源站
- 业务层策略：对动态接口配置更严格的频控，对可疑流量触发验证码校验
接入方案可参考DDoS 高防接入实战，把网络层大流量和应用层 CC 分层处理；Nginx 限流的更多细节可参考Nginx limit_req 实战。
Q：还有什么补充建议？
- 先监控后防护：带宽、CPU、数据库连接数要有告警，发现异常比拦截更早一步
- 动静分离：页面静态化 + 全站缓存，动态请求越少，CC 的可打面越小
- 关键接口单独策略：登录、支付、搜索接口的限流阈值要比全局更严格
- 定期演练：整理一份应急 checklist，攻击发生时按步骤执行，而不是临时翻配置