After speaking with several DDoS-protected CDN providers, one emphasized “Tbps-scale mitigation,” another focused on low pricing, and a third promised easy onboarding. All three pitches sound appealing, but they still leave one practical question unanswered: Can users access the service reliably, and will the application remain available during an attack?

When evaluating a DDoS-protected CDN, first confirm that the service supports your workload and protocols. Then assess network performance for your target users and the scope of protection. Finally, use trial results and a complete quote to make the decision. Websites, APIs, and games have different requirements; a large headline mitigation figure does not mean critical APIs, origin infrastructure, and every port are protected.

Start with the workload: what exactly needs protection?

A DDoS-protected CDN combines content delivery with attack mitigation, but onboarding methods, protocol support, and security capabilities vary by service. Before procurement, break “protect the entire project” into specific entry points: which domains, which APIs, which connections, and the paths they actually traverse.

This table is a useful first-pass filter. For example, if a team needs to protect UDP game-session traffic but a candidate plan only supports HTTP/HTTPS proxying for websites, the product category is the wrong fit; comparing monthly prices should come later.

Websites, APIs, and games should not share one set of acceptance criteria

Browser users may be able to complete an interactive challenge, while machine clients often cannot. A rule that reduces malicious web traffic may also cause a mobile app to parse an HTML challenge page as JSON, resulting in API errors.

For persistent connections, asking only whether WebSockets are “supported” is not enough. Cloudflare documentation states that the initial HTTP upgrade request is inspected by the WAF, but after the connection is established, the WAF does not continue inspecting subsequent WebSocket traffic. Therefore, “WebSocket support” and “continuous inspection of every application message” are different capabilities; verify each provider’s implementation in its own documentation.Cloudflare WebSocket compatibility documentation

Game deployments should also distinguish among the website, login APIs, resource updates, and real-time game connections. Solutions that require client-side integration should account for SDK integration, release coordination, and rollback costs. See how to choose between a game protection SDK and a DDoS-protected IP service to determine the integration approach before shortlisting providers.

How to evaluate network connectivity: test where your users actually are

Claims such as “a large global edge network,” “direct connectivity to Hong Kong,” and “intelligent routing” can be useful starting points, but they are not substitutes for testing.

You need to validate two network paths: from the user to the CDN edge, and from the edge to your application server. The latter is the origin path, and the application server is the origin. Cached images can be served directly from the edge, while real-time requests such as logins and queries still depend on origin connectivity and backend processing time.

Test where your users are

If most users are in Mainland China, test the major carrier networks—China Telecom, China Unicom, and China Mobile—across key provinces, including evening peak hours. If you also have international users, add regions in proportion to actual traffic rather than choosing a few countries just to create a “global” speed-test chart.

When evaluating connectivity, ask each provider:

• Are the advertised edge locations and network routes included in the plan you would actually buy, or are they only used for demos?
• Can the test domain use routing, security, and origin settings comparable to production?
• If a user network becomes congested or an edge location fails, how does failover work, and how is recovery determined?
• Which segment does the advertised “optimized routing” cover: user to edge, edge to origin, or both?

The lowest latency in a single region tells only part of the story. Also compare typical request times, the share of slow requests, and failure rates. A provider with a better average can still be a poor fit if important user regions see frequent timeouts.

Test APIs for dynamic workloads and full pages for content sites

Use representative production pages and read-only APIs. Keep content versions, origin infrastructure, cache conditions, and security policies as consistent as possible. Do not compare a cached image on one provider against a dynamic page performing its first origin fetch on another.

The following one-off check can be run from a Linux or macOS terminal with curl installed. Replace the example hostname with a public page or read-only endpoint you are authorized to test:

curl -sS --connect-timeout 10 --max-time 30 \
  -o /dev/null \
  -w 'status=%{http_code} ttfb=%{time_starttransfer}s total=%{time_total}s\n' \
  'https://www.example.com/'

status is the HTTP response code, ttfb is the elapsed time from the start of the request until the first byte is received, and total is the total transfer time. The 10-second connection timeout and 30-second overall timeout are limits for this example, not performance acceptance criteria.curl command-line options documentation

Keep timeout and other error records; do not discard failed samples. A 200 response does not necessarily mean the application succeeded—challenge pages can also return it. For 301 or 302, verify the redirect target; this command does not follow redirects automatically.

These checks only provide baseline measurements. Use a browser to validate asset loading and user interactions, and test login and checkout flows in a test environment with test accounts. A single request cannot establish sustained performance, much less protection capability.

Understanding the protection boundary: four things a provider must spell out

The protection boundary defines which traffic the service protects, which entry points remain outside that protection, and what happens when capacity or contractual limits are exceeded. This matters more to procurement than a standalone mitigation-capacity figure.

1. Does protection cover only the domain, or also the origin and other ports?

Putting a website domain behind a CDN does not mean all traffic to the server traverses the CDN. Administrative ports, subdomains that are not onboarded, and other services on the same host should be reviewed separately.

Historical DNS records can also expose an origin IP address. If an attacker bypasses the CDN and targets the origin directly, edge-layer rules are no longer in that traffic path. Address this with origin access restrictions, origin authentication, and upstream protection—not just DNS changes.Cloudflare origin protection documentation outlines checks for historical IP exposure, access control, and origin authentication; use the implementation supported by your chosen provider.

Before procurement, use methods for identifying and hiding origin IP exposure to inventory entry points. Blocking requests on the host alone will not help if an attack has already saturated upstream bandwidth; in that case, also assess network-layer or server-side protection.

2. What is included in volumetric DDoS protection, request-level protection, and application risk controls?

Gbps measures bandwidth volume, pps measures packets per second, and QPS measures requests or queries per second. They measure different things, so a large Gbps figure cannot substitute for application-layer testing.

A cached image and a complex search can impose very different loads on the origin even at the same request rate. Whether a DDoS-protected CDN can rate-limit malicious search requests depends on the specific endpoint, rules, and application behavior.

DDoS protection primarily addresses traffic or request volume intended to make a service unavailable; a web application firewall (WAF) evaluates suspicious web requests; bot management focuses on automated traffic. These controls can work together, but they do not automatically solve account takeover, payment fraud, or application vulnerabilities. For how these controls relate, see how WAF, bot management, and DDoS protection work together.

3. What does “unlimited protection” actually mean?

When a provider uses terms such as “unlimited,” “unmetered,” or “no cap,” ask exactly what the statement applies to. It may refer to how attack traffic is billed or to a specific mitigation allowance. Legitimate traffic bandwidth, request volume, concurrent connections, number of domains, and service terms still need to be confirmed separately.

Ask directly: “Which product and which traffic does this commitment apply to? Are there rate limits, proxy suspension, or blackholing policies? If so, how are customers notified and how is service restored?” Blackholing typically means temporarily dropping traffic to the target, which also affects legitimate access.

If the only answer is “Don’t worry, we can’t be taken down,” with no conditions that can be verified, pause before moving to a paid deployment.

4. Who handles false positives, incidents, and limit exceedance?

When legitimate users are blocked, can the customer find the corresponding security event? Can they identify which type of rule was triggered? Who is authorized to adjust it? If a critical workflow is affected, how do you reach someone who can actually resolve the issue?

During the trial, submit a realistic policy-tuning scenario—for example, protecting a login endpoint while allowing signed partner callbacks to continue working. A provider’s ability to explain rule scope, validation steps, and rollback procedures is more useful than simply asking whether support is “online 24/7.”

How should CDN07, Cloudflare, AWS, and similar options make the shortlist?

When comparing providers, go beyond the brand name and evaluate the specific product and plan. Different products from the same vendor can have different onboarding methods, rule capabilities, and pricing.

The following options can help you build a shortlist. They are not a performance ranking, and providers not listed here may also be suitable.

Cloudflare’s official documentation states that all plans include standard DDoS protection without usage-based billing for attack volume, while some advanced capabilities vary by plan. Therefore, it is not accurate to justify another option by claiming that the free plan has no meaningful protection; actual requirements still need to be compared with plan entitlements.Cloudflare DDoS protection documentation

AWS Shield Standard is provided automatically at no additional charge, while Shield Advanced is a separate subscription for enhanced protection; AWS WAF can also be configured with CloudFront. Evaluate these services as a combined architecture rather than treating CloudFront itself as a catch-all term for every advanced security capability.AWS Shield documentation, Configuring AWS WAF with CloudFront

For websites that need to evaluate Mainland China access and protection policies together, CDN07 combines performance acceleration with attack mitigation and provides configurable edge locations, bandwidth, and security policies. Start with the CDN07 DDoS-protected CDN service to submit specific requirements and evaluate the proposed configuration and acceptance criteria together.

Start by describing the workload: where users are located, which actions cannot fail, where the origin is hosted, and what attacks have occurred before. That context helps determine whether the main issue is network routing, caching, application-layer protection, or origin exposure, and allows targeted configuration requirements.

How to decide whether a trial passes—instead of ending up with a speed-test screenshot

Define must-have requirements first, then compare performance and cost among the options that meet them. If any of the following affects a critical workflow and remains unresolved, a low price should not be enough to approve the solution:

• The required protocol, port, or critical feature is not supported.
• Important user networks consistently fail to meet the agreed access targets.
• Legitimate login, callback, or persistent connections are blocked, with no verifiable remediation path.
• The protection scope, over-limit actions, or billing conditions cannot be clearly explained.
• There is no executable rollback path if something fails after migration.

After those filters, compare page experience, API response times, error rates, and configuration and maintenance overhead on representative networks. Trial records should include sample size, test time, cache state, and security settings; screenshots without that context are difficult to reproduce or verify.

Protection testing requires a separate plan. Attack simulation or stress testing should only be performed with authorization from the relevant CDN, origin, and network providers, with agreed intensity, test windows, and stop conditions. Ordinary access tests validate reachability and functionality; they do not prove that a particular mitigation capacity has been validated.

Review the availability SLA line by line: which service it covers, how downtime is calculated, what exclusions apply, and how service credits are requested. An SLA does not mean outages will never happen, and service-credit terms are not a substitute for a recovery plan.

How to compare monthly pricing without missing the real cost

Compare candidates against the same usage profile. At minimum, confirm base fees; legitimate traffic or bandwidth; request volume; domains and certificates; add-on security features; and related origin egress costs. Billing period, currency, and overage rules should also be listed consistently.

Two quotes can have the same monthly price while one includes the required policies and support and the other requires add-ons or internal maintenance. Their real cost can differ. For a deeper breakdown, see what determines DDoS-protected CDN pricing.

For quote requests, copy the template below and send the same requirements to each candidate provider:

Main user regions, operators, and peak times:
 Origin server location and access method: 
 Domain name, protocol, port, and long connection requirements: 
 Normal bandwidth, traffic, request volume, and concurrency: 
 Existing attack types, time, and available logs:
  Must maintain normal login, callback, upload, and other functions:
   Desired access, error rate, and recovery goals: 
   Test scope, migration time, and fallback requirements: 
   Budget and expected billing cycle: 
   Please specify: 
   Adapted products, included capabilities, excluded scope, limits and overrun actions, complete costs, technical support methods, and executable test and acceptance arrangements.

If a usage figure is not yet known, mark it as “to be measured” rather than guessing high or low just to obtain a quote. Before sharing logs, remove access tokens, session cookies, and personal or sensitive information. Passwords and private keys are not needed at the quotation stage.

Frequently asked questions

Which DDoS-protected CDN is best? Is there one choice that fits every website?

There is no single answer that applies without workload context. Content sites prioritize delivery and caching; transaction systems place more weight on dynamic requests and false-positive control; native games may require different protocols. Eliminate products that do not fit first, then use tests on your own networks and workloads to determine the order of the remaining candidates.

Does a higher DDoS mitigation capacity always make a service a better buy?

Not necessarily. Confirm whether the figure represents platform-wide capacity, a per-customer limit, or a specific test condition. Also evaluate application requests, legitimate-traffic capacity, and actions taken when limits are exceeded. A large bandwidth figure does not prove that an order API is appropriately protected.

Can a lower-cost DDoS-protected CDN be used for enterprise workloads?

Yes, it can be considered if it meets workload requirements and clearly defines pricing, limits, and service scope. A low price alone is not evidence of unreliability; likewise, a high price does not guarantee a good fit. Compare the full service scope and test results.

What is most often overlooked when choosing a DDoS-protected CDN for APIs?

Teams often overlook compatibility between security policies and machine-to-machine clients, along with authentication, upload-size limits, timeouts, and request rate limiting. Testing should verify not only status codes, but also response types, application fields, and whether the caller can process the result correctly.

Do I still need origin protection after deploying a DDoS-protected CDN?

Continue reviewing the origin’s exposed entry points. Requests that do not traverse the CDN should not be assumed to be protected; historical IP addresses, other ports, and services on the same host can create separate paths. Whether you need additional server-side protection depends on these exposures and upstream capabilities.

What information should I provide first when evaluating CDN07?

Start with the workload type, primary user networks, origin location, protocols, and critical workflows; then add normal usage and any historical attack records. This gives both sides a common basis for selecting an approach, designing tests, and producing a comparable quote.

Get verifiable answers before choosing a provider

When evaluating a DDoS-protected CDN, keep four points in mind:

• Workload and protocol requirements define the candidate set. If critical features do not match, change product direction before comparing further.
• Network quality must be validated with target users and real workloads, not by the lowest latency figure alone.
• Protection must clearly define coverage, false-positive handling, and what happens when limits are exceeded.
• The final choice should reflect acceptance-test results, total cost, and incident-handling capabilities.

Once your requirements are documented, ask each candidate provider to explain its proposed solution, then run a clearly scoped validation. If you are considering CDN07, submit your requirements through CDN07 DDoS-protected CDN consultation to define the evaluation around network connectivity, origin paths, and protection scope before selecting a configuration.