被 DDoS 攻击打穿了怎么办？如何保障业务连续性？

直接回答： 已经被打穿时，要做的是三件事：把流量交给边缘吸收、按业务重要性分档恢复（登录与支付 → 核心 API → 其余）、然后撤掉临时规则并复盘。但损失大小其实由攻击之前做完的六件事决定——攻击面清单、告警与值班、七层规则预置、源站收敛、日志留存、降级与依赖方案。Cloudflare 2026 年第三季度的 DDoS 威胁报告显示，其网络在该季度自动缓解了 1,820 万次网络层攻击，约每小时 8,226 次；其中 96% 在 10 分钟内结束，98% 低于 1 Gbps。这意味着两件事：打穿你的门槛比想象中低，而人工响应的时间通常比攻击本身还长。

DDoS 有多常见：不是「会不会」，而是「什么时候」

Cloudflare 2026 年第三季度的 DDoS 威胁报告给出了一组数字。该季度其网络自动缓解了 1,820 万次网络层 DDoS 攻击和 14.4 万亿次 HTTP DDoS 请求，平均约每小时 8,226 次，也就是每 0.44 秒一次。缓解掉的攻击流量合计 272.6 PB（网络层）与 95.1 PB（HTTP 层）。

更要紧的是攻击的形态：96% 在 10 分钟内结束，98% 低于 1 Gbps。Cloudflare 把这种「短、小、高频」的形态归因于按次付费的 DDoS 租借服务，目标集中在计算机软件、IT 服务与在线游戏这类依赖连续可用性的业务。1 Gbps 这个量级听起来不大，但官方的原话是：足以压垮一台服务器或一个网站。

对出海 SaaS 来说，这组数字有三个直接含义。

一、规模小不是护身符。 多数攻击的流量门槛很低，一条小带宽链路或一台没有防护的源站就够了。攻击者挑目标看的是动机，不是你的名气。

二、人工响应的时间通常比攻击还长。 96% 的攻击在 10 分钟内结束。等到有人看到告警、拉会、定性、改配置，攻击往往已经打完了。Cloudflare 在报告里的结论是：绝大多数攻击在分析师看到告警之前就已经结束。所以防护只能是「始终在线、自动触发」这一种形态。

三、短时高频与超大流量是两种形态，不是两个等级。 同一季度超过 1 Tbps 的超大攻击有 251 起，Mirai 类僵尸网络的单次最长攻击跑了 49.7 小时。两种都要覆盖。

被打穿一次，账上会多出哪些成本

「被打穿」通常不是说网站变慢，而是服务不可用那段时间里，业务侧同时开始失血。按出海 SaaS 常见的情况，成本大致落在这些地方。

收入与转化。 交易型业务按分钟计损失。订阅型业务更麻烦：中断期间的用户不会补回来，只会变成工单、差评和下个月的退订。

云账单。 攻击流量打在源站或自动扩容组上时，出向流量、请求数与实例数会同时抬升。账单在事故结束后才到，数额却是攻击当时决定的。这也是「把流量挡在边缘」最直接的财务意义：不让它进入你按量付费的那一段链路。

合同与 SLA。 企业客户合同里通常写有可用性承诺与赔付条款。一次长时间中断会触发赔付，也会进入下一次续约谈判和对方的安全审查问卷。

获客与投放。 不可用期间，搜索爬虫抓取失败、广告预算照常消耗、落地页跳出率飙升。这部分不会出现在任何一张账单上，但会在下个月的获客成本里体现。

人力与机会成本。 一次没有预案的事故会把研发、运维和客服全部拖进去，路线图停摆一两天。真正贵的往往不是中断本身，而是全员放下手上的事去救火。

举证与合规。 没有日志，你就无法回答客户「我的数据有没有受影响」，也无法在需要事件通报的行业里完成说明。这一项事后补不上。

值得单独说一句：上面这些成本里，只有第一项与攻击规模相关。 其余几乎都由「有没有提前准备」决定。同样一次攻击，有预案的团队损失的是十分钟里的部分请求；没有预案的团队损失的是几小时不可用，加上事后数周的信任修复。

为什么防护要放在边缘：Cloudflare 在这里的价值

明白了攻击有多常见、打穿有多贵，下一个问题才是「在哪里挡」。

答案是离源站尽可能远的地方，也就是边缘。原因很直接：如果攻击流量先抵达你的服务器、你的云账号、你的带宽，那么它已经在按你的单价计费、按你的容量上限消耗了。边缘防护的本质，是在流量进入你付费的那段链路之前把它吸收掉。

Cloudflare 在这件事上有三个具体优势。

一、容量与位置。 Cloudflare 的网络容量在 500 Tbps 量级，覆盖 330 多个城市。攻击流量在离来源最近的边缘被吸收，而不是挤进你的一条回源链路。

二、默认生效，不计量也不计费。 按官方可用性表，L3-7 的标准不限量 DDoS 防护、HTTP DDoS 攻击防护与网络层（L3/4）防护在 Cloudflare 各套餐上都是「是」。「能不能挡住」这件事默认就有答案，而且不会因为攻击流量大而产生额外费用。

三、自动化的速度。 上一节那组数字的另一面是：多数攻击结束得比人工响应快。这类防护只有「始终在线、自动触发」一种可行形态，靠人在告警之后上手是来不及的。

边界也要讲清楚：自动防护解决的是「流量能不能被吸收」，不是「你在事故里要不要做决策」。 仍然需要提前配好的包括托管规则集的自定义覆盖（各套餐允许的覆盖数量分别是 1、1、1、1、10）、七层的自定义规则与限流规则、告警与值班、源站收敛与日志留存。这几项都不是默认到位的，也正是下面这份清单要处理的事。

攻击发生前的六项准备

一、攻击面清单。 列出所有对外可解析的主机名、子域名、API 端点、源站地址与 DNS 托管位置，标注哪些是关键的。出海业务容易漏的是旧子域、合作方接入的域名、以及没接入代理的「仅 DNS」记录。

二、告警与值班。 各套餐都有告警，Enterprise 加上 Advanced DDoS Protection 附加项后有带过滤的高级告警。比告警本身更重要的是值班：谁在收到告警后有权决定上措施，这条链路要提前定好。

三、七层规则预置。 自定义规则条数是 5、20、100、1,000（按套餐），限流规则是 1、2、5、100（Enterprise 的条数取决于合同，且合同须含应用安全）。提前把登录、支付、短信、搜索这些端点的规则写好并验证过，不要等到攻击时才写。

四、源站收敛。 边缘挡得住不等于源站安全。只放行 Cloudflare 公布的 IP 段、开启回源鉴权，或者改用 Cloudflare Tunnel 出向连接，这一步做完，直连源站这条路才真正被堵上。

五、日志留存。 Logpush 在 Free、Pro、Business 上每个账号的任务上限是 1,000 个，Enterprise 没有账号级上限。不管用哪一层，日志要先跑起来——没有日志，事后既无法复盘，也无法向客户或合作方说明发生了什么。

六、降级与依赖方案。 出海 SaaS 通常依赖第三方：支付、短信、地图、身份提供商。攻击期间这些依赖也会受影响，提前准备好静态降级页、功能开关与排队机制，比临场决定要可靠得多。

处置顺序与分工：前 10 分钟、前 1 小时、之后

0 到 10 分钟：先确认，再动手。 三件事同时做：确认这是攻击还是自己的变更、容量不足或依赖故障；确认自动缓解正在生效（仪表盘与告警）；确认影响范围（哪个端点、哪个区域、哪一层）。这一步最容易犯的错是「先封一批 IP」——在定性之前做的处置，往往是后面误杀的来源。

10 到 60 分钟：按端点分档处置。 保护顺序按业务重要性排：登录与账号、支付与下单、核心 API、然后才是其余。动作上挑战优先于阻断——挑战可以放行真人，也可以随时撤回；大面积阻断一旦误伤，恢复成本更高。每条临时规则都要记下创建时间与回滚方式。

之后：回滚与复盘。 攻击结束后按顺序撤掉临时规则，避免长期留着没人记得的规则；记录发现时间、缓解生效时间、恢复时间、误杀情况与客户可见影响。

有三件事不建议在事故中做。 不要在没定性前按国家或大段 IP 封禁；不要在事故中把代理记录临时改成「仅 DNS」，那会把源站地址直接暴露出去；不要为了排查临时关掉安全措施而不留记录。

处置顺序之外，另一件必须提前定好的是分工。

值班决策人。 一个人负责判断「现在是几级事件」和「要不要上措施」。多人同时下指令是事故变长的常见原因。

网络与安全。 看边缘侧的信号与规则命中，调整覆盖与阈值，记录每一条改动。

应用与 SRE。 看源站错误率、队列深度与依赖状态，决定要不要降级或限流到用户侧。

客服与对外沟通。 准备一份可以立刻发出去的说明模板：承认影响、给出预计更新时间、说明数据是否受影响。攻击期间的沉默，比攻击本身更伤客户关系。

上游链路。 什么时候联系云厂商或 Cloudflare，取决于影响的层面与合同的响应承诺。这条升级路径要在预案里写成具体的人和渠道，而不是「到时候再说」。

出海业务还有一个特殊点：客户分布在多个时区，攻击可能发生在你的深夜。值班与授权必须是跨时区的，或者写成「任何人在什么条件下可以先做什么」。

企业版在应急预案里多出什么

先说结论：基础防护不分层，分层的是「你能提前准备到什么程度」。企业版与 Advanced DDoS Protection 附加项多出来的，是让预案更精细、让事故中需要人工判断的部分更少的那些能力。

更宽的覆盖与更细的观测。 规则集覆盖数量、新规则的误报主动检测、自适应防护覆盖的规则范围，以及 profiling 会纳入哪些信号——这些决定你能提前把多少判断写进规则里。

可以先观察，再执行。 WAF 自定义规则的 Log 动作属于企业版能力。新规则先只记录、看清它拦下了谁，再收紧成阻断，这条路径直接决定误杀率。

更可用的告警与日志。 带过滤的高级告警来自 Advanced DDoS Protection 附加项；Logpush 在 Free、Pro、Business 上每个账号的任务上限是 1,000 个，企业版没有账号级上限。

合同侧的响应承诺。 什么时候能联系到谁、走什么升级路径，写在合同里，而不是事故中临时找渠道。

下表逐项列出官方 Availability 表中的差异，供技术评审时核对：

能力	Free	Pro	Business	Enterprise	Enterprise + Advanced DDoS Protection
L3-7 标准不限量防护	是	是	是	是	是
HTTP DDoS 攻击防护	是	是	是	是	是
托管规则自定义	是	是	是	是，含 Log 动作	是
规则集覆盖数量	1	1	1	1	10
新规则的误报主动检测	否	否	否	是	是
自适应 DDoS 防护	仅错误类自适应规则	仅错误类自适应规则	仅错误类自适应规则	仅错误类自适应规则	全部自适应规则
自适应防护的信号	仅错误率	仅错误率	错误率与历史趋势	错误率与历史趋势	加客户端国家、UA、查询串与 ML 评分
告警	是	是	是	是	带过滤的高级告警
Advanced TCP / DNS 防护	需 Magic Transit	需 Magic Transit	需 Magic Transit	需 Magic Transit	需 Magic Transit

两点说明：上表直接对应 Cloudflare 官方的 Availability 表，未列出的能力不代表没有，只是未在该表列出。Magic Transit 是企业级产品，用于保护自有网段或混合网络，也是 Advanced TCP Protection 与 Advanced DNS Protection 的前提。

把这句话反过来读更重要：「能不能挡住」不是选型问题，「出事时你要花多少时间做人工判断」才是。 而人工判断的那部分时间，就是被打穿的那部分时间。

企业版的 100% SLA 保证什么

采购评审里几乎一定会问到这条，值得把承诺本身说清楚。企业版合同里有明确的可用性承诺，官方表述是：服务将 100% 的时间在全球投递客户内容。它承诺的是 Cloudflare 自身服务的可用性，而支撑这句承诺的，是前面说过的那张网络：500 Tbps 量级的边缘容量、330 多个城市、13,000 多张网络互联；公开记录中最大的攻击——31.4 Tbps、每秒超过 2 亿次请求——就发生在它的网络上，被自动缓解，客户服务没有中断。

有两点值得写进评审纪要：

• 防护不限量、不按攻击大小计费。 L3-7 标准防护自动生效，攻击再大也不会多出一笔「攻击流量账单」。
• 100% 可用性写进了合同。 它不是营销话术，而是 SLA 条款，带明确的违约救济与响应承诺。

业务连续性的另一半——源站收敛、依赖降级、容量与预置规则——正是这份预案要覆盖的部分，也是我们能帮上忙的地方。

四个最常见的失败点，以及怎么提前练掉

一、告警没配，或没人值班。 攻击持续数小时才被客户告知，是最常见也最难看的一种。告警与值班链路必须能在没有真实攻击时被验证。

二、缓解规则没预置。 事故中临时写的规则没有经过验证，误杀概率高，而且没人记得事后要撤。规则应该在平时写好、用观察方式跑过、并留好名字与说明。

三、源站没收敛。 边缘侧一切正常、源站已经挂了，这种故障形态最难定位。只放行 Cloudflare IP 段、开启回源鉴权或改用隧道，是唯一能把这条路径彻底关掉的做法。

四、日志没留存。 没有日志，就没有复盘，也无法回答客户「我的数据有没有受影响」。日志要在攻击之前就跑起来，而不是之后补。

还有一类经常被漏掉：下游依赖。支付回调、短信网关、对象存储的公开端点，这些在攻击中同样会被打，而且不在你的边缘规则覆盖范围内。

怎么在没有真实攻击时演练。 拿一份假设场景（例如「登录接口在 UTC 02:00 出现每秒数十倍增长」）走一遍：谁收到告警、谁决定、改了什么、怎么对外说。推演的价值在于暴露职责空白，不在于技术细节。

规则先观察后执行。 新规则先用可恢复的动作跑一段时间，看它拦下了谁。能不能「只记录不处置」取决于套餐——WAF 自定义规则的 Log 动作是 Enterprise 才有的能力。

演练要覆盖的四件事。 告警链路能否触达值班人、规则发布与回滚是否熟练、源站是否真的无法从公网直连、对外公告模板是否可用。

复盘要看四个数。 发现时间、缓解生效时间、误杀率、客户可见影响。这四个数比「攻击有多大」重要得多，因为前三个是你能改进的。

演练频率不需要高，但要有：每季度一次桌面推演，每次重大架构变更后更新一次攻击面清单。

这套预案解决不了什么

• 源站自身容量不足。 攻击只是把容量问题提前暴露出来，扩容与架构调整是另一件事。
• 应用层漏洞与业务逻辑问题。 一个慢查询接口不需要攻击者就能自我耗尽，这类问题在边缘看不到。
• 第三方依赖故障。 依赖挂掉时，你的边缘规则什么也做不了，只能靠降级与多供应商设计。
• DNS 与注册商层面的问题。 查询洪泛会打到权威 DNS，这部分要单独设计，预案里要写明由谁负责。
• 账号与业务风控。 撞库、薅羊毛这类问题不是流量问题，判据在业务数据里。
• 把入口集中到一家供应商这个取舍本身。 这是主动选择，代价与边界可以参考网站遭受 DDoS 攻击时，CDN 能否解决问题？。

常见问题

我们不是大厂，也会被 DDoS 吗？ 会。Cloudflare 2026 年第三季度的数据里，98% 的网络层攻击低于 1 Gbps，这个量级足以压垮一台服务器或一条小带宽链路。租借式攻击服务的目标选择看的是动机，不是名气；出海 SaaS 依赖连续可用性，本身就在这类攻击的偏好范围内。

Cloudflare 已经自动挡 DDoS 了，为什么还要预案？ 自动防护解决的是「流量能不能被吸收」，预案解决的是「决策什么时候做完」。攻击中真正造成损失的，往往是临时写的规则、没验证的配置和没人负责的沟通，而不是防护没生效。

被打穿一次，实际损失由什么决定？ 只有直接收入损失与攻击规模相关，其余几项——云账单、SLA 赔付、获客中断、人力占用、事后举证——几乎都由「有没有提前准备」决定。同样一次攻击，有没有预案的差别是十几分钟的部分请求与几小时全站不可用。

攻击发生时第一步该做什么？ 先确认，再动手。区分这是攻击还是自己的变更、容量问题或依赖故障，确认自动缓解在生效，确认影响范围。在定性之前按国家或大段 IP 封禁，是误杀与二次事故的主要来源。

企业版相比免费版，在应急上多出什么？ 基础防护两者都自动生效。企业版多出的是规则集覆盖数量、新规则的误报主动检测、自适应防护的规则范围与 profiling 信号、WAF 自定义规则的 Log 动作（可以先观察再阻断）、带过滤的高级告警、Logpush 无账号级上限，以及合同里的响应承诺。这些决定的是预案能精细到什么程度。

企业版有 100% SLA，是不是就保证不会被打穿？ 在防护容量这件事上，规模本身就是答案：Cloudflare 的边缘网络容量已超过 500 Tbps，覆盖 330 多个城市；公开记录中最大的攻击——31.4 Tbps、每秒超过 2 亿次请求——发生在它的网络上并被自动缓解，客户服务没有中断，而且防护不限流量、不按攻击大小计费，100% 可用性有合同 SLA 兜底。SLA 承诺的对象是 Cloudflare 自身服务的可用性；源站被绕过直打、源站容量与第三方依赖不在其内，这一半靠源站收敛、降级方案与演练过的预案补上。

攻击结束后还要做什么？ 按顺序撤掉临时规则，记录发现时间、缓解生效时间、恢复时间、误杀情况与客户可见影响，然后更新攻击面清单与阈值。没有这一步，下一次攻击会重复同样的问题。

相关阅读

• 出海企业如何选择 DDoS 防护服务？
• 海外网站遭遇 CC 攻击怎么办？
• 套了 CDN 还会被打穿？源站 IP 暴露的六个常见路径与收敛方法
• Cloudflare DDoS 防护能力说明

如果你的预案还停留在「出了问题再处理」，可以先从攻击面清单开始：把对外可解析的资产列一遍，往往当天就能发现几个不该暴露的东西——和我们一起做一遍。