Why does China's company registry fail from a script but load in a browser?

On 14 August 2026 the registry front page returned HTTP 521 to every scripted request we made from two unrelated Chinese networks, six attempts in total, while two government control hosts returned 200 from the same machines in the same seconds. The 521 body is a JavaScript challenge: a client that executes the script obtains a cookie and is admitted on a later request, and a client that does not execute it stays on 521. A browser executes it automatically. A plain HTTP client never does.

Does a 521 mean the registry is down or blocking foreign users?

No. Both of our vantage points were inside mainland China, so this is not about foreign IP addresses, and the same-session control hosts returned 200, which rules out a network fault. A 521 is an answer, not silence — the server received the request and declined to serve the page to that particular client.

Can anyone sell instant automated Chinese registry data?

Not from that front door, and not honestly. A challenge that requires a real browser session puts a hard floor under the cost and latency of any automated pipeline pointed at it. If a vendor quotes instant bulk registry data, the question worth asking is which source it actually comes from and when it was last retrieved.

Measurement recordTwo networks, six requests

The registry answers people. It refuses programs.

China's national company registry is the source every sourcing guide tells buyers to check, and it is the source that keeps failing when anyone points a script at it. We measured it from two unrelated networks inside mainland China: six requests, six 521s, while two government control hosts returned 200 from the same machines in the same seconds. The registry is not down. It is running a JavaScript challenge, and that single fact quietly invalidates a whole category of product claim.

Published 14 August 2026 · Observations from 14 August 2026 · Extends our eight-source availability panel.

Short answer

A 521 is an answer, not silence. The server got the request and declined to serve that particular client. Run the same URL in a browser and it returns 200.

So the honest sentence is not “the registry is down”. It is: the registry answers people and refuses machines.

What we measured

Two vantage points that share no infrastructure, three rounds each, with control hosts requested from the same machine in the same session. The controls are the whole point: without them, a 521 is indistinguishable from a broken proxy, a routing problem or an IP-range block.

14 August 2026 — two Chinese networks, three rounds each
Host	Role	Shandong consumer broadband	Shanghai cloud host
National company registry, front page	Target	521, 521, 521	521, 521, 521
Registry sub-host	Target	412, 405, 412	—
Central government portal	Control	200, 200, 200	200, 200, 200
Market regulator portal	Control	200, 200, 200	200, 200, 200

The Shandong exit was confirmed independently as a China Unicom consumer address before the run, because we had already been burned once by assuming which network a proxy port actually left from — see below.

Both vantage points are inside mainland China. Whatever this is, it is not a foreign-IP block, and the same-second controls rule out a network fault.

What the 521 actually is

The 521 response is not empty. It carries a challenge cookie and a body of obfuscated JavaScript that, when executed, computes a second cookie. A client that runs the script obtains that cookie and is admitted on a subsequent request. A client that does not run it stays on 521 for ever.

That is the ordinary shape of a JavaScript challenge, and it explains the behaviour exactly: a browser executes the script without the user noticing, so a person sees a working website; a plain HTTP client executes nothing, so a program sees a wall. The same URL, at the same second, from the same machine, gives two different answers depending on what is asking.

A person with a browser reaches it. That was confirmed on the same day on a third, unrelated mainland connection, by someone simply opening the page and seeing it load.

What we did not do, and will not

We did not attempt to pass the challenge, and this page is not a guide to passing it. There is no request recipe here, no cookie construction, and no code. Working around a site's bot protection is the line our own verification work does not cross: the records we deliver are read by a person, from the official portals, in the ordinary way.

Two limits on the claim itself. The challenge is identified from the shape of the response and from secondary technical sources, not from any vendor's documentation — we did not ask the operator and they have not told us. And this describes one front page on one date; a different path on the same site, or the same path next month, may behave differently.

Two things we concluded first, and got wrong

This section is here because the errors are more instructive than the result, and because a measurement page that only shows the tidy ending is asking you to trust it rather than check it.

Error one: a vantage point that was not where we thought

We reported an additional observation from what we believed was an Australian exit, showing total failure on all three URLs, and started reasoning from it. It was wrong twice over. That proxy port left through the same Shandong address as the other one, so it was never a second country. And the control host failed on it too — which meant the proxy itself was down and the entire observation was void, not evidence of anything.

The fix was mechanical: query an IP geolocation service for each port's actual exit address before trusting any of them. The lesson is not mechanical: a control host that fails is not a data point, it is a broken instrument.

Error two: nearly publishing “the registry refuses connections”

With a single vantage point and no analysis of what the 521 contained, we were one edit away from putting that sentence on this website. It would have been wrong in a way that mattered: it reads as a claim about the registry's posture toward the outside world, when the actual finding is about client type.

What stopped it was not a test. It was a person saying “that's odd, I can open it” — and then opening it. One human counter-example beat a clean-looking automated result, and the response-header analysis that followed is the only reason this page says what it says.

Both errors were caught before publication. They are recorded here because the alternative — quietly correcting and presenting the result as though we had it right the first time — is the same habit that produces verification reports with no empty rows in them.

Why this is worth a buyer's attention

If you have ever been told an official Chinese source was “down”, or watched a lookup fail and read it as the supplier hiding something, this is the mechanism you were actually meeting. It is also a useful test of anyone selling you data: a challenge that requires a real browser session puts a hard floor under the cost and latency of any automated pipeline pointed at that front door. Instant bulk registry data, quoted cheaply, is a claim to interrogate rather than accept — ask which source it came from and when it was last retrieved.

Our own answer to the same problem is unglamorous: the checks are executed China-side by a person, and every delivered line carries the source it came from and the date it was retrieved. You can see what that produces on a real named company, including the query that came back with nothing.

Citing this

Quote or reproduce these results freely, including commercially, provided the date (14 August 2026), the vantage points (two unrelated networks 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.

Currawong, “China's company registry answers browsers, refuses scripts”, three-round observations from two unrelated mainland Chinese networks with same-session controls, 14 August 2026. https://currawongweb.com/verify/gsxt-javascript-challenge/

Machine-readable evidence, every host and round: the observation table (CSV, CC BY). It carries the exact hostnames, the per-round status codes and the vantage for each row — the page above 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.