摘要：# CC攻击来了，别只盯着IP，先看看谁在“玩命”点 昨天半夜，一个做电商的朋友突然给我打电话，声音都变了：“后台崩了！全是刷单的，不对，这量也太大了……” 我让他赶紧把日志拉出来看。好家伙，一个注册才三天、名叫“批发王”的账号，在一分钟里，对着商品详…

CC攻击来了，别只盯着IP，先看看谁在“玩命”点

昨天半夜，一个做电商的朋友突然给我打电话，声音都变了：“后台崩了！全是刷单的，不对，这量也太大了……”

我让他赶紧把日志拉出来看。好家伙，一个注册才三天、名叫“批发王”的账号，在一分钟里，对着商品详情页的某个查询接口，发起了近两千次请求。这哪是正常用户？这分明是扛着水枪往你服务器接口上滋水，不冲垮不罢休。

这就是典型的CC攻击，但和我们常说的“拿IP硬怼”不太一样。它更狡猾，更像一次“精准爆破”。攻击者早就不是无脑扫了，他们拿着偷来或注册的账号，伪装成正常用户，专挑你那些耗资源、但又必须开放的API接口下手。

很多朋友一提到CC防御，脑子里蹦出来的就是“封IP”、“上验证码”。这没错，但有点像是“城门失火，殃及池鱼”——你把城门关了（封IP），好人也进不来了；你让每个进城的人都做套奥数题（验证码），用户体验也就崩了。

说白了，防御的核心思路得变一变：别只认IP，得认“人”——也就是用户角色。

一、为什么“一刀切”的限速总误伤自己人？

我们之前常用的，是基于IP的请求频率限制。比如，一个IP地址每秒最多请求10次。这方法简单粗暴，初期有效，但现在问题很大：

1. 误杀严重：公司、学校、大型小区往往共享一个公网IP出口。一个人使坏，全办公楼的人跟着遭殃，页面都刷不开。我见过最冤的是一个咖啡馆的WiFi，因为有个客人在刷票，导致整个咖啡馆的IP被拉黑，老板差点以为被同行搞了。
2. 绕过成本低：对攻击者来说，换IP（代理IP池、秒拨IP）的成本太低了，几乎可以忽略不计。你封100个，他还有10000个等着。
3. 打不中要害：攻击者手里有海量账号。他可以用1个IP，轮番使用100个账号来攻击，你的IP限速规则形同虚设，但你的数据库和业务逻辑已经被这100个“合法”账号拖垮了。

所以，我们必须把视线从网络层（IP）往上抬，抬到业务层。在这里，每个用户都被打上了不同的标签：未登录游客、普通注册用户、VIP会员、内容管理员、超级管理员……

不同角色，对网站资源的消耗能力和合理访问频率，是天差地别的。

二、基于用户角色的限速：把好钢用在刀刃上

思路其实很直白：给不同身份的人，发放不同额度的“请求信用卡”。

• 未登录游客（匿名用户）：这是最需要“严管”的群体。他们能访问的页面有限（通常是首页、公开内容），动作也简单（浏览）。对他们的限速要最严格。比如，对 /api/product/list 这个查询接口，匿名IP每10秒最多请求20次。一旦超了，立刻弹出图形验证码，再超就临时封禁IP一段时间。这里的逻辑是：如果你真是正常用户，登录一下就能获得更好的体验；如果你不是，那我就要给你设置重重障碍。

• 普通注册用户：他们已经付出了注册成本，是网站的基本盘。额度可以适当放宽，但也要区分核心操作和非核心操作。比如，浏览商品、加入购物车可以宽松；但“提交订单”、“领取优惠券”这类涉及核心资源和羊毛党重灾区的接口，必须设置严格的次数限制（如每用户每分钟最多提交5次订单）。很多电商的优惠券被一秒抢空，问题往往就出在这里——对“领取”接口没有做用户维度的次数限制。

• VIP/付费用户：这是你的金主爸爸，体验必须优先保障。他们的请求额度应该最高，甚至可以对某些读接口不做频率限制（但写接口依然要保底防护）。这里的平衡在于：既要防止攻击者盗用高权限账号作恶（所以写操作必须限），又要确保付费用户的流畅感。 我自己的经验是，给VIP用户单独配置一套更宽松的规则集，并配合实时的业务监控，一旦发现某个VIP账号行为异常（比如突然开始疯狂爬数据），立刻告警，由运营人工介入核实，而不是程序自动封禁。

• 后台管理员：这是最危险的维度。一个泄露的管理员账号，攻击者可以直接调用后台接口进行毁灭性操作。对管理员账号的所有操作，尤其是删除、修改全局配置等，除了需要二次认证（如手机令牌），还必须记录每一次请求的详细日志，并设置低频限制。比如，“删除全站文章”这种接口，同一个管理员账号24小时内只能成功调用一次。这招防的就是“内鬼”和“撞库”。

三、落地实操：怎么配才不算“白配”？

道理都懂，但一配置就抓瞎。分享几个我踩过坑的要点：

1. 别拍脑袋定数字：所有频率阈值（比如“每秒多少次”），一定要基于历史正常用户的行为日志来定。去分析你过去一周的日志，看看99%的正常用户，在对应接口上的最高频率是多少，然后在这个基础上放宽20%-50%作为初始阈值。这叫基线学习，比任何专家的猜测都靠谱。

2. 动态调整是关键：限速规则不能是死的。比如大促期间，正常用户的访问频率肯定会暴增。这时候，你的规则引擎要能联动营销系统，临时、自动地给所有用户（或参与活动的用户）提升额度。等大促结束，再自动恢复。这需要你的风控系统和业务系统有API打通。

3. “软拒绝”优于“硬拒绝”：用户触发了限速规则，别直接返回一个冷冰冰的“429 Too Many Requests”。体验太差。更好的做法是：

   • 首次超限：请求正常响应，但在响应头里加一个友好提示：“您操作有点快哦，歇口气儿~”。
   • 再次超限：将请求放入延迟队列，让它等几秒再处理，同时前端提示“排队中，请稍候”。
   • 持续超限：再弹出验证码进行人机校验。 这种梯度处置，既能过滤机器流量，又能最大程度保住真实用户的体验。

4. 别忘了“聚合维度”：单一维度有漏洞，那就多维叠加。一个终极策略可以是：“同一用户ID，在同一个核心接口上，每分钟不超过N次；并且，这些请求如果来自超过M个不同的IP，则触发高危告警。” 这就同时防御了“单账号高频刷”和“盗号后分散IP攻击”两种场景。

四、最后说句大实话

没有任何一种防护方案是银弹。基于用户角色的访问控制，是CC防御体系中至关重要、但经常被忽略的一环。它补上了IP限速的短板，让防护变得更精细。

但你也别指望配完这个就高枕无忧。它必须和Web应用防火墙（WAF）的规则库、精准的IP黑白名单、业务逻辑上的防重放攻击机制等等，组合在一起，才能形成一个立体的防御网。

真正的安全，不是买一个最贵的“高防”产品扔那儿就完事了。它更像是一场持续的“猫鼠游戏”，需要你真正理解自己的业务，知道数据从哪里来，用户是谁，坏人可能怎么下手。然后，把你的防护资源，像好钢一样，精准地用到刀刃上。

如果你的后台还在用一套规则对付所有人，是时候去看看日志，想想该怎么给你的用户们“分分级”了。毕竟，让VIP会员和爬虫机器人一个待遇，这生意做得可就有点亏了。