Your VPN Check Says Timeout but the Connection Works — and Vice Versa
A familiar picture: half the servers in the list are marked unreachable, you connect to an “unreachable” one, and everything loads. Or the opposite — every indicator is green and pages will not open. Both cases mean the same thing: the checker and real use are measuring different quantities, and the indicator can be wrong in either direction.
This is not a bug in a particular app. It follows from how the built-in check is built and how modern traffic-restriction mechanisms work. They measure different things.
What does the built-in check do?#
Almost every client uses the same trick: send a lightweight HTTP request through the connection and time the response. Usually the target is a service endpoint such as generate_204, which by design returns an empty response with no body.
Roughly one to two kilobytes cross the connection. The check answers one question: did a connection establish and return headers quickly.
That is a reasonable check for a world where a connection either works or does not.
Why that stopped being enough#
Modern restriction mechanisms do not work on a pass-or-drop basis. They count.
Cloudflare publicly described behaviour observed in Russia from 9 June 2025: a connection is allowed to load only the first ~16 KB of any resource, after which data stops flowing. The connection stays open — no reset, no error message. It affects HTTP/1.1, HTTP/2, and HTTP/3 over QUIC alike.
Put the two numbers side by side:
| Volume of the built-in check | ~1–2 KB |
| Threshold where the stream stalls | ~16 KB |
An order of magnitude apart. A connection that will freeze at the sixteenth kilobyte passes the built-in check with excellent latency and earns a green mark.
Symptom one: red but working#
The inverse case is more common and less alarming.
The check marks servers unreachable because it fires many requests to many servers at once — it refreshes the whole list. Some restriction mechanisms react to exactly that shape: several simultaneous TLS connections to one address inside a short window look nothing like browser behaviour.
The result is that the check provokes, through its own bulk polling, the very restriction it is trying to detect. It measures itself rather than the network.
After a pause you connect to one server, over one connection, and it works.
Symptom two: green but broken#
This one is more dangerous, because it raises no suspicion.
Every indicator is green — the check passed on its kilobyte and a half. You open a page and it loads halfway. A video starts and freezes after a few seconds. A download reaches a certain size and stops.
The identifying trait: failure arrives after a volume, not immediately. The first bytes come through fine.
How to check for yourself#
The built-in check cannot be trusted here. You need a probe that pulls enough data.
Practically: download a file comfortably larger than a megabyte through the connection and see whether it completes. Any public test file will do. What matters is not the speed but whether it finishes.
If the download consistently stops around the same size, you are watching a volume restriction, not a server problem.
Walkthrough: how the two cases look side by side#
The difference is clearest when two downloads of the same file are placed on one timeline.
Normal download
bytes 0 ─────────────────────────────────────────► 2 MB
▲ ▲ ▲ ▲
0.1s 1.2s 2.4s 3.8s complete
Volume restriction
bytes 0 ────────►│ (silence)
▲ ▲ ▲
0.1s 0.4s 15s+ timeout
└── 16,384 bytes, stream stalled
connection NOT reset
The decisive difference is not speed but the fact that in the second case the connection stays open. No reset, no error — the data simply stops arriving.
That is exactly why a browser shows an endlessly spinning indicator instead of an error message: as far as it is concerned, the download is still in progress.
A numeric example: why the check cannot see the problem#
Take concrete quantities and count.
| What happens | Bytes |
|---|---|
| Secure connection handshake | ~4,000 |
| Request to the service endpoint | ~200 |
204 No Content response — empty body |
~150 |
| Total across the connection | ~4,350 |
| Threshold where the stream stalls | ~16,000 |
The check finished a quarter of the way to the threshold. It physically could not reach it — and reported success.
Now the same arithmetic for a proper probe:
| What happens | Bytes |
|---|---|
| Handshake | ~4,000 |
| Downloading 256 KB | ~262,000 |
| Total | ~266,000 |
The threshold is passed sixteen times over. If a restriction exists, the probe will meet it and record the byte at which the stream stalled.
Hence the margin rule: a probe should not be “slightly above the threshold” but an order of magnitude above it, because the threshold itself was observed by different people as a range rather than an exact number.
What to distinguish when something “does not work”#
Separating symptoms is worth the effort — they point at different causes and have different fixes:
| Symptom | What it resembles |
|---|---|
| Connection never establishes | restriction by address |
| Connection drops right after establishing | interference at the handshake |
| First kilobytes arrive, then silence | volume restriction |
| Speed is sharply reduced but everything works | bandwidth throttling |
| Only some sites fail to open | restriction by name, not by channel |
The last row matters: if one specific site will not open through the VPN while everything else works, the problem is most likely not the VPN at all.
What this means in practice#
Do not trust the indicator colour in either direction. A red server is worth trying. A green one is worth verifying with a real download if behaviour is strange.
Do not refresh the whole server list when something is broken. Bulk polling makes things worse for several minutes. Try one server and give it time.
Watch volume, not speed. “Slow” and “stops at a specific point” are different diagnoses.
Summary: indicator, meaning, action#
| What the indicator shows | What it can mean | What to do |
|---|---|---|
| Red on one server | the test request failed, though the server may work fine | connect and check with volume |
| Green | a small volume passed, the restriction simply did not appear | transfer hundreds of kilobytes |
| Red on every server | a problem in the network, the carrier or name resolution | check a control route |
| Green but pages will not load | the restriction engages after the first kilobytes | change route, not client settings |
The “what to do” column matters more than the first two: it turns the indicator from a verdict into a hint about where to start checking.
Conclusion#
The built-in connection check was designed when filtering was binary: an address was reachable or it was not. Today it measures a quantity that has stopped being decisive.
That does not make the check useless — it still catches unreachable addresses and resets. But its green mark is no longer proof that a connection works, and its red mark is no longer proof that one is broken.
The rule is simple: a probe must measure the quantity by which the network actually breaks. If the restriction counts kilobytes, the probe has to send them.
Terms#
- Built-in check - a short test request a client uses to judge server reachability before connecting.
- Volume freeze - a restriction where the connection establishes, passes the first kilobytes and then stalls.
- False negative - the check reports a server unreachable when it is in fact working.
FAQ#
Can a red indicator be trusted?#
No. A red status means one specific test request did not complete, not that the server is unreachable. Test by connecting instead.
Why does a green indicator not guarantee it works?#
Because the test request carries too little data. Restrictions that engage after the first kilobytes never appear inside it.
How do you check a server properly?#
Transfer a deliberately large volume — hundreds of kilobytes — repeat it several times, and compare against a route known to be reachable.
Further reading#
- Whitelists: What They Are and Why They Change
- Why Blocking Hits One User and Not Another
- Measuring Blocking Correctly
- Walk the route from setup to diagnosis in the GigaTap VPN guides.
- Pick your next step with the VPN start helper.
- Device-specific profile import lives in the client setup hub.