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

What I 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.

Client type changes the answer. Every host here was requested with a browser user agent, three times, with controls in the same session; one court host answered only to the browser agent. That is the whole point of profiling clients: the same URL can serve one caller and refuse another on the same afternoon.

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. That is 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 explanation we take forward. As stated below, however, we have not yet measured the browser side 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. It is 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 and leaving the correction visible.

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, treat “a real browser gets 200” as the best available explanation. It is not 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. This means “the control returned 200” is not a fact on its own. It is meaningful only together with the profile that produced it. Any availability panel that does not state its client profile, including our own earlier panels, 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 matters in two situations. When a supplier check “fails”, the gate may be the cause rather than anything about the supplier. When a vendor quotes cheap instant registry data, ask which source it came from and when it was last retrieved. The official front door imposes a hard floor on the cost of doing it properly.

Our own answer is intentionally 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.

You are the one client profile not on that list, and these two checks need no session with that host anyway. Check an 18-character code offline → The check digit is recomputed in your own browser, with nothing sent anywhere. Turn an English or storefront name into candidate registered names → Free, and it reads republishing platforms instead of the front door profiled above.

Related: the 14 August challenge measurement this extends (data on Zenodo, DOI 10.5281/zenodo.21959355) · the eight-source availability panel · how to read a registration record once you have one.

What the record contains, once a client profile is no longer the question

This study shows that dressing a script up as a browser does not get you in. Read it alongside what the same records hold when access is not in dispute. On 21–22 August 2026 I queried nineteen dimensions for 45 Chinese manufacturers through a licensed commercial route, the companies on the NHTSA vehicle-manufacturer list resolving to exactly one Chinese entity.

Five client profiles all failed at the door. A licensed route answers for almost every company. The gap between those two facts is the whole argument for not spending effort on fingerprint games.

Two limits on reading this as a substitute. It is a different kind of access. It does not get around what this study measured. The zero row shows what no route can improve on: an empty sanction record is the ordinary state, so passing that check distinguishes nobody. The batch is described in the NHTSA manufacturer study and is read along different dimensions across this site.

Citing this

Archived copy with its own DOI, resolving independently of this site: Harvard Dataverse. A Zenodo archive of this matrix is in preparation. The Zenodo record previously linked here belongs to the 14 August challenge measurement and does not contain this matrix.

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/ Dataset: https://doi.org/10.7910/DVN/VPQU7E

@dataset{currawong_china_registry_client_profiles_2026,
  author    = {Bao L. Zhou},
  title     = {{China company registry client-profile matrix: five client fingerprints, three rounds each}},
  year      = {2026},
  publisher = {Harvard Dataverse},
  doi       = {10.7910/DVN/VPQU7E},
  url       = {https://doi.org/10.7910/DVN/VPQU7E}
}

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. 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.