大促零点的那一波流量，是所有电商运维一年里最难判断的几分钟。正常用户的秒杀行为——高频刷新活动页、反复提交订单、查询库存——在QPS曲线上与CC攻击几乎重合。照搬平日的限流阈值，真实用户会被大面积拦截；完全放开，刷单脚本会先于真实用户锁定库存和优惠券。攻击者很少在大促峰值时单纯打带宽，因为平台此时的带宽储备最充足。他们更常用的策略是“压垮最后一根稻草”：在零点前后叠加HTTP CC、API刷单和恶意爬虫，让源站在正常洪峰之上再承受一层异常请求，数据库连接池和订单链路会在最需要稳定的时候崩溃。
秒杀洪峰与CC攻击的四维判别：不看QPS，看结构
单看QPS无法区分正常洪峰和CC。秒杀开始的瞬间，QPS冲到日常的十倍是正常业务；CC攻击也可以在短时间内把单一接口的QPS拉到同一水位。两者的差异不在数量，而在请求的结构。
请求路径分布是第一判据。正常用户的路径是首页或活动页→列表→详情→下单，比例自然衰减；CC攻击死磕单一动态接口，比如只打/api/seckill/order或/api/coupon/claim，路径分布高度畸形。日志里按URL聚合TOP 20，如果前三个接口占了90%以上的请求，而静态资源请求量极低，基本可以按攻击处理。
静态资源拉取比例是第二判据。真实浏览器会请求CSS、JS、图片和字体，脚本通常只打接口。大促活动页的静态资源占比正常应当在60%以上；如果某个时间窗口内静态资源请求量骤降而动态接口QPS暴增，说明流量来源不是真实浏览器。
来源与指纹分布是第三判据。正常流量的IP分散，与用户地域和时段相符；CC的源IP集中在IDC或云段，User-Agent高度雷同。秒拨IP虽然能轮换地址，但ASN归属和指纹一致性仍然会暴露批量特征。
时间形态是第四判据。正常洪峰是秒杀时刻的尖峰后快速回落，曲线有一个自然的衰减尾巴；CC攻击是持续平稳或阶梯式抬升，攻击者不需要等你开抢，可以从活动前几小时就开始施压。
四个维度不需要同时满足才判定攻击。路径集中加静态资源占比异常，已经足以把流量送进更严格的审查队列，而不是继续用QPS阈值一刀切。
高防CDN的第一动作不是防攻击，是扛住正常洪峰
秒杀流量的特点是瞬时、集中、高度重复。活动开始那一秒，几万人同时刷新同一个活动页，所有请求打向同一个URL。如果这个页面没有缓存，全部回源，源站瞬间被压垮。
缓存预热必须在活动前完成。活动主页面、核心商品详情页、倒计时脚本、样式文件提前推送到边缘节点，设置长周期缓存和版本号哈希。活动开始时用户请求直接命中缓存，不产生回源。冷门URL如果被攻击者用来穿透边缘，回源限速和静态资源白名单负责兜底。
动态接口限流按接口分档，而不是一个全局数字。商品详情、搜索、推荐这类只读接口，阈值可以放宽；登录、下单、支付、优惠券领取这类写接口，阈值必须收紧。坚果盾高防CDN的边缘令牌桶支持按IP、会话、接口维度分别计数，秒杀写接口的下单间隔可以设到比日常更严格的档位，同时对活动页的刷新频率保持宽松。
限流的动作不是直接丢包。触发阈值后先返回无感JS挑战或降级响应，验证通过后放行，避免把真实用户挡在“活动太火爆”的提示页上。对于来自代理池的撞库和刷单请求，边缘节点之间的设备指纹共享可以识别同一设备在多个IP间切换的行为，不需要等请求打到源站才做判断。
支付与库存扣减接口：高防CDN管不到的部分用高防IP隔离
电商大促的流量不是全部走HTTP/HTTPS域名。支付网关的回调链路、库存服务的内部RPC、订单系统的TCP长连接，这些接口的协议形态决定了它们不适合放在高防CDN后面。但这些接口恰恰是攻击者最想打的目标：支付回调被刷会导致订单状态错乱，库存接口被打穿会直接造成超卖或锁库失败。
高防IP的接入方式是独立IP加端口转发。支付网关对外暴露的TCP端口映射到高防IP，客户端或第三方支付平台的回调地址改为高防IP加转发端口，源站真实IP不出现在任何回调配置中。库存服务的私有协议端口同样通过高防IP转发，源站防火墙只放行高防回源IP段。
端口转发在这里的价值不只是DDoS清洗。支付回调接口有固定的来源IP范围和签名格式，高防IP可以在转发层面对不符合格式的POST请求直接丢弃，不进入业务后端。库存扣减接口的TCP连接需要在清洗后保持会话粘滞，避免因为节点切换导致长连接断开、扣减请求重复提交。
库存扣减本身的一致性靠业务层解决——Redis原子DECR、MQ异步下单、唯一键防重。防护层要做的是确保到达业务层的请求是经过清洗和频率控制的，不让刷单脚本用海量无效请求把Redis和消息队列的容量耗尽。
源站保护：大促期间最容易被绕过的一环
无论边缘缓存和限流配置得多细，如果源站仍然可以被公网直连，攻击者在大促前踩点拿到源站IP，零点直接向源站发起请求，高防CDN和CDN的清洗层全部失效。
高防CDN和高防IP混合部署时，源站防火墙需要同时放行两套回源IP段：CDN回源IP只放行80/443，高防IP回源IP只放行支付和库存的业务端口。按来源地址段加目的端口做二维精确匹配，不做全端口放行。回源鉴权和源站白名单是乘法关系，不是加法关系：边缘拦得住，源站也收不到旁路流量，防护才闭合。
支付回调、物流通知这类第三方接口，建议使用独立的回源域名或专用线路，与大促主流量隔离。某个第三方通道被攻击时，核心交易链路不受牵连。
活动前配置清单与误封率控制
大促防护的成败，在活动开始前就已经决定了大半。以下六项在预热期跑完，比零点时临时加策略有效得多。
缓存预热覆盖活动主页面和核心商品页，确认命中率在活动前达到预期。动态接口限流阈值按历史峰值留余量，秒杀写接口单独设档，不与其他接口共用全局数字。行为识别规则针对秒杀场景调过灵敏度，用历史大促流量做一次回放测试，把误封率控制在0.1%以下——每1000个真实用户里误伤不到1个，秒杀场景下才够用。回源鉴权和源站白名单配置到位，从非白名单IP直连源站端口应当全部超时。高防IP的支付和库存端口转发规则验证连通，协议类型与源站监听一致。面板的实时流量和拦截数据在大促期间持续可观察，避免攻击已经开始而运维还在翻日志。
动态基线的作用在这里体现得最直接。系统在大促前学习日常的请求模式，活动期间实时调整基线，区分“秒杀页面的正常高频刷新”和“脚本批量调用下单接口”。静态阈值做不到这件事，把阈值设高则攻击穿过，设低则真实用户被拦。动态基线加上设备指纹和行为序列评分，才是大促CC防护的可用路径。
常见问题
大促秒杀期间，高防CDN的限流会不会误伤正常用户？
静态阈值会，动态基线和分级处置不会。秒杀场景的正常用户行为本身就是高频的，如果把日常的QPS阈值直接套用，真实用户会被大面积拦截。坚果盾高防CDN在边缘做的是按接口分档限流加行为序列评分：商品详情页的刷新保持宽松，下单接口的阈值按秒杀场景单独设定，触发后先返回无感JS挑战而不是直接丢包。配合活动前的历史流量回放调参，误封率可以控制在0.1%以下。
支付回调接口能不能也接高防CDN？
不建议。支付回调通常是第三方支付平台发起的TCP或HTTPS POST，来源IP范围固定，协议形态和Web页面访问不同。走高防CDN需要改回调域名和证书配置，改造面大且容易在第三方侧产生兼容问题。高防IP的端口转发更直接：回调地址改为高防IP加端口，源站防火墙只放行高防回源IP，第三方支付平台的签名和格式校验在转发层就能完成粗筛。
大促前换了源站IP，还需要配白名单吗？
需要。换IP切断的是历史DNS和已知扫描目标的关联，但如果新IP仍然对公网开放业务端口，攻击者通过端口扫描在大促前踩点仍然可以发现并直连。白名单是“默认拒绝，仅放行回源IP”的访问控制，换IP是切断已知泄露源，两者解决不同层面的暴露，不能互相替代。
秒杀洪峰和CC同时来，清洗容量怎么预留？
按“正常峰值加攻击峰值”的叠加水位评估，而不是只按历史攻击记录选保底。大促期间的正常流量本身就会达到日常的数倍，攻击流量在此基础上叠加，清洗设备需要同时处理两层流量。坚果盾高防CDN的分布式清洗架构把流量分散到多个清洗点，旗舰版1T、至尊版2T+的保底设计意图是避免单点成为瓶颈，配合弹性扩展应对不可预测的攻击峰值。建议在预热期完成一次模拟峰值测试，具体档位匹配可联系技术支持获取评估。
