Managed networks block things. That is their job, and this article is not about getting around it. It is about telling the difference between "this network will not let me reach it" and "this service is broken for everyone", because the two look similar and lead to completely different next steps.
The distinction matters most when you are the one who has to report it. Telling a vendor their service is down when your school firewall is blocking it wastes everyone's afternoon.
Blocks and outages fail differently ¶
A block is a decision made by something close to you. It is fast, deliberate and consistent. An outage is an absence of an answer somewhere far away. It is slow, and it varies.
| Signal | Administrative block | Real outage |
|---|---|---|
| Time to fail | Instant, well under a second | Seconds, often the full timeout |
| Consistency | Identical every attempt | Varies, sometimes works |
| Other sites | Fine, except similar categories | Fine |
| On mobile data | Works | Fails the same way |
| Error shown | Block page, reset, or NXDOMAIN | Timeout or 5xx |
The mobile data row is the decisive one. Turn Wi-Fi off, load the page over cellular. If it works, no outage is involved, and the full Wi-Fi versus mobile data walkthrough covers what to check next.
What each failure mode tells you ¶
A branded block page
Unambiguous. Some appliance terminated the request and told you so. Nothing else to diagnose.
NXDOMAIN, or a redirect to a search page
DNS filtering. The resolver refused to answer, or answered with an address that is not the site. Compare against a public resolver: dig @1.1.1.1 example.com +short. If the public answer is a real address and yours is not, the filtering is in DNS. Our DNS lookup shows the authoritative record for comparison. See also DNS_PROBE_FINISHED_NXDOMAIN.
Connection reset, immediately, on HTTPS only
Deep packet inspection reading the server name from the TLS handshake and killing the connection. Plain HTTP to the same host often behaves differently, which is itself the tell. This is the signature of a filtering appliance rather than a broken server. ERR_CONNECTION_RESET covers the same error from the other direction.
Connection refused, instantly
Something on the path sent an active rejection. On a managed network this is usually a firewall rule on a port rather than a domain, which is why non-standard ports break while ordinary browsing works.
A slow timeout with no response
This is the one that is genuinely ambiguous, because both a silent firewall drop and a dead server look identical from your chair. Resolve it from outside: run a multi-method check. Probes from our infrastructure are not behind your firewall, so if all four succeed the site is up and your network is dropping the traffic silently.
HTTP 403 from the site itself
Not a network block at all. The server answered, and refused. Shared or institutional IP addresses get rate-limited and blocked by origins and their CDNs, which is what Cloudflare Error 1020 usually means. The fix is with the site operator, not your network team.
What to do with the answer ¶
If it is a block, the useful action is a request to whoever runs the network, with the domain and the failure mode. If it is an outage, check the vendor's status page and our live outages page, then wait; there is nothing to fix at your end.
Either way, you now have evidence rather than a guess, which is the entire point of spending sixty seconds on it.
What TLS makes visible, and what it does not ¶
Filtering appliances have to identify a destination before they can decide about it. With HTTPS the URL is encrypted, but the hostname historically is not: it travels in clear text in the Server Name Indication field of the TLS handshake, which is what most SNI-based filtering reads.
This explains a failure that otherwise looks impossible. The connection is established, TLS begins, and then it is killed mid-handshake, so you get a reset rather than a block page. Nothing at the HTTP layer was ever exchanged, which is why there is no error message to read.
Encrypted Client Hello changes this by encrypting the name too, and networks that filter on SNI increasingly block connections that use it rather than allow what they cannot inspect. If a site fails on one browser and works on an older one, this is a candidate.
Two commands that settle it ¶
If you can reach a terminal, these separate DNS from the connection in about ten seconds each.
- Does the name resolve honestly?
dig @1.1.1.1 example.com +shortagainstdig example.com +short. Different answers mean DNS filtering. - Does the connection survive?
curl -sS -o /dev/null -w "%{http_code} %{time_total} " https://example.com. A fast non-zero exit is a decision. A slow one is silence.
The timing in that second command is the whole diagnosis in one number. Under a tenth of a second means something nearby answered.
What to send the people who run the network ¶
A request that gets acted on contains evidence rather than frustration:
- The exact hostname, not the product name.
- The failure mode and how long it took.
- Confirmation the destination is up, which is what a multi-method check gives you in a form you can link to.
- What it is for, in one sentence. Most block lists are category-based and over-broad rather than deliberate, and "this is our payment provider" resolves more tickets than any amount of technical detail.