China national company registry JavaScript-challenge observations, 14 August 2026
Description
HTTP status codes returned by China's national company registry and two government control hosts, measured from two unrelated networks inside mainland China on 14 August 2026. Method: each host root was requested three times per vantage point. The two vantage points share no infrastructure — a China Unicom Shandong consumer broadband line and a Shanghai cloud host — and the exit address of each was verified before the run. Control hosts were requested from the same machine in the same session, which is what distinguishes a server-side refusal from a broken proxy, a routing fault or an IP-range block. Result: the registry front page returned 521 on all six attempts. Both control hosts returned 200 on all six. A registry sub-host returned precondition and method refusals. The 521 responses carried a JavaScript-challenge signature: a client that executes the returned script obtains a cookie and is admitted on a later request, and a client that does not execute it stays on 521. A browser therefore reaches the site and a plain HTTP client does not. Limits, stated so they travel with the data: this is one date and two vantage points, both inside mainland China, so it says nothing about access from outside China and nothing about this host today. The challenge is identified from the shape of the response and from secondary technical sources, not from any vendor documentation. No attempt was made to pass the challenge and no circumvention method is published here or anywhere else by us. Fields: observation_date, host, label, role (target or control), vantage, vantage_detail, round1_status, round2_status, round3_status, challenge_signature, notes. Write-up, including the two wrong conclusions we reached before this one: https://currawongweb.com/verify/gsxt-javascript-challenge/
Files
Steps to reproduce
1. Obtain two network vantage points that share no infrastructure. Both of ours were inside mainland China; one consumer broadband line and one cloud host. If you use a proxy, verify each port's actual exit address first — we did not, once, and the resulting observation was void. 2. For each vantage point, request the root of each host in the table three times with a browser user agent, recording the status code per round. Request the control hosts from the same machine in the same session, not before or after. 3. Read the body and headers of any non-200 response before drawing a conclusion from the status code alone. A 521 whose body is executable JavaScript is a challenge, not an outage, and the two call for different sentences. 4. Treat a failing control host as a broken instrument, not a data point. If a control returns anything other than 200, discard the whole round. 5. Do not attempt to satisfy the challenge. The finding does not require it, and passing it would change what you are measuring.