如何判断你的服务器是在遭受 CC 攻击，还是业务繁忙

当你的网站变得异常缓慢，甚至直接掉线时，你往往很难分辨：这究竟是遭到了攻击，还是因为流量太好。这里先给出最直接的判断方法：如果是真实流量激增，带宽和 QPS 往往会同步上升；如果是 CC 攻击，QPS 会明显飙升，而带宽通常相对平稳，因为这类应用层流量主要由大量短小、重复的第 7 层请求构成。你可以按照下面这套四步诊断与响应指南，判断服务器是否正在遭受 CC 攻击。你将学会如何区分真实流量暴涨、网络层洪泛攻击，以及 CC 洪泛攻击，并据此采取正确措施。

先在监控中查看带宽与 QPS

大多数情况下，这个问题只需在一个地方就能初步判断：把带宽和 QPS 放在同一时间轴上并排查看。规则很简单。若是真实用户流量激增，带宽和 QPS 会同步上涨；若是 CC 攻击，QPS 会飙升，而带宽则相对平稳。原因很直接：CC 攻击本质上是应用层洪泛，由大量短小、重复的 HTTP 请求组成。单个请求传输的数据量很小，因此占用带宽有限，但请求数量会迅速攀升。

当两个指标同时上升时

打开你的监控面板，把两张图对齐来看。真正的流量高峰会表现为两条曲线同步上扬。页面浏览、文件下载和 API 调用都会携带一定的数据负载，因此用户越多，传输的字节数也越多。你还可以在访问日志中找到佐证：真实页面请求和下载记录会符合正常用户访问路径。不过这里有一个需要注意的例外。国际链路波动有时会触发 TCP 重传，从而造成“带宽看起来很满”的假象。此时带宽图会突然升高，但其中相当一部分流量其实是重复数据，而不是真实访问。在下结论之前，应先将来源地区与平时的用户分布做对比。

正常业务高峰和攻击在一开始看起来可能非常相似。营销活动、消息推送或内容病毒式传播，都可能同时拉高 QPS 和 CPU。此时要和你的常态基线对比。检查来源地区是否符合你的用户分布，访问路径是否像真实用户那样——先打开页面，再请求静态资源和 API——而不是反复只命中同一个接口。

当只有 QPS 单独飙升时

你最需要捕捉的，就是这种“指标背离”。下表展示了结合图表一起分析时，两类攻击是如何区分的。

对于 CC 攻击，总带宽通常相对平稳，但第 7 层 QPS、并发连接数和每秒新 HTTP 请求数会异常升高。对于网络层洪泛，带宽和每秒包数会急剧上升，而第 7 层 QPS 则可能保持平稳，甚至因为握手失败而下降。这种对比，是你最快速的第一步判断。先问自己：究竟是带宽和包量一起飙升了，还是只有请求速率单独上去了？

以下三个辅助信号，可以进一步确认第二种情况：

• CPU 长时间打满，而带宽并不突出

• 请求集中在少数几个高消耗 URL 上

• 访问日志中，同一批 IP 以高度规律的时间间隔反复请求

当这些现象与 QPS 飙升、带宽平稳同时出现时，就应先将其视为恶意流量，除非后续证据能够证明并非如此。这也是判断服务器是否遭受 CC 攻击、避免拍脑袋猜测的关键方法。

你的网站遭受的是 DDoS 还是 CC 攻击？

到这里，你已经知道第一个分界点：带宽和 QPS 同时上升，多半是真实流量高峰；只有 QPS 单独暴涨，则往往意味着麻烦。接下来的问题是：这究竟是哪一种麻烦？网络层洪泛和应用层洪泛会留下完全不同的痕迹，也需要采取不同的应对方式。判断你的网站遭遇的是 DDoS 还是 CC 攻击，关键就在于先确认攻击发生在哪一层。

网络层与应用层的典型特征

网络层 DDoS 最明显的信号，是带宽突然飙升。流量型洪泛会将海量原始数据包灌向你的链路，因此最关键的指标是每秒包数（pps）。而应用层 CC 攻击则恰恰相反。它会通过高频发送 HTTP/HTTPS 请求，去模拟看似正常的用户行为，目标通常是登录页、搜索页、提交表单等动态页面。每个请求本身都看起来合法，但目的在于耗尽服务器 CPU、数据库连接和其他计算资源，最终让服务停止响应。在这种情况下，最重要的指标就是每秒请求数。

不过，并不是所有应用层攻击都会表现为“请求风暴”。像 Slowloris 这样的慢速攻击同样属于这一层，但它并不会带来高 QPS。它的特点是请求长时间保持未完成状态，因此日志量甚至可能并不会明显增加。遇到这种情况，更应关注以下信号：

• ESTABLISHED 连接长时间处于饱和状态

• Web 服务工作进程耗尽，而 CPU 却并不高

• 日志量看起来正常，但站点已明显变慢

向数据中心索取流量图

网络层或传输层 DDoS 往往比较容易确认。你可以直接向数据中心索取对应 IP 的流量图。如果图上出现明显的入站流量尖峰，再与你自身监控数据进行比对，通常就能很快确认。相比之下，应用层 CC 攻击更难凭这类图表直接判断。因为其数据包看起来非常普通，所以流量图可能几乎没有明显变化。此时你需要更深入地分析请求、连接和日志，才能做出准确判断。

很多管理员容易被一个陷阱误导：攻击持续时间。CC 攻击者常常用短时间的攻击流量去耗尽资源，所以一次短暂事件并不代表服务器很快就会恢复正常。哪怕只是短短一波流量，也可能让数据库连接在攻击结束后仍被耗空。因此，持续时间只能作为较弱的参考信号，更应重视攻击强度和请求模式。当你判断服务器是否正在遭受 CC 攻击时，请求的形态远比持续了多久更重要。如果你怀疑服务器正在遭受攻击，但流量图却没有明显波动，就继续检查连接状态和访问日志，后面的章节会说明如何操作。这也是在怀疑遭遇 DDoS 或 CC 式攻击时，避免在错误层面浪费时间的正确排查思路。

检查 TCP 连接状态

监控图告诉你应该往哪里看，连接状态则会告诉你系统内部究竟发生了什么。你可以在主机上运行 netstat -an 或 ss -s，按状态统计 socket 数量。一个健康的 Web 服务器，会呈现与正常用户负载相匹配、相对稳定的状态分布。

识别异常的 SYN_RECV 与 TIME_WAIT

有两个状态尤其值得重点关注。第一，若有大量半开连接长期停留在 SYN_RECV，说明很多客户端发起了握手，却没有完成后续过程。互联网中存在少量此类噪声是正常的，但如果这一数量持续攀升到数百甚至更高，并长时间不下降，就值得警惕。第二，TIME_WAIT 的含义不同。每个关闭的连接都会在短时间内留下一个 TIME_WAIT，所以繁忙网站本来就会有一些。但如果它们成千上万地堆积，并且增长速度远高于清理速度，就说明有大量短生命周期连接正在以机器速度不断建立和关闭。这种模式更像是 CC 洪泛，而不是一大群真实用户在访问。

将连接情况与真实用户行为对比

数字本身只有放在基线中才有意义。建议你连续一周记录服务器在低峰期和高峰期的连接数，这样你就知道一个“正常的周二高峰”应该长什么样。当前连接数应与这套基线做比较，而不是和零相比。真实用户的行为也具有可识别性：他们会先加载页面，再获取页面资源，然后停下来阅读。而攻击源则会不停地敲打某些接口，几乎没有停顿。

除了 socket 数量，还要留意其他辅助信号。Ping 延迟升高、客户端在会话中途频繁掉线、服务器从服务器列表中消失，这些通常都说明是资源耗尽，而不是单纯“太受欢迎”。网络层洪泛往往也会连 SSH 一起拖垮，而 CC 攻击则常常不影响你正常登录。把这些线索视为辅助确认，而不是单独证据。接下来继续看日志。

通过 Web 访问日志识别 CC 模式

如果仅靠图表和 socket 状态仍难以判断，就去查看 Web 访问日志。日志会记录每一次请求，因此它往往比流量图更能准确帮助你判断服务器是否正在遭受 CC 攻击。CC 攻击会留下清晰可读的痕迹。大量请求会在短时间内集中涌入，而这些流量背后的模式，正是你判断问题性质的关键。

重复路径与单一来源连接

真实访客的请求通常会分散在多个页面上。他们会先访问首页，再打开文章，同时请求图片和脚本等静态资源。攻击流量则往往更集中。你会看到同一个 URL 被高频刷新，且常常伴随着来自单一源地址的大量并发连接。最明显的特征是：某个客户端反复只请求同一个接口，比如登录表单或搜索接口，而完全忽略静态资源。此时你要问自己：访问日志中是否在极短时间窗口里，对同一路径出现了大量请求？如果某些动态接口被带着相同参数反复冲击，这更像是 HTTP/HTTPS 洪泛，而不是正常读者访问。

使用日志工具进行检测与调查

日志分析工具可以在日志写入的同时实时扫描，并自动标记上述模式。它们还能帮助你保留证据，这对于事后调查同样重要。攻击突增检测又多加了一层防护：它会监测安全引擎的告警速率，一旦活动偏离正常范围，就发出预警。借助这些工具，你可以更有效地区分应用层攻击与网络层攻击。第 7 层洪泛会推高请求数，但包量仍相对平稳，表现为第 7 层 QPS 上升却没有相应的带宽增长；而较低层的 DDoS 则正好相反。这个对比能够帮助你确认攻击层级，并指导后续响应。

避免误判，并采取正确响应

先排除常见误报情况

促销活动、邮件群发或某篇内容突然爆红，都可能制造出看似“恶意”的流量高峰。在封禁任何来源之前，务必先排除这些情况。先检查你的营销活动日历和社交平台传播情况，再对比来源地区是否符合平时的受众分布。真实用户通常来自你原本服务的区域，而且他们会先打开页面，再请求其中的资源。爬虫大规模抓取或监控机器人也可能抬高请求数。此时可以查看它们是否声明了 User-Agent，以及请求频率是否足够克制。最后，还要确认这次流量峰值不是由不稳定的国际链路导致的重传噪声。重复数据包会抬高流量图，但并不会带来真实用户。

针对不同场景分别应对

如果是真实流量激增，应优先扩容并强化缓存。横向增加 Web worker，提升数据库连接上限，并通过 CDN 分发静态资源。如果业务允许，还可以缓存已渲染页面。这些措施能够在不影响真实用户的前提下有效吸收流量。

如果是 CC 攻击，则需要分层处理。先按来源和接口实施速率限制；再对可疑客户端加入 JavaScript 校验或验证码挑战。随后检查服务器日志中是否存在恶意脚本或已知漏洞利用，因为一台被攻陷的主机也可能正在参与洪泛。如果你怀疑遭受的是网络层攻击，则应立即联系服务提供商做上游清洗。这个层面的 DDoS，通常不是靠主机本地调优就能解决的。要学会根据各自的证据来调查不同类型事件：应用层洪泛会体现在请求日志中，而第 7 层请求风暴往往不会显著推高包量。确认攻击发生在哪一层，就用对应那一层的方法去处理。

通过“带宽与 QPS 是否背离”来判断，依然是识别服务器是否遭受 CC 攻击的最快第一步。只要先做这一项对比，就能避免一开始就在错误层面上猜测。随后再逐层确认：系统响应情况、TCP 状态以及访问日志，都会进一步印证请求模式所揭示的问题。保持冷静，按证据排查。在封禁任何来源之前先验证事实，在怀疑恶意之前也先考虑是否只是需要扩容。CC 洪泛和网络层 DDoS 都会留下各自鲜明的特征，因此必须将解决方案和你确认的攻击层级一一对应。最后，建议你现在就建立正常流量基线。连续一周记录低峰与高峰时段的数据，下一次再发生类似事件时，你会更容易做出准确判断。

常见问题

我多快能判断这是攻击还是正常繁忙？

先把带宽和 QPS 放到同一张图上查看。若两者同步上升，多半是真实需求增加；若 QPS 飙升而带宽基本平稳，则更像是 CC 洪泛。通常几分钟内就能得到初步答案，而不是耗上几个小时。

如果只是短暂宕机，是否就能排除攻击？

不能。攻击者经常通过短时间的 CC 流量突袭，迅速耗尽数据库连接和 worker 池。即便流量很快停止，服务也可能在之后长时间处于异常状态。判断依据应是请求模式，而不是持续时长。

CC 攻击会不会“躲过”我的带宽图？

会。因为单个请求携带的数据量很小，所以带宽图可能几乎不动。此时更应该关注请求速率、并发连接和 CPU 使用情况。相反，网络层 DDoS 通常会立刻在带宽图上表现出来。

在封禁任何来源之前，我应该先检查什么？

先确认来源地区是否符合你的目标用户分布；检查你的营销日历中是否有促销活动或内容爆红；查看 User-Agent 判断是否可能是爬虫。真实流量和恶意流量在路径多样性上差异明显，因此在采取措施前，一定要先阅读日志。

什么时候应该联系服务提供商，而不是继续调优服务器？

当你看到包量和带宽同时飙升时，就应该联系服务提供商。这个特征通常意味着遭遇的是网络层 DDoS，而上游清洗通常比主机本地调优更有效。至于应用层 CC 洪泛，则仍应主要在服务器侧进行处理。