Your domain has no ICP filing, your server is outside Mainland China, and users in Mainland China keep reporting slow pages. When you consider switching CDNs, another question arises: a Hong Kong DDoS-protected CDN costs more, while standard international CDNs offer more choices. Which is the better fit?

If most of your users are in Mainland China and attacks are already disrupting your service, start by testing a Hong Kong DDoS-protected CDN that addresses both connectivity and security. If you primarily deliver public static content or serve users outside Mainland China, compare standard international CDNs first. 

If slow access is the only known problem and you have no evidence of attacks, investigate network routes and origin fetches before paying for more mitigation capacity. Protection capacity does not translate into faster delivery.

The two categories are not sharply defined. A Hong Kong DDoS-protected CDN and a standard international CDN can overlap in both network coverage and security features.

Some global CDNs have locations in Hong Kong, and some entry-level plans already include DDoS protection. What matters is whether the configuration you purchase solves your actual problem.

First, check which edge locations you can use without an ICP filing

Here, an ICP filing means the registration required for certain services in Mainland China. Before comparing prices, ask which acceleration regions your domain can use and what the onboarding requirements are.

Requirements can differ by region even within the same provider. For example, Alibaba Cloud's ESA onboarding guidance lists Global, Mainland China, and Global excluding Mainland China as service regions. The first two require an ICP filing for the domain; the region excluding Mainland China does not.

The label “global CDN” alone therefore does not tell you whether a domain without an ICP filing is eligible. Check whether your chosen configuration includes edge locations in Mainland China and what review requirements apply.

Evaluate your origin and CDN separately. If the origin still runs in a data center in Mainland China, using a CDN in Hong Kong or elsewhere outside Mainland China does not replace the origin provider's filing and onboarding requirements. “No ICP filing required” describes the conditions for a particular service, not necessarily the entire deployment.

For a site with an origin in Hong Kong, the United States, Singapore, or another location outside Mainland China, there are two paths to examine: how users in Mainland China reach the CDN, and how the CDN reaches the origin. Both paths need to work well for performance to improve.

What should you compare between these CDN options?

“Hong Kong” describes an edge location; “DDoS-protected” describes a security capability. Neither label tells you everything about the product.

A standard international CDN may also include security protection. Cloudflare's DDoS protection documentation describes standard protections included in free and paid plans, while advanced features and configuration options vary. Check what your prospective plan already includes before identifying any gaps.

Compare the two quotes against the same set of criteria:

Edge location is particularly easy to misinterpret.

Cloudflare explains in its geographic traffic routing guidance that carrier routing and network interconnections affect where traffic goes; requests do not always reach the geographically nearest data center. Other providers may use different routing methods, so check each one separately.

A map showing a Hong Kong location establishes that the provider has resources there. It does not show how users on China Mobile, China Unicom, or China Telecom actually reach them. Test from those networks.

Likewise, a fast response from a Hong Kong entry point does not guarantee fast dynamic requests. If your origin is in the United States, a login request may still have to travel onward from Hong Kong to the origin. Improving the first leg without improving the origin path may do little to reduce the user's wait.

Where should your budget go first?

Many users in Mainland China, with attacks disrupting logins, transactions, or APIs

Put Hong Kong CDN configurations with suitable DDoS protection on your shortlist for testing.

Focus on what happens during an attack: Is the entry point reachable? Can legitimate requests get through? Can the origin handle the traffic forwarded to it? Can security rules be adjusted for the application?

Volumetric attacks and malicious HTTP requests that exhaust application resources need different responses. An entry point that absorbs substantial attack traffic does not necessarily prevent high-frequency requests from slowing a login API. Aggressive blocking, in turn, can harm legitimate users.

Test logins, payment notifications, and mobile app APIs separately. A machine-to-machine API cannot be assumed to complete a CAPTCHA intended for website visitors. Before buying, confirm that the provider can tailor policies to your authentication flow, request paths, and normal access patterns.

Also check for routes that bypass the CDN and reach your origin directly. Cloudflare's origin protection guidance emphasizes restricting unexpected access to the origin, a basic step when putting a protective proxy in front of it.

If an attacker can reach your origin's public IP address directly, the traffic may never pass through the CDN. For sites already facing this issue, review protection options after an origin IP address is exposed to decide whether to change entry points, restrict origin access, or add network-layer protection at the origin. Dropping requests on the server alone cannot restore upstream bandwidth that is already saturated.

No clear attacks, but access from Mainland China is slow

Finding the slow segment first is often cheaper than moving straight to a higher protection tier.

Choose three real resources or requests: a public page, an image or script file, and a dynamic API that fetches from the origin. Check whether they slow down together in the same regions and time periods.

If cached static files load quickly while login and search remain slow, investigate the origin path and backend processing. If application logs show that a database query already takes a long time, changing CDNs will not remove that delay.

If only certain carriers slow down during the evening peak, compare the actual paths those users take to the CDN entry point before adding security features.

For an origin in the United States or another location outside Mainland China, test network routing and origin optimization for dynamic APIs separately. Even requests that cannot be cached may benefit from a better network path or connection handling, but measure the improvement with the same API on both configurations.

In that case, whether a Hong Kong DDoS-protected CDN is worth buying depends on the routes and services it provides. You may need a performance configuration rather than more mitigation capacity.

Mostly static content, with users across multiple countries and regions

For images, public documents, installation files, and cacheable video segments, start with edge coverage, cache effectiveness, and traffic costs.

If users are widely distributed, content can be cached, and your existing security is sufficient, a standard international CDN may fit the budget better. There is no need to move every public asset to a DDoS-focused configuration solely because of its label.

Static content can still be targeted by attacks and traffic abuse. Check cache policies, request limits, overage charges, and how abnormal traffic is handled. Cacheability alone does not eliminate risk.

You can also split delivery by workload: use a CDN suited to distributing public images and downloads, and a configuration suited to protecting logins, transactions, and critical APIs. Account for certificates, cross-origin access, and origin permissions so the static asset hostname does not expose an origin shared with critical services.

For an origin outside Mainland China that primarily serves users there and also faces attacks, CDN07's DDoS-protected CDN option that does not require an ICP filing can be configured around edge distribution, application bandwidth, and security policies.

Start evaluating the pages or APIs causing the most disruption, then decide which domains and entry points need coverage.

How to test two CDNs before switching production traffic

A trial should reproduce the problems your users actually encounter.

If complaints cluster during the evening peak, collect samples then. If they come mainly from users on one carrier, test that network more extensively. One successful visit from an office connection is not enough to justify a migration.

Keep the origin, content, and cache rules as similar as possible across both configurations. Record cache hits separately from origin requests. Otherwise, a file served directly from one CDN's edge could be compared with a fresh origin fetch through the other, making the speed comparison misleading.

Technical teams can compare entry points before changing DNS

If both providers allow preconfiguration, set up the same application domain, origin, and valid HTTPS certificate on each CDN, then connect through the test entry IP address supplied by each provider.

curl's guide to overriding name resolution explains how --resolve works: it sets a destination address for the current request while retaining the hostname in the URL for HTTPS server name identification and certificate validation. You do not need to change production DNS first.

The following example runs in macOS, Linux, or a WSL Bash environment with curl installed:

for cdn_ip in 203.0.113.10 203.0.113.20; do
  curl -q --noproxy '*' -sS -D - -o /dev/null \
    --resolve "www.example.com:443:${cdn_ip}" \
    --connect-timeout 5 --max-time 20 \
    -w "\nENTRY=${cdn_ip} HTTP=%{http_code} TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n" \
    'https://www.example.com/'
done

The domain and two IP addresses are examples. Replace them with your own test domain and the CDN test entry IP addresses explicitly supplied by the two providers. Do not enter the origin IP address or choose an arbitrary IP address from DNS results as a test entry point.

If a provider does not support this preconfiguration method, follow its trial process using a test domain. Do not hide an onboarding problem by disabling certificate validation.

The command prints response headers and several key results. According to the official curl option reference , read them as follows:

• HTTP: The HTTP response status code. First confirm that the content is correct; a 403 or 429 response calls for checking authentication and security rules. It does not, by itself, indicate a poor network path.
• TTFB: Elapsed time from the start of the request to the first byte, including connection setup and other stages. It is not simply the origin application's execution time.
• TOTAL: Elapsed time for this operation. If it times out or fails, do not treat the value as the duration of a complete download.
• Response headers: Use them to inspect redirects, caching, and security policies. Field meanings vary by provider; refer to the relevant documentation.

-q prevents local curl configuration from affecting the test, and --noproxy '*' bypasses proxies configured in the environment. The command does not automatically follow redirects; if you receive a 3xx response, check the destination first. The connection and overall timeouts are set to five and 20 seconds for this test. They are test limits, not performance standards.

Test a public, read-only page or API that does not trigger billable actions. Keep failures, timeouts, and unexpected status codes in the results instead of recording only the fastest run.

Repeat the test with normal DNS and real clients

The method above tests a specified entry point, but bypasses normal DNS resolution. Nor does one IP address necessarily identify a fixed physical edge location: with Anycast and similar mechanisms, the same IP address can lead to different network entry points.

Before choosing a provider, run controlled tests using normal DNS onboarding to evaluate actual traffic routing. Test browsers, mobile apps, and API clients separately. One curl request does not capture full-page asset loading, script execution, or complete user interactions.

Review the results in three groups:

1. Success rate: Do pages, logins, APIs, and callbacks produce the expected results?
2. Response time: Are the differences persistent across carriers and between daytime and the evening peak?
3. Application behavior: Do uploads complete, WebSocket connections stay stable, and streaming APIs keep sending data?

For a streaming AI API, receiving HTTP response headers does not mean useful content has started arriving. Continue measuring time to the first substantive output, gaps between chunks, and whether the response completes.

These tests measure access quality and compatibility; they do not establish the upper limit of DDoS mitigation capacity. Assess protection using the resources you purchase, policy configuration, incident response procedures, and acceptance criteria agreed with the provider.

Compare the full cost, not just the monthly starting price

Calculate normal usage before comparing protection charges.

At a minimum, gather recent monthly traffic, peak bandwidth, request volume, the number of primary domains, and which workloads cannot be cached. Video, downloads, and AI APIs consume resources differently. A quote based only on homepage traffic may point you to the wrong plan.

Check the full cost against these items:

Check mitigation capacity separately from bandwidth for legitimate traffic. A figure describing how much attack traffic a service can handle is not the sustained bandwidth available for downloads, video, or API requests.

Ask what “dedicated” means in a quote: a dedicated IP address, bandwidth, policies, or mitigation resources? Each has different costs and value.

Once you have a quote, use the method for calculating normal traffic and additional charges to check each line item. Do not double-count what the plan already includes, and clarify any unspecified overage rules in advance.

For sites under frequent attack, include the cost of handling incidents. Repeated late-night rule changes, false-positive investigations, and entry-point migrations consume engineering time. Configuration that fits the application and effective technical support may be worth more than a lower starting price.

Frequently asked questions

Can users in Mainland China access a domain without an ICP filing through a Hong Kong CDN?

You can use a Hong Kong CDN or another CDN outside Mainland China that accepts domains without an ICP filing to provide an entry point for those users. Using edge locations outside Mainland China is different from using locations within it. Actual performance still depends on the user's network, carrier routing, service configuration, and origin health.

Is a Hong Kong DDoS-protected CDN always faster than a standard international CDN?

No. A standard international CDN may also have Hong Kong locations, while a Hong Kong entry point may have a bottleneck on the path to the origin. Compare real results for your main users, especially during the evening peak and for dynamic requests that reach the origin.

Do standard international CDNs lack DDoS protection?

No. Some standard CDNs include relevant protection even in their basic plans. The differences may involve what is protected, policy controls, resource limits, and support. Check the specific product rather than judging by its name.

Do I need a higher-tier DDoS plan if my site has not been attacked?

Base the decision on the cost of downtime, your attack history, and existing protection. A new site with little traffic and limited impact from an outage can test a basic plan first. If downtime for logins, transactions, or critical APIs would cause material losses, assess protection and incident response in advance.

Do I still need a DDoS-protected server after adding a Hong Kong DDoS-protected CDN?

It depends on origin exposure and your application's entry points. A CDN generally protects traffic routed through its proxy. If the origin can still be attacked directly or other ports remain uncovered, you must address origin access controls and network-layer protection separately.

Can game services and AI APIs be onboarded like an ordinary website?

It depends on the protocol and interaction model. A game website, H5 page, or HTTP API can be assessed against the CDN's web proxy capabilities. A separate TCP or UDP game service needs a suitable protection product. For AI APIs, also test streaming output, timeouts, upload size, authentication, and compatibility with security rules. A working homepage is not enough.

Complete these checks before choosing

• Confirm which service regions accept a domain without an ICP filing and the applicable onboarding conditions, along with the origin's deployment requirements.
• Test the user-to-edge and edge-to-origin paths separately for Mainland China. Measure static assets and dynamic APIs separately as well.
• Confirm the protection scope and capacity for legitimate traffic your workload needs, and whether attackers can still bypass the CDN to reach the origin.
• Calculate total cost from actual usage, then weigh evening-peak performance and technical support before migrating.

If your origin is in Hong Kong or elsewhere outside Mainland China and most users are in Mainland China, gather user locations, origin location, critical APIs, and recent attack details, then contact CDN07 to assess a deployment plan . Agree on the network routes and protection configuration to trial first, and verify them with real pages, APIs, and clients before deciding.