How to Test Cloudflare Speed in China: Results by Region and ISP

Is Cloudflare actually fast in mainland China?

This question comes up often, but there is no fixed answer. Beijing Unicom loading quickly does not mean Guangzhou Mobile will be fast; Shanghai Telecom hitting cache does not mean Chengdu Telecom will reach the same node this time; a website may test normally in the morning but show clear fluctuations during evening peak.

So, when testing Cloudflare speed in mainland China, you cannot just open it once on your own computer, nor rely on a single nationwide average.

The right approach is to break down city, ISP, responding node, cache status, and request phase, and observe P50, P95, success rate, and download speed separately.

A test with meaningful diagnostic value should answer at least the following questions:

If you only say 'my latency here is 180 ms,' you still cannot judge how Cloudflare performs for real users.

Before testing, distinguish: the standard global network and China Network are not the same

When discussing Cloudflare speed in mainland China, the easiest thing to confuse is two different network conditions.

Standard Cloudflare global network

Most individual site owners and users on standard plans are on Cloudflare's global network.

Requests from mainland China users are routed to corresponding data centers based on network routing, ISP interconnection, and Cloudflare traffic scheduling, but this does not mean the domain is using Cloudflare points of presence inside mainland China.

If the entry point is outside mainland China, access paths are affected by cross-border networks, ISP routing, evening peak congestion, and entry location.

Even if two websites both show 'using Cloudflare,' their speed in mainland China can be completely different, because origin location, cache hit ratio, page size, and business configuration are not the same.

Cloudflare China Network

Cloudflare also offers China Network. According to Cloudflare's currentofficial China Network documentation, this service runs some Cloudflare performance and security capabilities in mainland China data centers through its partner JD Cloud, is available only to Enterprise plan customers, and requires a separate subscription.

Onboarding to China Network also requires a valid ICP filing or license for the top-level domain to be onboarded, and it is not a capability automatically available after opening a standard Cloudflare account. For specific requirements, see Cloudflare'sICP documentation.

Therefore, a speed test report should first state which of the following the test target belongs to:

If you do not distinguish these two cases first, using results from a standard free plan website to represent Cloudflare China Network, or comparing them the other way around, will lead to distorted conclusions.

Step 1: Confirm whether domain traffic actually goes through Cloudflare

First check the response headers:

curl -sS -D - -o /dev/null https://www.example.com/ \
  | grep -Ei '^(server|cf-ray|cf-cache-status|age):'

You may see:

server: cloudflare
cf-ray: 9f1234567890abcd-NRT
cf-cache-status: DYNAMIC

Cloudflare'sslow website troubleshooting documentationstates that responses served through Cloudflare includecf-ray.

If this field is absent, continue checking:

• Whether the DNS record has Cloudflare proxy enabled;

• Whether you are testing the correct hostname;

• Whether the page redirects to another domain that does not go through Cloudflare;

• Whether another CDN or reverse proxy is layered in front;

• Whether the current request directly accesses the origin IP.

Do not only look atserver: cloudflare. HTTP response headers can be modified or retained; it is better to combinecf-ray, CNAME, response IP, ASN, and other evidence to judge.

You can first useCdnChart CDN Check, to view domain resolution, response IP, and Cloudflare-related characteristics.

Step 2: See which Cloudflare data center mainland users enter

For domains already proxied by Cloudflare, you can visit:

curl -sS https://www.example.com/cdn-cgi/trace

The response may contain:

fl=...
h=www.example.com
ip=198.51.100.20
ts=...
visit_scheme=https
colo=NRT
http=http/2
loc=CN
tls=TLSv1.3

wherecolois the three-letter code of the Cloudflare data center connected to this request.

Cloudflare's/cdn-cgi/endpoint documentationalso lists/cdn-cgi/traceas a troubleshooting tool for identifying the data center a request passes through.

There are three details to note here.

colo only represents this one request

The same ISP may enter different data centers in different cities; the same city may change at different times due to routing and capacity adjustments.

You cannot checkcoloonce and conclude that users nationwide access from there.

Cloudflare's official troubleshooting documentation also notes that a request not entering the geographically closest data center is not necessarily an error; it may relate to ISP routing, traffic engineering, and reliability-first policies.

The cf-ray suffix cannot simply be treated as the user entry point under all architectures

cf-rayThe three-letter suffix of

can usually provide a clue about the data center processing the request. However, Cloudflare notes in its HTTP response header documentation that when Argo Smart Routing or Argo Tiered Caching is used, the data center code in the Ray ID may reflect the data center connecting to the origin, not the data center the user initially entered.

Therefore, in complex architectures, check/cdn-cgi/trace, Cloudflare logs, and account analytics together.

Do not judge speed solely from a data center code

Physical distance matters, but it is not everything.

Actual speed also depends on ISP routing, packet loss, congestion, whether cache is hit, and the origin fetch path from that node to the origin.

An entry point that looks closer is not necessarily more stable than another at all times.

speed.cloudflare.comCan it be used to test your own website?

It can be used, but it only answers part of the question.

speed.cloudflare.commainly tests download, upload, latency, jitter, and packet loss from the current device to Cloudflare's network. Cloudflare'sAIM metrics documentationalso lists these network quality metrics.

It is suitable for judging:

• Whether the current broadband or mobile network itself is unstable;

• What the basic quality is from the current device to Cloudflare's network;

• Whether download, upload, latency, jitter, and packet loss show obvious anomalies.

But it cannot replace testing your actual domain. Because the actual website also involves:

• your own DNS and CNAME configuration;

• the entry point the domain is actually scheduled to;

• Cloudflare cache rules;

• Workers or WAF processing;

• the origin fetch path from Cloudflare to the origin;

• origin response time;

• page resources and third-party scripts.

Therefore, a practical method is to treat it as a set of 'local network baselines':

If speed.cloudflare.comand your own website slow down at the same time, suspect the local network or ISP path first; if the former is normal but your domain is clearly slow, continue checking domain routing, caching, origin fetches, and the page itself.

Step 3: Choose three types of test targets

Cloudflare speed testing in mainland China cannot only test the homepage. It is recommended to prepare three fixed URLs, each addressing different questions.

1. Page HTML

https://www.example.com/

Used to observe the actual entry point, redirects, dynamic processing, and time to first byte.

However, by default Cloudflare does not cache all HTML as ordinary static files; actual behavior is also affected by Cache Rules and origin response headers.

2. Small static resource

https://www.example.com/assets/app.css

You can choose a logo, CSS, or JavaScript file.

Small files are suitable for observing DNS, handshake, TTFB, and cache hits, because the download itself takes less time.

3. Large file of fixed size

https://static.example.com/test/10mb.bin

Large files are suitable for comparing sustained download speed. Test files should be public, have fixed content, allow caching, and contain no private information.

Different test nodes must use exactly the same URL and file size. Do not test a 5 MB file in Beijing and an image in Guangzhou, then compare the total times together.

Step 4: Build a test matrix by region and ISP

Mainland speed testing should at least split region and ISP into two dimensions.

A basic test matrix can be designed like this:

This does not mean testing every city every time; choose representative nodes based on user distribution.

For example, if 80% of a website's users are in East China and South China, prioritize adding samples from Shanghai, Hangzhou, Guangzhou, and Shenzhen, rather than evenly distributing test runs for 'nationwide coverage.'

If the website supports both IPv4 and IPv6, record them separately. The two protocols may enter different routes and entry points, and mixing results can hide problems.

You can useCdnChart Website Speed Test, to observe responses for the same Cloudflare domain from different regions and networks.

After testing, group results by region and ISP, rather than only looking at the fastest, slowest, or overall average nationwide.

Step 5: Test each node repeatedly, not just once

Cloudflare routing, cache status, and network conditions all change. One result only represents that moment.

Recommended:

• Quick check: test each node 5 times consecutively;

• Configuration validation: test each node 10 times, recording first and repeat requests separately;

• Fluctuation investigation: test every 15–30 minutes for at least 24 hours;

• Evening peak issues: take multiple sampling rounds before, during, and after peak;

• Long-term observation: keep daily or weekly trends for P50, P95, and success rate.

Test frequency should be controlled according to file size and business cost. Do not launch high-frequency, large-file, or concurrent stress tests against websites that are not yours.

Step 6: Use curl to record Cloudflare request timing

The following command outputs the main timings for one HTTPS request:

curl -sS -o /dev/null \
  -w 'status=%{http_code}\nip=%{remote_ip}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nttfb=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\nspeed=%{speed_download}\n' \
  https://www.example.com/assets/app.css

Example output:

status=200
ip=203.0.113.20
dns=0.021482
connect=0.083154
tls=0.162310
ttfb=0.238955
total=0.301226
size=92560
speed=307279

These values are only for demonstration and do not represent any real Cloudflare node.

size_downloadis in bytes, andspeed_downloadby default represents the average number of bytes downloaded per second. To convert to MiB/s, divide the result by1024 × 1024.

For small files,speed_downloadis easily affected by handshake and sampling time, so use a fixed larger file when comparing throughput.

Each time field is cumulative from the start of the request and can be roughly broken down as:

DNS解析时间  = time_namelookup
TCP阶段      = time_connect - time_namelookup
TLS阶段      = time_appconnect - time_connect
首字节前等待 = time_starttransfer - time_appconnect
内容下载阶段 = time_total - time_starttransfer

If HTTP instead of HTTPS is used, redirects occur, a proxy is used, or connections are reused, some fields are interpreted differently. When troubleshooting overall page speed, also use the browser Network waterfall chart.

Test continuously and record response headers

for i in $(seq 1 5); do
  printf 'request=%s ' "$i"
  curl -sS -o /dev/null \
    -w 'status=%{http_code} ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' \
    https://www.example.com/assets/app.css
  sleep 2
done

Then check Cloudflare fields separately:

curl -sS -D - -o /dev/null https://www.example.com/assets/app.css \
  | grep -Ei '^(cf-ray|cf-cache-status|age|cache-control|server):'

Do not add a random timestamp to every request in routine stability tests. Different query parameters may create different cache keys, causing results to consistently show as cold cache orMISS.

Which metrics should be prioritized in mainland speed tests?

Among these, success rate should rank before latency.

A node with very low average latency but occasional timeouts may provide a worse real-user experience than a slightly slower but stable node.

View Cloudflare cache HIT and MISS separately

The first request for a static resource may be:

cf-cache-status: MISS

The second becomes:

cf-cache-status: HIT
age: 15

IfHITis clearly fast andMISSis clearly slow, it means the path from users to the Cloudflare edge may not have a serious problem; the slow part is more likely in the origin fetch path after a cache miss or in origin processing.

If it is alreadyHIT, and TTFB still fluctuates significantly on a specific ISP or region, you should check routing from users to the Cloudflare entry point, connection quality, node changes, and edge processing logic.

If it consistently showsDYNAMIC,BYPASSorMISS, confirm whether the test target is inherently uncacheable and whether cookies, query parameters,Cache-Controland Cache Rules affect the results.

Cloudflare's cache troubleshooting documentation listsHIT,MISS,DYNAMIC,BYPASS,EXPIREDandREVALIDATEDother statuses, and recommends analyzing them together with cache rules, response headers, and query parameters.

Do not only look at averages: P50, P95, and success rate matter more

Suppose the following is a set of demo results and does not represent real data from CdnChart or Cloudflare:

P50 is close to what most users usually experience; P95 is used to observe the slower subset of requests.

If P50 is normal but P95 is very high, the website is not slow overall; instead, there is a long tail related to nodes, routing, time periods, or cache status.

Sample counts in different regions must be as close as possible. Testing 100 times in Shanghai and only once in Chengdu, then comparing P95, is meaningless.

CdnChart testing methodologyUses percentiles such as P50 and P95 to observe typical performance and tail experience. When looking at Cloudflare speed in mainland China, also retain region and ISP dimensions; do not let a single nationwide average mask local problems.

What do different speed test results indicate?

This table is used to narrow down scope, not to assign final blame.

For example, 'Mobile slow, Telecom fast' can indicate ISP differences, but without routing, packet loss, and node logs, you cannot directly conclude that one network is faulty.

Should ping and MTR be used?

They can be used, but do not treat them as complete Cloudflare website speed tests.

Ping mainly observes ICMP round-trip latency and packet loss; it cannot reflect DNS resolution, TLS handshake, HTTP processing, caching, or origin fetches. Some network devices also restrict or ignore ICMP, so 'ping fails' does not mean the website is unavailable.

MTR can continuously observe latency and packet loss at each hop along the path, making it suitable for further checking the network path from an ISP to a Cloudflare entry point:

mtr -rw www.example.com

Windows can use WinMTR.

When analyzing, focus on whether the problem continues to later nodes and the final target; if only an intermediate hop shows packet loss and later nodes recover, it may simply be that the device limits probe responses, and it cannot be directly treated as real service packet loss.

Cloudflare also recommends using MTR to check path latency and packet loss when TCP connection or TLS handshake times are high.

When submitting a support ticket, provide the time, region, ISP, target URL, CF-RAY, and slow request results together, rather than just a ping screenshot.

A ready-to-execute Cloudflare mainland China speed testing workflow

Round 1: Confirm onboarding and entry point

1. Check whether the domain returnscf-ray;

2. Check whether DNS and response IP belong to the expected network;
   

3. Use/cdn-cgi/traceto record the currentcolo;

4. Test IPv4 and IPv6 separately;

5. Confirm whether it is the standard global network or China Network.

Round 2: Fix three URLs

1. Homepage or business HTML;

2. A public small static file;

3. A large file of fixed size.

All regions use the same URLs, without changing query parameters or file versions.

Round 3: Sample by region and ISP

1. Select nodes separately in key regions such as North China, East China, South China, and Southwest China;

2. Each key city should cover Telecom, Unicom, and Mobile;

3. Test each node at least 5 times consecutively;

4. Record success rate, response IP,coloand timings for each stage;

5. Distinguish first requests from cache-hit requests.

Round 4: Repeat across time

Repeat tests in the morning, afternoon, evening peak, and time windows when users complain.

If the problem appears occasionally, continue for 24–72 hours rather than stopping sampling after speed recovers.

Round 5: Summarize by P50 and P95

Calculate separately:

• success rate;

• P50 and P95 TCP connection time;

• P50 and P95 TTFB;

• average and P50 download speed for large files;

• for eachcolooccurrences;

• proportion of HIT, MISS, and other cache statuses.

Finally, cross-reference slow requests by region, ISP, entry data center, cache status, and time period; the problem will usually narrow from 'Cloudflare seems a bit slow in mainland China' to a more specific scope.

Most common mistakes in Cloudflare mainland China speed testing

Testing only your own broadband

Local results at best represent the current city, current ISP, and current time. The Cloudflare mainland China experience must be observed across regions and ISPs.

Looking only at the fastest node

The fastest result only shows that one good result is theoretically possible; it does not show that ordinary users consistently get the same experience. P95 and failure rate are often closer to real complaints.

Using speed.cloudflare.cominstead of the target website

It can evaluate the basic quality from the local network to Cloudflare, but it will not test your domain's own caching, origin fetches, Workers, and page resources.

Assuming mainland nodes are used just because Cloudflare is shown

The standard global network and China Network are different products with different onboarding requirements. Confirm with account configuration, ICP filing status, nodes, and official logs.

Averaging MISS and HIT together

The paths for the two types of requests may differ. When mixed, you can see neither edge access quality clearly nor origin fetch performance clearly.

Adding random parameters to the URL every time

This may continuously create new cache keys and prevent normal cache reuse. If specifically testing cold cache, create a separate group and label it clearly.

Looking only at latency, not success rate

A 'low-latency node' that occasionally times out may perform worse in practice than a slightly slower but stable node.

Deciding whether to switch CDNs based on one evening peak result

One anomaly may come from the local network, a single node, or temporary routing.

Before switching services, confirm the scope and duration of the problem through multiple rounds of data.

FAQ

Does Cloudflare have nodes in mainland China?

Cloudflare offers a separate China Network service, running some products and network capabilities in mainland China through a partner.

But it is a separate subscription for Enterprise customers and requires the onboarding domain to have a valid ICP filing or license. Standard Cloudflare global network users cannot automatically be considered to be using China Network.

How fast is Cloudflare Free in mainland China?

There is no fixed conclusion suitable for every website.

Mainland China speed is affected by city, ISP, cross-border paths, entry data center, origin location, cache hit, and page content. Test your real domain across multiple regions and ISPs.

How can I tell which Cloudflare node a visit enters?

You can visit the/cdn-cgi/traceunder your domain to view thecolofield, and combine it withcf-ray, response IP, and Cloudflare logs.

When using Argo or tiered caching, do not rely only on the CF-RAY suffix to determine the user entry point.

Why is Telecom fast and Mobile slow, or vice versa?

Different ISPs have different interconnection, egress, and routing to Cloudflare, and may enter different data centers.

Compare response IP,colo, TCP, TLS, and TTFB in the same city and for the same URL.

Should Cloudflare speed tests measure latency or download speed?

For web pages and small files, focus mainly on connection, TTFB, and stability; for software, images, video, and large-file workloads, also look at sustained download speed.

The two should be tested separately.

Cloudflare ping is low, why is the website still slow?

Ping only covers ICMP round trips. A website also goes through DNS, TLS, HTTP processing, caching, possible origin fetches, and page rendering.

Low ping does not prove the page will be fast.

Cloudflare shows HIT, why is it still slow in mainland China?

HIT only means content is returned from Cloudflare cache; it does not mean the path from the user to the entry node is necessarily fast.

You still need to check TCP, TLS, entry data center, ISP routing, packet loss, and content download speed.

How many times should each region be tested?

At least 5 times for a quick check; for formal comparison, more than 10 times is recommended, covering different time periods.

For intermittent issues, also keep recording for more than 24 hours, then compare P50, P95, and failure rate.

Summary: Cloudflare speed in mainland China must be examined separately

To judge whether Cloudflare is fast in mainland China, you cannot rely on a single speed test screenshot, and even less can you use your home broadband to represent users nationwide.

A reliable test needs to:

1. First confirm that requests truly go through Cloudflare;

2. distinguish the standard global network from Cloudflare China Network;

3. record response IP,colo,cf-rayand cache status;

4. fix three test targets: HTML, a small static resource, and a large file;

5. test separately by city, Telecom, Unicom, Mobile, and IPv4/IPv6;

6. run multiple rounds per node and cover different time periods;

7. compare success rate, DNS, TCP, TLS, TTFB, download speed, P50, and P95;

8. use Cloudflare and origin logs to confirm at which layer slow requests occur.

You can first useCdnChart Website Speed Testto test the same Cloudflare domain across multiple regions, then useCdnChart CDN Checkto verify resolution, response IP, and vendor characteristics.

A truly useful conclusion should not be 'Cloudflare is fast in mainland China' or 'Cloudflare is slow in mainland China,' but rather:

which region, which ISP, at what time, through which entry point, and under which cache status the problem occurred.