电商大促期间CC攻击的本质不是单纯打带宽，而是打交易逻辑和资源消耗点。攻击者很清楚大促时段的服务器扩容成本极高，每一秒的卡顿都直接对应订单流失。因此防护措施必须围绕“识别真实用户”和“保住核心交易链路”两个目标展开，而不是泛泛地堆硬件或上高防IP。
先区分CC攻击的两种主要形态
第一种是HTTP Flood，攻击者用大量代理IP对商品详情页、搜索接口、购物车页面发起高频请求，目的是耗尽Web服务器连接数或应用线程。第二种是慢速攻击，比如Slowloris变种，每个连接只发一半请求然后挂起，占满服务器的并发连接池。大促场景下这两种攻击经常混合出现，且会模拟正常用户的浏览器指纹和Cookie行为，单纯靠IP频率限制很容易误伤真实买家。
第一层：在边缘节点做请求合法性校验
大促前必须把静态资源和部分动态请求前置到CDN边缘。对于到达源站的每一个请求，先校验是否携带了完整且合理的浏览器特征。具体做法是在边缘层部署JavaScript挑战，要求客户端执行一段简单的计算并回传结果。真实浏览器能自动完成，而多数脚本化的CC工具无法正确执行。这个挑战不能对所有请求开启，只对触发风控规则的请求启用，否则会拖慢正常用户体验。
同时要校验请求头完整性。正常浏览器访问会携带Accept、Accept-Language、Referer、User-Agent等完整头信息，而很多CC工具只发送精简的GET请求。可以设置规则：缺少Referer且UA为常见攻击脚本特征的请求直接丢弃。但注意不要只依赖UA黑名单，攻击者会伪造UA。
第二层：基于行为特征的动态限速
固定阈值的频率限制在大促场景下基本无效。比如设置单IP每秒最多10次请求，攻击者用大量代理IP每个只发5次请求就能绕过。正确做法是基于行为相似度做动态聚类限速。把请求按IP段、UA、Cookie、访问路径、请求时间间隔等维度做特征向量化，当一批请求的行为模式高度相似且访问量异常时，对这批请求整体进行限制，而不是针对单个IP。
举个例子，如果突然有300个不同IP在3秒内同时请求同一个SKU的库存查询接口，且UA都是同一种安卓机型、请求间隔都是精确的0.5秒，这就不是正常用户行为。正常用户访问会有随机的时间间隔和不同的设备指纹。动态限速系统可以自动识别这种模式并触发验证码或直接丢弃。
第三层：核心交易链路与普通页面隔离
大促时最怕的是CC攻击把整个网站打挂，导致连正常下单的用户也进不来。必须把交易核心链路从普通内容浏览中物理隔离出来。具体做法是：商品详情页、搜索、购物车、下单、支付这几个核心接口使用独立的域名或独立的服务集群，普通资讯页、活动页、帮助中心等使用另一套集群。攻击者如果打的是普通页面集群，核心交易不受影响。
在架构上，核心交易集群要设置独立的连接池和线程池，并且限制非核心接口对核心服务的调用频率。比如商品推荐接口不能无限制地调用库存服务，否则一个非核心接口被CC打爆后，会通过内部调用链拖垮整个交易系统。
第四层：智能验证码与无感验证
对于触发风控规则的请求，不能直接封IP，因为大促期间大量用户来自移动运营商NAT出口，封一个IP可能误伤几百个真实用户。正确做法是弹出智能验证码。但传统图形验证码体验太差，大促时会导致转化率下降。可以采用无感验证，比如滑动轨迹分析、设备指纹比对、行为时序分析。真实用户滑动验证码的轨迹有自然的加速和减速过程，而机器模拟的轨迹往往是匀速或随机抖动。
更进一步的方案是基于设备指纹做信誉评分。每个设备在大促前通过日常访问积累信誉分，大促期间信誉分高的设备请求直接放行，信誉分低的设备触发验证码。攻击者新注册的设备指纹信誉分低，自然会被拦截。
第五层：源站侧的连接管理和资源保护
即使边缘层过滤掉大部分攻击流量，源站仍需做好自我保护。Web服务器层面要调整超时参数，比如将keepalive_timeout调短，限制单个连接的最大请求数，防止慢速攻击占满连接。对于Nginx，可以配置limit_conn模块限制单IP并发连接数，但阈值要结合业务实际设置，移动端用户可能一个IP下有多个并发连接。
应用层面要设置接口超时和降级机制。比如库存查询接口如果响应时间超过500毫秒，直接返回缓存中的库存数据，而不是等待数据库查询完成。下单接口如果依赖的第三方服务超时，先返回“系统繁忙请稍后重试”，而不是让线程一直挂起。大促期间宁可牺牲部分实时性，也要保证核心接口不被拖垮。
第六层：实时监控与自动化响应
CC攻击的流量特征变化很快，人工分析日志再封禁往往来不及。需要建立实时监控指标，比如每秒请求数、平均响应时间、错误率、连接数、特定接口的QPS。当某个指标出现异常突变时，自动化系统要能在10秒内触发预设的防护策略。
这里给出一个简单的Nginx + Lua限速示例，用于在源站侧做应急防护：
-- 在nginx.conf的http块中配置共享内存
lua_shared_dict cc_limit 10m;
-- 在server块中配置访问阶段脚本
access_by_lua_block {
local limit = ngx.shared.cc_limit
local key = ngx.var.binary_remote_addr
local req_count, err = limit:incr(key, 1)
if req_count == 1 then
ngx.shared.cc_limit:expire(key, 1) -- 1秒窗口
end
if req_count > 50 then -- 单IP每秒超过50次请求
ngx.exit(403)
end
}
这个示例只适合应急使用，生产环境需要结合更复杂的规则引擎。自动化响应的核心逻辑是：先观察、再限制、最后封禁。观察阶段只记录日志，限制阶段对可疑流量返回验证码或延迟响应，封禁阶段只针对确认的攻击源。
第七层：大促前的压力测试与攻击演练
很多电商平台平时防护做得不错，但大促时流量是平时的10倍以上，防护策略的阈值没有相应调整，导致正常流量被误杀。大促前必须做两件事：一是按预估峰值的1.5倍做压力测试，验证核心接口在高压下的响应时间和错误率；二是做模拟CC攻击演练，用自建的压测工具模拟不同形态的CC攻击，检验防护策略的触发准确率和误杀率。
演练中要特别关注移动端流量。现在大促期间移动端占比通常超过80%，移动网络的IP复用率高，UA和设备指纹的多样性比PC端低，防护策略需要针对移动端做特殊优化，否则很容易把正常用户拦截掉。
第八层：与运营商和云服务商的协同
当攻击流量超过自身带宽承受能力时，需要借助上游运营商做流量清洗。大促前要与云服务商确认高防IP的切换流程和生效时间，确保攻击发生时能在5分钟内完成流量牵引。同时要准备好备用域名和备用入口，如果主域名被攻击导致DNS解析异常，可以通过备用域名快速恢复服务。
这里要强调一点：高防IP不是万能的。很多高防服务对HTTP Flood的清洗能力有限，尤其是针对模拟真实浏览器的CC攻击。高防IP主要解决的是大流量DDoS攻击，对于CC攻击，核心还是靠应用层的风控和架构隔离。
容易被忽视的细节：Cookie校验与会话保持
CC攻击工具很多不支持完整的Cookie会话管理。可以在用户首次访问时下发一个带有加密签名的Cookie，后续请求必须携带这个Cookie才能访问核心接口。攻击者如果只发请求不处理Cookie，会被直接拦截。这个方案对用户体验影响很小，因为真实浏览器会自动处理Cookie。
但要注意Cookie校验不能只做静态值比对，要做动态签名。比如Cookie中包含时间戳和签名，服务端验证签名是否有效且时间戳在合理范围内。攻击者即使抓包拿到Cookie，如果无法破解签名算法，也无法批量伪造有效Cookie。
总结大促CC防护的关键思路
电商大促的CC防护不是靠单一技术能解决的，需要边缘校验、行为分析、架构隔离、验证码、源站保护、监控响应、压测演练、外部协同多个层次配合。核心原则是：不追求完全阻断攻击，而是保证真实用户能顺利完成交易。所有防护策略的调整都要以转化率和误杀率为最终衡量标准，而不是单纯看拦截了多少攻击请求。
