不做攻击测试，怎么判断高防CDN的防护承诺靠不靠谱？

一家高防CDN说自己支持“T级防护”“秒级清洗”“无限防御”，另一家展示全球带宽、节点数量和历史最大攻击峰值。单看宣传页面，似乎防护数字越大，能力就越强。

问题是，这些数字可能根本不在同一个口径里。

有的写的是全球网络总容量，有的是整个清洗平台曾经处理过的最大峰值，有的是单个节点容量，还有的只是厂商历史上观察到的攻击，并不代表你的域名、套餐和所在区域能够获得同等保护。

普通用户也不适合为了验证宣传，主动向网站制造DDoS流量。即使测试的是自己的域名，流量仍可能经过CDN共享节点、运营商和云平台，违反服务协议，影响其他客户，甚至触发安全处置。

不做攻击测试，并不等于只能相信销售话术。更可靠的方法是建立一条证据链：

保护对象是否明确
→ 防护范围是否写清
→ 架构能否阻止绕过
→ 检测与处置流程是否可执行
→ 控制台和日志是否提供证据
→ SLA与费用是否进入合同
→ 厂商能否解释失败和误拦截

判断高防CDN靠不靠谱，不是寻找一个绝对安全的数字，而是确认宣传、产品能力、技术架构和合同责任能不能互相对应。

先问清楚：这个高防CDN到底保护什么

“支持DDoS防护”不是一个完整答案。

高防CDN通常面向HTTP和HTTPS网站，通过域名接入保护Web流量。但网站实际业务可能还包括：

• WebSocket长连接；

• API接口；

• HTTP/3和QUIC；

• 文件下载；

• 音视频传输；

• 游戏TCP或UDP端口；

• 邮件、SSH和数据库服务；

• 独立公网IP；

• 权威DNS服务。

如果产品只代理HTTP和HTTPS域名，就不能默认它同时保护源站上的SSH、游戏UDP端口或其他公网服务。

评估前应先做一张保护对象表：

销售只说“全业务防护”，却无法把协议、端口、域名和IP逐项对应起来，是第一个风险信号。

“防护带宽”必须问清是哪一种数字

看到1 Tbps、10 Tbps或更高数字时，不要先比较大小，先问它代表什么。

至少需要区分：

全球网络总容量
清洗中心总容量
单个区域可用容量
单个节点容量
单客户承诺能力
单域名或单IP套餐上限
历史观察到的攻击峰值
合同内保证的防护额度

这些数字不能互相替代。

例如，“全球网络容量数百Tbps”只能说明厂商网络规模较大，不能证明某个地区、某条运营商线路或某个基础套餐能够使用全部容量。

“曾防御10Tbps攻击”也不等于每个客户都有10Tbps保障。还需要追问：

• 这是峰值还是持续流量；

• 持续了多久；

• 是单个目标还是多个目标合计；

• 发生在哪个地区；

• 攻击流量以bps、pps还是rps计算；

• 合法业务在防护期间是否仍然可用；

• 套餐达到什么条件会被限速、黑洞或暂停；

• 是否存在单客户、单域名或单节点限制。

真正有意义的不是厂商曾经见过多大攻击，而是你的业务在合同和当前架构下能获得什么处置。

bps、pps和rps不能混成一个“防护值”

不同类型的攻击消耗的资源不同。

一个低带宽、高pps的小包攻击，可能主要消耗网络设备和连接状态；一个大量访问动态接口的HTTP攻击，带宽未必夸张，却可能把应用、数据库和第三方接口拖垮。

因此，“防护100G”不能自动推导出“能防多少HTTP请求”，也不能证明动态API在攻击期间仍然可用。

必须分清L3/4防护、L7防护、WAF和Bot管理

高防CDN常把多种安全能力放在一张宣传图里，但它们解决的问题不同：

• L3/4 DDoS防护主要处理网络层和传输层流量；

• HTTP DDoS防护主要识别应用层请求洪泛；

• WAF主要针对SQL注入、XSS、路径利用等Web攻击特征；

• Rate Limiting按照请求频率限制客户端；

• Bot管理识别自动化程序及其行为；

• 验证码或挑战用于区分部分真实用户与自动请求；

• 缓存可以减少静态内容到达源站的次数。

Cloudflare在官方DDoS攻击覆盖文档中也将L3/4和L7保护分别说明，并通过不同托管规则处理网络层与HTTP层攻击。这个例子说明，成熟产品会把保护层级拆开，而不是只用一个“防DDoS”开关概括所有能力。

评估其他厂商时也应采用同样思路：

网络层由什么系统检测？
HTTP层由什么规则判断？
缓存未命中的动态请求怎样保护？
登录、搜索和API接口怎样限速？
WebSocket和长连接是否有单独策略？
误拦截后如何快速回滚？

如果销售把WAF、CC防护、DDoS清洗和Bot管理解释成同一种能力，说明产品边界可能没有讲清楚。

“CC攻击防护”要落到具体规则

“CC攻击”在市场宣传中通常指大量HTTP请求消耗网站资源，但它不是一个足以直接配置的精确指标。

需要继续问：

• 按IP、Cookie、会话、设备还是API密钥限速；

• 是否支持路径级规则；

• 是否区分GET、POST和其他方法；

• 是否能识别共享NAT后的大量正常用户；

• 是否支持登录、搜索、下单等接口使用不同阈值；

• 超出阈值后是记录、限速、挑战还是阻断；

• 规则修改多久生效；

• 是否能够查看命中原因和被拦截样本；

• 移动App和API客户端无法执行浏览器挑战时怎样处理。

如果厂商只回答“系统自动识别”，却无法说明可见指标、动作和误判处置，就很难判断自动防护到底做了什么。

看它是自动防护，还是出事后人工切换

高防产品通常分为两种基本模式：

常态在线防护

流量一直经过防护网络，系统持续建立正常流量基线。发现异常后自动启用缓解策略。

优点是切换快，缺点是需要长期保证误判控制和正常访问性能。

按需牵引或人工切换

平时走普通线路，发现攻击后再切换解析、路由或高防入口。

这种模式可能降低常态成本，但要问清：

• 谁负责判断攻击；

• 是否需要人工提交工单；

• 发现异常到完成切换需要多久；

• DNS缓存是否影响生效；

• 切换期间现有连接如何处理；

• 攻击停止后怎样回切；

• 夜间和节假日由谁操作。

“秒级防护”如果实际流程是发现异常后联系销售、开工单、等待人工修改配置，就不能算真正的自动秒级缓解。

厂商是否能证明自己检测到了攻击

不做攻击测试时，控制台和事件报告是非常重要的证据。

成熟的高防CDN通常应能提供部分以下信息：

事件开始与结束时间
攻击目标
攻击类型或向量
峰值bps、pps或rps
攻击来源或主要网络分布
触发的防护规则
执行的动作
被允许和被拦截的流量
源站健康状态
合法用户访问是否受影响
事件结束后的分析报告

AWS Shield Advanced的官方能力说明将健康状态检测、自动应用层缓解和事件可见性作为独立能力；其指标文档还说明会发布检测、缓解和主要流量贡献者等指标。

这并不代表所有高防CDN都必须采用相同界面，而是说明防护不能只有一个“已拦截”数字。用户需要知道系统何时判断为攻击、执行了什么动作，以及业务是否仍然健康。

采购前可以要求厂商提供经过脱敏的事件报告样例，不需要真实客户名称和IP，但报告结构应该完整。

不要把一张“攻击截图”当成全部证据

常见的宣传截图可能只显示：

攻击峰值：500 Gbps
防护结果：成功

这张图没有回答：

• 峰值持续了几秒还是几小时；

• 是否只统计进入整个网络的流量；

• 单个客户是否真的承受了该流量；

• 攻击期间业务是否能正常访问；

• 是否发生大面积误拦截；

• 源站是否仍然在线；

• 是否触发黑洞或临时封禁；

• 客户为此支付了多少额外费用。

更有价值的材料是完整时间线：

10:02 检测到异常
10:02 自动进入缓解
10:03 攻击达到峰值
10:05 合法请求成功率恢复
10:27 攻击下降
10:40 解除临时策略

如果厂商声称“零秒防护”“零误判”，反而要谨慎。真实安全系统需要在检测速度、误判率和正常用户体验之间权衡。

健康检查比攻击数字更接近业务结果

高防系统识别了大量攻击流量，不等于网站一定可用。真正应该关注的是：

• HTTP成功率；

• 页面和API的P95延迟；

• TLS连接成功率；

• 源站CPU、内存和连接数；

• 数据库与第三方接口状态；

• 关键业务路径是否正常；

• 防护期间合法用户是否被挑战或阻断。

例如，AWS Shield Advanced允许将Route 53健康检查与保护资源关联，用于提高检测和缓解的响应速度与准确性。这个设计反映了一个重要原则：DDoS判断不能只看流量，还要结合应用是否健康。

评估高防CDN时，应问厂商能否将流量事件与业务可用性放在同一时间线上，而不是只展示清洗流量。

源站能被绕过，再高的防护数字也没有意义

如果攻击者知道源站IP后可以直接访问源站，就能绕开CDN边缘的清洗、WAF、限速和Bot防护。

需要确认：

• 业务域名是否只解析到CDN；

• 历史源站IP是否仍可直接提供内容；

• 未代理子域名是否暴露源站；

• IPv4和IPv6是否都限制访问；

• 源站安全组是否只允许CDN回源网络；

• 是否支持秘密回源头、签名或mTLS；

• 是否可以使用私有源站、隧道或专线；

• 邮件、管理面板是否与Web源站共用地址。

源站隐藏的目标不是让IP永远无法被查到，而是即使地址已知，未经认证的公网请求也不能绕过CDN。具体检查方法可参考待审核文章用了CDN为什么还能看到源站IP？源站隐藏应该做到哪一步。

如果厂商宣传高防能力，却不提供任何源站防绕过方案，只是让用户修改一个CNAME，防护闭环并不完整。

Anycast不能单独证明防护能力

Anycast可以让多个节点公布同一地址，并把流量引向不同网络入口。它有助于分散流量和提高网络可用性，但“采用Anycast”不等于“能够防御任意规模攻击”。

还要继续确认：

• 多少区域真正公布该地址；

• 攻击流量会在哪些位置清洗；

• 单一区域的入口和清洗能力；

• 节点异常时是否会撤销路由；

• 攻击是否可能把合法用户带到远端节点；

• 配置、规则和证书是否在各节点一致；

• 某个运营商是否存在单点或上游瓶颈。

架构上的区别可以参考待审核文章Anycast CDN和DNS调度CDN有什么区别？普通网站该关心吗。

真正的判断仍要落到目标用户地区的可用性、路由质量、清洗位置和故障恢复，而不是Anycast这个名词本身。

查清楚误拦截会影响哪些正常用户

防护规则过松会漏掉攻击，过严则可能伤害真实业务。

重点检查以下用户和请求：

• 大型企业或校园NAT出口；

• 搜索引擎爬虫；

• 支付、短信和物流回调；

• 移动App API；

• 合作方固定IP；

• WebSocket长连接；

• 上传、下载和视频分片；

• 秒杀或直播开始时的真实流量高峰；

• 无法运行JavaScript或验证码的客户端；

• 海外用户与代理网络。

Cloudflare的Under Attack Mode官方说明明确提示，该模式会向访客展示中间验证页面，并可能暂时影响访问和分析数据。

这说明防护动作本身也有业务成本。评估厂商时不能只问“能不能拦”，还要问：

拦截后用户看到什么？
API是否会收到403或挑战页面？
误拦截怎样定位？
规则能否先以观察模式运行？
紧急回滚需要多久？

合同里要看什么，而不是只看宣传页

宣传页面可以随时调整，真正涉及责任的内容应进入订单、服务条款或SLA。

至少确认以下项目：

特别要看“无限防护”“不计量防护”后面的限制：

• 是否适用于当前套餐；

• 是否存在合理使用政策；

• 是否可以因风险过高暂停客户；

• 正常业务带宽是否另行收费；

• 高峰期间是否降低线路质量；

• 是否只有特定节点具备高防能力；

• 攻击导致的源站扩容费用由谁承担。

SLA赔付通常是服务抵扣，不一定等于业务损失赔偿。必须看合同原文，不能只听口头解释。

不发起攻击，也能做哪些验证

检查接入后的真实请求路径

确认业务域名已经经过高防CDN，并记录：

CNAME链
响应IP与ASN
IPv4和IPv6入口
TLS证书
响应头
缓存状态
不同地区的连接结果

这不能证明清洗容量，但能确认接入链路是否符合厂商描述。

检查源站是否被限制

在已获授权的环境中，使用正确Host和SNI尝试直连自有源站，确认普通公网请求不能绕过CDN取得业务内容。

这不是攻击测试，只是访问控制验收。

检查控制台是否具备可观察性

查看是否能获取：

• 安全事件列表；

• 请求和流量趋势；

• 防护动作；

• 规则命中原因；

• 源站错误和健康状态；

• 地区、ASN或请求特征；

• 日志导出或API；

• 告警通知；

• 事件报告。

如果演示账号只有总请求量和一个“安全防护已开启”状态，后续真实事件很难定位。

做桌面应急演练

不发送攻击流量，只模拟“监控告警已经触发”：

谁确认业务异常？
谁联系厂商？
需要提供哪些信息？
厂商通过什么渠道响应？
谁有权限调整防护规则？
API误拦截时怎样回滚？
攻击持续时怎样保护源站？
事件结束后谁提供报告？

CISA在理解和响应DDoS攻击指南中强调，应提前建立覆盖识别、缓解和恢复的DDoS响应计划，而不是攻击发生后再临时寻找联系人。

如果一次桌面演练就暴露出没有7×24联系人、权限不清和日志无法导出，这些问题比宣传数字更值得优先解决。

要求提供脱敏事件报告

厂商可以隐藏客户名称、域名和IP，但应保留：

• 时间线；

• 攻击指标口径；

• 防护动作；

• 业务健康状态；

• 误拦截情况；

• 恢复过程；

• 后续改进。

拒绝提供任何结构化材料，只给一张峰值截图，可信度有限。

检查状态页和历史故障记录

成熟厂商不一定从不故障，但应该能够说明：

• 哪个组件发生问题；

• 影响了哪些区域；

• 何时发现；

• 如何缓解；

• 是否发布复盘；

• 后续做了什么改进。

完全没有公开故障不一定代表从未出问题，也可能只是缺少透明度。

用证据等级代替“相信或不相信”

可以把厂商回答分成四个等级：

例如厂商声称“支持应用层自动防护”：

• 如果能在控制台看到对应规则、动作和日志，并写入合同，接近A级；

• 如果只有官方文档，但当前套餐没有该功能，最多是B级；

• 如果销售说“出问题联系我们”，属于C级；

• 如果宣传页只写“智能AI防御”，属于D级。

这也符合CDNChart在CDN安全评分方法中采用的边界：TLS协议和响应头可以进行公开实测，而DDoS清洗容量、WAF和Bot能力通常只能标记为厂商声明或配置证据，不能伪装成已经独立验证的结论。

一份可以直接发给厂商的问题清单

采购或续费前，可以要求厂商书面回答：

1. 当前套餐保护哪些域名、IP、协议和端口？
2. L3/4与HTTP L7分别由什么系统处理？
3. 宣传中的防护数字是什么口径？
4. 单客户、单域名、单IP是否存在上限？
5. bps、pps、rps和并发分别如何计量？
6. 防护是常态在线、自动触发还是人工牵引？
7. 检测时间和缓解时间从什么事件开始计算？
8. 什么情况下会限速、黑洞或暂停服务？
9. 动态API和缓存MISS请求如何保护源站？
10. WebSocket、HTTP/3和非HTTP业务是否支持？
11. 能否提供脱敏事件报告和日志字段样例？
12. 日志保存多久，能否通过API或文件导出？
13. 误拦截如何申诉、放行和回滚？
14. 是否支持源站IP限制、认证请求或mTLS？
15. IPv4和IPv6是否执行相同防护策略？
16. 攻击期间的正常流量怎样计费？
17. 7×24应急响应通过什么渠道联系？
18. 攻击期间是否适用可用性SLA？
19. SLA违约是服务抵扣还是费用赔付？
20. 多节点或多区域故障时怎样切换？

无法一次回答全部问题并不等于厂商一定不可靠，但核心保护范围、容量口径、源站防绕过、黑洞策略、日志和费用边界不能长期模糊。

哪些表现应该提高警惕

出现下面这些情况时，不要仅凭低价或大数字下单：

• 只宣传全球总带宽，不说明单客户保障；

• 把历史最大攻击当成套餐防护上限；

• 无法区分bps、pps和rps；

• 把WAF、CC防护和DDoS清洗混为一谈；

• 声称绝不误拦截，却没有日志和回滚机制；

• 防护必须出事后联系销售手动开通；

• 源站仍可被公网直接访问；

• 不说明黑洞、限速和暂停条件；

• 无法提供控制台演示或事件报告样例；

• “无限防御”只存在于宣传页，合同没有对应承诺；

• 攻击流量免费，但正常业务带宽和清洗后流量费用不透明；

• 只列节点数量，不说明高防能力实际部署在哪些节点。

普通网站最低应该确认什么

预算有限的中小网站不需要建立复杂的安全采购体系，但至少应确认六件事：

业务流量是否一直经过高防CDN
源站是否不能被直接绕过
网络层和HTTP层保护是否都包含
防护是否自动启用
攻击期间是否会额外收费或黑洞
出现误拦截时能否找到7×24支持

如果这六项都没有明确答案，再大的防护数字也很难转化为实际保障。

需要进一步比较候选产品时，可以结合高防CDN怎么选？防护能力、节点与测试方法中的线路、节点、回源和计费维度建立同口径表格，而不是把不同厂商的宣传数字直接放在一列比较。

常见问题

不做攻击测试，能百分之百确认高防CDN能力吗？

不能。没有真实攻击或经过授权的专业验证，就无法完全确认极端情况下的清洗能力。但可以通过技术架构、控制台、事件报告、合同、源站保护和应急流程显著降低采购不确定性。

可以对自己的域名做DDoS测试吗？

不能只因为域名属于自己就直接测试。流量还会经过CDN共享设施、运营商和云平台，可能影响第三方并违反服务协议。任何高负载或安全测试都应取得CDN、云厂商和相关网络方的书面授权，并限定目标、时间和停止条件。

厂商写“无限防护”就不会黑洞吗？

不一定。“无限”可能只表示不按攻击流量计费，不代表没有公平使用政策、单客户限制、区域容量或暂停服务条款。应以合同和产品规则为准。

有WAF是不是就能防CC和HTTP DDoS？

不能直接等同。WAF擅长识别Web攻击特征，HTTP DDoS还涉及行为、速率、请求成本、客户端识别和源站健康。部分产品会整合这些能力，但需要分别确认。

Anycast节点越多，防护能力越强吗？

节点数量和Anycast覆盖有助于分散流量，但防护还取决于上游带宽、清洗能力、自动化策略、单区域容量和源站保护。节点多不能单独证明防护效果。

攻击流量被拦截了，为什么源站还是宕机？

可能存在源站IP被绕过、动态请求穿透缓存、数据库或第三方接口耗尽、回源连接数过高，以及防护规则只覆盖部分路径等问题。需要把边缘事件与源站健康指标放在同一时间线上检查。

ISO 27001、SOC报告能证明DDoS清洗能力吗？

不能直接证明。这类认证或审计可以反映安全管理、流程和控制体系，但不能替代具体的防护容量、自动缓解、日志能力和攻击期间可用性证据。

价格很高的高防CDN一定更靠谱吗？

不一定。高价可能包含更好的线路、支持、日志、专属规则和SLA，也可能只是不同计费模式。应按照相同保护对象、地区、流量、支持和合同口径比较。