做了这么多年网站运维我最怕的不是服务器宕机而是业务还在、请求也正常但用户就是感觉卡得要死。这种场景十有八九是碰上了CC攻击。CC攻击检测这件事最让人头疼的地方在于它看起来和正常流量几乎一模一样CPU高、数据库慢、页面转圈你查来查去又找不到一个明确“凶手”。这篇文章就把我这些年实际用过的、新手也能上手的CC攻击检测方法做个汇总从看日志、看连接数、看监控指标到借助WAF和脚本自动化尽量用大白话讲清楚每个方法背后的原理和适用场景。不管你是一个人维护个人站还是在小团队里负责系统照着这套思路基本能在十分钟内判断出“是不是CC、打到哪个接口、需不需要立刻封禁”。1. 认识CC攻击为什么它这么难发现1.1 CC攻击到底是什么CC攻击的完整叫法是Challenge Collapsar听起来很学术我一般把它理解为“业务逻辑攻击”。传统的大流量攻击靠带宽硬砸把机房出口打满攻击特征很明显防火墙很容易发现。但CC攻击模拟的是真实用户的访问行为它不追求流量大而是追求“请求多、消耗高”。打个比方普通攻击是拿大锤砸门店CC攻击是雇一群人进店只试不买把营业员累到虚脱但你没有理由赶走顾客。放到技术场景里CC攻击往往集中打某些“价格不菲”的接口比如登录、搜索、下单、查询这些功能每次请求都要查数据库、做计算、拼页面服务器处理一个请求的成本远高于攻击者发一个请求的成本。攻击者不需要多高的带宽只需要大量并发请求就能把服务器的CPU、内存、数据库连接池迅速耗尽。1.2 常见的四种攻击形态新手最难的地方在于CC攻击不是一个固定招式它至少有四种常见形态每种的特征都不一样。第一种是粗暴型。攻击者直接用大量代理IP、云主机发起高频请求目标和接口很集中日志里会出现大量相同URL、相同UA的请求。这种其实最好识别只要看流量统计就能发现问题。第二种是慢速型。代表是Slowloris这种思路攻击建立连接之后一直不发送完整请求或者以极慢的速度发送把服务器的连接池和线程池占满。这种攻击流量很低日志里甚至看不到完整请求记录但服务器的可用连接数会越来越少。第三种是代理池型。攻击者使用分布广泛的代理IP每个IP只发少量请求整体频率也不算夸张但总量叠加起来非常可观。这时候单看某个IP根本看不出异常必须从总请求量、接口分布、用户行为特征来综合判断。第四种是精准打击型。攻击者分析过你的业务知道哪个接口最消耗资源比如报表导出、批量查询、短信发送接口然后专门打这几个点。这种攻击最隐蔽因为请求看起来完全正常只是数量比平时多几倍。1.3 新手为什么容易漏掉我在很多次复盘中发现CC攻击漏掉的原因不是检测工具不够而是思路没转过来。新手往往盯着带宽看发现带宽占用不高就以为“不是攻击”但CC攻击本来就不怎么占带宽它占的是应用处理能力。还有一层原因是现在很多站点前面挂了CDN、云WAF源站看到的所有请求都来自CDN节点攻击者借CDN转发掩护源站日志清一色都是CDN的IP你根本不知道真正的攻击IP长什么样。另外CC攻击常常只打某一个接口。首页、静态资源都正常甚至其他页面都很快只有接口慢或者偶尔报错。这种“局部故障”很容易被当作代码Bug去排查耗费大量时间才发现是攻击。2. 从访问日志里找异常最容易被忽略的第一步2.1 一条日志里能看出什么不管站点前面有没有CDN源站的访问日志永远是第一手证据。我见过很多新手系统都卡成幻灯片了还不知道去翻日志。这个问题一定要改因为日志能告诉你“谁在什么时间访问了什么”这是排查一切问题的起点。最常见的Nginx日志格式大概长这样log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for;$remote_addr是访问来源IP$time_local是访问时间$request是请求方法、路径和协议$status是状态码$http_referer和$http_user_agent分别对应来源页面和客户端标识。如果站点前面有CDN或高防还要看$http_x_forwarded_for因为$remote_addr会变成CDN节点地址。看日志的时候先不要着急用复杂工具直接打开日志文件肉眼翻一翻最近一两分钟的内容。正常的用户访问是零散的、随机的请求的URL五花八门状态码也正常。如果看到某个URL反复出现或者某个IP在短时间内刷出大片日志心里就要有数了。2.2 用现成命令找出异常IP肉眼只能看个大概要精准定位还得靠命令行。这里给你一条新手必备的Linux组合命令cat access.log | awk {print $1} | sort | uniq -c | sort -nr | head -20这条命令的作用是读取访问日志用awk取第一列也就是客户端IP排序后统计每个IP出现的次数再按次数降序排列取前20行。输出的第一列是请求次数第二列是IP地址。如果看到某个IP的请求数比第二名高出几个数量级比如第一名请求了5万次第二名只有300次那基本可以断定这个IP有问题。我实际操作中会再多看一步把请求数最高的IP和具体URL组合起来看这样能判断对方在打哪个接口grep 目标IP access.log | awk {print $7} | sort | uniq -c | sort -nr | head -20如果这个IP集中访问同一个接口重复几百上千次说明攻击目标非常明确。另外要留意$http_user_agent很多攻击脚本的UA要么为空要么是乱写的和正常浏览器的UA差别很大。2.3 按接口维度统计请求量只看IP还不够因为代理池型攻击会把请求分散到大量IP上单个IP的请求量可能不高。这时候可以从接口维度去统计让“被打的接口”自己站出来。还是用命令行第7列是请求路径cat access.log | awk {print $7} | sort | uniq -c | sort -nr | head -30正常业务下访问量最高的通常是首页和几个核心页面但不会高到离谱。如果某个接口一小时内涨了几十倍并且它的耗时和错误率同步上涨基本就是攻击目标。这里有个细节要注意很多URL里带了用户ID、订单号这类动态参数比如/order/100023/detail直接统计会把每个订单都当成独立URL看不出规律。正确的做法是先做归一化处理再用正则把URL里的数字替换成固定标识再聚合统计。我通常写一个几十行的Python小脚本干这个活比用纯命令行方便很多。2.4 日志检测的边界日志方案最大的问题是“事后诸葛亮”。访问日志是请求结束后才写入的就算你一分钟看一次攻击也已经持续了一分钟。对于突发性强的CC攻击这几分钟可能就已经把数据库打挂了。而且如果你的站点有多个后端节点日志分散在每台机器上单一节点看到的请求量会被稀释。这也是为什么日志只能用来做“确认”不能完全依赖它做“发现”。更可靠的思路是结合实时信号把日志和系统指标放在一起看。所以我建议把日志排查作为第一步但线上监控和实时检测必须同时做好。3. 实时连接数与系统指标攻击正在发生时的“体温计”3.1 查看当前TCP连接状态发现站点变慢第一件事是先登录服务器看一眼连接状态。Linux下最常用的是ss命令比netstat快不少。先看整体状态分布ss -ant | awk {print $1} | sort | uniq -c | sort -nr输出会列出各种连接状态的数量比如LISTEN、ESTABLISHED、TIME_WAIT、SYN_RECV。正常情况下一台Web服务器上的ESTABLISHED连接数和服务器的并发处理能力有关几百到几千都有可能但不会突然暴涨。SYN_RECV大量增加说明可能有SYN FloodTIME_WAIT多一般是短连接关闭后的正常残留不用太担心真正需要关注的是ESTABLISHED异常攀升。CC攻击发生时攻击者建立的连接会长期占用着不放表现为ESTABLISHED数量快速上涨并且很难降下来。配合uptime看系统负载如果负载持续走高而连接数也在涨八成就是在被CC。3.2 快速定位连接数最多的IP确定连接异常后下一步就要揪出是谁占用连接。用这条命令统计当前连接数最多的IPss -ntu | awk {print $5} | cut -d: -f1 | sort | uniq -c | sort -nr | head -20这条命令会把每个连接的远端IP扣出来统计次数。理想情况下普通用户访问完页面连接很快就释放了单个IP很难同时保持几十条连接。如果看到某个IP有几百甚至几千条ESTABLISHED连接基本可以判定是异常来源。不过这里要留个心眼如果你的站点挂到了CDN后面源站看到的IP都来自CDN运营商这时候单个CDN节点IP连接数高是正常的不能一刀切。更好的做法是在WAF或者安全网关层做防护源站本身只允许CDN回源IP访问这样即使攻击者打到了源站也只能看到回源节点IP无法直接定位到真实攻击IP。关于这一点后面章节还会专门说。3.3 Nginx的请求计数怎么读除了看系统连接Nginx自带的stub_status模块也是个好东西。它在路径/nginx_status下输出一组关键计数开启方式是在server配置里加几行location /nginx_status { stub_status on; access_log off; allow 127.0.0.1; deny all; }访问之后会看到类似这样的输出Active connections: 245 server accepts handled requests 85012 85012 698730 Reading: 3 Writing: 12 Waiting: 230重点是requests字段它反映的是Nginx启动以来的累计请求数。真正有价值的不是绝对值而是增量。每隔几秒刷一次比如curl -s http://127.0.0.1/nginx_status sleep 5 curl -s http://127.0.0.1/nginx_status把两次的requests数值相减再除以5秒就能算出每秒请求量。如果这个数从正常情况下的每秒几十次突然涨到几百上千次而且持续时间长达几分钟那八九不离十是CC攻击。加一个crontab每隔一分钟把这个差值记下来再用一个阈值得出告警信号就形成了一套最简单的请求量监控。3.4 系统负载和带宽怎么配合看CC攻击会导致CPU使用率、数据库线程数、进程数同步飙高但带宽占用不一定高。这就好办多了你可以用top看CPU和load average用mpstat看单核情况用free -h看内存是否吃紧。如果CPU被消耗得很高再看是用户态还是内核态。正常业务流量大时用户态CPU高是因为在跑PHP、Java这些业务代码CC攻击打到静态资源时会大量占用内核态和网络中断处理打到动态接口时用户态CPU和数据库连接同时飙升。带宽方面iftop或nload都可以实时看流量如果带宽不高但机器慢得离谱先把注意力放到应用层和数据库上强拉带宽排查反而浪费时间。综合这几个指标我的判断习惯是三步走先看连接数和请求量有没有异常暴涨再看系统负载和进程数有没有同步升高最后定位到具体接口确认是不是CC。这条路径对新手来说最友好不需要装额外监控工具现有的Linux命令就够用。4. 业务侧信号数据库慢查询与接口响应突变4.1 数据库连接池为什么先崩很多CC攻击的目标接口都牵扯数据库所以说CC攻击最先击穿的往往不是应用服务器而是数据库连接池。我见过太多情况应用服务器CPU还没怎么涨数据库连接数直接打满后面所有请求都在排队等连接。排查的时候第一时间切换到数据库这边看状态。比如MySQL里执行SHOW STATUS LIKE Threads_connected; SHOW STATUS LIKE Threads_running;Threads_connected是当前打开的连接数Threads_running是正在执行语句的线程数。当这两个数值快速上涨并且逼近配置上限时说明有大量请求在消耗数据库资源。再看慢查询日志如果大量之前从未出现过的慢SQL突然刷屏而且这些SQL都来自同一个业务接口那就要怀疑是接口被针对了。有个很容易踩的坑是看到慢SQL第一反应是去优化SQL。实际上很多慢SQL在正常压力下根本不会慢是并发一高锁竞争加剧才导致每条查询都变慢。这时候再怎么优化效果都有限先把流量压下去让连接数降下来慢SQL自己就消失了。4.2 请求耗时的长尾现象应用侧最直观的信号是接口响应时间出现“长尾”也就是P95、P99耗时突然上涨。正常业务下绝大多数请求都在几百毫秒内返回即便有个别慢请求也不影响整体体验。攻击来临时大量请求堵在服务端排队前一个请求没处理完后一个请求只能干等表现为接口整体变慢P99耗时甚至从原来的1秒涨到几十秒。不需要昂贵的APM工具Nginx访问日志里就有相关字段。如果你的日志格式里加了$request_time直接按耗时排序就行cat access.log | awk {print $NF, $7} | sort -rn | head -20注意每条日志的字段位置要根据你自己的日志格式来调整。看到耗时最高的请求集中在某个URL并且这些请求来自异常IP或者缺少正常Cookie的客户端基本就能锁定攻击目标接口。4.3 错误码比例突然异常除了耗时变长状态码分布也是重要信号。CC攻击打到应用层后容易出现几种典型结果。如果连接被服务器拒绝或者超时会产生大量499如果动态处理能力耗尽后端的PHP-FPM或Java线程池无法响应会产生502如果请求量太大导致CPU过载、处理不过来可能出现504。Nginx层面的“连接队列溢出”也会导致客户端端看到连接被重置。我排查的时候会专门看每分钟内各状态码的数量cat access.log | awk {print $9} | sort | uniq -c | sort -nr正常业务下200为主少量302、404、400。如果某个时间段突然出现大量5xx和499配合前面几条检测信号就能确认系统正处于过载状态。4.4 一个现场排查记录举一个我处理过的典型例子。一个某跨平台业务系统的站点突然反馈页面卡顿我先看系统负载2核4G的机器load average接近8CPU几乎打满。再看连接数SSH到机器上用ss -ant一看ESTABLISHED连接数比平时高了5倍。排到第三层看Nginx日志发现有一个优惠券查询接口一小时内请求量暴涨原因是某个IP段发起了大量带相同Cookie特征但IP不断变化的请求。整个定位过程大概花了不到十五分钟靠的就是“系统负载—连接数—日志URL”这条链路。确认攻击后先在Nginx里对该接口做了基本防护配置再对异常IP段进行封禁网站恢复正常。事后我复盘觉得真正拖慢定位进度的往往是“要不要确认是攻击”这个心理过程。舍得多看几张图、多跑几条命令定位并不难。5. 用自动化工具和策略把检测变成常态5.1 接入WAF和高防的思路手动排查毕竟不能24小时盯着所以生产环境还是要借力自动化工具。现在各大云服务商都有Web应用防火墙和高防产品它们对CC攻击的识别思路是统计连续时间窗口内的访问频率、单IP请求速率、URL分布、UA指纹再结合验证码、频率限制、IP封禁等手段进行拦截。选产品的时候不要看宣传里的“防多大流量”要看它对应用层CC的检测灵敏度。建议优先选带“人机校验”能力的WAF因为CC攻击本质上是“模拟人类”的行为而验证码是机器和人类的天然分界线。把WAF前置到源站可以让攻击流量在边缘节点就被过滤掉源站只接收清洗后的干净流量这是成本最低的高效方案。5.2 自写脚本实现自动封禁没有预算买高防也有开源自建的路子。最简单的做法是写一个定时脚本周期性地从日志里统计高频IP超过阈值就自动封禁。这里我给出一个可以改着用的思路不涉及具体业务代码重点是理解判断逻辑#!/bin/bash # 每分钟统计access.log中访问次数超过300的IP并通过iptables临时封禁 threshold300 log_file/var/log/nginx/access.log hits$(mktemp) tail -6000 $log_file | awk {print $1} | sort | uniq -c $hits awk -v th$threshold $1 th {print $2} $hits | while read ip; do /sbin/iptables -I INPUT -s $ip -j DROP echo $(date %F %T) blocked $ip /var/log/cc-block.log done rm -f $hits这个脚本有几个关键点。第一用tail -6000只取最近一段日志避免统计过期流量第二阈值不能定死要根据业务基线和机器处理能力调整第三用iptables封禁IP之后被误封的IP虽然会被放开但需要一套解封机制不然会累积越来越多的黑名单条目。更保险的做法是给封禁记录加时间戳用一个定期任务把封禁超过30分钟的IP自动解封。5.3 人机验证和JS挑战的放置位置频率限制只能挡住“傻攻击”挡不住请求速率不高但总量很大的代理池攻击。这时候就需要在关键路径上引入人机验证。简单说就是在访问某些高风险接口之前先给客户端下发一段JavaScript浏览器能正常执行然后带上Cookie继续访问而攻击脚本不会解析JS拿不到合法Cookie就会被挡住。人机验证的位置有讲究。如果放在全站会影响真实用户和SEO抓取不太可取放在登录接口、查询接口这类动态业务入口更合理。另外要特别注意API应用很多服务端到服务端的API没有浏览器环境没法执行JS这种场景只能靠签名校验和频率限制不能用统一的人机验证方案。新手设计防护策略时容易把一套方案套到所有接口上结果要么误伤用户要么无效告警这方面一定要根据业务路径区分对待。5.4 告警通知要打到手机上再好的检测策略没人看到也是白搭。我强烈建议把监控和告警打通让异常发生的第一时间就通过办公协作软件的机器人通知发送到手机。典型告警触发条件有这么几个每分钟请求量超过正常值的三倍单个IP连接数超过100P99耗时超过2秒5xx错误率超过1%。这些阈值一开始可以宽松一点宁可多报几次也要先积累业务基线。运行一段时间后再根据误报情况收紧参数。脚本层面可以直接写一个检测脚本发现异常就调用Webhook接口发送信息配合crontab每30秒跑一次。这样即使你在睡觉站点被CC手机也会立刻弹消息处理效率能高一大截。6. 别把正常流量误伤常见误判场景与处理6.1 高并发正常业务长什么样CC检测做得再准也免不了和正常业务流量混淆。最常见的就是运营活动比如限时秒杀、限量抢购、优惠券领取。这类场景下某个接口确实会被大量用户同时访问单个IP请求频率高整体请求量瞬间飙升用前面的方法判断几乎每个指标都符合CC特征。怎么区分看两点。第一点是时间特征正常活动通常有明确的时间窗口比如10点开放流量在10点准时爆发持续5到10分钟就会回落攻击通常没有明显的时间规律可能半夜两点突然冲上来。第二点是请求内容正常用户抢购时会访问活动首页、商品详情、下单接口路径是连续的还会带referer、Cookie等上下文攻击请求往往只打一个接口缺少完整的页面浏览路径。所以我在活动期间会把告警阈值临时调高预先做好扩容同时在排查时第一句话不是“封IP”而是“今天有没有活动”这句话能挡掉一半误判。6.2 爬虫和CC攻击的边界搜索引擎爬虫、数据采集工具、监控系统探活这些也能造成高频请求。区别在于善意爬虫通常有一个明确的UA标识比如常见的搜索引擎爬虫的UA里会带自己的名字CC攻击则可能伪装UA但也可能直接用裸UA或者浏览器UA。看到某个IP请求频率高先用UA过滤一遍。如果UA明显是搜索引擎爬虫而且访问路径正常、robots协议遵守得不错一般不用管或者可以在Nginx层对其单独限速而不是封禁。如果是模拟浏览器UA的高频请求再配合“是否只打动态接口”“请求间隔是否规律”“是否带Cookie”这几个维度去判断。这里有个特别隐蔽的坑有些采集器会随机生成UA每次请求的UA都不一样看似行为人化实际是程序行为。对这种机器特征可以通过行为一致性来判断——真正的人每次访问之间总是有思考时间的请求间隔呈现出“短-短-长-短”的自然分布机器访问间隔通常非常均匀或者严格卡在某个时间点上。用一小段时间的请求记录去做间隔分析往往能发现规律。6.3 连接数高不一定代表攻击还有两类场景不能光看连接数下结论。一类是WebSocket、HTTP/2长连接。长连接的特点是连接建立后长时间不释放单个IP保持几十条连接也很正常这时候ESTABLISHED数量虚高但服务器负载并不高CPU、内存都正常那就不是攻击。另一类是反向代理架构。如果Nginx和上游应用之间用的是proxy_pass那么Nginx到上游之间会产生大量内部连接这部分连接也会被ss统计到但它属于系统内部流量和外部攻击没直接关系。排查时要用ss -tnp查看具体的进程连接关系把外部访问连接和内部转发连接区分开不然容易被自己“吓”到。6.4 误封之后怎么快速恢复自动封禁脚本虽然好用但误封真实用户的事情我也遇到过。最典型的是办公网络出口IP共享一栋楼几十个人共用同一个IP某个同事的爬虫脚本或者某个员工反复刷新导致整个出口IP被封所有同事一起“掉线”。处理这个问题必须留后路。封禁脚本要能解封简单做法是为每条封禁规则附带一个到期时间例如在脚本里把封禁操作记录到文件用一个辅助脚本定期清理超过30分钟或60分钟的规则。管理员还可以在WAF管理后台手动放行指定的IP段或者让用户访问一个验证页通过验证后自动加入临时白名单。原则是“宁可放宽一小会儿也不要让真实用户被长时间挡在外面”。6.5 快速排查速查表综合这些经验我把排查时主要看的指标和判断依据整理成了一张速查表检测维度正常基线疑似CC信号确认动作单IP请求数分钟级低于阈值零散分布某IP请求数达到几百甚至几千查看该IP访问的URL是否单一单接口请求总量平稳波动短时间内暴涨数倍以上结合耗时和错误码验证是否核心接口ESTABLISHED连接数平稳与并发相符持续上涨且不回落统计连接数Top IP确认是否集中每秒请求数固定范围超出基线3倍以上刷新查看是否持续而非瞬时CPU/负载可用余量充足长时间接近或超过核数观察CPU是内核态还是用户态高数据库连接数稳定到达上限或者缓慢持续攀升查看慢日志、活跃线程数耗时P99可接受从几百毫秒涨到数秒以上聚焦耗时最高接口的访问来源错误率接近05xx/499比例突增区分是网络层超时还是应用层过载这张表不是用来硬套的它更像是一个排查清单。不同的业务系统差异很大关键是要先记录自己系统的正常基线没有基线就没有“异常”可言。7. 一次完整排查过程复盘7.1 现象与最初判断有一次我负责维护的某个业务站点在下午三点左右开始异常。外部反馈是“页面能打开但登录和查询功能很卡”内部监控显示应用服务器CPU接近90%数据库连接数达到上限。第一轮排查时我们一度怀疑是代码层面出了死循环因为上报错误集中在同一个查询接口而且该接口在最近的版本中刚发过更新。这个插曲很值得新手注意不要因为“最近改过代码”就默认故障是改出来的。我们当时排查了将近二十分钟代码才发现这个接口在旧版本同样存在最近发布版本只是碰巧调整了它旁边的功能并没有改变接口本身逻辑。后来回到数据和流量层面分析才知道问题出在流量异常增长上。7.2 分步排查的实际路径我们把排查顺序重新整理成了更系统的流程。第一步看全局监控大屏。CPU高、负载高、数据库连接打满三个指标同时异常说明不是单一组件的问题大概率是入口流量异常。第二步看Nginx日志。重点统计最近十分钟每个URL的请求数和每个IP的请求数。结果显示某个“订单状态查询接口”的每分钟请求量是平时的二十倍以上请求IP分布并不集中但请求行为高度一致大部分请求都集中在同一个接口而且不访问别的页面。第三步看数据库侧。慢查询数量暴增慢SQL都指向订单状态表的查询和刚才定位的接口完全对应。到这里基本已经能认定是攻击了——真正的用户不会只盯着一个接口用这么极端的频率刷新而且这些请求的时间间隔非常规律。第四步看攻击来源。因为站点前面挂了一层转发服务源站看到的IP来源比较分散我们通过转发服务提供的访问信息和请求特征模板判断出这是有组织、有预谋的恶意访问而不是某几个IP随手刷出来的。7.3 处置动作与恢复过程我们当时的处置动作分了三步。第一步是快速止损在转发服务控制台把该接口的每秒请求阈值限制住超出部分直接返回错误码。这一步用了不到五分钟接口请求量立刻降到正常范围数据库连接数慢慢回落页面恢复可访问。第二步是保留证据把异常请求的日志片段保存下来包括完整请求头、UA、Cookie、referer以及时间序列。这些信息可以用来追查攻击来源、提取攻击特征万一后续封禁策略需要精细化调整也有据可查。第三步是调整防护策略把该接口纳入人机验证保护范围同时设置按IP访问频率限制。由于这个接口本身需要登录态我们在验证逻辑上做了定制既不阻断正常登录用户的访问又能拦截无登录态的批量请求。从发现异常到核心服务恢复总耗时大约四十分钟。真正用来封禁和调整配置的时间很短不少时间浪费在没有在第一时间给出“这是攻击而不是代码故障”的判断上。7.4 复盘后的长期改进这次事件之后我们做了三件固化下来的事。第一是把所有核心动态接口的响应时间、请求量做成独立监控看板并且设定了基线告警不再等到用户投诉才发现问题。第二是在源站和外部访问之间增加了针对异常请求特征的自动识别让机器干机器擅长的事。第三是形成了一份现场处置手册里面写清遇到突发流量时先看哪些指标、跑哪些命令、找哪几个人避免每次出问题都像无头苍蝇一样乱撞。这些改进的核心思路只有一条把“检测能力”从“人脑”搬到“系统”里。CC攻击的手法日新月异但检测方法翻来覆去就是看日志、看连接、看指标、看行为这几件事。新手如果能把这套方法串联起来再结合自动化工具遇到CC攻击就不会再手足无措。我个人在实际操作中最大的体会是检测CC攻击不是找到一个“银弹”指标而是要让多个信号互相印证。单看请求量可能误伤活动流量单看IP可能对代理池攻击失效单看连接数可能被长连接干扰。把日志、实时连接、系统负载、数据库指标、业务响应耗时放一起看那些藏在“正常”外衣下的攻击自然就会露出马脚。