Every managed network — a campus, an office, a hotel Wi-Fi, an ISP under regulatory order — blocks some sites. From the user’s seat it looks the same: you type an address, and instead of the page you get a spinner, a timeout, or a grey error notice. Underneath, there are three completely different mechanisms at work. Knowing which one is in play explains why some approaches route around it and others do not.
None of this is exotic. It is the same handful of tools, deployed by network administrators managing bandwidth, policy, or compliance obligations. Let’s look at each.
Three ways a network filters a site
The first and most common is a DNS block. When your device requests youtube.com, it asks the network’s DNS server for the matching IP address. A filtered DNS server simply lies — it returns nothing, or the address of a “blocked” landing page. The site is still online; your device just cannot look up the address.
The second is an IP or firewall rule. Here the network knows the real address and refuses to carry traffic to it. This is heavier to run and more thorough, because it does not matter how the device resolves the name — the network path itself is closed.
The third is inspection of the connection itself, often called deep packet inspection (DPI). The simplest form reads the destination hostname (the SNI field) out of the TLS handshake and drops or resets the connection. Many commercial firewalls and secure web gateways can do this, and national filtering systems use it too. The heavier form, TLS inspection, decrypts the traffic entirely; it only works on devices that have the organisation’s own root certificate installed, which is common on managed work laptops and some school devices.
All three are usually driven by category lists: the filter vendor sorts sites into categories such as “social media”, “games” or “proxies and anonymisers”, and the administrator ticks the categories to block. That last category matters here, because it is aimed at sites like the one you are reading.
How to tell which one is in play
Diagnosis usually takes about a minute. If the page fails instantly with a “server not found” message, DNS is the likely cause. If it hangs and eventually times out, an IP rule or a dropped connection is more likely. If you get a branded “this site is blocked” page, the filter is announcing itself, and its category name often tells you why. A single lookup from a terminal tells you a lot:
# See what the network resolves youtube.com to
nslookup youtube.com
# A filtered network often returns 0.0.0.0
# or the IP of a "blocked" landing pageIf that command returns an address like 0.0.0.0, DNS filtering is in play — the simplest of the three to route around.
The methods, side by side
| Method | Cost to run | Proxy routes around? |
|---|---|---|
| DNS block | Low | Yes, if the proxy’s domain is not blocked |
| IP / firewall rule | Medium | Yes, if the proxy’s addresses are not blocked |
| Hostname (SNI) inspection | Medium to high | Yes, if the proxy’s hostnames are not blocked |
| TLS inspection on a managed device | High | Not privately: the organisation can read the proxied pages |
The destination site was never offline. The filter simply sits between the request and the response — and a proxy shifts the request path to somewhere the filter does not cover.
What each layer stops
Changing DNS servers routes around DNS-level blocks, but not IP rules. A full VPN routes around both DNS and IP filtering, but requires an application install that is unavailable on many managed devices. A web proxy operates at the browser-tab level: because the request is made from the proxy’s servers, a network without TLS inspection sees an encrypted connection to the proxy, not the destination. It still sees that you used a proxy, and can log it.
Each layer has a matching tool. The right one depends on the block type in front of you, the device you are on, and the network’s rules: many school and workplace acceptable-use policies forbid proxies by name, and breaking them can have consequences even when the page loads.