The check says a site is unreachable but I can open it in another tab. Why?

Browsers restrict cross-origin requests. A site that loads normally when you navigate to it can still refuse a background request from another page, and the browser reports that refusal to us as an ordinary failure. Treat a single failure with everything else passing as inconclusive.

Is this the same as a down detector?

No. Down detectors aggregate reports from many users to judge whether a service is broken globally. This runs once, from your device. If everything here fails, the answer is almost certainly local, which is the useful thing it can tell you.

Why do you not test more sites?

A short curated list of large, well-connected providers answers the question. A long list turns the page into a request generator against third parties for no additional diagnostic value.

Can I use this to check whether a site is blocked in my country?

It is not built for that and it will mislead you. A blocked site and a CORS refusal look identical from inside a browser. Censorship measurement needs purpose-built tools that distinguish DNS tampering, TCP resets, and TLS interference, and those exist and are better at it.

Does the check send anything to my network administrator?

No. The requests go from your browser to the listed services, exactly as any web page request would. Nothing is reported to us or anyone else. Your own network can of course see the traffic, as it can see all your traffic.

Can I Reach It?

Test from your own browser whether major services answer, to tell a local network problem apart from a site being down.

Every request below leaves your browser, not our servers. Nothing is sent to us and nothing is stored.

Endpoint	Result	Elapsed	What it is
Googlehttps://www.google.com/generate_204	Waiting	—	The endpoint Android uses to detect a captive portal. Empty body, so the timing is close to the connection cost.
Cloudflarehttps://cloudflare.com/cdn-cgi/trace	Waiting	—	Cloudflare edge diagnostics. Answers from whichever Cloudflare location your network routes to.
GitHubhttps://github.com/favicon.ico	Waiting	—	A small static asset on the GitHub origin.
Microsofthttps://www.msftconnecttest.com/connecttest.txt	Waiting	—	The endpoint Windows uses for its own network check.
Applehttps://captive.apple.com/hotspot-detect.html	Waiting	—	The endpoint iOS and macOS use to detect a captive portal.
Wikipediahttps://www.wikipedia.org/static/favicon/wikipedia.ico	Waiting	—	A static asset served by the Wikimedia CDN.
jsDelivr CDNhttps://cdn.jsdelivr.net/npm/preact@10.29.0/package.json	Waiting	—	A public package CDN. Blocked in some corporate networks that filter script sources.
unpkg CDNhttps://unpkg.com/preact@10.29.0/package.json	Waiting	—	A second public package CDN, on a different network from jsDelivr.
Google over IPv6IPv6 onlyhttps://ipv6.google.com/generate_204	Waiting	—	This hostname publishes AAAA records only, so a success proves your IPv6 path works end to end.
icanhazip over IPv6IPv6 onlyhttps://ipv6.icanhazip.com/	Waiting	—	A second IPv6-only hostname, on a different network, so one operator cannot decide the answer.

Timing includes DNS, the connection, TLS and the response, so it reads much higher than a ping. Requests use mode: 'no-cors' with a 5 second timeout, so the browser hides the response and we only learn whether it arrived.

The endpoints, and why each one is on the list

Endpoint	Address family	Why it is here
Googlehttps://www.google.com/generate_204	IPv4 or IPv6	The endpoint Android uses to detect a captive portal. Empty body, so the timing is close to the connection cost.
Cloudflarehttps://cloudflare.com/cdn-cgi/trace	IPv4 or IPv6	Cloudflare edge diagnostics. Answers from whichever Cloudflare location your network routes to.
GitHubhttps://github.com/favicon.ico	IPv4 or IPv6	A small static asset on the GitHub origin.
Microsofthttps://www.msftconnecttest.com/connecttest.txt	IPv4 or IPv6	The endpoint Windows uses for its own network check.
Applehttps://captive.apple.com/hotspot-detect.html	IPv4 or IPv6	The endpoint iOS and macOS use to detect a captive portal.
Wikipediahttps://www.wikipedia.org/static/favicon/wikipedia.ico	IPv4 or IPv6	A static asset served by the Wikimedia CDN.
jsDelivr CDNhttps://cdn.jsdelivr.net/npm/preact@10.29.0/package.json	IPv4 or IPv6	A public package CDN. Blocked in some corporate networks that filter script sources.
unpkg CDNhttps://unpkg.com/preact@10.29.0/package.json	IPv4 or IPv6	A second public package CDN, on a different network from jsDelivr.
Google over IPv6https://ipv6.google.com/generate_204	IPv6 only	This hostname publishes AAAA records only, so a success proves your IPv6 path works end to end.
icanhazip over IPv6https://ipv6.icanhazip.com/	IPv6 only	A second IPv6-only hostname, on a different network, so one operator cannot decide the answer.

8 dual-stack endpoints.2 IPv6-only endpoints.5 second timeout each.No request touches our servers.

This is not a censorship measurement

A browser collapses every network failure into one opaque error. A DNS answer that was tampered with, an injected TCP reset, a TLS handshake that was interfered with, a corporate proxy rule and a cross-origin refusal all arrive here as the same thing. Calling any of them blocking would be a guess dressed up as a measurement.

Real censorship measurement needs to see the DNS answer, the reset packet and the TLS record, which a page cannot. Projects such as OONI and Censored Planet do that with purpose-built clients. Where the answer matters, use those instead of this page.

Using it to isolate a problem

The value of this page is the pattern, not any single row.

Everything fails. Look at your own connection first: Wi-Fi, the router, and any captive portal. Also check whether a content blocker is stopping the requests, since that failure looks the same.
One provider fails, others pass. Likely that provider, or DNS filtering aimed at it. Confirm with a DNS lookup for the same name on /dns-lookup.
Everything passes but one website will not load. The problem is that website, its DNS, or its certificate. Check the name on /dns-lookup and the certificate on /ssl-checker.
Everything passes slowly. Congestion. Run the speed test and the ping test to see whether it is throughput or latency.

What this deliberately is not

It is not a censorship measurement tool. Detecting deliberate blocking requires distinguishing DNS tampering, injected resets, and TLS interference, and a browser cannot see any of those; the Fetch API collapses every failure into one opaque error. Presenting a failed fetch as evidence of blocking would be guessing, and in places where the answer matters, guessing is worse than saying nothing.

About this tool

Your browser makes a small request to each of several widely used endpoints, including Google, Cloudflare, GitHub, and a few CDNs, and the page reports which ones answered and how long each took. Every request starts in your browser, on your network, so the result describes your connection rather than ours. A browser cannot see why a request failed, so one failure alone is inconclusive.

How to read the result

Reachable, with a time: The request completed and a response arrived. The time includes DNS resolution, connection setup, TLS, and the response itself, so it is larger than a ping figure and not comparable to one.
Blocked, or timed out: Blocked means the request failed straight away, and timed out means nothing came back within five seconds. Past that split we cannot say more, because the Fetch API deliberately hides the detail from pages, so a DNS failure, a TCP reset, a TLS error, and a network filter all surface as the same generic error.
All reachable: Your connection works and DNS resolves. If one site still will not open while everything here passes, the problem belongs to that site or to a DNS entry specific to it.
None reachable: Either your connection is down, a captive portal is intercepting requests and wants you to log in, or an extension or filter is blocking cross-origin requests from this page. The last case is common and looks identical to an outage from inside the browser.
Mixed results: One provider failing while the others pass points at DNS filtering, a network policy, or a regional problem at that provider. Everything slow but still working points at congestion.
Measured from your browser: This check runs on your device and is subject to CORS, extensions, and cache, so a failure here is not proof that a service is down for anyone else. It is a local diagnostic, not a status page.

Questions people ask

The check says a site is unreachable but I can open it in another tab. Why?: Browsers restrict cross-origin requests. A site that loads normally when you navigate to it can still refuse a background request from another page, and the browser reports that refusal to us as an ordinary failure. Treat a single failure with everything else passing as inconclusive.
Is this the same as a down detector?: No. Down detectors aggregate reports from many users to judge whether a service is broken globally. This runs once, from your device. If everything here fails, the answer is almost certainly local, which is the useful thing it can tell you.
Why do you not test more sites?: A short curated list of large, well-connected providers answers the question. A long list turns the page into a request generator against third parties for no additional diagnostic value.
Can I use this to check whether a site is blocked in my country?: It is not built for that and it will mislead you. A blocked site and a CORS refusal look identical from inside a browser. Censorship measurement needs purpose-built tools that distinguish DNS tampering, TCP resets, and TLS interference, and those exist and are better at it.
Does the check send anything to my network administrator?: No. The requests go from your browser to the listed services, exactly as any web page request would. Nothing is reported to us or anyone else. Your own network can of course see the traffic, as it can see all your traffic.

Last reviewed 2026-09-05.