Measuring Blocking Correctly

A probe must measure the quantity by which the network actually breaks. Four requirements: volume, seriality, failure classification and vantage point.

2026-08-31 GIGATAP Team #vpn
#vpn#anticensorship#diagnostics#measurement#network

Measuring Blocking Correctly

Before fixing anything you have to be able to measure it. With traffic restrictions that is harder than it looks: most available tools measure the wrong quantity relative to how the network actually breaks. Hence the familiar picture: the tool reports green, the users complain, and both are right.

Here are four requirements without which a measurement answers nothing.

Requirement one: volume#

The core principle fits in one sentence: a probe measures the quantity by which the network breaks.

If the restriction counts kilobytes, the probe has to send them. A check that transmits a kilobyte and a half against a sixteen-kilobyte threshold measures nothing relevant — it measures connection setup.

A practical minimum: at least 256 kilobytes, an order of magnitude above the known threshold. The margin matters because the threshold was observed by different people as a range rather than an exact number.

What to record is not elapsed time but the byte at which the stream stalled. That is the only quantity that separates a volume restriction from an ordinarily slow network.

Requirement two: seriality#

The second requirement is non-obvious, which is why it is the one most often violated.

A probe that opens many connections at once creates the very condition under which a concurrency restriction fires. It measures its own effect and collects a refusal it caused itself.

This is not a theoretical nicety: the bulk server-list refresh in VPN clients is exactly such a fan-out, and it explains a share of the false “unreachable” marks.

The rule: probes run sequentially, with a pause between them. Slower, but the result describes the network rather than the probe.

Requirement three: classifying the failure#

“It does not work” is not a measurement result. The result is which type of failure was observed, because the countermeasure depends on the type.

A minimum set of distinguishable classes:

Class Trait What it points at
No answer to SYN connect timeout restriction by address
Reset after the handshake RST following ClientHello reset injection
Stall after N kilobytes bytes flowed, then silence, no reset volume restriction
Bandwidth cut, connection alive works but slow bandwidth throttling
Timeout during the handshake no answer after ClientHello restriction by name
System DNS and DoH disagree different addresses name-resolution tampering
Connection accepted, no data port open, empty response accept-and-discard at the edge

Separating the first two rows matters: no answer to SYN and connection refused are different diagnoses. The second usually means the service is not listening — that is configuration, not censorship.

No off-the-shelf open tool provides this classification today; the community has discussed the need, but the implementation is left to whoever needs it.

Requirement four: vantage point#

The most expensive requirement and the most frequently ignored.

Restriction mechanisms operate inside specific networks. A measurement from another network proves the server is correct, not that the service is usable. A successful probe from a foreign data centre says nothing about what a user on a home ISP in the target region will see.

Hence an inconvenient corollary: one vantage point gives an observation, not an acceptance. A conclusion needs several independent operators — because, as covered separately, filtering is distributed and differs between networks.

If you have fewer independent points than required, the honest result is “observation with a stated limitation”, not “it works”. The difference is one of phrasing, but it prevents conclusions you later have to retract.

Walkthrough: one probe, four different conclusions#

The same failure, recorded four ways. Compare what each one lets you do next.

RECORD 1 — a verdict
  "does not work"
  → next step: unknown

RECORD 2 — a verdict with timing
  "does not work, 15.2 s"
  → next step: unknown, though clearly a timeout

RECORD 3 — with stages
  dns 15ms · tcp 41ms · tls 380ms · first byte 402ms · timeout
  → already visible: connection and handshake SUCCEEDED, it breaks later

RECORD 4 — with volume
  dns 15ms · tcp 41ms · tls 380ms · first byte 402ms
  received 16,384 B · stalled at 16,384 · no reset · 15.2 s
  → volume restriction, class identified, countermeasure known

All four records describe the same event. The first two support no action at all; the third narrows the area; only the fourth names the cause.

The difference in collection cost is zero — these quantities are available at probe time. The difference in value is decisive.

A numeric example: how many repetitions you need#

Restrictions are probabilistic, and a single observation says little. Simple arithmetic.

Repetitions Successes What can be claimed
1 0 nothing — coincidence is indistinguishable from a pattern
1 1 nothing — same
5 0 probably a restriction, but the sample is small
20 0 a restriction, provided the direct control passes
20 12 partial — more interesting than total failure

The last row is often the most informative: 60% success is neither “works” nor “does not work” but a sign of a probabilistic mechanism, or of a dependency on conditions that vary between attempts.

A pass/fail verdict destroys that picture entirely.

Three ways to fool yourself#

A single successful probe. Restrictions behave as temporary states and are probabilistic. One success is indistinguishable from coincidence. You need enough repetitions to speak about a proportion rather than a fact.

A probe without a control. Observing that “it does not work through the VPN” without also checking “it does not work directly either” fails to separate a channel restriction from the resource simply being down.

Confusing symptom with cause. “Slow” can be bandwidth throttling, a volume restriction during a slow phase, node overload, or a problem at the resource. Without recording bytes and per-stage timings they cannot be told apart.

What to record#

For each probe it pays to keep a vector rather than a verdict:

DNS time
TCP connect time
TLS handshake time
time to first byte
bytes received
byte at which the stream stalled
total time
failure class

A pass/fail verdict discards everything that lets one cause be distinguished from another. A week later it cannot be used to reconstruct what was observed.

Why compare a hostname against an address?#

A cheap and underrated technique is running the same probe twice: once by hostname, once directly by address.

By name By address Conclusion
fails succeeds name resolution is stalling on the server side
fails fails the cause is not name resolution
succeeds fails expected: the edge discards connections carrying an address instead of a name

The third row explains why simple reachability checks report dead hosts as alive — and why it is worth knowing in advance, so it is not mistaken for a finding.

Conclusion#

Measuring blocking is not “try it and see”. It is four requirements, each of which, when violated, yields a plausible but wrong answer:

sufficient volume, or volume restrictions stay invisible; seriality, or the probe measures itself; failure classification, or the result suggests no action; a vantage point inside the target network, or the result describes the wrong conditions.

A tool that violates any of them is not merely useless — it is dangerous, because it supplies confidence without grounds.

Terms#

  • Control measurement - a parallel probe over a route known not to be restricted, taken under the same conditions.
  • Seriality - repeating a measurement several times in a row, separating a persistent failure from a random one.
  • Failure classification - assigning a failure to a specific type instead of a generic “did not work” mark.

FAQ#

How many repetitions are enough?#

At least three. One measurement cannot separate failure from fluctuation, and two do not show which of the results is the outlier.

Why is a control measurement needed?#

Without one a failure admits two explanations: the route is broken, or the network is. The control separates them.

What should be recorded alongside the result?#

Time, network, carrier, client version and the volume transferred. Without those conditions the result cannot be compared with a future one.

Further reading#