A Chinese Cloud Probe Is Not a Chinese Visitor: The Same Hosts, Opposite Answers

Most published figures about third-party resources in China are single samples. We have argued before that a single sample is not a measurement — cross-border behaviour there varies by more than two orders of magnitude across a day, and a number taken at 2pm tells you very little about 9pm.

So we ran it properly: five third-party resource categories, sampled every ten minutes, from a probe inside mainland China, each one requested twice — once directly, once through our own delivery network. 720 measurements over twelve hours, covering the evening peak that operators plan around.

Then we did the thing that mattered more, and it cost us a recommendation.

Update, 30 August 2026. The twelve-hour study below was run from a commercial cloud line inside China — which is how almost every published China measurement is taken, including ours. We said at the time that we would repeat it from a consumer connection and publish the result even if it was unflattering. We have now done that, and the problem is bigger than a wrong recommendation: for one whole category of hosts, a mainland cloud probe and a mainland consumer line do not report the same country. Hosts that answered 100% of the time from the cloud answered 0% of the time from a Beijing home line. The original data stands — it faithfully describes that vantage. What it does not describe is a visitor. See what changed when we moved the probe.

What was measured

The list is not arbitrary. It comes from measuring real vendor websites from inside China and recording which third-party hosts actually stopped responding — these five categories are what showed up.

Method: probe inside mainland China (Alibaba Cloud cn-zhangjiakou); each resource requested directly and through our network in the same round; throughput calculated over the body transfer only, excluding time-to-first-byte, so that small files are not dominated by connection setup; 30-second timeout; timeouts counted as results rather than discarded. 72 samples per cell, 28 August 2026. Times below are China local time.

Results across twelve hours

72 samples per cell.

What we concluded, and what we got wrong

On this data we wrote that Google Fonts and the tag manager should be left exactly where they are. Both were reachable in 100% of attempts, both answered in roughly 110 milliseconds direct against roughly 300 through an additional hop, and we argued — correctly, on those numbers — that routing an already-healthy host somewhere else is a latency tax you pay on every request for no benefit.

The reasoning was sound. The vantage was not. We had written, in the same article, that “is this host healthy from Shanghai at 9pm” is not a question you can answer from anywhere else — and then answered it from a datacenter.

Anyone who has actually operated a website in China will already be raising an eyebrow at that table, because Google-owned hosts are not generally usable from a Chinese consumer connection, and no one who works there needs a measurement to tell them so. That is precisely what makes the result worth publishing. We did not discover that those hosts fail for visitors. We discovered that our probe said otherwise, at 111 milliseconds, seventy-two times out of seventy-two.

A mainland cloud instance is not a neutral observation post. It is a commercial network with its own arrangements, and for at least one category of hosts those arrangements clearly do not extend to the person loading your page from home.

Anyone who builds software in China already knows the shape of this, because it is the daily experience of the toolchain. Upstream sources that the rest of the world takes for granted are not usable from the mainland, so the domestic clouds run their own substitutes: container registries, package registries, language runtimes. We rely on this ourselves — the measurement package the volunteer ran downloads its browser and its runtime from a domestic mirror, because the upstream sources are not reachable from where they were running it. An environment that quietly substitutes a working path for a broken one is a very convenient place to build. It is a very poor place to measure from.

We are not going to speculate about the specific mechanism for these particular hosts — we have not measured it, and an explanation we cannot support is worth less than the observation we can. The finding stands on the discrepancy itself, and the discrepancy is total: 72 out of 72 from the cloud, 0 out of 112 from a home line.

The generalisation is the useful part. If your China measurements come from a mainland cloud instance — and almost all published China measurements do — you cannot assume they describe what a visitor sees. That includes ours, until we check them the way we checked these.

What changed when we moved the probe

On 30 August 2026 a volunteer in Beijing ran our measurement stack on a China Mobile residential broadband line, using the same code, the same 60-second ceiling and the same three-runs-per-site design as our datacenter probe. That run loaded 88 real websites — 264 page loads — and recorded, per request, every host that never returned a response.

Here is what those same five hosts did:

The two hosts we told you to leave alone are the two that never answered once. Not slower. Not intermittent. Zero responses out of 112 and 54 respectively.

This is not an artifact of the timeout

The obvious objection is that these requests were still in flight when a 60-second page load was abandoned, and would have completed given longer. They would not have. The check is to look only at page loads that finished successfully and ask what those same hosts did inside them:

The page finished. The host still never answered. These are not requests that ran out of time; they are requests that were never going to be answered on that connection.

The hosts nobody warns you about

Across those 264 page loads, 102 distinct hosts never returned a response at all, and 101 of them — 99% — were third parties, not the site being requested. Only 13 of the 102 were Google-owned. Set those aside as already understood, and 89 hosts remain. This is the part that is not common knowledge, and it is the part worth acting on:

The consent-banner host is the one to look at twice. A consent script usually runs before anything else on the page and frequently blocks rendering until it resolves; a geolocation lookup that never returns is therefore not a missing cookie banner, it is a page that does not start.

The intermittent hosts are more interesting than the dead ones, because intermittent is the case nobody plans for:

A host that fails one time in four cannot be diagnosed by loading the page once, which is how almost everyone checks. It also cannot be fixed by a rule of thumb, because the rule would have to be right about a host that is right most of the time.

Three quarters of all these failures were of one specific kind: the request was sent, nothing came back, and no error was ever raised. Not a refusal, not a reset — silence. Nothing in the page reports a problem, because from the browser’s point of view nothing has gone wrong yet.

And the sites themselves were mostly fine: of the 57 sites that failed to finish loading, every single one returned a first byte, and two thirds painted something on screen before stalling. Not one was unreachable. What breaks a page in China is usually not the page.

The result that decides whether a form works

www.google.com/recaptcha did not respond once. Zero successful requests out of 72 on the datacenter line, across every hour sampled, from mid-afternoon through the evening peak and past midnight. Through our network, 72 out of 72. On the Beijing home line the same host failed in all 18 requests that reached it.

This is not a latency finding, and it is not a gradient. Form verification is the gate on submission: if the widget never loads, the submit button never becomes active. A page in that state is not slow. It is a form that cannot receive a single lead, and nothing in the page reports an error, because the request is issued and simply never answered.

If your China site has a gated contact form and you have never measured this specific thing, it is the first thing worth checking.

The result that only shows up over time

The public JS CDN was reachable in 100% of attempts by both routes on the datacenter line, and failed in none of its 36 requests on the home line. Reachability told us nothing useful. The distribution did:

Direct time-to-first-byte more than doubled between the quietest hour sampled and the 21:00 peak. Across the same twelve hours the delivered route stayed between 99 and 110 milliseconds — a spread of eleven milliseconds.

The single number that captures it is the ratio of the 95th percentile to the median:

A p95 of 1,757ms against a median of 660ms means one request in twenty takes nearly two seconds — and on a page with a dozen such requests, one of them landing in that tail is enough to hold up rendering. This is why an average is the wrong summary statistic for China, and why a figure sampled once is worth very little.

What this adds up to

Four failure modes, and only one of them is what people usually mean by “slow in China”:

1. Some hosts are genuinely fine — but you have to say from where. The public JS CDN held up on both vantages. That is a claim we can now make with two data points instead of one, and it is the only host on this list that earned it.
2. Some hosts are reachable but unstable. The median looks tolerable; the tail is where the page actually breaks. You cannot see this without sampling across the day.
3. Some hosts never answer at all. No error, no timeout event, no signal — and if that host is your form verification, the business consequence is total rather than degraded.
4. Some hosts answer perfectly from one place inside China and never from another. This is the one we did not have before, and it is the one that overturned our own recommendation. A datacenter line and a consumer line in the same country are not the same network.

The practical consequence is narrower and more useful than “route everything” or “route nothing”. The route has to be decided per resource, on measurements taken from where your visitors actually are — and a host that passes from a cloud line has not been shown to pass from a home line. Leaving an already-fast host untouched is still the correct action when it is genuinely fast for your visitors. What changed is our confidence about which hosts those are, and how much evidence it takes to say so.

Why this is not only a delivery question

Everything above is about which requests complete, and that is a delivery problem. But the fix people reach for — serve from inside mainland China, so the request never has to cross a border at all — is not purely a technical decision. Serving to Chinese users from mainland infrastructure is what brings the ICP filing requirement into play: the filing is issued to a mainland legal entity and binds to your hosting arrangement, and an unfiled site cannot be lawfully carried by a mainland access provider.

So the same architecture decision answers two questions at once, and it is worth answering them together rather than discovering the second one late: which of your requests complete for a real visitor, and are you permitted to serve them from the place where they would complete.

Limits

• The consumer measurement is one volunteer, one ISP, one night. A China Mobile residential line in Beijing, run overnight on 30 August 2026. A second ISP and a second city would make it a finding rather than a data point. The per-host results are 100% and 0% rather than gradients, with 112 and 54 requests behind the two largest, which is why we are willing to publish it at this sample size — but a single vantage is a single vantage.
• The twelve-hour study is a datacenter line. International transit from a commercial cloud is materially better than from a consumer connection, so every direct-route figure in the first half of this article is optimistic. The second half is what that optimism costs.
• Different browser builds. The datacenter probe runs Debian’s Chromium 151.0.7922.173; the volunteer ran Chrome for Testing 151.0.7922.77. Completion and time-to-first-byte are insensitive to that difference; paint timings should be read as directional only.
• Five resources, 88 sites. Chosen because they are common and because they showed up in earlier failure data, not because they are exhaustive.
• Throughput excludes TTFB, which is the fair way to compare small files but means the throughput column and the TTFB column should be read separately.
• The twelve-hour test pushed every resource down both routes, which is what a comparison requires and is not how a site is delivered. The delivered route there is also a simplified configuration built for measurability, not the production arrangement.

What we are measuring next

A second consumer vantage on a different mainland ISP, which is the single thing that would move the Beijing result from a data point to a finding. We are also extending the consumer run past the 88 sites reported here.

We would rather publish a recommendation being overturned than leave it standing because it was ours. If you are making an architecture decision on the strength of the first half of this article, the second half is the part that should change your mind.

The method behind these numbers, including the eight ways we got it wrong first. The wider picture is in our 280-site census measured from inside China. And if you want to see which third-party hosts your own site depends on, our China firewall test reports them per resource from inside the mainland.