服务器被攻击后想确认是不是CC而不是大流量，最直接的办法不是盯着带宽曲线看，而是看请求有没有真正打到应用层、连接是不是大量停在ESTABLISHED状态、以及源IP有没有在反复请求同一个URL。
服务器被CC攻击怎么判断？先分清大流量攻击和CC攻击的区别
大流量攻击和CC攻击经常被混为一谈,尤其是中小网站第一次遇到攻击时，看到带宽飙高就喊CC，看到CPU打满就以为是大流量，实际判断逻辑完全不同。
| 对比维度 | 大流量攻击 | CC攻击 |
|---|---|---|
| 带宽占用 | 高，经常接近上限 | 多数情况下不高，可能只占三成不到 |
| 连接状态 | SYN_RECV大量出现，或UDP单向流量 | ESTABLISHED大量出现 |
| 应用层日志 | 新增请求少，甚至没有 | 日志增长极快，请求频繁 |
| 源IP特征 | 伪造源IP多，难以追溯 | 真实肉鸡IP多，分散但行为一致 |
| 资源消耗 | 带宽、网络设备 | CPU、内存、数据库连接池 |
| 恢复速度 | 攻击停止后立刻恢复 | 攻击停止后仍需一段时间消化积压请求 |
从这张表就能看出,带宽高不高不是判断CC的核心指标，很多CC攻击的带宽只有几十Mbps，但能把一台8核16G的服务器打到无法响应。
网站被CC攻击表现：连接状态更像“慢刀子”
大流量攻击像洪水,堵在门口，服务进不来，CC攻击像一堆人反复按门铃，门没被撞坏，但屋里的人已经累垮，具体到服务器上，表现有明显差异。
大流量攻击的典型表现
- 带宽监控曲线几乎垂直拉满,ping延迟从几十毫秒飙到几百甚至丢包
- 连接状态里SYN_RECV比例异常,或者出现大量UDP协议流量
- 网站日志新增量很低,因为请求根本还没走到应用层
- 攻击停止后,服务通常能较快恢复正常
CC攻击的行为指纹
- 带宽没跑满,但CPU使用率持续高位，内存也可能缓慢上升
- 单个IP同时保持几十甚至上百条ESTABLISHED连接
- 访问集中在少数几个动态页面,比如搜索接口、登录接口、下单接口
- User-Agent高度一致，甚至Referer也相同
- 日志里大量出现502、503、504，说明后端处理不过来
用命令查实时连接数，快速确认是不是CC攻击
判断CC最直接的方法就是登录服务器,用几条命令看当前连接状态和IP分布，这里以Linux服务器为例，操作路径都是可复现的。
Linux服务器30秒排查路径
先看带宽情况,确认是不是带宽先被打满：
iftop -n
如果带宽不高,继续看TCP连接状态概要：
ss -s
再看当前已建立的连接里,哪些IP数量最多：
ss -tan state established | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr | head -20
如果输出里某个IP出现几十次甚至上百次,CC概率就很大，接着可以从Nginx或Apache日志里抓高频IP和URL：
awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
awk '{print $7}' /var/log/nginx/access.log | sort | uniq -c | sort -nr | head
这两条命令能直接告诉你：谁在打，打的是什么接口，如果某个URL被同一个IP反复请求，基本可以定性为CC。
Windows服务器排查路径
Windows服务器没有iftop,但同样可以快速排查：
- 打开任务管理器,切换到“性能”页，再打开“资源监视器”
- 在网络选项卡里看哪个进程占用大量连接
- 执行
netstat -ano | findstr ESTABLISHED统计当前已建立连接 - 找到异常PID后,回到任务管理器对应进程，确认是否为Web服务
- IIS日志路径通常在
C:inetpublogsLogFiles，可以用文本工具或日志分析脚本提取高频IP
日志分析：四个字段锁定CC攻击
只看实时连接还不够,访问日志里的四个字段能帮你进一步坐实判断。
时间戳密集度
正常用户的请求间隔有随机性,几秒到几十秒不等，CC攻击脚本的请求间隔往往极短且均匀，比如同一IP每一秒请求一次，持续数分钟，日志里这种密集时间戳一旦成片出现，就很可疑。
请求URI集中度
正常访问会请求首页、列表页、详情页、静态资源，CC攻击通常只打一个或少数几个URL，而且这些URL往往是动态接口，用命令统计URI分布：
awk '{print $7}' access.log | sort | uniq -c | sort -nr | head -10
如果某个URI占比异常高,说明攻击目标明确。
状态码变化
大流量攻击时,访问日志可能压根没新增，CC攻击时，日志会大量记录502、503、504，原因很简单：后端进程被占满，无法正常响应，看到这类状态码集中爆发，优先怀疑CC。
User-Agent和Referer
正常访问的User-Agent五花八门，Referer也各不相同，CC攻击脚本很多使用固定UA，Referer要么为空，要么固定一个来源，提取UA分布后，如果某一种UA占了绝大多数，配合高频请求，基本可以判定为CC。
从源头IP分布看：分散不等于不是CC
不少运维一看到攻击源IP分散,就觉得不像CC，实际上行业共识认为，现在的CC攻击多数不是单一IP硬打，而是利用大量真实肉鸡发起，源IP分散反而更常见。
所以判断是不是CC,不要只看IP集中度，要看请求行为：
- 是否大量请求同一个URL
- 是否User-Agent相同
- 是否没有完整浏览器行为,比如不加载图片、CSS、JS
- 是否请求频率明显超出正常人操作
国内服务器被攻击后怎么确认是不是CC而不是大流量
国内服务器一般接入了基础DDoS防护,有些是机房默认提供的，这种情况下，判断思路要更结合防护面板。
- 登录云平台或机房防护控制台,先看“连接数”和“CC拦截”曲线，而不是只看Gbps
- 如果带宽只跑了一小部分,但网站打不开，基本可以排除纯大流量攻击
- 使用宝塔面板的话,打开“网站监控报表”或“防火墙”模块，看单IP请求频率
- 国内多个地域的机房,比如上海、杭州的BGP线路，本身对突发流量的抗性较强，一旦出现服务异常而带宽未满，更要优先怀疑CC
如果是海外服务器,部分线路质量波动较大，排查时要先确认不是网络抖动或国际链路拥塞，再下CC结论。
结合WAF日志快速定性
已经接入WAF或云防护的站点,后台数据往往能直接给出答案。
- 看命中规则类型：如果命中CC规则、频率限制规则，说明是应用层攻击
- 看回源请求占比：边缘拦截越多，回源请求越少，CC特征越明显
- 看响应码分布：429、403集中出现，是典型的限频触发结果
- 看拦截后的源IP列表：如果大量IP被判定为高频访问，可进一步佐证
服务器被CC攻击后，先确认再处理
确认是CC以后,处理顺序不要乱。
- 先限制或封禁高频源IP,可以用
iptables或云防火墙 - 优先保护数据库连接池,避免被耗尽
- 对动态接口临时加验证码或JS挑战
- 检查用户搜索、登录、下单等高消耗接口，是否存在可被刷的漏洞
- 必要时接入专业应用层防护,而不是只升级带宽
记住一个判断逻辑：大流量攻击看带宽和SYN状态，CC攻击看应用层日志和ESTABLISHED连接，先看连接状态，再看请求日志，基本能在几分钟内定性。
Q&A
服务器被CC攻击怎么判断是真实用户还是攻击流量？
真实用户访问会带动一个完整的资源加载链,比如HTML之后会请求CSS、JS、图片，User-Agent多样，请求间隔有随机性，攻击脚本通常只请求目标URL，不加载附属资源，User-Agent固定，请求间隔均匀或极短，综合这些行为，就能把真实用户和攻击流量区分开。
大流量攻击和CC攻击的防御成本有什么区别？
大流量攻击通常按清洗流量峰值计费,基础DDoS防护就能覆盖一部分，CC攻击需要应用层识别和策略调度，很多云厂商单独售卖CC防护包，按QPS或防护规则计费，防御成本上，CC的长期开销往往高于同等流量规模的大流量攻击。
服务器被攻击后如何确定是CC而不是大流量？
优先看带宽与CPU的背离情况：带宽高但CPU正常，偏大流量；带宽不高但CPU打满，偏CC，再看连接状态：SYN_RECV多是大流量，ESTABLISHED多且日志高频重复请求是CC，最后看访问日志中单个IP或单个URL的集中度，即可定性。