网站没宕机，交易先瘫痪：双十一电商如何防止网络攻击？

电商大促防DDoS攻击

零点一过，页面能打开，商品也能加进购物车。点提交订单，转圈，超时。再点一次，提示系统繁忙。切到支付页，白屏。

这时候你去看服务器监控，CPU 不高，带宽没满，网站根本没有宕机。但订单就是进不来。这类攻击的目标不是让网站停下来，而是让交易停下来。它比把站打挂更省成本，也更难被第一时间的告警发现，因为流量和资源指标看起来都正常。

为什么“网站正常”反而更难查？

多数团队的监控盯的是带宽、连接数和 CPU。这几项正常，值班的人会先排除掉攻击，转去怀疑库存服务或者数据库。

攻击者正是利用了这一点。打挂一个网站需要很大的流量，成本高，还容易触发清洗；反复请求下单、领券、支付回调这几个接口，只需要很小的流量，就能让业务停住。绿盟科技《2025 全球 DDoS 攻击态势报告》里有一组数据可以印证这个方向：应用层攻击中 HTTPS Flood 占比达到 45.03%，这类请求形式看起来和正常用户没有区别。

报告里还提到一个判断：DDoS 正在从带宽对抗变成决策速度的对抗。AI 把攻击的侦察、实施和规避跑成一条自动流水线，防护这边还在开会，那边已经换了一轮打法。人的反应时间，在这个节奏下根本不够。

交易链路上，攻击者先掐哪一环？

一条完整的下单链路要串起好几个服务，攻击者只需要掐住其中一个，前面的环节看起来就全是正常的。

越靠后的环节，用户情绪越大。领券失败用户会重试，订单创建失败用户会放弃，支付回调出问题用户会直接投诉。

从预售到返场，哪几个时刻最容易出事？

风险不是均匀铺开的，它跟着你的业务节奏走。

10 月下旬：预售和定金夜

最先出状况的常常不是首页，是领券、定金、资格校验这类营销接口。它们逻辑轻、调用频繁，出问题时首页还好好的，用户只觉得"券领不了"。

11 月 1 日：开门红

一次不用花钱的演练。限流阈值、回源配置、防护策略在这一天第一次碰到真实峰值。开门红稳不住的地方，11 月 11 日会被放大好几倍。

11 月 10 日晚 8 点到零点：直播预热

直播间观众、加购的人、等着付尾款的人同时在线，真实流量和异常请求混成一片。这是整个大促里最难分清"挤"还是"被攻击"的一段时间。

11 月 11 日零点：决定性窗口

最危险的不是流量最大的那一刻，是最不能出错的那一刻。攻击会掐着整点来，短到你还没把人叫齐就已经收手。手动改配置、临时开权限，这些动作在零点那几十秒里基本做不完。

11 月 11 日白天到返场：撤防之后

火力转向支付、退款、物流查询接口，页面能打开，但下单失败、物流查不到。这时候团队已经开始撤值守、降配置，攻击却还在继续。售后高峰本来就吃人手，再出事，投诉直接落到店铺评分。

怎么分清是攻击，还是自己的系统撑不住？

不用等安全团队出结论，先看资源指标和接口指标哪个异常。

把这张表和上面那条链路放在一起用：先确定是哪个环节异常，再判断异常来自请求量还是内部瓶颈。

阿里云《安全态势报告（2025 年 11 月）》里有一组数字可以说明大促期间的攻击密度：当月拦截 DDoS 攻击 17.83 万次，比 10 月多了 70.55%；平台平均每天为客户防御的攻击有 67.14 亿次。腾讯云 EdgeOne《2025 DDoS 与应用安全威胁趋势报告》的统计是，L3/L4 DDoS 攻击年度峰值从 1.2 Tbps 升到 4.1 Tbps，11 月是全年峰值月，达到 4.12 Tbps。

攻击密度摆在这里，“先假设是自己系统的问题”这个默认顺序，在大促当天往往要反过来。

中小商家最容易忽视的问题

这几条每年都有人中招，跟技术强弱关系不大，问题出在判断上。

我的店小，没人会关注到我。 真不是这么回事。大量攻击来自自动化扫描和批量试探，谁先暴露就打谁，跟名气无关。阿里云 11 月的态势报告里有个基数可以参考：平台平均每天为客户防御的攻击有 67.14 亿次，拦下的攻击 IP 有 2.66 万个。攻击是日常化的，不是冲着谁的名气来的。一个没做防护的小站，扛不住的量级比多数人想的要低。

我买了云服务器，云厂商会帮我扛。 云平台确实自带基础防护，但那是默认水位，不是无限额度。超过之后要另外开通弹性防护，或者引入独立的清洗服务。买了服务器，不等于买了大促级别的防护。

提前一天买防护就来得及。 接入、源站排查、策略验证、切换演练，没有一件能在半天内做完。真正的成本不在购买，在验证。

接了高防就万事大吉。高防主要处理流量型和连接型攻击。下单、支付、领券这类接口的异常请求，还得靠 WAF、频率限制和 Bot 识别配合。另外，源站真实地址如果还能被直接访问，攻击者完全可以绕开防护入口。

一次攻击打过来，防护是怎么接住的？

防护不是买一个开关，是一条链路。从流量进来到干净请求回源，中间四个环节，缺一个，前面做的都可能白做。

1. 流量检测与清洗：流量先到清洗节点，异常的部分在那儿丢掉，剩下的干净流量才往源站走，不占你的带宽。

2. 源站保护：真实源站只接受清洗节点和可信来源的回源请求，把绕路这条道堵上。

3. 应用层控制：给下单、支付、领券接口配 WAF 规则、频率限制和 Bot 识别，处理流量型防护接不住的那部分。

4. 监控与响应：盯带宽、连接数、状态码和接口延迟，提前定好处置流程和责任人。

以 OgCloud为例，其官网在数据中心与带宽产品中列出 DDoS防护服务，能力包括流量检测与清洗、恶意流量过滤、防护资源按需调整，并把交易、七层应用和在线业务列为防护场景。对有时间限的大促业务，自动化清洗能省掉人工判断的时间，资源按需调整适合应对整点流量突变。

双十一倒计时，每天该做什么？

结语

双十一的胜负，在 11 月 11 日之前就分得差不多了。那天晚上发生什么，只是前一个月准备工作的结果。一次演练值不值，看三个数就够了：清洗从发现异常到真正生效用了多久、正常用户有没有被一起拦掉、攻击期间还能不能看清各接口的走势。这三个数测不出来，参数再大也只是纸面数字。