5 Best Tools to Test If Your Website Works in China (2026)

If you’re a developer, marketer, or founder, you don’t actually care whether your site is “blocked in China” as an abstract concept.

You care about the real question:

Can a user in China load my site, see the important page, and complete the action (signup / purchase / download) without rage-quitting?

This article is the website-owner version of China testing:

• why sites fail in China (it’s not always the Great Firewall)
• 5 tools to test reachability and performance from within China
• a comparison table and a simple workflow
• how to interpret test results
• how to improve accessibility (CDN strategy, dependency audit, ICP filing basics)

If you’re a traveler just trying to open Google, use the simpler guide: How to test if a website is blocked in China.

Quick Answer

To test a website in China properly, you need three layers:

1. Network reachability (DNS + TCP + TLS + HTTP status)
2. Real page load (JS/CSS/image dependencies and third-party calls)
3. Regional variance (multiple China cities and carriers)

Most “it works” false positives happen because you only tested layer 1.

Table of Contents

• Why Websites Fail in China
• The 30-Minute China Test Workflow
• The 5 Best Tools (Detailed Reviews)
• Tool Comparison Table
• How to Interpret Results
• How to Improve Website Accessibility in China
  • Dependency Audit (Google Fonts Is Not Your Friend)
  • CDN Strategy
  • Hosting Location Tradeoffs (Mainland vs Hong Kong)
  • ICP Filing Basics
• Technical Checklist (Engineer Section)
• FAQ
• CTA: Run a China Readiness Audit

Why Websites Fail in China

There are three buckets of failure:

1) Actual blocking (GFW)

This includes:

• DNS interference
• IP blocking
• connection resets
• TLS/SNI filtering

2) China routing + latency problems

Even if you’re not blocked, you can still be unusable:

• long distance to your origin
• weak peering into China
• packet loss on cross-border routes

Result: page loads… eventually… and users leave.

3) Blocked dependencies (the silent killer)

Your domain loads fine, but your site uses:

• Google Fonts
• Google Analytics scripts
• YouTube embeds
• reCAPTCHA
• map providers that don’t work

Result: broken UI, missing text, forms that never submit, “white screen” SPA failures.

For many modern sites, blocked dependencies cause more damage than direct blocking.

The 30-Minute China Test Workflow

If you’re testing “does my site work in China?”, you want a workflow that answers three questions quickly:

1. Can the user reach your domain at all?
2. Can the user load your page fully (fonts/JS/CSS/API calls)?
3. If it fails, is it blocking, routing, or your own dependencies?

Here’s a simple workflow you can repeat anytime you ship changes.

Step 0: Pick the page that matters

Don’t test your homepage only. Pick:

• your signup / checkout page,
• your pricing page,
• your app shell route (if you’re an SPA),
• and your most “third-party heavy” page (maps, video, captcha).

If the important page is broken, “homepage works” is irrelevant.

Step 1: Run a multi-node China HTTP test (reachability + region variance)

Use 17CE or BOCE with multiple mainland nodes (north/south + different carriers).

What you’re looking for:

• consistent success across nodes (good sign)
• one carrier failing repeatedly (routing/peering issue)
• repeated TLS handshake failures (TLS/SNI problems)
• DNS resolution differences (DNS/CDN misrouting)

Step 2: Run a block-signal test (quick sanity check)

Use GreatFire Analyzer and/or GFW Report.
Think of these as the smoke alarm, not the firefighter.

If they scream “blocked,” you still need to confirm what is blocked: your domain, your IP, or a dependency.

Step 3: Run a dependency audit (the “white screen” killer)

If your domain is reachable but the page “looks broken,” assume blocked dependencies:

• Google Fonts / fonts.gstatic
• analytics/tag managers
• YouTube embeds
• captcha providers
• maps and geocoding APIs

If any critical resource is blocked, your users see missing text, broken layouts, or forms that never submit.

Step 4: Fix one thing, then retest (don’t change 12 variables)

China debugging rewards boring discipline:

• fix one dependency or routing change,
• rerun the same tests,
• keep a simple log of results.

If you only test once, you’re not “testing”—you’re “hoping.”

The 5 Best Tools (Detailed Reviews)

These tools overlap, but that’s the point: you want confirmation from multiple angles.

Tool 1: 17CE (Multi-Node Website Test)

Best for:

• real China node performance checks
• seeing regional variance

How to use:

1. Enter your URL
2. Select a spread of nodes (north/south + different carriers)
3. Run the test and export results

What to watch:

• DNS time spikes
• connect failures from specific regions
• repeated TLS handshake failures

Screenshot guide (what you’ll typically see):

• a table of test nodes (city + carrier)
• per-node timing breakdown (DNS / connect / SSL / first byte)
• error types like timeout, handshake failure, or HTTP status codes

How to use it well:

• Run the same test twice. One bad node can be noise; a pattern is data.
• Pick at least one node from the north and one from the south. Routing can differ wildly.
• If one carrier fails repeatedly, you likely have a peering/routing issue—not a “China blocked us” issue.

Common mistake:

• Testing only your homepage and declaring victory. Modern failures happen on pages with third-party calls.

Tool 2: BOCE (Multi-Node HTTP/HTTPS Monitoring)

Best for:

• repeated “spot checks” over time
• clear breakdown of DNS/connect/SSL/HTTP

Use it to:

• verify changes after you switch CDNs
• compare performance across regions

Screenshot guide:

• timing breakdown per node (DNS, connect, SSL, request, response)
• a simple pass/fail view that’s good for non-engineers

How to use it well:

• Create a baseline test (before changes), then rerun after each change.
• Test at different times of day. Cross-border routing can be “fine at 2am” and “pain at 7pm.”

Common mistake:

• Treating “HTTP 200 from one node” as success. Your users are not a single node.

Tool 3: GreatFire Analyzer (Block signal)

Best for:

• fast “likely blocked?” sanity check

Weakness:

• doesn’t tell you why your page fails

Use it as:

• early signal, not final diagnosis.

What it’s good for (realistically):

• catching obvious “this domain is consistently unreachable” situations
• giving you a quick yes/no signal before you spend time on deep performance debugging

What it’s not:

• a performance test
• a JavaScript/page-render test
• a dependency audit

How to use it well:

• If it reports “blocked,” immediately test your static HTML page as well as your app page. Sometimes the app breaks because of blocked third-party calls, not because your domain is blocked.

Tool 4: GFW Report (Second opinion)

Best for:

• confirming block patterns
• cross-checking DNS/connect behavior

Use it to confirm:

• “this is a real block” vs “this is a performance problem.”

Practical approach:

• If GreatFire says “blocked” and GFW Report also suggests block patterns, treat it seriously.
• If one tool says “blocked” and another shows normal reachability but slow load, you may have a routing/performance problem, not a block.

How to use it well:

• Test both https://yourdomain.com/ and a “dumb” endpoint like https://yourdomain.com/health (if you have one). The more complicated the page, the more ways it can fail.

Tool 5: ChinaZ / ITDog (DNS + Ping + Route hints)

Best for:

• debugging DNS answers from China nodes
• seeing rough latency patterns

Warnings:

• ping is not definitive (ICMP blocked on many servers)
• treat it as supportive evidence

How to use it well:

• Compare DNS answers from multiple China nodes. If the IP differs from what you expect, your CDN routing or DNS config may be the culprit.
• Use route hints to see whether traffic is taking a weird detour that adds latency.

Common mistake:

• Over-trusting ping. Many origins/CDNs block ICMP, so “ping failed” does not equal “website blocked.”

Tool Comparison Table

Tool	Best for	Strength	Weakness
17CE	Multi-region real tests	Lots of China nodes	Can be noisy; requires interpretation
BOCE	Repeat monitoring	Clear breakdown	Node availability varies
GreatFire	Block detection	Quick signal	Not a full load test
GFW Report	Cross-checking	Helpful patterns	Limited performance depth
ChinaZ/ITDog	DNS/ping hints	Fast debugging	Ping can mislead

How to Interpret Results

If DNS answers differ from global

Likely:

• DNS interference
• misconfigured DNS/CDN routing

Fix:

• use robust DNS providers
• simplify CNAME chains
• avoid pointing critical resources at blocked domains

If TLS handshakes fail

Likely:

• SNI/TLS filtering or certificate chain issues

Fix:

• ensure modern TLS config
• ensure full certificate chain served
• consider alternate CDN endpoints

If HTTP works but page looks broken

Likely:

• blocked JS/CSS/fonts or third-party APIs

Fix:

• self-host fonts and critical assets
• replace blocked third-party scripts
• add graceful fallbacks

If everything works but slow

Likely:

• routing/latency problem

Fix:

• add China-friendly CDN
• consider Hong Kong origin + smart routing
• optimize payload and reduce third-party calls

If only some cities/carriers fail

Likely:

• cross-border routing/peering issues
• CDN edges that perform unevenly by carrier

Fix:

• test more nodes to confirm the pattern
• talk to your CDN/provider with the failing node list (city + carrier + timestamps)
• consider multi-CDN or a different CDN strategy if one carrier is consistently bad

If your HTML loads but your app is a white screen

Likely:

• blocked JS bundles, blocked API calls, or blocked third-party scripts
• a single blocked request that prevents rendering (common in SPAs)

Fix:

• test a “no-JS” fallback page (even a minimal server-rendered shell)
• remove blocked dependencies from the critical path
• add timeouts/fallbacks so one blocked analytics script doesn’t kill the UI

If text is missing or fonts look broken

Likely:

• Google Fonts / fonts.gstatic.com is blocked
• your CSS references blocked external fonts

Fix:

• self-host fonts (or use system fonts)
• ship fonts as part of your build and serve them from your own domain/CDN

If forms/checkout fail but browsing works

Likely:

• captcha provider blocked
• payment provider blocked or slow
• third-party fraud/analytics scripts blocking form submission

Fix:

• use a captcha provider that works in China or provide a fallback (email verification, rate limits)
• minimize “must-load” third-party scripts on critical flows

How to Improve Website Accessibility in China

Dependency Audit (Google Fonts Is Not Your Friend)

Audit your critical path:

• fonts
• analytics
• tag managers
• maps
• captchas
• video embeds

If your site’s first render depends on blocked domains, the user sees a broken page.

Practical replacements:

• self-host fonts
• use privacy-friendly analytics with self-hosting
• avoid YouTube embeds; provide alternate video sources
• choose a captcha provider that works in China

Quick dependency checklist (things that commonly break China access)

If your site depends on any of these in the first render, you’re taking on risk:

• Google Fonts (CSS + fonts.gstatic.com)
• Google Analytics / Tag Manager
• YouTube embeds
• reCAPTCHA
• Google Maps tiles/geocoding
• certain social logins that require blocked domains

The principle is simple:

If the dependency is blocked, don’t let it block your UI.

Practical engineering moves:

• make analytics non-blocking (load after first paint; time out quickly)
• don’t block form submit on marketing scripts
• add graceful fallbacks (“video unavailable” is better than “site unusable”)

CDN Strategy

If you rely on a global CDN only, your China performance may vary wildly.

Practical approaches:

• China-optimized CDN (if you’re eligible and compliant)
• Hong Kong + optimized routing
• dual-CDN strategy (advanced)

A realistic CDN approach for most teams

You don’t need to move your entire backend to mainland China to see improvement. A common pragmatic pattern:

1. Keep your origin where it is (or in Hong Kong/Singapore).
2. Put static assets (JS/CSS/fonts/images) behind a CDN with good China routing.
3. Cache aggressively so the “cross-border part” happens as little as possible.

If your site is an SPA:

• your JS bundle is your product
• if the bundle is slow or blocked, your product is slow or blocked

CDN strategy comparison (high level)

Strategy	Pros	Cons	When it’s worth it
Global CDN only	Simple	China performance may be unpredictable	China is not a core market
HK origin + better routing	Operationally simple	Still cross-border	You want improvement without compliance overhead
Mainland CDN/edge	Fastest potential	Often needs ICP + compliance	China is a primary market
Dual-CDN	Resilient	Complex ops	You have scale and dedicated engineering

Hosting Location Tradeoffs (Mainland vs Hong Kong)

Mainland hosting:

• can be fastest for mainland users
• but may require ICP filing and other compliance steps

Hong Kong hosting:

• often easier operationally
• still relatively close
• but performance can vary depending on routing

Practical rule:

• If you can’t (or won’t) do mainland hosting, make your static assets fast and your app resilient.

What usually hurts the most from outside-mainland hosting:

• large JS bundles
• heavy image pages without CDN optimization
• chatty APIs (lots of small requests)
• real-time features (WebSockets) if routing is unstable

What usually survives fine:

• mostly static marketing sites with cached assets
• lightweight APIs with good caching and fewer round-trips

ICP Filing Basics

If you host a website on mainland China servers, you generally need an ICP filing (备案).

High-level reality:

• it’s a business process, not a code change
• you usually need a China entity and local hosting provider support
• timelines and requirements vary

If you don’t want to do ICP:

• host outside mainland (Hong Kong/Singapore/etc.)
• use CDNs and optimize dependencies

What ICP does (and doesn’t) do:

• It can be required for mainland hosting and some mainland CDN setups.
• It does not magically “unblock” a domain that’s blocked by policy.
• It does not fix blocked third-party dependencies (that’s still on you).

If you’re evaluating ICP, treat it as a business decision:

• Are you actively marketing to mainland users?
• Do you need consistent performance and support?
• Do you have the ability to handle compliance requirements?

Technical Checklist (Engineer Section)

If you want to make your site “China-ready,” run this list:

Network and TLS

• Serve a complete certificate chain
• Enable modern TLS versions/ciphers
• Avoid mixed content warnings (especially on mobile)
• Ensure HTTP/2 (or HTTP/3 where appropriate)

Practical tests you can run from anywhere (not China-specific, but catches breakage):

curl -I https://yourdomain.com/
curl -I https://yourdomain.com/your-critical-page

If you see odd redirects, missing headers, or inconsistent www vs non-www, fix that first. China debugging is hard enough without self-inflicted wounds.

DNS

• Keep DNS simple
• Avoid long CNAME chains
• Ensure CDN uses China-friendly routing

Practical DNS hygiene:

• Use fewer indirections. Every extra CNAME is another point of failure.
• Keep TTLs reasonable during migration (then increase after stable).
• Make sure your apex/www/subdomains all behave consistently.

App dependencies

• Remove/replace blocked third-party scripts
• Self-host critical JS/CSS/fonts
• Provide fallbacks for maps/video

The engineer move: identify critical-path dependencies.

Critical-path = required for the first meaningful render or form submission.
Everything else should be non-blocking and allowed to fail gracefully.

Quick “blocked dependency” scan (build artifact idea)

You don’t need perfect tooling to find 80% of issues. Grep your built HTML/JS for obvious blocked domains:

rg -n \"google-analytics|googletagmanager|fonts\\.gstatic|fonts\\.googleapis|recaptcha|youtube\\.com\" out/ .next/ dist/ 2>/dev/null

If those appear in your critical path, expect China users to see broken pages.

Performance

• Reduce JS bundle size
• Add server-side rendering where helpful
• Cache aggressively for static assets
• Test on mobile networks, not just office Wi‑Fi

Practical performance wins that help China disproportionately:

• self-host and compress fonts (or use system fonts)
• reduce third-party scripts on initial load
• ship fewer JS chunks; fewer requests is better when routing is unstable
• enable long-term caching for versioned assets (hash in filename)

UX hardening (so “blocked” doesn’t mean “blank screen”)

• Add timeouts around analytics/tag scripts.
• Render text with system fonts first, then swap to custom fonts when available.
• If maps don’t load, show the address and a copy button instead of a broken map widget.
• Avoid gating signups behind captcha providers that may not work in China.

Monitoring

• Monitor from multiple China regions
• Track both “up/down” and “time to interactive”

Minimum monitoring setup:

• one daily multi-node check (17CE/BOCE)
• one “critical page” check (signup/checkout)
• alerts on failure spikes per region/carrier

FAQ

Is my site blocked in China if it’s slow?

Not necessarily. Many sites are reachable but too slow to be usable. Distinguish “blocked” from “poor routing” and “blocked dependencies.”

Do I need ICP filing to be accessible in China?

No. ICP filing is generally required for hosting inside mainland China, but many sites can still be accessible (and fast enough) from outside with the right CDN/dependency strategy.

What is the #1 fix for a modern web app?

Remove blocked dependencies from the critical path. The fastest win is often self-hosting assets and replacing Google-linked resources.

Will a CDN automatically fix China access?

Sometimes it helps a lot. Sometimes it does almost nothing. A CDN improves routing and caching, but it won’t fix blocked third-party scripts or a page that depends on blocked APIs.

Is “ping works” enough?

No. Ping/ICMP is often blocked by servers/CDNs and isn’t a reliable signal. Even if TCP works, your full page load can still fail due to blocked dependencies.

Can I make my site usable in China without ICP?

Often yes—especially for content sites and SaaS dashboards—by making static assets fast and removing blocked dependencies. ICP becomes relevant when you want mainland hosting/CDN and deeper local optimization.

CTA: Run a China Readiness Audit

If China users matter to your business, don’t guess. Test, measure, fix, repeat.

Start with:

• How to test if a website is blocked in China
• Best VPN for China (2024) (for your own testing access)