7 of 8 Chinese official hosts repeated their status codes.

Before relying on a saved access result

Check when and how it was obtained. The repeat measurement below shows what stayed stable and what changed.

Same eight targets, same two controls, one mainland host. This time every host was requested three times with a bare command-line client and three times with the same client sending only a browser user-agent string.

The court host returned 403 to the bare client and 200 to the script with a browser user-agent header on 8 August. On 15 August, both profiles returned 200 in all three rounds. Neither profile ran a real browser.

Seven of eight hosts also repeated their baseline codes on 22 August. The court host returned 200 under both scripted profiles. These are results at separate dates; neither continuous access nor changes to record content were measured.

What that means for an answer you saved last week

The comparison uses the same client profiles at each date. Mixing a bare-client result with a browser-header result could make a client difference look like a change over time.

Two practical readings follow.

Seven repeated codes do not prove a lasting refusal. We measured short sessions on separate dates. We did not monitor the days between them or estimate the chance that a retry would work.

The court host changed in both directions. It returned 200/200 on 15 and 22 August, then 403/200 on 7 September. The September panel records that later result. A saved response needs its date and profile.

A repeat gives another dated observation. It can show a difference between sessions, but it cannot show what happened between them. Recheck the source before relying on a saved access result.

What we changed in the method, and why

The original panel recorded a bare-client result and a browser-header result in separate columns, which was the right instinct. What it did not do is treat the client profile as part of the finding. Earlier the same week we paid for that. We compared a bare-client result against a user-agent result from a different run and reported a host as having drifted between dates when nothing had drifted at all. That correction is documented on the entry-point page.

The CSV records each profile and round. Its extra reference row, for the market regulator host, shows 403 in three bare-client requests and 200 in three browser-header requests. Collection notes mention a separate five-repeat run; those extra requests are not columns in this CSV.

The reference host is outside the eight-target panel. All eight targets and both controls returned the same codes under the two profiles on 15 August. That does not rule out other client checks or predict a browser session.

Boundaries: root paths only; a consumer connection on 8 August and a mainland cloud host on 15 August. No company search was performed. A 200 is a response code, not proof of usable record content. Both place and date changed. The snapshots cannot isolate the cause or show continuous access.

Why this matters if you are buying from China

The baseline and retests show dated request outcomes. Seven targets repeated the baseline at the August retests; the court host changed. No session establishes that an official record is absent or that a source will stay unavailable.

When someone tells you a check could not be completed, the useful questions are which source, on what date, and with what client. All three are recoverable from a measurement like this one; none of them are recoverable from “the system was down”.

The panel's anchor source is the GSXT, the National Enterprise Credit Information Publicity System, the China company registry itself. Anyone who needs to verify Chinese company identity eventually depends on it, directly or through a reader on the China side. That is why its answer pattern is worth measuring on a date rather than asserting from memory. For China due diligence work, that means the honest citation is never "the registry is unreliable". It is this panel's row, with its date.

Start with the details you already hold. Check an 18-character code offline → It checks structure, not issued identity. Read pasted business-scope wording → Both run in your browser without requesting these official hosts.

Related: the 8 August baseline panel · six official registry entry points, six answers · five client profiles against the registry front page · how to search the registry once you are in.

The same rule, turned on our own newer measurements

An access result and a company record answer different questions. A separate commercial-source run on 21–22 August used 45 selected company codes. It did not query the official hosts in this panel. See the code-selection limits.

The commercial source returned change records for 41 of 45 codes. That is a record-presence count, not a change rate. It does not establish that these records age faster than the access results.

Keep the query date and scope with each figure. The 22 August retest JSON holds the access results, including a rejected overseas attempt. It does not contain the private company-level records. A human check needs an agreed source and scope.

Citing this

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

Quote or reproduce these results freely, including commercially. Keep both dates (8 and 15 August 2026), the vantages (a consumer connection for the baseline and a mainland cloud host for 15 August), the client profiles and the stated limits attached to them.

Currawong, “7 of 8 Chinese official hosts repeated their status codes”, baseline 8 August 2026 and retest 15 August 2026, three rounds per profile from one mainland Chinese host with same-session controls. https://currawongweb.com/verify/chinese-official-sites-retest/

BibTeX

@dataset{currawong_china_official_source_retest_2026,
  author    = {Bao L. Zhou},
  title     = {{Eight official Chinese verification sources re-measured after seven days, under two client profiles}},
  year      = {2026},
  publisher = {Zenodo},
  doi       = {10.5281/zenodo.22004759},
  url       = {https://doi.org/10.5281/zenodo.22004759}
}

Machine-readable evidence, every host and round: the observation table (CSV, CC BY). It carries the baseline values, the per-round retest values under both client profiles, a changed flag and a user-agent-discrimination flag. 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 on root paths. 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.