Our own measurements

What opens from where

Once a day each of our nodes — in Amsterdam, Frankfurt, Istanbul, Tokyo and Hong Kong — opens two dozen popular services and records what answered and how fast. This is not a retelling of someone else’s reports: it is what we measured ourselves, with a date and a list of points.

Five points are five points, not a map of the world. What follows from that is explained below.

Loading the measurements…

How to read this table

A row is a service, a column is one of our servers. A cell holds what the service answered that server: the status code and the latency, or the reason there was no answer. What matters is not a single cell but the whole row.

What the row showsWhat it means
200 everywherethe service is alive and reachable from everywhere we have eyes
403 everywherethe service rebuffs requests from data centres — that is its own rule, not blocking
one point silent, the rest 200the most informative picture: this is what regional blocking looks like
one point several times slowera bad route from that node, not a fault in the service

What is not here

The word "blocked" does not appear here — not out of cautious wording but out of precision. Our node stands in a data centre, while filtering is set up on the path to home and mobile internet: it can fire for a resident of the country and not fire for a server in the same country. The reverse happens too. So the table answers the question "what does our server see from there", not "what does a person see from there" — and the second does not follow directly from the first.

A summary picture by country, assembled from public sources, is on the blocking map. To check your own site from these points, go here.

Service will not open for you?

If the table shows it alive and you cannot reach it, the problem is the road to it. That is exactly what a VPN fixes.

How it works →

FAQ

guest@404vpn:~$ cat live-reach-faq.md
[01] $ Is this a blocking map?
> No, and calling it that would be an overstatement. Blocking fires on the path from a local resident to a service, while our node stands somewhere else on that path — in a data centre in the same country, or even a neighbouring one. We show exactly what we measured: from such a server of ours, such an address answered like this. For a full picture by country there is a separate page assembled from public sources.
[02] $ Why does ChatGPT refuse from every point?
> Because many services rebuff requests from data centres — and that is exactly where our nodes are. A 403 in such a row means "the site did not want to talk to a server", not "the site is blocked". You can tell by the fact that the refusal arrives identically from everywhere: blocking does not behave that way.
[03] $ What does "no answer" from one point and 200 from the rest mean?
> That is the most informative row in the table. The service is alive — four nodes out of five opened it — but from one particular network it is unreachable. That is what regional blocking looks like. To be sure, watch whether it repeats day after day: a one-off network glitch looks the same, which is why we re-check every failure with a second request right at measuring time.
[04] $ How often is the data updated?
> Once a day. More often makes no sense: blocking does not change hourly, and extra requests load both other people’s services and our own nodes. The date of the last sweep is at the top of the page — if it is old, the sweep did not run, and we show that rather than serving yesterday as today.
[05] $ Will you add countries?
> Yes, as the network grows: every new node automatically becomes a new vantage point, and no separate page is needed for it. The most valuable points are inside countries with real filtering — there the difference between rows means something real.