CC攻击打的是应用层，稳住订单的关键不是把攻击全挡住，而是把下单、支付、库存这条主链路单独护住。 大促前夜的流量本来就紧，攻击混进来时，先保交易闭环，再谈全站体验。
CC攻击和DDoS攻击有什么区别，大促前夜先分清
很多团队一看到告警就上高防清洗,结果流量下去了，订单接口还是超时，原因很简单：打你的不是同一种东西。
攻击手法的差别
- DDoS偏网络层和传输层,靠流量洪峰堵带宽，特征是总入口流量陡增、连接数异常。
- CC攻击偏应用层,模拟正常用户反复请求登录、搜索、秒杀、下单接口，单IP请求频率不高但总量可观，IP分散、UA伪装、会话伪造都很常见。
- 业内专家指出,大促期间的攻击更倾向“掐点”：在整点开售、优惠券发放、尾款支付这几个时间窗集中施压，目的不是打瘫网站，而是拖慢交易链路、制造超时和重复提交。
| 对比项 | DDoS攻击 | CC攻击 |
|---|---|---|
| 攻击层级 | 网络层、传输层 | 应用层（HTTP/HTTPS） |
| 典型特征 | 带宽打满、连接数暴涨 | 接口响应变慢、错误率上升 |
| 主要受害面 | 整站可达性 | 登录、下单、支付等关键接口 |
| 防护重心 | 流量清洗、运营商联动 | 限流、人机校验、缓存、排队 |
订单是怎么一步步丢掉的
一条下单请求要穿过CDN、WAF、负载均衡、网关、订单服务、库存服务和支付网关，CC攻击最容易卡在三处：
- 会话校验：每次请求都查Redis或鉴权服务，攻击流量把连接池打满。
- 库存扣减：热点SKU行锁竞争，正常用户排队等锁，等不到就超时。
- 支付回调：回调接口被刷，幂等判断失效，产生重复订单和对账压力。
看清这条链路,后面的动作才有落点。
大促期间被CC攻击订单系统崩了怎么办：四道闸按顺序拉
先说处理顺序,别一上来就全站开验证码，正确做法是先把非核心功能让路，再把交易链路单独加固。
前五分钟做什么
- 打开云WAF或高防的CC防护“紧急模式”，阈值按当前正常QPS的1.5到2倍设置，避免一刀切误伤。
- 把商品详情、活动页、评论、推荐这些读多写少的接口切到CDN缓存或静态化页面。
- 在网关层对下单、支付、领券三类接口单独建限流桶，和浏览类接口分开计数。
- 临时关闭积分查询、历史订单列表、优惠试算等非交易必需功能，减少后端压力。
第一道闸：限流，给下单接口单独的桶
限流要分接口、分用户、分来源，Nginx层可以这样配：
limit_req_zone $binary_remote_addr zone=order:10m rate=5r/s;
limit_req_zone $binary_remote_addr zone=pay:10m rate=2r/s;
location /api/order/create {
limit_req zone=order burst=10 nodelay;
limit_req_status 429;
proxy_pass http://order_backend;
}
网关层再用令牌桶按用户维度限,已登录用户和游客分开配额，返回429时给前端一个“排队中”的友好提示，比直接白屏强。
第二道闸：缓存，把读流量挡在交易链路之外
- 商品详情、库存展示、活动规则提前预热到Redis和CDN，库存展示允许短暂的不一致，扣减仍以数据库为准。
- 下单前的校验收敛成一个轻量接口,避免一次下单打七八个后端服务。
- 静态资源全部走CDN,源站只留动态请求。
第三道闸：排队，把洪峰削成平峰
下单请求进消息队列,前端轮询结果或走长连接推送，队列长度要设上限，超过就快速失败并提示“当前人数较多”，库存扣减用预扣加异步落单，支付回调做严格幂等，这样即使入口被打，交易也不会雪崩。
第四道闸：降级，保支付不保体验
- 关闭非核心推荐、猜你喜欢、浏览足迹。
- 优惠券发放改成整点分批放量,避免瞬时抢券打穿服务。
- 支付链路单独部署、单独限流，支付回调接口只允许支付网关的固定回源IP访问。
电商CC高防价格一般多少，按什么计费
这是采购时问得最多的问题,直接说结论：没有统一价，计费维度不同，差价很大，行业共识认为，大促场景更适合“保底加弹性”的组合，而不是单纯买带宽。
| 方案 | 计费方式 | 适合场景 | 注意事项 |
|---|---|---|---|
| 云WAF | 按域名数加QPS套餐，超出按量 | 中小电商、接口型攻击 | 关注CC防护规则是否可自定义阈值 |
| 高防IP | 保底带宽加弹性峰值 | 有大流量攻击史 | 回源带宽和回源IP白名单要提前配 |
| CDN加边缘WAF | 按流量和请求数 | 静态资源多、全国用户 | 边缘节点规则下发有延迟 |
| 自建防护 | 服务器加带宽加人力 | 有专职安全团队 | 大促弹性扩容慢，运维成本高 |
价格上的经验判断：按QPS计费的云WAF，日常小套餐成本可控，大促临时升配按天或按月加购更划算；高防IP的保底带宽是固定支出，弹性部分按攻击峰值结算，近年来不少厂商推出大促保障包，包含压测、值守和临时扩容，采购前把“攻击峰值超出套餐后怎么计费”问清楚，比只看标价重要。
杭州电商大促CC防护怎么落地
杭州及华东一带电商密集,机房选择、备案接入和就近回源都有讲究，落地路径可以按这个顺序走：
- 域名CNAME接入高防或云WAF,确认回源IP段，源站安全组只放行这些IP。
- 在控制台开启CC防护,先设“观察模式”跑一天，看误拦截比例再切“拦截模式”。
- 对登录、下单、支付三个路径配置独立的防护规则，登录加滑块或短信校验，下单加频率限制，支付只放行支付网关回源。
- 大促前做一次全链路压测,重点压库存扣减和支付回调，记录拐点QPS。
- T-1日冻结策略变更，只留紧急开关，值守人员明确谁有权调阈值。
具体操作上,源站可以用iptables临时封禁异常网段，例如把压测中确认的恶意来源段加入黑名单：
iptables -I INPUT -s 203.0.113.0/24 -j DROP
封禁前先确认该网段没有正常用户,避免误伤，监控上盯住四个指标：下单接口P99延迟、429比例、库存扣减失败率、支付回调积压量，任何一个越线，就按前面四道闸的顺序加码。
电商大促CC攻击防护常见问题
大促前多久做防护配置比较稳妥？
一般提前七到十五天完成接入和压测,留出观察误拦截的时间，T-1日只做策略冻结和值守排班，不再大改规则，临时抱佛脚接入高防，回源配置和缓存预热都来不及做，效果会打折扣。
开启严格CC防护会不会误伤真实用户？
会,所以要用分级策略：浏览类接口宽松，登录和下单类接口严格，再配合灰度放量观察429比例，相当一部分误伤来自共享出口IP的企业用户和校园网，必要时对已验证登录态的用户放宽阈值。
CC攻击期间要不要直接关站止损？
不建议,关站等于把订单直接让出去，还会影响大促坑位和流量权重，更划算的做法是降级非核心功能、保住支付和库存链路，让能成交的订单先成交，保支付链路比保全站体验更优先，这是多数电商在实战中形成的取舍。
攻击不会因为大促就讲道理,防护也不能靠临时堆设备，把交易链路拆开护住，限流、缓存、排队、降级按顺序拉闸，订单才稳得住。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/793067.html
