Measurement record · One mainland host, five client profiles

Dressing a script up as Chrome does not get you in.

A common piece of advice for reaching China's national company registry is to send a browser user agent, or to use a Chinese IP address. We tested five progressively more browser-like clients from a single host inside mainland China. All five returned 521 — including one presenting a genuine Chrome TLS fingerprint. A government control host returned 200 to all five in the same session.

Published 15 August 2026 · Observations from 15 August 2026 · Extends our 14 August challenge measurement

Short answer

The refusal is not about what your client claims to be. User agent, full browser headers, HTTP/2 and a real Chrome TLS fingerprint all failed identically. Whatever the gate checks, it is not a header and it is not the TLS handshake — which leaves executing the challenge script as the remaining candidate.

What we measured

One host, one session, five client profiles, three rounds each. The profiles are cumulative: each adds one layer of browser realism on top of the previous one. The control host was requested with the same five profiles in the same session — without that, a 521 is indistinguishable from a broken host or a blocked network.

15 August 2026 · Alibaba Cloud host inside mainland China · three rounds per cell
Client profile	Spoofs UA	Browser headers	TLS fingerprint	Runs JS	Registry	Control
A — bare curl	no	no	no	no	521, 521, 521	200, 200, 200
B — user agent only	yes	no	no	no	521, 521, 521	200, 200, 200
C — full browser headers	yes	yes	no	no	521, 521, 521	200, 200, 200
D — full headers, HTTP/2	yes	yes	no	no	521, 521, 521	200, 200, 200
E — genuine Chrome TLS fingerprint	yes	yes	yes	no	521, 521, 521	200, 200, 200

Profile C sent the complete set a real Chrome navigation sends: Accept, Accept-Language, Accept-Encoding, all four Sec-Fetch-* headers and Upgrade-Insecure-Requests. Profile E used curl-impersonate v2.1.0, which reproduces Chrome's actual TLS ClientHello and HTTP/2 settings fingerprint — the layer that ordinarily separates a scripted client from a browser before a single byte of HTTP is sent.

We requested front pages only. No search was run, no record was retrieved, and nothing was done to solve or bypass the challenge. This page reports which clients are refused; it does not describe how to get past the refusal, and we will not publish that.

What this rules out

Three explanations you will find in circulation do not survive this table.

“Send a browser user agent.” Profile B did exactly that and changed nothing. So did every profile after it.

“It only blocks foreign IP addresses.” Every request above came from inside mainland China. Being on a Chinese network is not sufficient. Our 14 August measurement found the same thing from two other mainland networks, so this is now three mainland vantage points in agreement.

“It is fingerprinting your TLS handshake.” Profile E presented a genuine Chrome fingerprint and was refused identically. If TLS were the discriminator, E would have behaved differently from A.

What is left is the layer none of these five clients has: actually executing the challenge script and returning with the cookie it computes. That is consistent with what the 521 body contains, and it is the reading we take forward — while being explicit below about the fact that we have not yet measured the browser side of it ourselves.

What we still have not measured, including one thing we stated too strongly

Our 14 August page says, of the registry front page: “Run the same URL in a browser and it returns 200.” That sentence is an inference, not one of our observations — every row in that study's dataset is a scripted request. It should have been written as an inference from the start, and we are correcting it here rather than quietly.

Today's table strengthens the inference by eliminating the alternatives, and the operator reports reaching the site normally in a browser from inside China. But an inference plus an unrecorded personal observation is not a measurement, so the honest state is:

Browser, inside China — not systematically measured. Operator-reported as working.
Browser, outside China — not measured.
Script, outside China — attempted and abandoned. Our Australian egress could not reach the control hosts either, so that vantage measures nothing about the registry. The null rows are in the dataset precisely so nobody reads them as a finding.

Until those cells are filled by an instrumented browser rather than by reasoning, treat “a real browser gets 200” as the best available explanation, not as something we have shown.

A control host that discriminates too, and the wrong conclusion we drew from it

Our first pass recorded that a second control host returned 403 where an earlier run had recorded 200, and we wrote that down as drift. That was wrong, and we caught it within the hour. Re-testing the same host five times with each profile gave 403 on all five bare requests and 200 on all five that sent nothing but a Chrome user-agent string. Nothing had drifted — the two runs had used different clients.

The correction matters more than the error. A control host can discriminate on client shape just as the target does, which means “the control returned 200” is not a fact on its own: it is only meaningful together with the profile that produced it. Any availability panel that does not state its client profile — including our own earlier ones — is under-specified. www.gov.cn is the one host here that answered 200 to every profile on every round, which is what makes it usable.

Why this matters if you are buying from China

The practical consequence is narrow and concrete: a pipeline that does not run a real browser session cannot read this front door, no matter how convincingly it dresses up. That covers most of what gets sold as instant or bulk registry access — plain HTTP clients, server-side fetches and API wrappers all sit in profiles A through E.

This is worth knowing in two situations. When a supplier check “fails”, the failure may be this gate rather than anything about the supplier. And when a vendor quotes you cheap instant registry data, the reasonable question is which source it actually came from and when it was last retrieved — because the official front door imposes a hard floor on the cost of doing it properly.

Our own answer is deliberately unglamorous: the checks are executed China-side by a person, and each delivered line carries its source and retrieval date. You can see what that produces on a real named company, including a query that came back empty.

Citing this

Quote or reproduce these results freely, including commercially, provided the date (15 August 2026), the vantage (one Alibaba Cloud host inside mainland China) and the stated limits travel with them. The date is load-bearing: a status code from August 2026 says nothing about this host today — as the control host that moved between 14 and 16 August demonstrates.

Currawong, “Faking a browser is not enough: China's company registry tested with five client profiles”, three-round observations from one mainland Chinese host with same-session controls, 15 August 2026. https://currawongweb.com/verify/china-registry-client-profiles/

Machine-readable evidence, every profile and round: the observation table (CSV, CC BY). It carries the client profile, which layers each one spoofs, the per-round status codes, and the null vantage rows — the page states the finding, the file lets you check it.

If you re-run this from another network or date and see something different, we want to hear it — corrections that survive checking get published here with attribution, including ones that contradict us. Browse all measured studies and methods in the research index.

This page reports connectivity observations. It is not legal advice, it is not a statement about any company, and it is not a claim about the completeness of any official database.