If your server is hosted in Singapore or the United States, users in Mainland China may load the homepage reasonably quickly, yet spend much longer waiting for login, search, or order queries. The site may perform normally most of the time, then experience frequent timeouts during peak evening hours or under attack. Looking only at edge location and advertised mitigation capacity is rarely enough to choose the right DDoS-protected CDN.

To evaluate both performance and protection, test the two network segments separately: the path from users to the CDN edge and the path from the edge to the overseas origin. Then evaluate caching, dynamic APIs, and legitimate-user availability during an attack. A DDoS-protected CDN can improve content delivery and security, but it cannot replace database optimization or automatically protect an origin entry that bypasses the CDN.

Before choosing an overseas DDoS-protected CDN, determine where the bottleneck actually is

A CDN, or content delivery network, receives user requests through edge nodes. The origin server is where the website application actually runs and where the original content is stored. An “origin fetch” occurs when an edge node retrieves content from the origin.

For websites hosted outside Mainland China, user access involves at least two network segments that should be evaluated separately: the connection from users in Mainland China to the CDN edge, and the connection from the CDN edge to the overseas origin. When a request is served from cache, the edge can return reusable content directly. Requests that require real-time processing generally still need to reach the origin and application.

These symptoms are useful starting points for troubleshooting, but they are not enough to identify the root cause. For example, an API timeout may result from cross-border connectivity or from a slow database query. If you do not have baseline measurements, start with the troubleshooting approach for slow website access to distinguish connection time, server response time, and resource download time before deciding what type of service to purchase.

How should you compare network connectivity to reflect the real experience of users in Mainland China?

Edge location matters, but the complete delivery path matters more

Hong Kong edge locations are worth including when testing access from Mainland China, but being “in Hong Kong” does not by itself guarantee better performance. The user's carrier network, inter-carrier connectivity, peak congestion, and the path from the edge to the origin can all affect the final result.

Suppose a user is in Guangzhou, the CDN edge is in Hong Kong, and the origin is in the United States. A cached image may be returned directly by the Hong Kong edge, while an order query that requires an origin fetch still has to wait for communication between the Hong Kong edge and the U.S. origin, as well as backend processing. This is an example of a network path, not a measured result from any particular provider.

When you see terms such as “CN2,” “direct connectivity,” or “optimized routes,” ask additional questions: Which part of the path does the optimization cover? Which carrier networks are included? Does it apply to the plan you are purchasing? How does traffic fail over during congestion or an outage? Optimization on one segment does not mean that every user and every request will receive the same performance.

Test according to your user distribution, not the number of measurement locations

Use existing access logs to identify your primary user regions, then cover the China Telecom, China Unicom, and China Mobile networks in those areas. If your service has significant mobile traffic, include cellular network testing as well.

A practical comparison method is to select representative provinces and repeat tests during business hours, evening peak periods, and your own traffic peaks. Record the network, time, URL, cache status, errors, and sample size. One hundred requests from the same data center still do not represent one hundred real-world access environments.

When comparing two providers, use the same application version, the same origin, and comparable security policies. Test the actual production domain using the supported onboarding method from each provider. If you use a test subdomain, also verify cookies, cross-origin rules, and login callbacks so differences in the test environment are not incorrectly attributed to the CDN.

Do not place an image served from one provider's pre-warmed cache and an image requiring its first origin fetch from another provider into the same performance ranking.

Track latency, failure rates, and business outcomes together

TTFB, or Time to First Byte, measures the time from the start of a request until the first byte of the response is received. For browser navigation, TTFB can include DNS resolution, connection establishment, TLS negotiation, redirects, and time spent waiting for the response. A high TTFB therefore does not necessarily mean that the server itself is processing requests slowly. See Google web.dev's TTFB guidance for the measurement methodology.

When evaluating providers, retain at least four categories of results:

1. Typical and slow-request latency. Look at both the median P50 and P95. P95 represents the response time that approximately 95% of samples fall below and is generally more useful than an average for exposing slow requests.
2. Failures and timeouts. Track failed attempts as a percentage of all attempts. Do not remove failed samples and report only the performance of successful requests.
3. Actual page loading. Fast delivery of the homepage HTML does not mean that above-the-fold images, scripts, and third-party resources will also load quickly.
4. Critical business operations. Whether users can complete login, whether queries return the correct data, and whether callbacks are accepted are much closer to actual business outcomes than a screenshot showing low latency.

There is no single “acceptable” response time in milliseconds that applies to every website. Establish a baseline first, then set targets based on the waiting time your users can reasonably tolerate, with separate acceptance criteria for critical workflows such as login and payment.

How should static caching and dynamic APIs be optimized separately?

Cache content that can be safely reused to reduce unnecessary origin fetches

Images, stylesheets, scripts, and publicly downloadable files can be assigned caching policies based on how frequently they change. Here, a “cache hit” means that a request can use an existing cached response; it does not mean that every request must avoid the overseas origin.

When reviewing caching, check whether the content can be shared, how long it can remain cached, and what the actual cache result was. Cache-Control: no-store means the response should not be stored; private without a field restriction means a shared cache should not store the response; no-cache allows the response to be stored but requires validation before it is reused, so it should not be interpreted as “do not cache at all.” These meanings are defined by HTTP caching standard RFC 9111.

User-specific content involving accounts, orders, balances, and similar data should not simply be placed under site-wide caching to increase the cache hit ratio. Also verify that CDN rules do not override origin settings in a way that could cause one user's response to be returned to another user.

During procurement, clarify how cache is purged when a new version is released, how the first request is handled, and whether cache warming or similar capabilities are included in the proposed plan. Serving an outdated price or page because of incorrect cache updates is also a business incident.

For requests that require real-time processing, focus on the origin path and application

Dynamic requests cannot be accelerated simply by copying a page to the edge, but they may still benefit from more suitable network paths, connection reuse, and traffic steering. The actual benefit depends on the network path and service implementation and must be validated using your own APIs.

At minimum, select a set of publicly accessible read-only APIs, then validate login, checkout, and callback workflows in a test environment. If static resources improve significantly while dynamic APIs remain slow, continue investigating edge-to-origin connection time, backend processing time, and database load.

A CDN cannot eliminate slow database queries or make real-time data located at a remote origin appear without communication. For highly interactive applications, if origin fetches remain the bottleneck, also evaluate application deployment locations, data access patterns, and regional service architecture.

How can you use command-line tools to collect comparable performance data?

The following command works in Linux or macOS terminals with curl installed. Replace the example address with a public page or read-only API that you are authorized to test. Do not repeatedly test endpoints that create orders, send SMS messages, or trigger other side effects.

curl -sS --connect-timeout 10 --max-time 30 \
  -D - -o /dev/null \
  -w '\nhttp_code=%{http_code}\nremote_ip=%{remote_ip}\ndns=%{time_namelookup}s\nconnect=%{time_connect}s\ntls_ready=%{time_appconnect}s\nttfb=%{time_starttransfer}s\ntotal=%{time_total}s\n' \
  'https://www.example.com/'

This command makes a single GET request, displays the response headers and timing information, and discards the response body. The 10-second connection timeout and 30-second total timeout are example limits, not service acceptance thresholds. Field definitions are available in the official curl documentation.

Read the results as follows:

• http_code confirms the HTTP response status. A 200 response may still be a verification page, so check it in a browser or inspect the response body. 000 means that no HTTP response code was obtained; check the curl error output.
• dns, connect, and tls_ready are cumulative times measured from the start of the request until each corresponding stage completes. They should not be added together.
• ttfb includes the wait before the first byte is received. total is the total time taken to complete this transfer and does not include the browser's subsequent resource downloads or page rendering.
• remote_ip identifies the remote IP address used for this connection. It can help verify the access path, but the IP's geographic attribution alone cannot establish which data centers handled all of the traffic.

The command does not automatically follow redirects. If you receive a 301 or 302, first inspect the Location header, confirm the final address, and measure the final URL separately. If the transfer fails, retain the error record even if an HTTP status code was already returned.

Response headers can also help identify caching, but cache-status fields should not be interpreted identically across providers. For example, Cloudflare's CF-Cache-Status: HIT indicates that a resource was found in its cache, while MISS indicates that a cacheable resource was not found in the cache and was fetched from the origin. These are Cloudflare's own cache-status definitions. For other services, use the corresponding provider's documentation.

A single curl request represents one point in time, one network, and one resource. Apply the same methodology across the regions and time periods selected above, then combine the results with browser measurements and application logs to make them useful for procurement decisions.

How should DDoS protection be validated without ending up in a situation where the attack is blocked but legitimate users cannot get through?

Evaluate mitigation bandwidth separately from application capacity

Distributed denial-of-service (DDoS) attacks consume resources with large volumes of malicious traffic or requests. What is commonly called a CC attack in the Chinese market generally focuses on resource consumption caused by application-layer requests. These different forms of pressure should not be reduced to a single number representing “how many Gbps of attacks” a service can handle.

Gbps describes bandwidth volume, pps describes packets per second, and QPS describes queries or requests per second. The same number of requests can place very different levels of pressure on the origin depending on whether they retrieve a cached image or trigger a complex database query.

When requesting a quote, ask specific questions: Does the advertised capacity represent the provider's total platform capacity or the amount available to an individual customer? What limits apply to legitimate traffic bandwidth, request volume, and concurrent connections? If agreed limits are exceeded, will the provider rate-limit traffic, charge additional fees, or potentially blackhole the traffic—that is, temporarily discard traffic destined for the target? What are the conditions for service recovery?

More useful than a generic claim of “support for large attacks” is a clear description of the protection scope, actions taken when limits are exceeded, alerting methods, and incident-handling procedures.

Include false positives in your testing

A web application firewall (WAF) inspects and handles suspicious Web requests, while bot management focuses on identifying and managing automated traffic. Whether a policy is appropriate depends on the application. More challenges or more blocked requests do not automatically mean better protection.

Browser pages, app APIs, payment callbacks, search crawlers, and long-lived WebSocket connections should each be tested for compatibility. Payment callbacks in particular should retain business authentication such as signature verification; do not remove all validation simply because you are concerned about false positives.

You can also use the approach to coordinating WAF, bot management, and DDoS protection to record which rules match legitimate requests, then assess their applicability and exception requirements.

If attack simulation or load testing is required, first obtain authorization from the CDN, origin, and network service providers involved in the test. Agree in advance on the test intensity, duration, stop conditions, and how legitimate traffic will be monitored. Without such testing, you can evaluate the proposed solution and existing logs, but you should not claim that its ability to withstand attacks has been validated.

Do not leave the origin exposed outside the protection layer

After a domain is connected to a CDN, historical DNS records, unproxied subdomains, or other services hosted on the same system may still expose the origin IP address. If an attacker can bypass the CDN and connect directly to the origin, protection at the edge does not automatically cover that path.

Review the origin's open ports, restrict Web access based on the provider's documented origin address ranges and authentication methods, and preserve verified channels for necessary traffic such as management, monitoring, and certificate validation. A shared origin-IP allowlist does not mean that only your application is permitted. Where possible, combine it with origin authentication.

Cloudflare's origin protection documentation also discusses historical IP exposure, access restrictions, and origin authentication separately. The specific capabilities described there belong to Cloudflare; implementations from other providers should be verified individually.

A host firewall can reject unwanted requests, but if an attack has already saturated the upstream bandwidth to the origin, rules on the host cannot restore that bandwidth. In that situation, also evaluate upstream traffic scrubbing or server-side protection. For additional entry-point checks, see how to identify and hide exposed origin IP addresses.

How can you turn your DDoS-protected CDN requirements into an acceptance-ready solution?

Define the conditions that must be met before comparing prices. This reduces the risk of discovering after a trial that a required protocol is unsupported or that dynamic APIs are incompatible.

CDN07's DDoS-protected CDN service combines access optimization for Mainland China with DDoS protection and provides options for customized edge, bandwidth, and security-policy configurations. For websites hosted outside Mainland China that need to balance access performance in Mainland China with attack protection, start with the CDN07 DDoS-protected CDN solution to review the fit for your environment, including user distribution, origin location, and dynamic APIs.

This combination makes it easier to evaluate network connectivity and security policies together. However, the actual performance improvement must still be confirmed through application-level testing. Edge coverage, supported protocols, plan limits, and service commitments should all be documented in the proposed solution.

Cost comparisons should use the same measurement basis: normal traffic or bandwidth, request volume, number of domains, protection capacity, add-on features, and egress charges from the overseas origin itself. Do not compare monthly fees alone, and do not assume that an item labeled “unlimited” means that all other resources are unlimited. You can first review the cost structure of DDoS-protected CDN services, then request quotes using the same usage profile.

Before the production cutover, verify certificates, the origin Host header, security rules, forwarding of the real client IP address, and critical business functions. Then perform a limited validation according to the onboarding plan. Keep the original configuration and a rollback path, and define in advance which failures or performance regressions should stop further traffic migration. A DNS change should not be treated as an instantaneous switch for every user.

Frequently Asked Questions

Will access from Mainland China always become faster after an overseas server is connected to a DDoS-protected CDN?

Not necessarily. Improvement depends on the path from users to the edge, the path from the edge to the origin, caching, and application processing. Performance may improve if the new edge is better positioned for your primary users and reduces unnecessary origin fetches. If the bottleneck is a database or third-party API, that bottleneck still needs to be addressed.

Is a DDoS-protected CDN in Hong Kong always faster than one in other regions?

There is no basis for making that assumption. Geographic location is only one factor; carrier interconnection, traffic steering, congestion, and the origin path also affect performance. Prioritize comparisons based on the networks your users actually use and your peak periods rather than treating a single test from one city as representative of all users in Mainland China.

Can a DDoS-protected CDN accelerate dynamic APIs such as login and order queries?

It may reduce some network latency, but real-time processing generally cannot be replaced with shared caching. Test the origin path and backend processing separately, and verify that user-specific data is not cached incorrectly. A significant improvement for static images does not mean that dynamic APIs will see the same benefit.

Should I disable protection immediately if an API starts failing after CC protection is enabled?

First review the error responses, security events, and origin logs to determine whether the requests are being blocked incorrectly by a security rule. If the issue is compatibility-related, adjust the policy for the affected API, caller, and authentication method, then verify that legitimate traffic works normally again. Disabling all protection may expose the original risks again.

Do I still need a DDoS-protected server if I already use a DDoS-protected CDN?

It depends on the origin's exposure, upstream protection, and application protocols. If the origin remains directly accessible, its historical IP address has been exposed, or other services are still reachable without going through the CDN, those entry points require separate evaluation. Connecting a website to a CDN does not automatically protect every port on the underlying server.

Can a gaming business simply purchase the same DDoS-protected CDN solution used for websites?

Not based solely on the fact that it is a “gaming website.” A game website, login API, WebSocket connection, and native TCP/UDP gameplay traffic may have very different onboarding requirements. Provide the protocols, ports, client-side modification requirements, and latency targets before deciding between a website CDN, a game-security SDK, or a server-side solution.

Next step: Validate performance and protection with your own application

For overseas servers serving users in Mainland China, keep these four points in mind when evaluating providers:

• Evaluate access performance across both segments: users to the edge and the edge to the origin.
• Validate static resources, dynamic APIs, and complete business workflows separately.
• Evaluate protection based on legitimate-user availability as well as whether the origin can still be bypassed.
• Procurement should clearly define testing standards, billing boundaries, and incident-handling procedures.

Once you have your primary user regions, carrier distribution, origin location, key test URLs, and existing attack records, you can conduct a targeted comparison. If you are evaluating CDN07, you can submit this information through DDoS-protected CDN consultation to discuss network connectivity, origin access, and security policies first, then determine the configuration based on the agreed test results.