Without Attack Testing, How Can You Tell If a High-Protection CDN's Protection Claims Are Credible?

One DDoS-protected CDN claims it supports 'Tbps-level protection,' 'second-level scrubbing,' and 'unlimited defense,' while another showcases global bandwidth, number of nodes, and largest historical attack peak. At first glance, it seems the larger the protection numbers, the stronger the capability.

The problem is these numbers may not be based on the same definition at all.

Some refer to total global network capacity, some to the largest peak ever handled by the entire scrubbing platform, some to a single node's capacity, and some merely to attacks a vendor has observed historically. None of these mean your domain, plan, and region can receive the same level of protection.

Ordinary users also should not generate DDoS traffic against a website just to verify marketing claims. Even if you test your own domain, the traffic may still traverse shared CDN nodes, carriers, and cloud platforms, violating terms of service, affecting other customers, and even triggering security response.

Not conducting attack tests does not mean you have to rely on sales talk. A more reliable approach is to build a chain of evidence:

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

Judging whether a DDoS-protected CDN is reliable is not about finding an absolutely safe number, but about confirming that marketing claims, product capabilities, technical architecture, and contractual responsibility align with one another.

First ask: what exactly does this DDoS-protected CDN protect?

'Supports DDoS protection' is not a complete answer.

A DDoS-protected CDN usually serves HTTP and HTTPS websites, protecting web traffic through domain onboarding. But a website's actual business may also include:

• WebSocket long connections;

• API endpoints;

• HTTP/3 and QUIC;

• File downloads;

• Audio and video delivery;

• Game TCP or UDP ports;

• Email, SSH, and database services;

• Dedicated public IPs;

• Authoritative DNS services.

If a product only proxies HTTP and HTTPS domains, you cannot assume it also protects SSH, game UDP ports, or other public services on the origin server.

Before evaluation, create a protected asset table:

If sales only say 'full-business protection' but cannot map protocols, ports, domains, and IPs item by item, that is the first risk signal.

'Protection bandwidth' must be clarified: which kind of number is it?

When you see1 Tbps,10 Tbpsor a higher number, do not compare the size first; ask what it represents.

At minimum, distinguish among:

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

These numbers cannot substitute for one another.

For example, 'global network capacity of hundreds of Tbps' only shows the vendor has a larger network; it does not prove that a specific region, carrier line, or basic plan can use all that capacity.

'Has defended against a 10 Tbps attack' also does not mean every customer gets 10 Tbps of protection. You still need to ask:

• Is this peak or sustained traffic;

• How long did it last;

• Is it a single target or the sum of multiple targets;

• Which region did it occur in;

• Is attack traffic measured in bps, pps, or rps;

• Was legitimate business still available during mitigation;

• Under what plan conditions will rate limiting, blackholing, or suspension occur;

• Are there per-customer, per-domain, or per-node limits.

What really matters is not the largest attack a vendor has seen, but what treatment your business can receive under the contract and current architecture.

bps, pps, and rps cannot be mixed into one 'protection value'

Different attack types consume different resources.

A low-bandwidth, high-pps small-packet attack may mainly consume network device and connection state resources; an HTTP attack with many requests to dynamic endpoints may not have impressive bandwidth, yet it can overwhelm applications, databases, and third-party APIs.

Therefore, '100G protection' cannot automatically lead to 'how many HTTP requests it can defend against,' nor does it prove that dynamic APIs remain available during an attack.

You must distinguish L3/4 protection, L7 protection, WAF, and Bot management

DDoS-protected CDNs often place multiple security capabilities in one marketing graphic, but they solve different problems:

• L3/4 DDoS protection mainly handles network-layer and transport-layer traffic;

• HTTP DDoS protection mainly identifies application-layer request floods;

• WAF mainly targets Web attack signatures such as SQL injection, XSS, and path exploitation;

• Rate Limiting restricts clients based on request frequency;

• Bot management identifies automated programs and their behavior;

• CAPTCHAs or challenges are used to distinguish some real users from automated requests;

• Caching can reduce the number of times static content reaches the origin.

Cloudflare'sofficial DDoS attack coverage documentationalso describes L3/4 and L7 protection separately and handles network-layer and HTTP-layer attacks through different managed rules. This example shows that mature products break out protection layers rather than summarizing all capabilities with a single 'DDoS protection' switch.

When evaluating other vendors, use the same approach:

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

If sales explain WAF, CC protection, DDoS scrubbing, and Bot management as the same capability, it suggests the product boundaries may not be clearly defined.

'CC attack protection' must be tied to specific rules

In marketing, 'CC attacks' usually refers to large numbers of HTTP requests consuming website resources, but it is not a precise metric you can directly configure.

You need to ask further:

• Rate limiting by IP, cookie, session, device, or API key;

• Does it support path-level rules;

• Does it distinguish GET, POST, and other methods;

• Can it identify large numbers of legitimate users behind shared NAT;

• Does it support different thresholds for login, search, order, and other endpoints;

• After a threshold is exceeded, does it log, rate-limit, challenge, or block;

• How long until rule changes take effect;

• Can you view the match reason and blocked samples;

• How are mobile apps and API clients handled when they cannot execute browser challenges.

If a vendor only answers 'the system automatically identifies it' but cannot explain visible metrics, actions, and false-positive handling, it is hard to judge what automated protection actually does.

See whether it is automatic protection or manual switching after an incident

DDoS protection products generally fall into two basic modes:

Always-on protection

Traffic always passes through the protection network, and the system continuously builds a baseline of normal traffic. When anomalies are detected, mitigation policies are enabled automatically.

The advantage is fast switching; the drawback is the need to maintain false-positive control and normal access performance over time.

On-demand diversion or manual switching

Normally traffic uses ordinary routes; after an attack is detected, DNS, routing, or the DDoS-protected entry point is switched.

This mode may reduce steady-state costs, but you need to ask:

• Who is responsible for determining an attack;

• Is manual ticket submission required;

• How long from anomaly detection to completed switching;

• Does DNS caching affect when it takes effect;

• How are existing connections handled during switching;

• How do you switch back after the attack stops;

• Who operates it at night and on holidays.

If 'second-level protection' actually involves contacting sales after an anomaly, opening a ticket, and waiting for manual configuration changes, it cannot be considered true automatic second-level mitigation.

Can the vendor prove it detected the attack

When you do not conduct attack tests, the console and incident reports are very important evidence.

A mature DDoS-protected CDN should generally provide some of the following:

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

AWS Shield Advanced'sofficial capability descriptiontreats health checks, automatic application-layer mitigation, and event visibility as separate capabilities; itsmetrics documentationalso states that it publishes metrics such as detection, mitigation, and top traffic contributors.

This does not mean all DDoS-protected CDNs must use the same interface; it means protection cannot be just a single 'blocked' number. Users need to know when the system determines an attack, what action it took, and whether the business is still healthy.

Before purchase, you can ask the vendor for a redacted sample incident report. Real customer names and IPs are unnecessary, but the report structure should be complete.

Do not treat an 'attack screenshot' as all the evidence

Common marketing screenshots may only show:

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

This image does not answer:

• Did the peak last seconds or hours;

• Does it count only traffic entering the entire network;

• Did a single customer actually sustain that traffic;

• Was the business accessible during the attack;

• Did widespread false positives occur;

• Was the origin still online;

• Was blackholing or temporary blocking triggered;

• How much extra did the customer pay for it.

More valuable material is a complete timeline:

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

If a vendor claims 'zero-second protection' and 'zero false positives,' be cautious. Real security systems must trade off detection speed, false-positive rate, and normal user experience.

Health checks are closer to business outcomes than attack numbers

A DDoS protection system identifying large amounts of attack traffic does not mean the website is necessarily available. What you should really focus on is:

• HTTP success rate;

• P95 latency of pages and APIs;

• TLS connection success rate;

• Origin CPU, memory, and connection counts;

• Database and third-party API status;

• Whether critical business paths are functioning normally;

• Whether legitimate users are challenged or blocked during protection.

For example, AWS Shield Advanced allows Route 53 health checks to be associated with protected resources to improve the speed and accuracy of detection and mitigation. This design reflects an important principle: DDoS determination cannot rely only on traffic; it must also consider whether the application is healthy.

When evaluating a DDoS-protected CDN, ask whether the vendor can place traffic events and business availability on the same timeline, rather than only showing scrubbed traffic.

If the origin can be bypassed, even the highest protection numbers are meaningless

If attackers know the origin IP and can access the origin directly, they can bypass CDN edge scrubbing, WAF, rate limiting, and Bot protection.

You need to confirm:

• Does the business domain resolve only to the CDN;

• Do historical origin IPs still serve content directly;

• Do unproxied subdomains expose the origin;

• Are both IPv4 and IPv6 restricted;

• Does the origin security group allow only CDN origin-pull networks;

• Does it support secret origin headers, signatures, or mTLS;

• Can it use a private origin, tunnel, or dedicated line;

• Do email and admin panels share addresses with the web origin.

The goal of origin hiding is not to make the IP permanently undiscoverable, but to ensure that even if the address is known, unauthenticated public requests cannot bypass the CDN. For specific checks, see the pending review articleWhy can the origin IP still be seen when using a CDN? How far should origin hiding go.

If a vendor promotes DDoS protection capabilities but does not provide any origin anti-bypass solution and only tells users to change a CNAME, the protection loop is incomplete.

Anycast alone cannot prove protection capability

Anycast allows multiple nodes to announce the same address and directs traffic to different network entry points. It helps distribute traffic and improve network availability, but 'uses Anycast' does not equal 'can defend against attacks of any scale.'

You also need to confirm:

• How many regions actually announce the address;

• Where attack traffic is scrubbed;

• Entry and scrubbing capacity in a single region;

• Whether routes are withdrawn when a node fails;

• Whether an attack may direct legitimate users to remote nodes;

• Whether configurations, rules, and certificates are consistent across nodes;

• Whether a given carrier has a single point of failure or upstream bottleneck.

For architectural differences, see the pending review articleWhat is the difference between an Anycast CDN and a DNS-scheduled CDN? Should ordinary websites care.

The real judgment still comes down to availability, routing quality, scrubbing locations, and failure recovery in the target user regions, not the term Anycast itself.

Find out which legitimate users false positives will affect

Protection rules that are too loose will miss attacks, while those too strict may harm real business.

Focus on checking the following users and requests:

• Large enterprise or campus NAT egresses;

• Search engine crawlers;

• Payment, SMS, and logistics callbacks;

• Mobile app APIs;

• Partner fixed IPs;

• WebSocket long connections;

• Uploads, downloads, and video segments;

• Real traffic peaks at flash sales or livestream starts;

• Clients that cannot run JavaScript or CAPTCHAs;

• Overseas users and proxy networks.

Cloudflare'sofficial Under Attack Mode documentationclearly notes that this mode displays an interstitial verification page to visitors and may temporarily affect access and analytics data.

This shows that protection actions themselves have business costs. When evaluating a vendor, do not only ask 'can it block'; also ask:

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

What to look for in the contract, not just the marketing page

Marketing pages can be adjusted at any time; content that truly involves responsibility should be included in the order, terms of service, or SLA.

Confirm at least the following items:

Pay special attention to the limits behind 'unlimited protection' and 'unmetered protection':

• Whether it applies to the current plan;

• Whether a fair use policy exists;

• Whether the customer can be suspended for excessive risk;

• Whether normal business bandwidth is billed separately;

• Whether line quality is reduced during peak periods;

• Whether only specific nodes have DDoS protection capabilities;

• Who bears origin scaling costs caused by attacks.

SLA compensation is usually service credits and does not necessarily equal business loss compensation. You must read the contract text, not just rely on verbal explanations.

What verification can you do without launching attacks

Check the real request path after onboarding

Confirm that the business domain goes through the DDoS-protected CDN and record:

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

This cannot prove scrubbing capacity, but it can confirm whether the onboarding path matches the vendor's description.

Check whether the origin is restricted

In an authorized environment, use the correct Host and SNI to attempt a direct connection to your own origin and confirm that ordinary public requests cannot bypass the CDN to retrieve business content.

This is not an attack test; it is access control acceptance.

Check whether the console provides observability

See whether you can obtain:

• Security event list;

• Request and traffic trends;

• Protection actions;

• Rule match reasons;

• Origin errors and health status;

• Region, ASN, or request characteristics;

• Log export or API;

• Alert notifications;

• Incident reports.

If a demo account only has total request volume and a 'security protection enabled' status, it will be difficult to pinpoint real incidents later.

Conduct a tabletop emergency exercise

Without sending attack traffic, only simulate 'monitoring alerts have been triggered':

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

In CISA'sUnderstanding and Responding to DDoS Attacks guideit emphasizes building a DDoS response plan covering identification, mitigation, and recovery in advance, rather than looking for contacts after an attack occurs.

If a single tabletop exercise reveals there is no 24/7 contact, permissions are unclear, and logs cannot be exported, these problems are more worth solving first than marketing numbers.

Request a redacted incident report

Vendors may hide customer names, domains, and IPs, but should retain:

• Timeline;

• Attack metric definitions;

• Protection actions;

• Business health status;

• False positives;

• Recovery process;

• Follow-up improvements.

Refusing to provide any structured material and only giving a peak screenshot has limited credibility.

Check the status page and historical incident records

A mature vendor may not never have outages, but it should be able to explain:

• Which component had the problem;

• Which regions were affected;

• When it was discovered;

• How it was mitigated;

• Whether a postmortem was published;

• What improvements were made afterward.

No public incidents at all do not necessarily mean there have never been problems; it may simply mean a lack of transparency.

Use evidence levels instead of 'believe it or not'

You can divide vendor answers into four levels:

For example, if a vendor claims 'supports automatic application-layer protection':

• If you can see corresponding rules, actions, and logs in the console and they are written into the contract, it is close to Level A;

• If only official documentation exists but the current plan lacks the feature, it is at most Level B;

• If sales say 'contact us if there is a problem,' that is Level C;

• If the marketing page only says 'intelligent AI defense,' that is Level D.

This also aligns with the boundaries CdnChart uses inCDN security scoring methodologyin that TLS protocols and response headers can be publicly tested, while DDoS scrubbing capacity, WAF, and Bot capabilities can usually only be marked as vendor claims or configuration evidence, not disguised as independently verified conclusions.

A question list you can send directly to vendors

Before purchasing or renewing, you can ask the vendor to answer in writing:

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. 多节点或多区域故障时怎样切换？

Being unable to answer all questions at once does not necessarily mean a vendor is unreliable, but core protection scope, capacity definitions, origin anti-bypass, blackhole policy, logs, and cost boundaries should not remain vague for long.

What signs should raise your vigilance

When the following situations appear, do not place an order based only on low price or big numbers:

• Only promoting global total bandwidth without explaining per-customer guarantees;

• Treating historical maximum attacks as the plan's protection limit;

• Unable to distinguish bps, pps, and rps;

• Conflating WAF, CC protection, and DDoS scrubbing;

• Claiming absolutely no false positives but having no logs and rollback mechanism;

• Protection must be manually activated by contacting sales after an incident;

• The origin can still be accessed directly from the public internet;

• Not explaining blackhole, rate limiting, and suspension conditions;

• Cannot provide a console demo or sample incident report;

• 'Unlimited defense' exists only on the marketing page, with no corresponding commitment in the contract;

• Attack traffic is free, but normal business bandwidth and post-scrubbing traffic fees are not transparent;

• Only listing the number of nodes without explaining where DDoS protection capabilities are actually deployed.

What should an ordinary website confirm at minimum

Small and medium-sized websites with limited budgets do not need a complex security procurement system, but they should at least confirm six things:

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

If there are no clear answers to these six items, even larger protection numbers are hard to convert into actual assurance.

If you need to further compare candidate products, you can combineHow to choose a DDoS-protected CDN? Protection capability, nodes, and testing methodsto build a same-basis table using dimensions such as routes, nodes, origin pulls, and billing, rather than directly comparing different vendors' marketing numbers in one column.

Frequently asked questions

Can I be 100% certain of a DDoS-protected CDN's capability without attack testing?

No. Without real attacks or authorized professional validation, you cannot fully confirm scrubbing capability under extreme conditions. But you can significantly reduce procurement uncertainty through technical architecture, console, incident reports, contracts, origin protection, and emergency processes.

Can I conduct DDoS testing against my own domain?

You cannot test directly just because the domain belongs to you. Traffic also passes through shared CDN infrastructure, carriers, and cloud platforms, may affect third parties, and may violate terms of service. Any high-load or security testing should obtain written authorization from the CDN, cloud provider, and relevant network parties, and define the target, time, and stop conditions.

If a vendor writes 'unlimited protection,' will there be no blackholing?

Not necessarily. 'Unlimited' may only mean attack traffic is not billed; it does not mean there is no fair use policy, per-customer limit, regional capacity, or service suspension clause. The contract and product rules should govern.

Does having a WAF mean it can defend against CC and HTTP DDoS?

Not directly equivalent. WAF excels at identifying Web attack signatures; HTTP DDoS also involves behavior, rate, request cost, client identification, and origin health. Some products integrate these capabilities, but each must be confirmed separately.

Does having more Anycast nodes mean stronger protection?

The number of nodes and Anycast coverage help distribute traffic, but protection also depends on upstream bandwidth, scrubbing capacity, automated policies, single-region capacity, and origin protection. Many nodes alone cannot prove protection effectiveness.

If attack traffic is blocked, why is the origin still down?

Possible reasons include origin IP bypass, dynamic requests passing through cache, database or third-party API exhaustion, excessive origin connection counts, and protection rules covering only some paths. You need to examine edge events and origin health metrics on the same timeline.

Can ISO 27001 and SOC reports prove DDoS scrubbing capability?

Not directly. Such certifications or audits can reflect security management, processes, and control systems, but cannot replace evidence of specific protection capacity, automatic mitigation, logging capability, and availability during attacks.

Are more expensive DDoS-protected CDNs necessarily more reliable?

Not necessarily. A higher price may include better routes, support, logs, dedicated rules, and SLA, or it may simply be a different billing model. Compare using the same protected objects, regions, traffic, support, and contract definitions.