出海企业如何选择 DDoS 防护服务？

直接回答： 别按宣传的带宽买 DDoS 防护，真正决定你能不能扛住的是三件事：它覆盖你哪些攻击面、生效的前提是什么、以及它在哪里失效。Cloudflare 的网络层与 HTTP 层不限量防护是全套餐包含的（含免费套餐）；非 HTTP 端口（游戏、语音、自定义 TCP/UDP）需要 Spectrum，属于付费套餐且自定义协议需 Enterprise；要保护整段 IP 需要 Magic Transit，仅 Enterprise。这一切成立的前提只有一个：流量真的经过 Cloudflare，且你的源站不对公网直接响应。

先问对问题：不是「能扛多少 G」，而是「暴露面是什么」

大多数 DDoS 采购对话都从容量开始——「你们能扛多少 Gbps」。对出海企业来说这个数字基本没有意义，原因很简单：容量是厂商的问题，不是你的问题。任何一家像样的服务商，其 anycast 网络的入口带宽都远大于攻击者能组织起来的量级。真正决定你能不能活过一次攻击的是另外三件事：

1. 覆盖面：你实际的攻击面，它是否覆盖？只有 Web 前端加一个 API 的企业，和运行游戏服务器、语音服务、或整段 IP 的企业，暴露面完全不同。
2. 生效前提：防护要生效，必须先满足什么条件？现实中大量「买了防护却没防护」的情况，都是因为流量根本没走清洗网络。
3. 失效边界：它在哪里停止工作？那个缺口里会发生什么？每个产品都有覆盖不到的层面，区别在于你是攻击前就知道边界在哪，还是攻击中才知道。

三种攻击面，三种答案

你的暴露面	攻击长什么样	对应的机制	套餐门槛
仅 Web / API（HTTP/HTTPS）	流量型洪水、HTTP 洪水、慢连接	反向代理在边缘吸收并过滤	HTTP DDoS 防护全套餐可用，可调深度随套餐
非 HTTP 的 TCP/UDP（游戏、语音、MQTT、自定义端口）	协议洪水、连接耗尽	在业务前加一层端口代理	Spectrum——付费套餐；自定义 TCP/UDP 需 Enterprise
整段 IP、任意协议	什么都可能，包括代理解析不了的协议	隧道或 BGP 宣告你的网段	Magic Transit——仅 Enterprise

这张表上最贵的错误，是用第三行的方案解决第一行的问题；或者更糟——攻击发生时才发现你的游戏后端在第二行，而买的防护只覆盖第一行。

每个套餐都包含什么，不包含什么

基线其实很宽。文档原话是：Cloudflare 向所有套餐、所有服务的客户提供 3、4、7 层不计量的 DDoS 防护；可用性表中，Standard 不计量 DDoS 防护（3–7 层）、HTTP DDoS 攻击防护、网络层（L3/4）防护在 Free、Pro、Business、Enterprise 各档都是 Yes。

所以 Free 到 Enterprise 的差异不是「能不能扛住大攻击」，而是你能看见多少、能调多少：

能力	Free / Pro / Business	Enterprise + Advanced DDoS Protection
HTTP DDoS 规则 override	1 个，且不能自定义表达式	最多 10 个，支持自定义表达式
DDoS 规则的 Log 动作	不可用	可用（Enterprise + 该附加订阅）
自适应规则	仅 error 类自适应规则	全部自适应规则；画像增加国家、UA、查询串与 ML 分值
告警	标准告警	带过滤的高级告警
敏感度阈值	默认 1,000 errors/s 触发；Pro/Business/Enterprise 还需错误率达正常约 5 倍	默认值相同，但可按 override 调整

有两个命名陷阱，在对内报价前必须分清。第一，附加订阅的「Advanced DDoS Protection」（上表）与**「Advanced DDoS Protection systems」不是一回事——后者指 Advanced TCP、DNS 与可编程流防护，文档标明仅面向 Magic Transit 客户**。第二，不少文章还在引用「HTTP DDoS Attack Analytics」这个叫法，现行文档中已不使用。

另一个常被忽略的点：敏感度（High / Medium / Low / Essentially Off）属于 DDoS 托管规则集，不属于 WAF。WAF 侧对应的调节旋钮是 OWASP 的 score threshold（Low ≥ 60、Medium ≥ 40、High ≥ 25）。把两者混为一谈，会提出根本无法落地的需求。

决策路径

Cloudflare 能力 vs 团队职责

事项	Cloudflare 提供的	你的团队必须做的
吸收流量型攻击	全套餐不计量 L3/4/7 缓解	确保流量真的经过 Cloudflare
HTTP 洪水缓解	HTTP DDoS 托管规则集；低套餐 1 个 override	调敏感度，需要更多 override 时评估附加订阅
请求速率控制	限流规则：按套餐 1 / 2 / 5 / 100 条；周期 10 秒到 65,535 秒	选择计数维度；绝对上限在应用层实现
源站保护	反向代理隐藏源站地址	更换已泄露源站 IP；源站只放行 Cloudflare 网段
应急开关	Under Attack Mode	明确谁有权开启、何时关闭
非 HTTP 业务	Spectrum / Magic Transit	签约前先确认协议与网段要求

边界与不适用情况

• 仅 DNS 解析的记录得不到任何防护。主机名是灰色云时，请求直连源站，边缘缓解完全不参与。这是「买了防护却不生效」最常见的原因。
• 源站 IP 泄露会让代理形同虚设。文档的立论是「攻击者只能打到反向代理本身」——这只在源站地址不为人知、且无法从公网直达时成立。
• 限流不是精确计数器。官方明确它不是为了让精确数量的请求到达源站而设计，且计数器按数据中心独立累计、缓解有几秒延迟。绝对配额必须放在应用层。
• Under Attack Mode 不是配置项。文档把它定义为最后手段之一，插入约五秒的插页，并明确会影响第三方统计工具。应作为「打破玻璃时才用」的开关，指定责任人与回退步骤。
• 多 CDN 或部分代理架构必须明确回答：不走 Cloudflare 的那部分流量怎么办。「大部分走了」不是答案。

FAQ

要扛住大攻击是不是必须买 Enterprise？ 不是。不计量 L3/4/7 防护在所有套餐都有，包括 Free。Enterprise 改变的是可观测性与可控性：更多且支持自定义表达式的 DDoS override、Log 动作、更宽的自适应规则、高级告警；此外 Magic Transit 与自定义协议 Spectrum 确实只有 Enterprise 才能用。

上了 CDN 就自动有防护了吗？ 只对经过它的流量有效，而且只限它代理的层级。CDN 挡在静态资源前面，不会保护裸 IP 上的游戏服务器，也不会在源站地址公开时保护源站。这个问题在下面那篇里有完整展开。

怎么验证防护真的生效？ 按顺序做三件事：你关心的每个主机名都解析到 Cloudflare 且处于代理状态；源站对公网只响应 Cloudflare 网段；用一次受控测试确认出现的是预期的缓解或挑战，而不是源站超时。

我们已经给云厂商付了 DDoS 防护的钱，是不是重复了？ 不一定重复，但两层反向代理叠在一起而没有规划通常会坏事：第二跳丢失客户端 IP、健康检查与缓存行为变化、源站白名单没人负责。先定哪一层是权威层，另一层做透传。

相关阅读

• 网站遭受 DDoS 攻击时，CDN 能否解决问题？
• 海外网站遭遇 CC 攻击怎么办？
• 企业级 WAF 应该如何选择？
• DDoS 防护能力页