China’s company registry refused every scripted client we tested.

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

The challenge described here is one reason a front page can refuse an automated caller. Measured on the same date, five of eight official verification hosts declined to serve their front page while both controls answered. This was a pattern across the hosts buyers are sent to. It was not one site behaving oddly.

The Shandong exit was confirmed independently as a China Unicom consumer address before the run. We checked because an earlier test had assumed 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 and 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.

The other refusals, and why the status code misleads

The registry front page is not the only official source that turns a program away, and the rest do it in at least four different ways. On 15 August 2026 we requested each front page from inside mainland China, twice, under two different client identifiers, and read only the response headers. What came back changes how a failed lookup should be written down.

Changing the client identifier achieved nothing. Four of the five refusals returned byte-identical headers whether the request announced itself as a command-line tool or as a desktop browser. The common advice to “try a different user agent” costs time and leaves more failed requests behind it.

The status code does not identify the mechanism. A 412 from one portal and the 521 from the registry carry the same protection vendor's fingerprint and are one system. A 412 from a second portal is something else. Sorting failures by status code sorts them wrongly.

One request is not a measurement. The court enforcement source moved from refusal to normal service inside ten minutes with nothing changed at our end. That cuts both ways: our own earlier record for that host, taken on 9 August, may equally have caught it mid-window instead of found a policy.

Header signatures, host names and per-round codes are intentionally not printed here. They are in the dataset, which is what a person checking this needs and a person copying it does not. As above, we did not attempt to pass any of these controls and this page is not a route around them.

Two things we concluded first, and got wrong

This section is here because the errors are more instructive than the output. A measurement page that only shows the tidy ending is asking you to trust it instead of 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. That meant the proxy itself was down, so the entire observation was void.

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. The response-header analysis that followed is the reason this page says what it says.

Both errors were caught before publication. They are recorded here because quietly correcting them and pretending the first output was right is the same habit that produces verification reports with no empty rows.

Why this is worth a buyer's attention

Perhaps you have 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 instead of 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.

Two things you can do from your own desk, without reaching that front door. If the supplier has given you an 18-character code, check its structure and check digit offline → It runs in your browser and catches a transcription error before it becomes the wrong company. If an English or storefront name is all you have, search for the candidate registered names → Free, and it returns the registered Chinese name alongside its code. Neither one touches the host measured above: the first needs no network at all, and the second reads republishing platforms instead of the portal.

Related: the eight-source availability panel this extends (data on Zenodo, DOI 10.5281/zenodo.21859883) · how to read a registration record once you have one. The host under measurement is the GSXT, the National Enterprise Credit Information Publicity System, the national China business registry. This is why the finding matters to anyone whose China due diligence assumes automated registry access.

What the same records look like when the door is not the problem

This study measures a door that opens for browsers and closes for scripts. It says nothing about the value of what is behind it. 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.

So the content is substantial and the obstacle this study documents is about access, not about the record being thin. That distinction matters for anyone deciding whether the effort is worth it: the wall is real, and so is what sits behind it.

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

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.

Archived copies, each with its own DOI, resolving independently of this site: Zenodo · Harvard Dataverse · Mendeley Data.

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/

@dataset{currawong_gsxt_javascript_challenge_2026,
  author    = {Bao L. Zhou},
  title     = {{China national company registry JavaScript-challenge observations: two networks, three rounds each}},
  year      = {2026},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.21959355},
  url       = {https://doi.org/10.5281/zenodo.21959355}
}

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.