Seven of eight had not moved at all.

What moved

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 one that moved is the court enforcement host. On 8 August a command-line client got 403 there while a browser got 200 — the classic shape of a host that turns plain scripts away. On 15 August the bare client got 200 on all three rounds. It stopped refusing.

What that means for an answer you saved last week

We went into this expecting to find drift, partly because we had just caught ourselves misreading a client-profile difference as a host changing between dates. The data says the opposite: on a seven-day horizon these hosts are boring, and boring is useful.

Two practical readings follow.

A refusal is structural, not a bad day. If the registry refused your tooling last week it will almost certainly refuse it this week, in the same way. Retrying later is not a strategy; the shape of the refusal is a property of the source.

But a source can quietly become more open, and nobody announces it. The court enforcement host went from turning scripts away to answering them, within a week, with no notice anywhere. Anything you built on “that source refuses automation” is now slightly wrong, and would have stayed wrong indefinitely if nobody re-measured.

This is the argument for repeating a measurement rather than publishing it once. A single-date panel — including our own from 8 August — tells you what happened on that date and quietly implies it generalises. Only the second run tells you which parts were stable and which were not.

What we changed in the method, and why

The original panel recorded a command-line result and a browser result in separate columns, which was the right instinct. What it did not do is treat the client profile as part of the finding — and 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.

So this retest records the profile against every single cell. It also carries one extra reference row, for a host outside the original panel that genuinely does discriminate: bare requests get 403, the identical request with a browser user-agent string gets 200, five out of five each way.

That row exists to keep the finding honest in both directions. User-agent discrimination is real, but on this panel it is rare: none of the ten hosts measured here behaved differently under the two profiles. Having caught ourselves over-reading one case, the corrective is not to assume it everywhere.

Boundaries: root paths only, one mainland vantage point, two dates. No search was performed and no record was retrieved. A 200 means the door opened, not that the data behind it is complete or that a query would succeed. Both dates are single-session snapshots, so “unchanged” here means unchanged between two points, not continuously monitored.

Why this matters if you are buying from China

Most of what a buyer is told about official Chinese sources is undated. “That system is unreliable” and “you can't check that from abroad” circulate as permanent facts. This panel now has two dated points, and they support a narrower statement: the pattern of which sources answer and which refuse held steady across a week, and one source relaxed.

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”.

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.

Citing this

Quote or reproduce these results freely, including commercially, provided both dates (8 and 15 August 2026), the vantage (one cloud host inside mainland China), the client profiles and the stated limits travel with them.

Currawong, “Seven days later: re-running the eight-source availability panel with two client profiles”, 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/china-official-source-retest/

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.