摘要：# 当你的网站被“点穴”：CC攻击如何让业务瞬间“瘫痪”，以及我们能做点什么 我前两天跟一个做在线教育平台的朋友聊天，他叹了口气说：“上个月被‘点穴’了半小时，客服电话被打爆，老板的脸都绿了。” 他说的“点穴”，指的就是CC攻击。这玩意儿不像DDoS那样…

当你的网站被“点穴”：CC攻击如何让业务瞬间“瘫痪”，以及我们能做点什么

我前两天跟一个做在线教育平台的朋友聊天，他叹了口气说：“上个月被‘点穴’了半小时，客服电话被打爆，老板的脸都绿了。” 他说的“点穴”，指的就是CC攻击。这玩意儿不像DDoS那样洪水漫灌，搞大场面，它更像精准的“针灸”——专挑你最疼的地方扎，比如登录接口、搜索页面或者支付环节。

说白了，很多老板觉得上了防火墙就高枕无忧，结果CC一来，防火墙报表一切正常，CPU也没跑满，但真实用户就是死活打不开网页。这种憋屈，干运维的兄弟应该都懂。

一、 CC攻击：不是让你的服务器“炸了”，而是让你的用户“没了”

我们先得把概念掰扯清楚。很多人，包括一些销售，会把CC攻击和DDoS混为一谈。其实差别大了去了。

• DDoS（分布式拒绝服务）：好比找来一千万个人，同时挤向你公司大楼唯一的旋转门。目标是把门挤垮，让整栋楼谁都进不去。它追求的是流量压垮。
• CC（Challenge Collapsar，挑战黑洞，现在泛指HTTP/HTTPS层攻击）：它不挤大门。它可能只派出一百个人，但每个人进去后，都直奔服务台，拿着本《十万个为什么》开始问一些需要后台疯狂查数据库的复杂问题。这一百个人把所有的服务员都霸占了，导致后面真正想办业务的顾客（正常用户）永远排不上队。它追求的是资源耗尽。

所以，CC攻击最阴险的地方在于：从监控大屏上看，你的网络带宽稳如老狗，服务器CPU可能也就跑到70%，但你的Web应用就是不可用了。 因为攻击者消耗的是数据库连接、应用线程、Redis查询次数这些更深层的、宝贵的业务资源。

我见过最典型的案例，是一个电商网站在大促前被搞了。攻击者用几千个“肉鸡”（被控制的电脑），持续高频地访问商品详情页——那个页面调用了十几次数据库，还有复杂的促销规则计算。结果就是，数据库连接池被瞬间占满，新的正常用户请求全部卡在“连接数据库”这一步，页面一直转圈圈。而与此同时，网络流量监控上，几乎看不出任何异常波动。

这种场景，你是不是觉得后背一凉？你的源站如果还这么“裸奔”着，心里其实已经有答案了。

二、 SLA成了废纸？当可用性承诺遭遇“精准打击”

现在但凡是个云服务商或者IDC，都会跟你签SLA（服务等级协议），拍着胸脯保证99.9%甚至99.99%的可用性。听起来很美，对吧？

但这里有个坑，很多朋友踩过：SLA保障的往往是“基础设施”的可用性。比如，云主机本身是不是在线，网络链路是不是通畅。而CC攻击破坏的是“应用层”的可用性。你的服务器好好的，网络也通着，但你的网站就是“服务不了用户”。

这就好比你租了个铺面，房东保证房子不倒、水电有通（基础设施SLA）。结果有一群人天天来你店里，不买东西，就围着柜台问东问西，把真正的顾客全挡在外面。你的生意做不成，你能怪房东吗？房东的SLA可没管这个。

所以，当CC攻击来袭，你指着SLA去找云厂商理论，对方很可能一脸无辜：“亲，我们的监控显示您的ECS运行状态和网络IO都是正常的哦。” 这时候，你手里的SLA协议，可能真就跟一张废纸差不多。

很多所谓的高防方案，PPT写得天花乱坠，真遇到这种针对性的CC，立马就露馅了。因为它可能只在网络层做粗放式的流量清洗，根本识别不了这些“伪装成正常用户”的恶意请求。

三、 别硬撑了：从“被动挨打”到“主动设防”的实用思路

那怎么办？坐以待毙肯定不行。基于我这些年看过和参与过的案例，有几条实实在在的措施，比那些空洞的“建议”管用。

1. 源站隐藏是“必选项”，不是“可选项” 这是第一条，也是成本最低、效果最显著的一条。千万别让攻击者直接摸到你的真实服务器IP。 把你的服务器放在高防IP、高防CDN或者WAF后面，让这些防护节点作为“前台”替你接待所有访客。攻击者打的永远是防护节点的IP，你的源站IP藏得好好的，压力自然就小了一大半。这就好比你把公司注册在园区，前台有保安，闹事的人连你办公室在几楼都找不到。

2. WAF规则别只会用“默认套餐” WAF（Web应用防火墙）是防御CC的核心武器，但很多人配置完默认规则就扔那不管了，这相当于买了把好枪却不上子弹。你得根据自己业务的特点去定制规则：

• 针对登录接口：设置单IP在短时间内的失败尝试次数限制。比如，一分钟内同一个IP密码错误5次，就把它临时封禁10分钟。
• 针对搜索/查询接口：限制单IP的请求频率。正常用户一秒点一次搜索顶天了，如果发现某个IP一秒发几十次搜索请求，直接拦截。
• 人机验证（Captcha）关键时刻要敢用：在关键业务路径，比如登录、提交订单前，弹出滑动验证码。虽然对用户体验有一丁点影响，但能有效拦住99%的简易攻击脚本。别怕被用户骂，真被CC打瘫了，用户骂得更狠。

3. 业务自身要“抗揍”一点 技术防护是盾牌，业务架构优化是内功。有些地方稍微改改，就能大幅提升抗CC能力：

• 缓存，缓存，还是缓存：把那些频繁访问、又不经常变的数据（如商品信息、文章内容）狠狠怼到Redis或Memcached里。攻击者请求过来，直接从内存返回，不查数据库，消耗的资源可以忽略不计。
• 给数据库“减负”：优化慢SQL，避免全表扫描。有些CC攻击就是故意触发你的慢查询，来拖死数据库。
• 动静分离：把图片、JS、CSS这些静态资源扔到对象存储（比如阿里云OSS、腾讯云COS）或者CDN上，别让它们占用你动态应用服务器的资源。

4. 监控要看到“毛细血管”里 别光盯着CPU和带宽。你需要监控：

• 应用线程池使用率：是不是快满了？
• 数据库连接数：有没有异常飙升？
• 单个API接口的QPS（每秒查询率）：有没有平时几百，突然变成几万的接口？
• Nginx/Apache的日志：看看是不是有大量来自少数IP的、规律性的请求。

发现异常，告警要快。有时候，早发现一分钟，就能早拦截一场灾难。

四、 说点实在的：没有银弹，只有组合拳

最后说点大实话。世界上不存在一种神器，买来装上就能防住所有CC攻击。 防护是一个动态的、持续的过程。

你需要的是组合拳：高防/WAF做前沿阵地 + 源站隐藏保底 + 业务代码优化提升内在修为 + 精细化监控快速响应。

也别迷信“无限防”的宣传。任何防护都有成本，高防流量、WAF规则计算都要钱。真遇到不计成本的攻击，拼的也是双方的钱包和耐力。所以，除了技术手段，制定好业务连续性计划同样重要：什么时候该切换高防线路？什么时候该启用备用源站？客服怎么应对用户咨询？这些预案，平时多演练，战时才不慌。

行了，关于CC攻击和SLA那点事，今天就聊到这。防护这事儿，永远别等到被打疼了才想起来。现在就去检查一下你的配置，说不定，某个不起眼的开关，就是下次救你命的关键。