Cloudflare CDN Review: The Appeal of the Free Plan and the Reality of Mainland China Access

Add a domain to Cloudflare, enable the proxy, images start showing HIT, and origin traffic drops. Overseas colleagues find it fast, while mainland China users report occasional failures at night. This scenario often pushes the discussion to two extremes: some say the free plan is enough, others say Cloudflare is unusable in mainland China. Both judgments skip the most important conditions: which users, accessing what content, and which part of the request is slow?

The appeal of Cloudflare’s free plan is real, but free basic features, correct content delivery, and acceptable mainland China access must each be proven separately.For sites with lots of public static content, a high share of overseas users, and a team that can maintain configurations, it has strong trial value. For mainland transaction, booking, or login services, overseas results or one cache-hit image cannot justify launch. Aggregate results from Cloudflare’s global network also cannot be treated as the delivery conclusion for the free plan in mainland China; selection must ultimately come down to your own domain and critical business.

What the free plan really saves is the barrier to adopting basic capabilities

The value Cloudflare provides is not just caching.Cloudflare Free planIt greatly lowers the barrier to putting a website behind basic security and performance services. For small teams, there is no need to first build an edge proxy, manage edge certificates, configure caching, and then integrate a security entry point separately; they can focus on the website itself. This operational simplification can sometimes matter more than shaving a few dozen milliseconds off a single speed test.

However, DNS hosting and website proxying must be clearly distinguished. According toCloudflare proxy status documentation, an orange cloud means supported HTTP traffic goes through Cloudflare, while a gray-cloud DNS-only record is just resolution and does not automatically get caching and protection on the same proxy path. Using Cloudflare NS for a domain does not mean all subdomains are using Cloudflare CDN; the homepage, images, API, and mail hosts should be checked one by one.

It is also not static file storage in the traditional sense. After proxying is enabled, the origin still has to serve content; cache misses, non-cacheable services, and responses that need updating can all continue to consume origin resources. A free CDN can reduce delivery burden, but it cannot replace databases, application servers, and a reliable deployment process. Writing off a successful domain onboarding as “the whole site is now globally accelerated” misses a large share of real requests.

Billing must also be broken down by product.Cloudflare request path and billing documentationdistinguishes the billing dimensions of basic bandwidth from products such as Workers, storage, cache persistence, and routing. Regular CDN bandwidth is included in the plan, but that does not mean all add-on services invoked by the same request are free, nor that the origin cloud provider will not charge for public egress. During evaluation, record what is actually enabled rather than just seeing “Free” on the account homepage.

“Free traffic” does not mean unlimited delivery of any content

Cloudflare’s CDN is positioned for web and website delivery. ItsCDN media and large file terms of useset out usage boundaries for video, large files, and content with a high share of images and audio on Free, Pro, and Business, involving the corresponding paid services; if requirements are not met, service may be restricted. Ordinary webpage images should not be conflated with using the CDN as a large image host, video site, or download platform.

There are at least three different questions here: whether the content complies with the terms of use, whether a single request exceeds technical limits, and whether transfer capacity meets business needs. Being able to download a file does not prove the use complies with the terms; a small file hitting cache does not prove large files will be cached. Upload request size, cacheable file size, origin timeout, and sustained download speed constrain different parts, so seeing one “limit” should not lead to conclusions about both uploads and downloads.

Therefore, for video, software mirrors, user files, and businesses with a high share of media external links, first confirm product fit using content structure and expected usage, then run performance trials. Simply upgrading a standard website plan cannot be treated as a way to automatically remove all media restrictions. If a site is just using normal article images, there is also no need to read the terms as forbidding even one image; the key is actual use and the applicable service scope.

The reality of mainland China access: first confirm which network is being used

The regular global network and Cloudflare China Network are two different access conditions. OfficialCloudflare China Network access requirementsdocumentation states that the China Network runs some performance and security products in mainland China through partner JD Cloud and is sold as a separate subscription for Enterprise customers; each top-level domain to be onboarded also requires a valid ICP filing or license. It is not a set of nodes free accounts automatically get after enabling the proxy, nor a capability that turns on when upgrading to Pro or Business.

This affects the request entry point. If mainland users enter an overseas edge, the user-to-edge leg still traverses the relevant cross-border path. Even if the response is a HIT and caching removes the origin wait for that content fetch, users still have to complete the connection and transfer to the edge.Caching can eliminate the second half of the work, but it cannot magically shorten an already slow entry path.This is exactly why “great hit ratio but still inconsistent experience in mainland China” can both be true.

Entry points also cannot be understood by geographic distance alone. Cloudflare’srequests not entering the geographically nearest data centerdocumentation covers network routing, interconnection, and traffic engineering. Different carriers, address families, and times may get different paths; the city closest to a user on a map is not guaranteed to be where this particular connection actually enters, let alone the most stable path. Observe the actual domain rather than inferring experience from node count.

The location of a mainland origin can also change the calculus for dynamic requests. When mainland users enter an overseas edge and non-cacheable content must be fetched from a mainland origin, the path may include two cross-border legs: user to overseas edge and overseas edge back to mainland origin. Caching static content may still help, but dynamic pages may not benefit. To judge whether moving the origin improves experience, consider the user entry point, edge-to-origin fetch, application processing, and data dependencies together—not just “the server is close to mainland China.”

We are more cautious with commercial websites focused on mainland China: first prove they open reliably in key regions, then discuss how much the free plan saves. For overseas-focused sites, test conclusions from different regions can be accepted separately. Mainland China, Hong Kong/Macau/Taiwan, and overseas should not be lumped into one “Asia” group, and China Telecom, China Unicom, and China Mobile should not be merged into one national average. ExistingCloudflare speed tests by region and carrier in mainland Chinacan cover specific sampling methods; this article further maps those results to procurement and architecture decisions.

How much caching helps depends on what the site can actually share

Cloudflare’sdefault cache behaviorprimarily determines resource eligibility by file extension, and HTML and JSON are not cached by default. So on a WordPress site, images, CSS, and JS may already hit cache while the homepage HTML still goes to the origin; on a SaaS site, frontend assets may be fast while account queries still wait on the database. If origin load does not drop noticeably after adopting a free CDN, it may not mean the network is ineffective—the main requests may simply not be entering the shared cache.

Before testing, split requests into three groups: versioned public assets, public HTML or APIs that can be shared for a short time, and user-specific services. The first group is suitable for full caching; the second requires clear freshness and update rules; the third must first guarantee permissions and isolation. A dynamically generated page is not necessarily uncacheable; a file that looks static does not mean you can ignore whether it returns user identity information.

The cache key determines which requests are treated as the same object. If product filter parameters, language, currency, or login state affect the response, they cannot simply be ignored. Ignoring all query parameters can mix different product results; retaining irrelevant marketing tracking parameters can create many cache duplicates. The right approach is to list the variables that affect content, then check the rules available on your current plan and the actual responses—not infer that you have the same capabilities from someone else’s configuration screenshot.

In particular, do not use a site-wide forced caching rule to chase a pretty HIT ratio. Account centers, shopping carts, admin areas, and downloads with authorization information all need separate validation. According toshared cache and private response configurationdistinguish what can be stored, then check content isolation using two authorized accounts, an anonymous state, and requests after logout. If cross-user content leakage is found, stop the performance trial, fix the rules first, and handle existing cached objects.

Hit ratio must also be split between requests and bytes. Many small icon hits can raise request hit ratio without necessarily saving the egress used by large images. The release process matters too: long caching suits assets whose URL changes when content changes, not entry files that are constantly overwritten. Purging at the edge also does not mean old copies in users’ browsers disappear immediately; if updates rely on frequent full-site cache purges, include the origin peak during refill in the cost.

How can you tell whether the slowness is at the entry point, the origin fetch, or the page itself?

CF-Cache-Status cache statuscan help break down requests: HIT means the cache served the object, DYNAMIC usually means the request was not eligible for caching, BYPASS corresponds to not caching at the response stage, and REVALIDATED involves validation with the origin. DYNAMIC does not mean a configuration error; keeping account APIs dynamic may be exactly the right behavior. Age only helps explain object age and cannot be used to calculate how much longer it will remain in cache.

Cloudflare’s official cache documentation distinguishes behavior under different configurations, so do not treat no-cache simply as never storing, and do not judge all forced caching rules safe based only on Set-Cookie. Edge misses and requests actually reaching the enterprise origin also need to be checked under architectures such as tiered caching and Workers. Client state, origin logs, and the current configuration are three evidence surfaces; without the latter two, you can at most point to a likely direction.

This table is for narrowing scope, not assigning blame. Even a slow HIT request may still involve edge code, extra processing, or transfer issues; even if direct origin access is fast, that does not automatically prove Cloudflare origin fetch is slow, because the two tests may not take the same path. Correlate request time, cache status, configuration version, and business processing records to make an informed choice about adjustments.

Before upgrading to a paid plan, ask which part of the request the purchased capability can change

The capabilities added by Pro, Business, and Enterprise must be checked against actual products and contracts; upgrading itself is not a technical mechanism for “getting faster in mainland China.” More granular security controls, more rules, and better support channels may be valuable, but that value is separate from whether mainland users enter a domestic network. If sales recommends an upgrade, ask for a clear change in delivery path, feature scope, and acceptance criteria—not just a promise of a “priority route.”

For exampleArgo Smart Routing origin optimizationis included in the relevant Smart Shield product bundle and focuses on network transport from Cloudflare to the origin. It is worth using to validate network wait on MISSes and non-cacheable requests, but it should not be understood as automatically gaining mainland nodes after moving from a free plan to a paid one, nor does it promise to remove all issues on the user-to-overseas-edge leg. When database processing dominates the time, its room for improvement is also constrained by the application bottleneck.

A paid trial should set up an interpretable control group: keep a free baseline and, under the same regions, URLs, cache conditions, origin, and business version, change only the capability you plan to buy. If you also change the origin, extend TTL, compress images, and then enable routing optimization, you cannot tell which investment made the difference. For assets that already HIT, do not use samples that barely go to origin to prove origin optimization benefits; for security products, check whether legitimate requests are handled correctly and whether the rules are sufficient.

So upgrade thresholds can be very specific: continue evaluating routing features only if origin network wait is a high share and control tests show improvement; study more suitable security controls only if free rules cannot express business exceptions; include related services in the contract only if troubleshooting data or support channels are insufficient. If connections in target regions still fall short, compare delivery architectures rather than iterating among standard plans.

Free security capabilities are worth using, but also check how they treat legitimate users

“Free means insecure” and “once Cloudflare is on, security takes care of itself” are both inaccurate. According toCloudflare managed WAF rule coverage, the Free Managed Ruleset protects against some high-impact, widely exploited vulnerabilities; availability of the full Cloudflare Managed Ruleset and OWASP rulesets depends on the plan. A product name containing WAF does not mean all rules, detection scope, exception controls, and logging capabilities are the same.

When evaluating security, look at both malicious traffic handling and completion of legitimate business. Normal users on shared egress, mobile apps, payment callbacks, third-party webhooks, and monitoring programs each have different access characteristics. A challenge page may suit interactive browsers but can interrupt API clients that cannot complete verification. Troubleshooting requires identifying which security feature, which rule, and which condition triggered; do not attribute every access failure to mainland network routes.

A specific example isBot Fight Mode exception limits: it may challenge API or mobile app traffic, and cannot be skipped through ordinary WAF custom rules or Page Rules Skip. With this kind of issue, adding another “allow rule” may not work. Identify the product’s enforcement mechanism and choose a strategy or product that can meet the exception requirement, rather than disabling site-wide protection long term.

The origin itself must still ensure authentication, patching, access control, and origin security. Production HTTPS can followFull (strict) origin certificate validationconditions by preparing a valid certificate, matching domain, and port; HTTPS on the browser connection should not be treated as validating the other origin leg. Which traffic the origin allows and how to prevent proxy bypass must also be designed separately. There is no need to attack others’ websites here—only use authorized tests to validate your own configuration and legitimate business.

Cloudflare CDN evaluation: pass two gates first, then do three sets of accounting

CDNChart recommends setting two gates first:The first is correct delivery; the second is availability for key users.Account content must not leak across users, releases must not return the wrong version for long, and core operations must not be blocked by challenges; if these fail, hit ratio and free bandwidth cannot compensate. After correctness passes, check whether pages, login, search, or checkout in target regions can complete reliably within the business-agreed wait range. Thresholds should be set by the business before testing, not chosen afterward to look good.

Once the gates are passed, look at three sets of accounts: the experience account records wait times, long tail, and failures by region; the origin account records actual requests, egress, and peaks; the operations account records configuration complexity, troubleshooting time, add-on services, and rollback capability. A free plan may significantly save origin traffic without improving first visits from mainland China; or its caching benefit may be ordinary but its integrated management highly valuable. Separate these benefits to see clearly the reasons to keep, upgrade, or replace.

The trial baseline should be the existing production delivery setup, not just a deliberately exposed origin. First freeze the content version, cache policy, and security rules, and prepare public HTML, versioned static assets, representative images, and key dynamic APIs. Public speed tests cannot complete login identity and business validation, so dynamic flows need test accounts; orders or payments should be validated in a secure test environment, not with real transactions.

For sampling, first allocate key regions according to real user distribution, then break down by China Telecom, China Unicom, China Mobile, as well as home broadband, mobile networks, and address family. A cloud server probe only represents that egress and cannot replace residential broadband. Overseas regions should be sampled separately by user country, and observation should increase during mainland peak hours and user complaint periods. Existing browser cache and first visits must also be separated; otherwise fast results from returning users can hide connection failures for new users.

For each record, keep test time and time zone, URL, network environment, response IP, status code, protocol, cache status, response size, and timing by phase; when available, add entry clues, Ray ID, and origin processing time. Count samples with different cache statuses and entry points separately, and do not directly compare warmed-up HITs with the control’s MISSes. Any improvement after a rule change should be identified as configuration optimization or a change in product capability.

You can usemulti-region website speed testinitially observe the response IP, status code, and access time of public URLs, then supplement diagnosis with controlled clients, browser observations, and server-side records. Cache, entry, or business fields the tool does not output cannot be inferred; it also cannot replace login flows, full page rendering, contract acceptance, or load testing. Clear division of labor keeps results from being overinterpreted.

A formal report should present attempts, business successes, timeouts, certificate errors, security blocks, and business errors, then report P50 and P95 for successful requests. P50 shows typical wait; P95 shows requests near the slower end, but neither replaces the failure rate. A few requests are not enough to explain stable tail behavior; expand the sample to cover relevant periods and state the sample size. Percentiles from different regions cannot be averaged directly; a global summary also must not let overseas successes hide persistent failures on a key mainland network.

If you need to summarize business impact, weight group failure rates by real user share, but keep each group’s results and set independent thresholds for key regions. Real user monitoring also has gaps: visits where the page or collection script did not load may leave no record at all. So do not conclude that all users can open the site just because the experience of collected pages is good; active probes, complaint records, and business logs should together fill in failure evidence.

Three checks to narrow “slow in mainland China” down to a specific issue

The commands below apply only to domains you are authorized to test, and the examples must be replaced. They are written for Linux/macOS; on Windows PowerShell use curl.exe and replace /dev/null with NUL. They are for low-frequency diagnostics, not load testing. The first uses fixed IPv4 and HTTP/1.1 for easier phase comparison; the protocols and connection reuse actual browsers use require a separate test group.

curl -4 --http1.1 --compressed -sS --connect-timeout 8 --max-time 30 -D - -o /dev/null -w "\nstatus=%{http_code} ip=%{remote_ip} dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first_byte=%{time_starttransfer} total=%{time_total} bytes=%{size_download}\n" "https://www.example.com/assets/app.v1.js"

Run repeatedly against a fixed URL and record CF-Cache-Status, Age, CF-RAY, Cache-Control, Content-Encoding, and response size. The first request is not necessarily a MISS, and repeated requests are not guaranteed to HIT every time; group by actual status and do not add random parameters that create non-reusable cache keys. The command discards the body, so it checks only response headers and timing; use a separate safe content check to confirm the expected resource was retrieved. Also keep the curl exit code and do not treat status 000 from a connection failure as an HTTP response.

According tocurl cumulative timing fieldsdefinitions, on a new HTTPS connection with no proxy and no redirects, the TCP phase can be approximated as connect minus dns, TLS as tls minus connect, and download as total minus first_byte. first_byte minus tls still includes request sending, edge processing, and possible origin wait; it is not pure origin processing time. The timeout limit is only an observation condition for this test, not a Cloudflare service commitment; if the URL redirects, check hop by hop and do not directly combine phases.

curl -4 -sS --max-time 15 "https://www.example.com/cdn-cgi/trace"

Cloudflare entry diagnostic endpointcan provide clues such as the colo for the current request. It is for checking the entry point, does not access all dependencies of your page, and does not prove account APIs have become faster. Replace with -6 to check IPv6-capable test networks separately, but preserve the distinction between no IPv6 support, resolution failure, and connection failure; client IP and other information in the output should be redacted before sharing.

Then combine withmeaning of CF-RAY and data center codescheck records. When Argo or tiered caching is enabled, some Ray information may correspond to the data center connecting to the origin, so do not treat the suffix alone as the nationwide user entry point; cross-check with diagnostic endpoints and available logs. Ordinary IP geolocation labels also cannot independently prove physical server location.

curl -4 --http1.1 --compressed -sS --connect-timeout 8 --max-time 30 --resolve www.example.com:443:203.0.113.10 -D - -o /dev/null -w "\nstatus=%{http_code} first_byte=%{time_starttransfer} total=%{time_total}\n" "https://www.example.com/assets/app.v1.js"

The last command is for origin comparison in an authorized environment, keeping the same URL, Host, and TLS SNI, and not accessing the bare IP directly over HTTPS. If the origin allows only CDN fetches, do not temporarily open it to the whole internet; use the test path the administrator already has. If the origin certificate relies on a private CA, configure that CA through a trusted process; do not add -k to skip verification. Direct access from a test machine to the origin is also not the same as Cloudflare’s origin fetch route; both only help locate issues, and conclusions should still combine origin logs and configuration.

Put the free plan into total cost, rather than comparing only monthly fees

The first item is actual origin savings. Assume a set of terms-compliant public static content delivers 600 GB to users per month with an 80% byte hit ratio; in a simplified model, transfer not covered by cache is about 120 GB. This is only an explanatory model, not a measurement by Cloudflare or CDNChart, and it excludes revalidation, cache refill, compression differences, and other dynamic content. In the end, check origin egress and billing; request hit ratio cannot be plugged directly into a traffic formula.

The second item is add-on capabilities and maintenance effort. The same website may use routing optimization, image processing, Workers, or storage at the same time, and each product has its own metering. Do not assume front-end edge code will not execute or incur charges just because public assets HIT; look at the actual invocation path. There is also certificate maintenance, rule regression, false-positive handling, and migration scripts—none of which appear on the free plan bill but can consume a lot of team time.

The third item is incident handling conditions. According toCloudflare technical support scope, Free relies mainly on the community for technical issues, and standard tickets are limited to billing, account, and registrar matters; availability of general technical tickets, chat, and emergency phone support varies by plan. Do not turn “account issues can be submitted as tickets” into “free website incidents have someone available at all times,” and do not confuse support first response with business recovery time.

Procurement should also confirm log fields, sampling method, retention time, export permissions, and alert channels item by item. A summary chart in the console does not mean you can retrieve any individual failed request, and not seeing an event yet does not prove there was never a false block; what evidence to retain should be determined by business troubleshooting and audit requirements.

For low-risk content sites, self-service troubleshooting is acceptable, and the free plan’s cost advantage is often easy to see. For ad landing pages, paid subscriptions, bookings, and transaction businesses, what is affected may be users’ opportunity to complete actions, not just server costs. Do not invent conversion loss estimates for access failures, but use your own business records to check whether the savings from free are offset by long-tail incidents, manual troubleshooting, or churn in key regions.

Which websites are worth adopting it for, and which should keep another delivery approach?

Overseas documentation, open-source project homepages, portfolios, and sites mainly made of public content are usually worth validating first with the free plan. Versioned static assets are easy to manage, personalized requests are few, and teams can more easily keep caching correct. Overseas corporate showcase sites can also start with it, but forms, inquiries, and dependent services must be validated in practice; low traffic does not mean one incident has little business impact.

Overseas SaaS, e-commerce, and membership businesses are not barred from using Cloudflare; they just cannot validate only static files. Free basic onboarding can be a starting point, and whether to keep it depends on dynamic paths, security exceptions, observability, and support requirements. For businesses focused on mainland China that need stable customer acquisition or successful critical operations, CDNChart recommends also comparing suitable domestic delivery options; if adopting China Network, accept it item by item based on separate onboarding, product scope, and contract.

When both domestic and international users matter, evaluate regional delivery or multi-CDN rather than insisting all traffic go through one provider. But the two paths need unified origin identity, certificates, cache freshness, purge mechanisms, and security rules; DNS switching is also affected by caches and client behavior and cannot be treated as instant, complete failover. Health checks used for switching must also reflect the real entry point and critical business, not just prove that an empty endpoint on the origin returns 200.

Do not casually chain another CDN before or after Cloudflare and call it “mainland China optimization.” Chaining can add origin fetch layers, duplicate caching, real IP restoration, and TLS configuration issues; the specific architecture should get support from the relevant products and be fully validated. Widely shared “preferred IPs” may also change by carrier and time and have no contractual guarantee; one faster result does not equal a maintainable long-term solution, and you should not change authoritative DNS or expose the origin without regression testing because of it.

Preserving exit capability is equally important. Before migration, back up DNS records and rule lists, and check DNSSEC, mail records, certificates, and origin access permissions for the new path. In particular, understandthe trust scope of Cloudflare Origin CA: these certificates are for Cloudflare-to-origin use and are not public certificates broadly trusted by browsers; switching directly to DNS-only may cause users to see certificate errors. Any claim that you can “turn off the proxy and roll back at any time” must first verify that the fallback path actually works.

Finally,Cloudflare vendor performance referenceis suitable for initial screening and aligning metric definitions, but cannot alone prove your free domain meets standards across the three mainland carriers; vendor aggregates also do not equal free-plan-specific results. A valuable evaluation conclusion should state clearly: which users and resources passed validation, which problems can be solved by configuration, and which requirements require a product upgrade or a different delivery architecture.

A few more questions to answer when selecting

If a domain has an ICP filing, will free Cloudflare use mainland nodes?

Having a filing does not automatically change the access product. A filing is one of the conditions for China Network onboarding and does not mean the network has been subscribed and enabled. Confirm the account, contract, and actual endpoints; do not infer node usage scope from domain records.

Cloudflare’s 1.1.1.1 is fast. Does that mean my website is fast?

No. Recursive DNS services, authoritative DNS, and website HTTP proxying do different jobs; testing the resolver does not cover your own domain’s caching, origin fetches, or application. Even fast resolution can be followed by waits in connection, business processing, or resource loading.

If the page opens, can a challenged visit be counted as a success?

It should be defined by the intended business. A visit where the user completes verification and gets the content can be recorded separately from a non-challenged visit; if monitoring or an API only receives a challenge page without the expected response, it should count as an incomplete business transaction. An evaluation must not automatically treat “the edge returned some HTML” as normal business success.

If the free plan meets requirements, do you still need to upgrade for “enterprise-grade”?

There is no need to upgrade based on a label alone. If correctness, key-region experience, security controls, and handling conditions all meet business requirements, the free plan can be kept. What is truly worth paying for is a validated capability gap; likewise, if key users consistently cannot complete business, the problem should not be ignored just because the monthly fee is zero.