How a check works

A check answers one question per provider: can this provider's customers open this URL right now, and if not, what stops them? Here is what happens between your request and that answer.

In short: we open your page through real customers' home and mobile connections on each provider, let that provider look up your domain the way it does for its customers, and compare what comes back with a clean connection from a datacenter. If our own test connection breaks, we throw the result away instead of blaming your site. We call a page blocked only when we see the block on at least 3 different customers' connections. The rest of this page is the detail, written for developers.

1. Your URL becomes cohorts

You send a full URL and one or more targets: a country, optionally an operator and a connection type. We expand that into cohorts: one cohort is one operator (internet provider) on one connection type, and its result is what the rest of the site calls one answer. {"country": "DE"} becomes six cohorts: Telekom, Vodafone and O2, each on home broadband and on mobile. Every cohort gets its own result. Results are never averaged into one percentage: you see, for example, "blocked on Telekom, fine on O2".

2. Real subscriber connections, chosen by network

Each cohort is measured through exits that sit on that operator's network: home routers and phones of real subscribers, reached through residential and mobile proxy networks. We pick exits by their network number (ASN), not by the label a proxy seller gives them, and we record the country, network and subnet of every exit we use.

Datacenter servers are used only as controls: they tell us what the page looks like when nothing is in the way.

3. DNS is resolved where the subscriber is

Most ISP blocks in Europe live in the operator's DNS resolver. If the name were resolved on our side, the block would be invisible. So the name always goes to the exit as a name, and the exit's own resolver answers. That is the natural path, the same one a browser on that line takes.

Where we have verified the address of an operator's resolver, we also ask it directly through the exit (explicit path) and connect to the address it returned, with your host name in TLS and HTTP. Mobile operators often use internal resolvers that cannot be addressed this way, so on every mobile network we rely on the natural path: we see only the answer the customer's phone got, and a DNS block there is marked at most likely.

4. Every measurement is bracketed by an echo

Right before opening your URL, the exit calls our echo server; right after, it calls it again. Both calls tell us which public address, network and country the exit really used. If anything changed in between, the exit moved and the measurement is discarded as proxy_failure with the reason exit_changed. If the exit could not reach our echo server at all, the failure is ours, not yours.

Then the failures are compared across exits:

• a failure that follows our proxy provider across several operator networks is a vantage problem;
• a failure that stays inside one operator's network across independent exits and pools is the operator;
• a failure everywhere, our datacenter controls included, is target_down: your site is down, not blocked;
• a refusal by your own anti-bot or geo rules is target_policy, not censorship.

5. Layers, in order

For each exit we look at the steps a browser goes through and stop at the first one that fails: DNS answer, TCP connection, TLS handshake (and whether the certificate is really yours), HTTP response. A blocked result always names the layer and the method, for example dns.redirect or tls_mitm.substitution. Answers are compared with our controls and with a catalogue of known operator notice pages.

6. Minimum evidence

We do not call a site blocked on one data point. A blocked verdict needs at least 3 different subscribers in at least 2 subnets of the operator. An ok needs at least 2 subscribers and clean controls. When there are not enough exits for a cohort, you get not_measured with the reason, not a green answer.

The confidence label says how direct the evidence is: confirmed needs a direct artifact such as a notice page or a forged DNS answer, likely is a consistent pattern without one, partial means exits disagree (the result says what share was blocked). While the system is uncalibrated, every result carries uncalibrated: true and no percentages.

7. Filters next to the verdicts

Some blocks are chosen by the user or by the user's DNS provider rather than by the operator. On every check, from our own servers, we ask DNS4EU, CleanBrowsing, Cloudflare for Families, Quad9, AdGuard and OpenDNS whether they filter your name. Where an operator sells an optional filter, we look for subscribers who have it on and report them as a separate group. As of 11 November 2026, this works for Telenor Nettvern+ (that group's result is at most likely), but not for Vodafone's and O2's optional security filters: we have not found such subscribers, so that group is reported as not_measured. We also look your URL and domain up in Google Web Risk, check Chrome's lookalike-domain rules and read Google's Ad Experience Report. None of this changes the operator verdict; it sits next to it.

What a check does not see yet

• The red warning pages a real Chrome or Edge shows, including SmartScreen and Chrome's on-device phishing model. We check the lists behind them; a browser-based check is being built.
• Cloudflare's "Suspected phishing" interstitial.
• Whether an expected text is present on the page. content checks are in the API contract but not available yet; they are being built.
• QUIC/HTTP/3, Encrypted Client Hello and throttling.
• Regular measurement of home broadband in Norway. Norwegian home lines can be requested, but are measured only when we have a suitable test connection at the time; otherwise the answer is not_measured.

In the result, coverage lists the layers that were checked and those that were not; the first four items above appear there as unchecked. If the most important layer for that country was not checked, it is also named in coverage_gaps, and an ok is then shown yellow instead of green. So a yellow or missing answer always has a stated reason.

Last updated 11 November 2026.

Verdict reference · API quickstart