网站被CC攻击打不开的时候，先看日志里的同一个来源IP

CPU打满、数据库连不上、页面一直转圈，带宽曲线却很平。这个组合基本就是应用层被刷。CC这个名字来自Challenge Collapsar，本质是大量看起来完全正常的HTTP请求。每个请求都不大，单个看毫无破绽。合起来把PHP进程和数据库连接全部占死。跟带宽型攻击的区别就在曲线上，这类攻击带宽几乎不动。云监控上看不出异常，容易当成程序问题。判断入口只有一个：访问日志。按IP和URL各排一次，答案就在里面。

取第一列排序去重，看前二十名。这是按IP统计最快的办法。单个IP几百上千次、其余都是个位数，这就是最直接的特征。再按小时切一次，看请求是不是集中在某几个时间点，跟正常访问的高峰对不上。

如果请求集中在搜索页、详情页这类动态页面，就是典型的打数据库。带随机参数的URL尤其可疑。那是为了绕过缓存。反过来，静态资源被刷不算坏事，CDN那一层能挡住。

几千个IP每个只来几次，按IP排完全看不出问题，这种是分散型。这时候要换维度，按UA、按URL特征、按请求时间的分布看。UA里带着明显工具特征，访问顺序固定，间隔均匀。那是脚本不是人。

处置顺序有讲究。先限速，nginx的limit_req最直接。zone定义在http块，location里引用，burst控制突发，加上nodelay表示不排队直接拒。默认超限返回503，可以改成429更准确。按IP限速对分散型效果有限，得改成按路径或者按UA限。再往上就是CDN和WAF，把判断交给边缘节点。

iptables或者云防火墙都行，封IP放在最后一步做。别整段封，除非能确认那个段里没有正常用户。封完观察十分钟，看CPU有没有下来。封之前先确认这个地址不属于搜索引擎或者监控节点，误封的代价比攻击还大。

日志留好，攻击特征要复盘，这两件事在处置完之后顺手做。再检查有没有被灌进垃圾数据，评论、注册、表单都可能被利用。表单要被限频，评论要加验证，这两类最容易被忽视。

平时的准备比临时处置有效。动态页面加缓存，让同类请求打在缓存上。数据库查询加限制，慢查询会把攻击效果放大好几倍。最耗资源的接口单独限流。

只看带宽不够，还要看请求数和PHP进程数。请求数暴涨、带宽不动，这个组合本身就是信号，监控维度至少要加一个。再跟历史同时段的数据比一下，才知道这次到底高了多少倍。

时间、峰值请求数、来源特征、用了什么手段，处置完把这些记下来。下次遇到同类攻击，能直接套用。记录里带上当时的配置值，复盘时才知道哪条规则真正起了作用。