网站被CC攻击了？别瞎猜，这几个地方一查一个准
摘要：# 网站被CC攻击了？别瞎猜，这几个地方一查一个准 **别一卡就说是CC攻击，先搞清楚是真被打，还是你服务器自己不行。** 网站一慢、一卡、一打不开，很多站长第一反应就是“我是不是被CC了？”。这种警惕性是对的，但盲目下结论没用。判断错了，你折腾半天防…
别一卡就说是CC攻击，先搞清楚是真被打，还是你服务器自己不行。
网站一慢、一卡、一打不开，很多站长第一反应就是“我是不是被CC了？”。这种警惕性是对的，但盲目下结论没用。判断错了，你折腾半天防火墙，最后发现是数据库没索引，或者服务器超售，那才叫浪费时间。
今天不聊那些复杂的原理，就站在运维和业务负责人的角度，告诉你：怎么快速、准确地判断，当前的问题是不是CC攻击造成的，以及攻击大概是个什么路数。
一、CC攻击不是“慢”的同义词，先排除自家问题
很多人有个误区，觉得网站访问慢就是被CC了。其实服务器性能瓶颈、程序BUG、数据库死锁、甚至机房网络波动，都能导致类似症状。先别急着甩锅，按顺序排查：
-
看服务器资源（最直观）
- CPU/内存： 登录服务器监控（宝塔、云监控、Zabbix都行），看是不是持续飙高到90%以上，甚至100%。CC攻击通常吃CPU和内存，因为要处理大量恶意请求。如果是数据库CPU高而Web服务器不高，那可能是慢查询导致。
- 连接数： 用
netstat -an | grep :80 | wc -l或ss -s看TCP连接数。如果连接数异常高（比如平时几百，现在几万），且很多是ESTABLISHED或SYN_RECV状态，这是典型攻击特征。 - 带宽： 看入站带宽是否跑满。注意： CC攻击不一定打满带宽！它主要消耗服务器处理能力。如果带宽先满，可能是DDoS流量型攻击，或者你的资源（如图片、下载文件）被恶意刷。
-
看Web服务日志（找源头） 这是判断CC攻击的核心证据。打开Nginx或Apache的访问日志（access log）。
- 异常IP集中： 短时间内，来自少数几个IP或一个IP段的请求量暴增。
- 异常请求路径： 大量请求集中攻击某一个或几个URL，比如登录页
/login、验证码接口/api/captcha、搜索页/search，或者直接攻击首页/。 - 异常User-Agent： 大量请求使用相同或伪造的UA，或者干脆是空UA。
- 请求频率： 同一个IP，请求间隔短得不像真人，比如一秒几十次请求同一个接口。
说白了，如果你看到日志里，同一秒内，同一个IP对同一个动态页面（尤其是需要查数据库的）发起几十次请求，并且持续不断，那基本可以锁定是CC攻击了。
二、CC攻击也分“傻”和“精”，对症才能下药
判断出是CC攻击后，还得看看它是什么类型，这决定了你的防护策略重点。
-
“傻”CC（低效攻击）
- 特征： 固定IP、固定URL、固定User-Agent，无脑刷。比如就用一个脚本，不停访问你首页。
- 判断： 日志里模式非常单一，一眼就能看出来。这种最好防，在WAF或防火墙里针对这个IP、这个URL限频，或者直接封IP段，很快就能缓解。
- 吐槽： 现在还用这种攻击的，要么是初学者练手，要么就是攻击成本极低，想碰碰运气看你是不是裸奔。
-
“精”CC（高效攻击/慢速攻击）
- 特征： IP池巨大（可能来自代理池、被控的“肉鸡”）、模拟真人行为（随机访问不同页面，间隔不固定）、攻击目标精准（专找你耗资源的API、搜索接口、数据库查询页）。
- 判断：
- IP分布很散，没有明显规律。
- 请求的URL有一定随机性，但最终会集中在几个消耗大的接口上。
- 可能携带正常Cookie，甚至通过了几次验证码（攻击端有破解能力）。
- 难点： 这种攻击很难用简单的IP黑名单搞定。它追求的不是瞬间打死你，而是用较低的流量和连接数，慢慢把你的服务器资源耗光，让你业务持续不可用，而且防护成本很高。
-
针对API/接口的CC
- 特征： 不攻击网页，专打你的移动端API、小程序接口、支付回调地址。攻击参数可能经过构造，绕过基础校验。
- 判断： 应用层监控（如APM工具）会发现某个接口响应时间暴涨、错误率飙升。服务器资源消耗可能不明显，但数据库或Redis被拖垮。
三、真被打时，紧急判断和止损步骤
如果你的判断八九不离十了，别慌，按这个顺序来：
-
立即启用临时防护：
- 云服务器/WAF面板： 如果有，立刻开启CC防护模式，设置一个较严格的频率阈值（比如单IP每秒5-10次请求）。
- Nginx层面限流： 通过
limit_req模块对可疑URL进行紧急限速。 - 封禁可疑IP段： 如果攻击IP相对集中，可以临时封禁整个CIDR段。
-
分析攻击模式，调整策略：
- 看攻击目标： 是打首页？还是打API？如果是API，是不是没做鉴权或限流？
- 看攻击源： 是国内IP多还是国外多？可以考虑临时屏蔽海外访问（如果业务允许）。
- 看是否混合攻击： 有没有伴随少量的DDoS流量，意在干扰你的判断？
-
验证防护效果：
- 开启防护规则后，持续观察服务器资源（CPU、连接数）是否下降。
- 观察业务恢复情况，特别注意有没有误封正常用户。很多CC防护一开，先把抢券的、刷新的真实用户给干掉了。
四、长期来看，怎么建立判断和防御体系？
靠人肉看日志不是长久之计。你得有点自动化手段：
- 监控告警是前提： 给服务器CPU、连接数、关键接口响应时间设置告警阈值。一有风吹草动，先收到通知。
- 日志分析要跟上： 用ELK、Grafana Loki等工具，把日志集中起来，能快速按IP、URL、状态码进行统计和排序。一眼就能看到“请求量TOP 10的IP”和“被请求最多的URL”。
- 防护工具要选对：
- 对于“傻”CC，服务器防火墙或基础WAF够用。
- 对于“精”CC和API攻击，你需要具备智能人机识别能力的WAF或高防服务，比如能验JS、验Cookie、验行为轨迹的。别指望简单限频能搞定一切。
- 最关键的一点：隐藏源站IP！ 无论用高防IP、高防CDN还是云WAF，确保所有流量都先经过清洗再回源。别让你的服务器IP暴露在公网上，这是最基本的常识，但栽在这上面的人最多。
最后说句大实话： 判断CC攻击，一半靠经验，一半靠工具。经验告诉你从哪入手，工具帮你快速验证。别等到真被打得焦头烂额时才研究，平时就该把你网站的“健康指标”摸清楚。正常状态什么样，心里有数了，异常状态来了，你才能一眼识破。
你的网站，现在经得起看日志吗？