What Counts as Proof That It Works

Connected and works are different claims. The thresholds below which a check proves nothing, and the minimum set of conditions under which a result can be believed.

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

What Counts as Proof That It Works

“I checked, it works” sounds like a fact. In practice the claim is almost always incomplete: it does not say what was checked, or at what volume. And the conclusion depends on volume: some restrictions cannot be detected by a small check at all, so it honestly reports success on a channel that is unusable.

Three different claims#

They get conflated, and most wrong conclusions start there.

Claim What is proved What is not proved
“It connected” the handshake completed that data will flow through it
“The page opened” a small volume passed that a large one will
“It works” needs qualification what volume, for how long, how many times

The first two checks are cheap and run automatically. They are useful, and they prove exactly what they prove.

The threshold below which a check is blind#

The key fact: there is a class of restriction that does not manifest below a certain volume.

The mechanism works like this: the connection establishes normally, the first kilobytes pass, and then transfer stops. The threshold is measured in tens of kilobytes.

bytes transferred
   │
16K├─────────╮
   │         │ ← goes no further
   │        ╱│
   │      ╱  │
   │    ╱    │
   0└──────────────────────► time
     ↑         ↑
   fast      that's it

Hence a consequence worth memorising: a check smaller than the threshold will report “works” on a completely unusable channel. A light page that opened, a successful health response, a short service reply — all of it fits inside the permitted allowance and therefore proves nothing.

The practical conclusion: a meaningful check transfers a volume well above the threshold — hundreds of kilobytes at minimum. That is not belt-and-braces, it is a necessary condition: otherwise you are measuring not the channel but its first few seconds.

Four dimensions of a check#

A proper check specifies four parameters, and all four change the result.

Volume. How much data was transferred. Separates “the handshake completed” from “a stream is flowing”.

Duration. How long the connection lived. Some restrictions key on time rather than bytes.

Concurrency. How many connections were open at once. A separate class of restriction reacts to the number of parallel sessions and never appears with one.

Repetition. How many times it was checked. A single result cannot distinguish a failure from a fluctuation.

A check that specifies one parameter out of four answers one question out of four.

The control: without it, you are measuring something else#

A separate mistake is measuring only the target channel.

If a check fails, that may mean the channel is broken — or that the network is bad, or the carrier is congested, or the test service itself is down. You cannot tell, because there is nothing to compare against.

NO CONTROL
target channel ──► slow  ⇒ conclusion: the channel is bad (?)

WITH A CONTROL
target channel ──► slow  ┐
ordinary path  ──► slow  ┘ ⇒ conclusion: bad network, channel is fine

target channel ──► slow  ┐
ordinary path  ──► fast  ┘ ⇒ conclusion: it is the channel

A control is a parallel measurement over a route known not to be restricted, under the same conditions. Without one, every result admits two explanations.

A numeric example#

The same line, four different checks. Watch the conclusion change.

Check Volume Result Conclusion
Health response ~1 KB ✓ 40 ms “works”
Light page ~12 KB ✓ 0.3 s “works”
256 KB file 256 KB ✗ stalled at 16 KB does not work
256 KB file, control 256 KB ✓ 1.1 s the network is fine

The first two rows are what most checks do. Both reported “works”. The third row shows the channel is unusable. The fourth proves the network is not to blame.

Two checks out of four gave the wrong answer — not through error, but through insufficient volume.

The minimum set#

What a check must contain for its result to be trustworthy:

Volume above the threshold. Hundreds of kilobytes, not units of them.

At least three repetitions. One result is an observation; three are evidence.

A parallel control measurement. Otherwise a failure is indistinguishable from a bad network.

Recorded conditions. Time, network, carrier, client version. Without them the result cannot be compared with a future one.

An explicit success criterion, set in advance. “256 KB transferred in under N seconds” is a criterion. “Seemed fine” is not.

What does a check not prove?#

An important limit: a successful check proves that things work at the moment of the check, on this network, for this route.

It does not prove they will work in an hour, on another carrier, or under a different load. Some restrictions engage on accumulated behaviour rather than instantly — and pass the check by starting later.

Hence the practice: a regular check beats a thorough one-off. Three measurements at different times tell you more than one detailed measurement.

Failure and degradation are different diagnoses#

Another distinction that the phrase “it does not work” erases.

Failure — the connection does not establish, or drops immediately. It presents identically at any load.

Degradation — the connection works, but worse: slower, with losses, with drops under load. It appears only above some threshold.

What is observed More likely failure More likely degradation
At small volume does not work works fine
At large volume does not work stalls or crawls
Repeatability consistent depends on time of day
Control channel may also suffer usually fine

The difference is practical: failure means the route is unusable and must be changed. Degradation may mean congestion, a bandwidth cap, or a problem on one specific segment — and often resolves without changing the route.

A check consisting of a single light request does not distinguish the two at all: under degradation it reports “works”, under failure “does not work”, and both answers are useless for deciding what to do.

Conclusion#

The difference between “it connected” and “it works” is measured not in quality but in volume.

One rule covers most of the mistakes: a check smaller than the threshold proves nothing. It will return a positive result on a channel unusable for real work — and return it honestly, because within its own volume the channel really did work.

Terms#

  • Volume threshold - the number of bytes below which a whole class of restrictions never manifests.
  • Success criterion - a measurable condition, set in advance, by which a check counts as passed.
  • Degradation - a working connection with worsened characteristics, as opposed to outright failure.

FAQ#

Why does “the page opened” prove nothing?#

Because a light page fits inside the permitted allowance. A restriction that engages after the first kilobytes never appears in it.

What volume counts as sufficient?#

Hundreds of kilobytes at minimum — well above the threshold below which a check is blind.

How many times should a check be repeated?#

At least three, at different times. A regular check tells you more than a single thorough one.

Further reading#