Users in mainland China can still encounter connection failures, challenges, stale content or 5xx errors after a site adopts Cloudflare or another CDN. Preserve the failing request first, confirm whether it uses the proxy, then separate the visitor-to-edge connection, cache and security decisions, and edge-to-origin connection. Recheck the same target, time window and networks before changing settings. Do not begin by clearing every cache, disabling protection or labeling everything a block.
This guide is for teams managing their own sites or authorized to investigate them. Cloudflare provides a concrete example; other CDNs have their own settings, error codes and logging capabilities. Domain checks supply network observations, not an automatic verdict assigning the root cause to a CDN, ISP, origin or application.
1. DNS hosting, proxying and caching are separate
Hosting DNS with Cloudflare does not mean every web request passes through its HTTP proxy. According to the official Proxy status documentation, proxied records route the relevant HTTP/HTTPS traffic through Cloudflare, while DNS-only records do not use that proxy path. An orange cloud describes proxy status, not guaranteed access from mainland China.
Check the hostname the user actually requested, rather than whether the overall domain is on Cloudflare. The apex domain, www, API and asset hosts may have different configurations; a redirect can also change the destination. Record the scheme, hostname, port and a sanitized path template, then have the owner confirm that request's proxy configuration and recent changes.
Different observed IP addresses, or an IP geolocation label, do not establish which data center handled a request. For DNS routing and cache background, see Different DNS Answers in China. This guide focuses on request paths and failure boundaries.
2. Separate visitor-to-edge from edge-to-origin
For a proxied HTTPS request, the browser-to-Cloudflare connection and Cloudflare-to-origin connection are separate. HTTPS for the visitor does not necessarily mean HTTPS to the origin; the origin protocol depends on configuration. When origin HTTPS is used, the origin has its own certificate. A working edge certificate seen by the browser does not establish that origin connectivity, certificates or application processing work. See Cloudflare's SSL/TLS concepts.
If the user receives no usable HTTP response, preserve the browser error and failure stage, compare relevant networks and check for corresponding edge records. If that same request receives a Cloudflare-generated error page, it has obtained an edge HTTP response, so the indicated origin or security boundary is a useful next investigation point. This is an inference about that request, not proof that every resource, user or business flow works.
A reset, timeout or successful TLS handshake is not a complete root-cause description. For handshake and certificate distinctions, see DNS Resolves but HTTPS Fails in China. Keep the original failure even when a retry succeeds.
3. Bypassing cache does not bypass Cloudflare's proxy
Caching determines whether stored content can serve a response; proxying determines its path. In Cloudflare's cache response documentation, HIT means cached content served the request; MISS means eligible content was not cached for this request and came from the origin; DYNAMIC means the request was not eligible for cache; and BYPASS means response conditions prevented otherwise eligible content from being cached. The last two do not mean DNS-only or disabled security.
“Cache bypass enabled” is not “the visitor connected directly to the origin.” Inspect the URL's response, matching rules and content version. A cache hit establishes that response's cache source, not that every edge is updated or the origin is currently healthy. HTML and JSON are not cached by default, but configuration such as Cache Rules can change behavior; see Default cache behavior. Do not infer the actual outcome from the file type alone.
For stale content, identify the affected page, script or API response and preserve its URL, version and available cache status. Make targeted cache changes or invalidations only when evidence points to that layer and the owner approves, then verify both origin and public responses. Record browser caches, CDN content caches and DNS caches separately.
4. Challenges and 403 need policy and application evidence
Cloudflare WAF, Bot Management or rate-limiting policies can trigger a Challenge Page. It returns HTML for a browser to process and can interrupt API or Fetch/XHR requests expecting JSON or another non-HTML response. See Challenge Pages and compatibility limits. A browser passing a challenge does not mean an automated client performs the same flow.
A site owner can look for cf-mitigated: challenge in the actual response, the official marker described in Detect a Challenge Page response. This is evidence from that response, not a field WeaveBit promises to return. A 403 can also involve origin permissions or Cloudflare policies; inspect the response and both sets of logs, using the official 403 troubleshooting guidance.
Do not translate a challenge or 403 directly into a GFW blocking verdict. If your own rules incorrectly stop an authorized monitor or client, the security owner should assess a narrowly scoped exception rather than disabling the site-wide WAF or allowing all traffic. For login, API or script failures, investigate the actual affected request with the business dependency guide.
5. Investigate 522–526 at their origin boundary
The following table applies to these errors returned by Cloudflare's website reverse proxy, not automatically to another CDN or Cloudflare product. A code suggests where to investigate first; it does not independently establish a single root cause or identical failures for every user.
| Error | Boundary identified by the official description | Check first |
|---|---|---|
| 522 | Cloudflare times out contacting the origin | Origin load, address, firewall and connection logs |
| 523 | Cloudflare cannot reach the origin | Origin address and routing between Cloudflare and the origin |
| 524 | The origin connection succeeds, but a read or write does not finish in time | Application duration, origin resources and asynchronous design |
| 525 | The Cloudflare-to-origin TLS handshake fails | Origin TLS, port, SNI and cipher suites |
| 526 | Cloudflare cannot validate the origin certificate in Full (strict) mode | Certificate names, validity, trust and chain |
For 524, identify the work exceeding the current origin waiting window and inspect application and server duration. Developers can assess asynchronous submission and status polling for long-running operations. Consult the current product and plan documentation for limits and configurable options; repeated retries are not a repair.
For 525 or 526, fix the relevant TLS or certificate configuration. Ignoring certificate errors or weakening validation is not a standard solution. A connection or HTTP response succeeding does not justify abandoning security checks.
6. An ordinary orange cloud is not China Network
Using Cloudflare alone does not establish that mainland visitors receive service from mainland data centers. The official China Network overview and onboarding guide describe a separate additional subscription for Enterprise customers, including ICP documentation and content review conditions. Some product capabilities also differ. This is a product boundary, not legal advice; confirm eligibility and deployment requirements with the provider.
Cloudflare also explains that Anycast requests do not necessarily reach the geographically closest data center in its geographic routing guidance. An IP's country label cannot establish every mainland user's actual path or experience, and switching CDNs cannot be promised to restore every network.
Evaluate providers or migrations against a baseline of your customers' relevant regions, ISPs and critical business paths, using comparable time windows. Report “improved on these networks” separately from “verified for all intended users”; one healthy node is not a nationwide guarantee.
7. Add WeaveBit domain observations, not an automatic CDN diagnosis
For actual hosts your company manages or is authorized to check, start with the free DNS poisoning check when you need that result. For multiple domains, broader HTTP/HTTPS-related observations or multiple-node comparisons, you can choose GFW Full directly without first checking each domain separately. Preserve the platform's public results without inferring its internal classification process.
GFW Full returns DNS Pollution, HTTP Host and TLS SNI components for selected nodes, plus a summary; it does not execute all seven available check methods. HTTP_RESPONSE_OK does not mean a 2xx response or business success. A successful TLS handshake is not a complete browser certificate-trust audit. It does not execute page JavaScript, solve challenges, sign in or request your chosen business path. See check methods and the results documentation for coverage and normal, abnormal and indeterminate outcomes.
A node observation is not the affected user's request. Keep the actual hostname, relevant ports and time comparable, and select GFW nodes relevant to the user's networks while retaining browser, CDN and origin evidence. A normal GFW Full result does not establish every network, resource and business flow works. An indeterminate outcome is neither normal nor confirmed blocking. See Align Checks with User Reports to compare different observations.
8. Keep minimal evidence and verify changes safely
For each observation, record the time with timezone, actual hostname and port, sanitized path template, user's region and ISP, browser error or HTTP status, proxy configuration, and, when available, CF-Ray, CF-Cache-Status and the challenge marker. Align these with security and origin logs from the same period, separating confirmed boundaries from unknowns.
The Ray ID documentation states that IDs are not guaranteed unique for every request, and Security Events may use sampled data. Search with time and other necessary context; a missing log match does not prove the request never arrived. The official information-gathering guide offers collection methods, but do not share raw HAR files, full request headers or logs.
Switching to DNS-only is not a risk-free test: it changes the path, can expose the origin and removes proxy-side protection. A Cloudflare Origin CA certificate is not directly trusted by ordinary browsers, so direct access can introduce certificate errors; see Origin CA guidance. If a comparison is necessary, the owner should confirm authorization, origin capacity, protection, certificates and rollback arrangements. Preserve the original hostname and correct TLS name rather than ignoring certificate errors to obtain a success.
Change only necessary factors, retain the before-and-after configuration and new observations, then have affected users verify the original business operation. Remove cookies, Authorization, keys, query tokens and personal information from shared records; provide only manually reviewed minimal fields. Close the incident by stating which networks and business steps recovered and which remain unconfirmed, not just “CDN normal” or “GFW normal.”