遇见CC攻击时，不少用户会手忙脚乱，但是一定要记住这个时候一定不能慌张，也不要着急去找是谁干的。最重要是让网站先恢复正常，因为遇见攻击时，黄金处置时间也就十几分钟，拖越久业务损失越大，用户跑的也越多。

第一步，先确认到底是不是CC攻击

有时候网站卡了不一定是被攻击，可能是程序有bug或者流量真的涨了。怎么区分？几个特征可以帮你快速判断。先看看CPU使用率，正常情况是随流量线性增长，但CC攻击的特征是流量没怎么变，CPU直接爆了。再看看访问日志，如果发现大量请求集中在同一个URL（比如登录接口、搜索接口），而且来源IP分布很分散，那基本就是被盯上了。

下面这个命令可以帮你快速找出高频访问的IP：

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head -20

如果某个IP在短时间内请求同一个URL超过100次，或者大量IP访问路径高度一致，基本上就可以判定了。

第二步，紧急止血——先让网站喘口气

确认被攻击之后，第一件事不是去找攻击源头，是先把恶意请求挡在外面。有几个办法可以快速生效。

如果用的是Nginx，可以直接加一个限流配置。在server块里加上这段，能限制每个IP每秒最多5个请求，超过的直接返回503：

limit_req_zone $binary_remote_addr zone=api_limit:10m rate=5r/s;

location /api/ {

limit_req zone=api_limit burst=10 nodelay;

error_page 503 = @fallback;

}

如果你用上了WAF（Web应用防火墙），这时候就该让它干活了。在WAF的控制台里开启CC防护，选“IP限速”模式，把频率阈值设低一点，比如30秒内超过50次就直接拦截。

还有一个更直接的办法：临时关掉非核心功能。比如商品评价、用户画像查询这些计算密集型的接口，先切到静态缓存或者直接关掉，把资源留给支付、登录这些核心业务。

第三步，流量分流——别让服务器硬扛

如果攻击流量已经把带宽打满了，光靠服务器硬扛肯定扛不住。这时候有两种选择。

一个是启用CDN或高防服务。如果你之前接入了Cloudflare或者阿里云、腾讯云的高防CDN，直接在控制台把“Under Attack Mode”打开，或者把流量切到高防IP上。清洗中心会自动识别恶意流量，把正常请求放进来。

另一个办法是临时换个IP。如果你的服务器有弹性公网IP，直接在控制台解绑旧的，绑一个新的上去。然后去DNS那边把A记录改成新IP，TTL设成60秒，让生效快一点。

在云控制台操作：解绑原IP，绑定新IP

然后去域名解析处修改A记录

第四步，等攻击过去了，别急着睡觉

攻击停了不代表完事了。接下来要做几件事，防止下次再被搞。

先去把攻击期间的日志扒下来，看看攻击者到底打了哪个接口。然后去优化那个接口——加缓存、加索引、加限流。如果发现是某个API被高频调用，可以考虑在业务层加个Token验证或者滑块验证，提高攻击门槛。

数据库和代码也得检查一遍。从最近的备份里恢复数据，确认没有东西被篡改。如果有条件，把数据库回滚到攻击前的时间点。

最后，给你的服务器穿上“防护衣”。建议至少做到这几样：接入WAF（这个是硬需求，几百块一年能挡住大部分攻击），开启云服务商的基础DDoS防护（很多是免费的），把Nginx的限流配置常开着，不要等到被打了再开。

说句实在话，CC攻击这种事，经历过一次就知道有多疼。但反过来想，它也是个机会，逼着你把防护体系搭起来。平时多花点心思，真出事的时候就能从容很多。

最后送你一个可以随时跑的“体检”命令，看看服务器状态正不正常：

# 实时查看连接数和CPU

watch -n 1 'netstat -an | grep ESTABLISHED | wc -l; top -bn1 | grep "Cpu(s)"'

希望这些经验能帮到你。下次再遇到这种事，就知道该从哪儿下手了。