When someone says “the site is blocked”, they are describing a symptom. Underneath that symptom sits one (or more) of four specific technical layers doing the blocking. Knowing which layer applies to your situation determines which countermeasure works. This cornerstone maps the four layers, gives an example of who uses each, and explains which defeat solves each layer.
Layer 1 — DNS filtering
The cheapest layer to deploy and the first line of most consumer-facing filters. When your device wants to reach youtube.com, it first asks a DNS resolver for youtube.com’s IP address. If the resolver is under filter policy, it lies — returns NXDOMAIN (domain does not exist), a block-page server IP, or nothing at all. Your device has no address to connect to, so it fails.
Who uses it: Most school Wi-Fi filters, hotel captive portals, many ISPs implementing government blocklists (Indonesia’s Kominfo, Pakistan’s PTA, Turkey’s BTK).
How to detect it: Change your DNS to Cloudflare 1.1.1.1 or Google 8.8.8.8. If the site loads, DNS filtering was the block. If not, you are hitting a deeper layer.
How a proxy defeats it: Your browser is asking the DNS resolver for anyproxy.site, not youtube.com. The resolver returns the real anyproxy.site IP because our domain is not on the filter list. Your device connects to us and we ask the destination on your behalf.
Layer 2 — IP-level blocking
More work to maintain but common at the ISP or firewall level. The filter drops packets destined for specific IP addresses. Changing your DNS does not help — even if you look up the destination correctly, the packets fail in transit.
Who uses it: National-level filters against known VPN provider IPs and social platform edge IPs. Enterprise firewalls category-blocking whole ranges. China’s Great Firewall against Meta, Google, X ranges.
How to detect it: Try connecting to the destination IP directly (bypass DNS entirely with a manual IP). If that fails on your network but works on cellular, IP blocking is likely.
How a proxy defeats it: Your packets go to our IP, not the destination’s. The intermediate network sees only traffic to us. Our server, on a different network, has no problem reaching the destination.
Layer 3 — Deep packet inspection (DPI)
Reads not just packet headers but payload contents. Identifies traffic by pattern — VPN protocol signatures, application fingerprints, even encrypted-connection metadata. Expensive to run at scale but hardware acceleration and machine learning have made it standard for major ISPs in filter-heavy countries.
Who uses it: China’s Great Firewall, Iran’s national filter, Russia’s Roskomnadzor, enterprise Zscaler / Cloudflare Gateway / Palo Alto Prisma.
How it identifies traffic: WireGuard, OpenVPN, IKEv2 all have distinctive handshake patterns that DPI can match reliably. Even TLS traffic has “JA3” and “JA4” fingerprints that identify the specific client library. VPN traffic that has not been obfuscated is usually recognisable within one round trip.
How a proxy defeats it: A web proxy over ordinary HTTPS to a mainstream domain (like anyproxy.site) looks like normal web traffic. The TLS fingerprint is the same as any browser. The destination hostname (via SNI, see layer 4) is our proxy domain. DPI blocks that fingerprint VPN protocols do not catch HTTPS to a well-known web-service domain.
Layer 4 — TLS SNI inspection
The specific DPI technique that reads the TLS Server Name Indication field from the encrypted-connection handshake. SNI is sent in plaintext in the TLS ClientHello (the first bytes of every HTTPS connection) because one IP can host many HTTPS sites and the server needs to know which certificate to present. The filter reads the SNI hostname and applies policy.
Who uses it: All modern DPI-based filters — Great Firewall, Roskomnadzor, enterprise proxies. Some school and workplace filters as an upgrade over pure DNS blocking.
Why it matters: SNI is the single largest privacy leak in HTTPS. Even with TLS encrypting the request body, the destination hostname leaks in the handshake. ECH (Encrypted Client Hello) hides SNI but adoption is still limited in 2026.
How a proxy defeats it: The SNI your browser sends is for anyproxy.site (the proxy domain), not for youtube.com (the actual destination). The filter reads “anyproxy.site” and applies proxy-domain policy — which for most filters is “allow”, because generic web-service domains are not on hostname blocklists.
Which layer is filtering you right now?
Diagnosis in order of speed:
- Try public DNS (1.1.1.1). If the site loads, layer 1 (DNS) was the block. Done.
- Try connecting via IP directly (find the IP with a public DNS lookup, then use it in the URL). If that works, layer 2 (IP) was not blocking — probably layer 1.
- Try a mobile hotspot to bypass your current network entirely. If the site loads there, the block is on your local network (layers 1-4).
- Try a web proxy (like AnyProxy) from your original network. If that works, one of the deeper layers was blocking. Confirms you need proxy or VPN.
- If web proxy fails and mobile hotspot works — your local network specifically blocks the proxy domain. Uncommon. Escalate to a different proxy, VPN, or wait for network policy to change.
The layer stack per country
Different regimes use different combinations:
| Country | Layer 1 (DNS) | Layer 2 (IP) | Layer 3 (DPI) | Layer 4 (SNI) |
|---|---|---|---|---|
| China (GFW) | Yes | Yes | Yes (aggressive) | Yes |
| Iran | Yes | Yes | Yes | Yes |
| Russia (Roskomnadzor) | Yes | Yes | Yes | Yes |
| Turkey (BTK) | Yes | Occasional | Some | Some |
| Indonesia (Kominfo) | Yes | No | No | No |
| Pakistan (PTA) | Yes | Some | Growing | Some |
| Most schools | Yes | Yes | Depends on vendor | Depends |
| Most workplaces | Yes | Yes | Yes (Zscaler / Umbrella) | Yes |
See the internet-censorship-by-country-in-2026 cornerstone for country-specific deep dives.
Layer 5 — application-level filtering (bonus)
Not a network layer strictly, but worth naming. Some filters use HTTP header inspection (X-Forwarded-For, User-Agent), URL path pattern matching, or JavaScript-detection tests to filter after the connection is established. Corporate DLP (data loss prevention) systems also inspect encrypted traffic when a company root certificate is installed on managed devices, effectively performing MITM on TLS.
Web proxies mostly do not need to defend against layer 5 because the browser talks to the proxy over ordinary HTTPS — no unusual headers, no proxy-specific paths visible on the wire, no JavaScript tests before the tunnel connects. Application-level filtering typically kicks in after the proxy has already established the connection to the proxy domain.
Layer choice determines your escalation path
If you are debugging a “site not loading” problem, working through the layers in order (DNS → IP → DPI → SNI) is faster than throwing every countermeasure at once. On school networks, DNS + IP are usually the whole story; a web proxy is overkill but still the easiest fix. On national censorship networks, all four layers are active; a web proxy over HTTPS to a mainstream domain is a legitimate lighter-weight option than a full VPN when the goal is one blocked page.
For the specific how-tos on defeating each layer, see the help center. For the tool-selection question, see proxy vs VPN vs Tor decision framework.