GSXT returned 521 in all 6 requests from 2 Chinese networks

What I measured

Two mainland networks, three rounds each. Control hosts were requested from the same machine in the same session. Their 200 responses show those requests worked. A network fault on the target route remains possible.

Earlier context: the separate 8 August eight-host panel records its own clients, controls and dates. The table below contains this study's observations.

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 tested networks were inside mainland China. The controls returned 200 in the same sessions. These results do not isolate routing, IP policy or the server that produced the target response.

What the 521 actually is

The saved CSV notes describe obfuscated JavaScript and a challenge cookie in the 521 response. That suggests a JavaScript challenge. The dataset does not contain a browser run showing that executing the script grants access.

The response notes are evidence about the tested scripts. They do not establish how the site decides to admit a client, whether a browser would load the page, or whether a company search would succeed.

The operator reported opening the page in a browser on another mainland connection that day. That report is separate from the recorded script tests; it has no instrumented browser result in this dataset.

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. Official-source reads belong to our scoped L3 human check. Self-service reports use a licensed business-information platform.

The challenge label comes from the saved response notes. No vendor has confirmed it, and this dataset has no raw response body to check. It covers one front page on one date. Other paths or later requests may differ.

Other codes do not identify a protection system

Earlier text attributed 15 August responses to named protection mechanisms, said a request never reached the origin, and described a court response as intermittent. The linked 14 August CSV does not contain those header captures or that time series. Those claims are withdrawn pending the original evidence.

The dated five-profile matrix and official-source retest show their own results and limits. A shared code or similar header does not by itself establish a common vendor or cause.

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 first treated a failed run as an Australian result. All three URLs had failed. There were two flaws. The reported exit was the same Shandong address as the other port. It was not a second country. And the control host failed on it too. That left the cause unresolved, so we excluded the observation from conclusions about the registry.

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 failed control leaves the cause of a target failure unresolved.

Error two: nearly publishing “the registry refuses connections”

We nearly used that claim after one network test, before reading the response notes. 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 recorded finding is six scripted responses from two networks.

The operator reported opening the page in a browser. That report prompted a closer look at the script responses. It was not an instrumented browser test, and we do not count it as one.

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

A failed scripted lookup is not evidence that a supplier is hiding a record. Ask a data provider which source it uses, when the record was read and what the result can establish. This study did not measure vendor costs, delivery times or data quality.

Self-service reports use a licensed Chinese business-information platform. A scoped L3 check adds a person reading named official sources. Each report states its source, query date and limits. See the current report scope and dated sample.

Start with the exact Chinese name and 18-character code. Check the code structure and check digit offline → This can flag a mistyped code; a valid code does not prove registration. If you need a record read, review the current report scope → The order states the source and delivery window.

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 separate provider run queried 19 dimensions for 45 selected company codes on 21–22 August 2026. The selected codes were not a set of verified supplier identities. These returned categories do not verify what any official entry point would show.

Read each returned record for its date, entity match and limits. A category hit does not establish that the record is complete or current.

Correction: the earlier zero-sanctions label was wrong. The retained administrative-penalty query has nine hits. The abnormal-operations and serious-illegality queries each returned zero hits; neither is an all-clear. See the provider-count correction and limits and the sample selection.

Questions about these results

What did the six scripted GSXT requests return?

All six recorded requests to the GSXT front page returned HTTP 521 on 14 August 2026: three from each of two mainland networks. The government controls returned 200. Browser sessions and company searches were not measured.

Does a 521 prove the registry is down or blocks foreign users?

No. A response was recorded, but the code alone does not identify its source or cause. Both tested networks were inside mainland China. The controls help bound the observation; they do not rule out a target-specific network issue.

Does this study establish the cost or quality of instant registry data?

No. We tested a root URL with scripts on one date. We did not measure vendor costs, delivery speed or data quality. Ask a provider which source it uses, when the record was read and what its result can establish.