How to Choose a DDoS-Protected CDN: What to Look for in Protection, Nodes, and Testing Scope

After reading some DDoS-protected CDN product pages, you may come away with a false impression: the higher the mitigation peak and the more nodes, the safer your website is.

Only after you actually onboard might you discover that the “Tbps-level protection” on the marketing page refers to a network-wide resource pool, not necessarily the capacity a single business can obtain. If you buy too little normal business bandwidth, traffic gets rate-limited even when there is no attack. DDoS-protected nodes may block attacks yet force legitimate users to take a longer path. And if CC rules are set too aggressively, attack requests are blocked, but search engine crawlers, API calls, and legitimate users get caught in the net as well.

So when choosing a DDoS-protected CDN, you cannot compare a single protection figure alone. You need to answer at least three questions at the same time:

• What can it protect against, and to what extent is that guaranteed?

• Do the protection nodes cover your actual users?

• Does testing cover normal access, false positives from rules, and behavior after protection switching?

Overlook any one of these three, and your selection could be off the mark.

First, confirm whether you actually need a DDoS-protected CDN

“DDoS-protected CDN” is not a product name with a fully standardized set of specifications. Vendors may bundle CDN, DDoS protection, CC protection, WAF, bot management, and Layer 4 proxying into one offering, but whether each capability is included, which protocols it supports, and how it is billed vary from vendor to vendor.

Start by identifying your business type:

If your business does not run over HTTP/HTTPS, do not assume a product can protect TCP or UDP ports just because “CDN” appears in its name.

Conversely, the fact that a DDoS-protected IP can scrub attack traffic does not mean it offers full edge caching, static asset optimization, or global node scheduling.

Evaluate protection by attack layer first, not by the “how many G” figure

DDoS attack is an umbrella term. The risks a website faces fall into at least the following categories.

Network-layer and transport-layer attacks

These typically aim to exhaust bandwidth, connection state, or the processing capacity of network devices — for example, UDP floods and SYN floods.

When evaluating this, find out whether the service covers L3/L4 attacks, which protocols it supports, and how traffic is handled once an attack exceeds the capacity you purchased.

HTTP floods and CC attacks

These attacks look more like a large volume of normal web requests and mainly consume connections, request-processing capacity, and database or backend API resources.

A large network-layer scrubbing capacity alone does not mean the service can accurately identify malicious application-layer requests.

What matters more here:

• Whether rules can be defined by URL, request method, header, cookie, client characteristics, and similar conditions;

• Whether it supports rate limiting, managed challenges, CAPTCHAs, or other verification actions;

• Whether rules offer a monitor or log-only mode so false positives can be checked before going live;

• Whether it can distinguish between different paths such as login, search, payment callbacks, and open APIs;

• Whether it provides detailed logs of rule hits, attack sources, and blocked requests.

Cloudflare's public documentation for its DDoS system shows that application-layer detection analyzes signals such as HTTP request metadata, request rates, and origin error rates, and that mitigation actions may include blocking, managed challenges, and logging. This helps explain why HTTP-layer protection cannot be measured by bandwidth alone. SeeHow Cloudflare DDoS protection works.

Web vulnerability attacks and malicious bots

SQL injection, XSS, and exploit attempts fall more within the scope of WAF protection; malicious scraping, credential stuffing, scalping, and automated abuse may require bot management, behavioral detection, or business risk controls.

WAF, bot protection, and DDoS protection are related but not interchangeable.

When a vendor says it “supports web security,” you still need to confirm which rule sets are included, whether they can be customized, whether they cost extra, and how long logs are retained.

Mitigation peak, business bandwidth, and QPS: three separate line items

The most common misreading of DDoS-protected products is comparing several completely different capacity metrics side by side.

Alibaba Cloud's official documentation clearly distinguishes baseline protection bandwidth, elastic protection bandwidth, and business bandwidth, and notes that an attack exceeding the baseline may trigger elastic protection charges; legitimate traffic exceeding business bandwidth can likewise lead to throttling or extra costs.

SeeAlibaba Cloud DDoS Protection instance purchase documentationandElastic protection bandwidth billing documentation.

This is not an issue unique to one vendor; it is a set of specifications you must break apart deliberately whenever you compare DDoS-protected products.

When you see “1 Tbps of protection,” keep asking at least:

• Is this the total capacity of the whole network, the capacity of a single scrubbing center, or the capacity one customer can use?

• Is it a baseline commitment, an elastic ceiling, or “best-effort protection”?

• Are single attacks, multiple attacks in the same period, and simultaneous attacks on several domains all counted the same way?

• Once the spec is exceeded, does the system blackhole, rate-limit, switch resources, or generate usage-based charges?

• Are elastic charges calculated by attack peak, duration, or a fixed tier?

• Are there limits on the number of mitigation events, regions, IPs, or domains?

If the sales contract and SLA do not spell this out, the big numbers on the product homepage tell you little about the actual scope of coverage.

“Unlimited protection” and “full-strength protection” still need boundaries defined

Unlimited protection does not necessarily mean your business stays available under any attack size, unconditionally. It may come with fair-use limits, specified attack types, specified regions, event caps, or best-effort clauses.

For claims like these, do not just ask whether they exist — get answers the vendor will confirm in writing:

• Which situations count as committed protection, and which are best-effort?

• Under what attack conditions does blackholing or traffic blocking kick in?

• Is there SLA compensation if protection fails?

• Are normal business bandwidth and QPS still guaranteed during an attack?

• Do major promotions, launch events, or special campaigns need to be reported in advance?

• Are protection resources shared across a single domain, a single IP, and the entire account?

With some products, elastic protection is billed by the actual attack peak that triggers it. If you have not set a cost alert or cap, a single attack — even one you successfully fend off — can produce a bill far larger than expected.

Billing rules are therefore part of the security plan itself.

How to evaluate DDoS-protected nodes: look at user paths first, node count second

Nodes in a DDoS-protected CDN do two things: they serve content to legitimate users day to day, and they identify and filter malicious traffic during an attack.

A large number of nodes may mean broader coverage, but the count says nothing about node capacity, line quality, or peak-hour performance.

When evaluating nodes, focus on four questions.

Which node will users be routed to?

If your users are mainly in mainland China, check access from China Telecom, China Unicom, and China Mobile separately in core cities. If they are mainly in Southeast Asia, Europe, or North America, test by actual country and local network distribution.

Do not substitute the “total number of global nodes” for the number of effective nodes in your target regions, and do not test only in the city where the vendor's data center is located.

You can useCDNChart website speed testto observe resolved IPs, connection times, TTFB, and download performance across different regions and carriers.

Are DDoS-protected nodes and regular acceleration nodes the same set of resources?

Some setups route traffic through regular CDN nodes normally and switch to DDoS-protected nodes or scrubbing centers when attacked; others perform detection and mitigation at the edge network at all times.

Neither architecture is inherently better outside a specific business context, but you must ask clearly:

• Do users switch nodes or IPs before and after an attack?

• Is the switch triggered automatically by the system or performed manually?

• Does the switch interrupt existing connections?

• Do DNS TTL and local DNS caching affect how quickly the change takes effect?

• How does legitimate traffic return to origin after scrubbing, and does the path get noticeably longer?

• When does traffic switch back after the attack ends, and could it flap frequently?

Do the nodes truly cover the carriers you need?

“Domestic BGP nodes” are no substitute for real-world testing across the three major carriers. A node's ability to connect to multiple carriers does not mean every line has the same capacity and routing quality during peak evening hours.

If your users are mainly in mainland China, cross-test China Telecom, China Unicom, and China Mobile in core regions at minimum. For a testing approach, see “Which regions and carriers matter most when choosing a CDN for a mainland China audience?” and adjust the weightings based on your own logs.

Where is the origin, and is the origin fetch path reasonable?

Having DDoS-protected nodes out front does not mean origin performance no longer matters. Cache misses, dynamic requests, login endpoints, and uploads still need to reach the origin.

If the DDoS-protected nodes are in mainland China and the origin is far overseas, dynamic requests may still travel a long origin-fetch path after scrubbing; if origin bandwidth is small, even a normal cache miss can overwhelm the origin once attack requests are filtered out.

If the origin IP is not hidden, even strong protection can be bypassed

A DDoS-protected CDN typically relies on reverse proxying: users hit CDN nodes, and the CDN fetches from the origin. If an attacker can discover the origin IP and reach it directly, they can bypass the CDN and send traffic straight to the origin.

When onboarding, check at least:

• Whether current DNS records still expose the origin IP;

• Whether historical DNS records, old subdomains, mail services, or test environments share the origin's IP;

• Whether the origin's security group or firewall allows only CDN origin-fetch addresses;

• Whether origin-fetch authentication headers, mTLS, or other identity verification are available;

• Whether origin management ports are exposed to the public internet;

• Whether the old address can still reach the real business after an IP change.

You can useCDNChart CDN detectionto view a domain's current CNAME, node IPs, and possibly the CDN in use, but it cannot prove the origin is fully hidden.

Origin protection also needs to be checked alongside DNS assets, cloud security groups, host firewalls, and access logs.

What should you test on a DDoS-protected CDN?

A genuinely useful test is not one where you generate a massive traffic attack yourself.

Unauthorized stress testing can affect the vendor's network, other customers, and your own production workloads — and may violate the terms of service.

The safer approach is to agree with the vendor on the POC scope, test window, target domains, traffic limits, and emergency contacts, then validate across the four areas below.

Level one: normal performance with no attack

Establish a baseline first; otherwise, once performance drops during an attack, you will not know where the difference began.

Recommended tests:

• DNS resolution results and the nodes users are routed to;

• TCP connection, TLS handshake, TTFB, and total time;

• P50, P95, and timeout rate;

• Latency for small files and sustained throughput for large files;

• Cold cache, warm cache, and dynamic origin fetches;

• China Telecom, China Unicom, China Mobile, and core user regions;

• Weekdays, weekends, and business peak hours.

Do not base conclusions on a single fastest result. You can refer toCDNChart testing methodologyand use percentiles and a sufficient sample size to observe typical performance and tail fluctuations.

Level two: business compatibility and security rules

List your real business paths and verify each one:

Application-layer protection fears two outcomes above all: rules too loose, and attacks reach the origin; rules too strict, and legitimate users cannot get through.

During the POC, analyze rule matches in monitor or log-only mode first, then adjust actions gradually — do not push the strictest policy to the entire site all at once.

Level three: protection switching and failover drills

What you are testing here is not how big an attack you can generate, but whether the protection workflow is controllable.

With the vendor's cooperation, you can run an authorized drill and observe:

• Whether alerts reach the right contacts in time;

• Whether automatic switching or traffic diversion follows the agreed procedure;

• How success rate, P95, and origin connection counts change during the switch;

• Whether established long-lived connections drop;

• Whether protection nodes still cover major regions and carriers;

• Whether DNS, caching, and sessions return to normal after switching back;

• Whether the console provides attack type, peak, duration, and mitigation actions.

AWS's public DDoS protection material lists packet validation, ACL and shaping, suspicion scoring, and SYN proxying as distinct mitigation mechanisms, showing that “blocking an attack” can involve several different actions.

Buyers do not need to know the vendor's internal algorithms, but they should know what the system does to traffic once protection is triggered. SeeAWS Shield DDoS mitigation mechanisms.

Level four: post-attack analysis and recovery

After a protection event ends, the platform should at minimum let operations staff answer:

• When did the attack begin?

• What type was it?

• How large was the peak?

• Which rules took effect?

• Was the origin affected?

• Were legitimate users blocked by mistake?

So also test:

• Whether attack logs can be searched by time, domain, URL, source, and rule;

• Whether raw logs, reports, or API exports are available;

• Whether alerts distinguish attack traffic from normal traffic spikes;

• Whether log retention meets troubleshooting and audit needs;

• Whether the vendor can provide incident postmortems and rule-tuning recommendations;

• Whether ticket, phone, and emergency response channels work outside business hours.

“The console shows it was mitigated” is only part of the picture. If you cannot explain how the attack was identified, what was blocked, or whether legitimate users were affected, it is hard to improve next time.

How do you scope testing so it does not spiral out of control?

You can keep the test matrix to five dimensions:

Each test unit should use the same URL, file size, cache rules, and sample size wherever possible.

Record fields can include:

时间、地区、运营商、解析IP、HTTP状态码、DNS耗时、
TCP耗时、TLS耗时、TTFB、总耗时、吞吐量、缓存状态、
防护规则、规则动作、源站状态、测试场景

If you need to narrow down candidates first, seeCDN vendor comparisonfor performance, coverage, and publicly available security information, then ask vendors for the official specifications of their current plans.

Public information is good for initial screening; the contract, POC, and real-world monitoring are the final basis.

How do you design a scoring sheet that marketing numbers will not skew?

Risk varies widely across businesses, so scoring weights should differ too. The example below illustrates the method; it is not a universal standard for every website.

It is more practical to set knockout criteria before scoring.

For example: no support for a critical protocol, persistent timeouts on a core carrier, no way to restrict which sources can reach the origin, no acceptable way to control elastic costs, or a vendor unwilling to put its post-limit handling rules in writing.

These issues should not be offset by high scores elsewhere.

When you contact vendors, ask them this list of questions directly

Rather than asking “can you stop DDoS,” frame your questions so the answers can go into a contract and test records:

• Which of L3/L4, HTTP flood, CC, WAF, and bot protection does your coverage include?

• Is the protection capacity you quote a network-wide, per-node, or per-customer specification?

• What are the baseline protection, elastic protection, business bandwidth, and business QPS figures?

• What happens when each spec is exceeded — blackholing, rate limiting, or extra charges?

• How is elastic protection billed, and can budget alerts or a cost cap be set?

• Which cities and carriers in mainland China have DDoS-protected nodes, and do nodes switch during an attack?

• Do you support IPv6, WebSocket, HTTP/3, Range requests, and large file uploads?

• How is the origin IP hidden, and what addresses or authentication are needed to allow only CDN origin fetches?

• Can protection rules log without blocking first, and how quickly can they be adjusted after a false positive?

• How long are attack logs retained, and do you support search, download, and API access?

• Which metrics does the SLA cover, and how are mitigation failures and prolonged unavailability compensated?

• Are POC and authorized drills allowed, and what are the test boundaries and contacts?

Only a solution that can answer these questions clearly is worth testing further.

If a vendor keeps repeating “many nodes, huge capacity, intelligent protection” without giving spec boundaries and post-limit handling, the procurement risk is hard to assess.

FAQ

What is the difference between a DDoS-protected CDN and a regular CDN?

A regular CDN's core job is caching and distributing content; a DDoS-protected CDN typically adds DDoS, CC, WAF, or other security capabilities on top.

But “DDoS-protected CDN” has no fully standardized set of features; the specifics still depend on the product specs and contract.

Can a DDoS-protected CDN stop all DDoS attacks?

No such promise can be made.

Results depend on the attack type and scale, the capacity you purchased, node resources, rule configuration, and origin security. Focus on the committed scope, elastic ceiling, post-limit handling, and availability of normal business during an attack — not on some abstract idea of “stopping everything.”

Is bigger protection capacity always better?

All else being equal, more ample protection resources are certainly valuable.

But if normal business bandwidth is insufficient, CC detection is weak, nodes are far from users, or the origin IP can be accessed directly, even a huge advertised peak will not solve everything.

Can a DDoS-protected CDN fully hide the origin IP?

CDN proxying can keep the origin address out of current DNS records, but whether it is truly hidden also depends on historical DNS, other subdomains, mail services, certificate assets, and origin firewall configuration.

After onboarding, restrict the origin to accept only trusted origin-fetch traffic, and check for old addresses and bypass entry points.

Can I send attack traffic myself to test a DDoS-protected CDN?

Do not test on your own without authorization.

Even if the target is your own domain, it can affect shared networks, upstream services, and other customers. Have the vendor confirm the test window, targets, traffic limits, and permitted methods, or use the vendor's official drill service.

Should a small website buy the highest tier from the start?

There is usually no need to buy at the maximum advertised tier right away.

Look first at historical attacks, business peaks, downtime losses, origin costs, and budget, then choose a baseline tier that covers your main risks — and get clear on elastic scaling and post-limit handling.

If you do not have historical attack data yet, start by compiling access logs, peak bandwidth, peak QPS, and anomalous events, then useCDNChart selection guidanceto narrow your shortlist. Asking for quotes with your real business baseline in hand usually gets you more verifiable answers than asking “which DDoS-protected CDN is best.”