Does everything get routed through 21YunBox?

No, and doing so would make some resources worse. In our own twelve-hour sampling from inside China, two of five common third-party resources were faster requested directly — by roughly 170 to 200 milliseconds. Those are left where they are. The route is decided per resource on measured behaviour, not applied wholesale.

How do you know which resources need changing?

By measuring both paths from inside mainland China and recording, per request, what completed and what never returned. That is the input the decision runs on. Our census records it for 280 sites and our residential run for 88 more; the method and its failure modes are written up separately .

Do we need to change our code or re-platform?

No. The work is at the delivery layer rather than in the application. What does need planning alongside it is the regulatory side: serving to Chinese users from mainland infrastructure is what makes the ICP filing a requirement, and the filing is issued to a mainland legal entity with its own lead time.

By the 21YunBox China Engineering Team·Reviewed 2026-08-30·Verified against primary sources

How does 21YunBox decide what to change about a site?

The decision is made per resource, and it is made on measurements taken from inside China rather than on a rule of thumb. That matters because the naive approach — route everything through a China delivery layer — makes some things worse. Measured fact: sampling every ten minutes for twelve hours from a probe inside mainland China, two of five common third-party resources were faster requested directly than through an additional hop, by roughly 170 to 200 milliseconds each. Those should be left alone, and a layer that rewrites every reference by default pays that penalty on all of them. Meanwhile the resources that genuinely need changing fail in a way that speed tuning cannot reach: across 280 enterprise sites measured from inside mainland China, 34% finished none of three attempts and roughly two thirds of those had already answered and painted before stalling. So the useful question about any given request is not «is it slow» but «does it complete, from where our visitors actually are» — and answering it requires having measured both paths. The delivery arrangement that removes the border crossing is also what brings the ICP filing with it, which is why the two are planned together rather than in sequence.

The measurements the decision is made on

Fact	Primary source
Sampling five common third-party resources every ten minutes for twelve hours from a probe inside mainland China, two of the five were faster requested directly — roughly 110ms against roughly 300ms through an additional hop. Routing an already-healthy host through a delivery layer costs latency for no benefit, which is why the decision has to be made per resource.	21YunBox — twelve hours of third-party sampling from inside mainland China
Across 280 enterprise sites requested three times each from a probe inside mainland China, 58% finished every attempt and 34% finished none — and roughly two thirds of the failures had returned a first byte and painted content before stalling. The common failure is not slowness and not blocking; it is non-completion.	21YunBox — 280-site China delivery census, measured from inside mainland China
What fails is usually a dependency rather than the site. Measured across 88 real page loads from a Beijing China Mobile residential broadband line, 102 hosts never returned a response and 101 of them were third parties, while every one of the 57 sites that failed to finish loading returned a first byte itself.	21YunBox — paired measurement from a Beijing residential broadband line
The vantage the measurement is taken from changes the answer. In a paired run, hosts that answered 100% of the time from a mainland cloud probe answered 0% of the time from a Beijing consumer broadband line — so a decision made on cloud-probe data can be wrong for real visitors.	21YunBox — paired measurement from a Beijing residential broadband line

Sources verified by the 21YunBox China engineering team on 2026-08-30.

How To Use 21YunBox

How-to guides for using 21YunBox. We make the below technologies work in China.

We've written several dozen guides for common uses for using 21YunBox.

Don't see your project represented here? Send us an email explaining what you do (or are trying to do) and we'll happily write a new one!

By Digital Experience Platform (DXP)

We make your sites load fast in China (including the CDN your DXP use).

Acceleration for China

Your favorite technology or tools don't work in China? Here are the guides to make it work.

Latest Tutorials

View All Tutorials →

21YunBox Makes Your Netlify/Vercel/Github/Stripe/Heroku/Vimeo and many other techs perform better in China within the Great Firewall of China.

Deploy Backend Services in China

Run your apps in China. No server configurations are needed. Git Push and your Rails, Express, Django, Laravel apps will be live in China within minutes.

Latest Tutorials