How ISPs actually block websites: DNS, HTTP, SSL and DPI
There's no single button an ISP presses to "block" a domain. There are about four or five of them, and most serious ISPs use a combination. This article walks through how each method actually works on the wire — and, just as importantly, how each one looks from the outside, which is what matters if you're trying to detect blocks instead of just complain about them.
1. DNS-based blocking
This is the oldest trick in the book, and still the most common. The ISP's DNS resolver just lies to you. Your browser asks "what's the IP for example.com?", and instead of the real answer, it gets something else — usually an IP that hosts a regulator's "this site has been blocked" page, or an NXDOMAIN that makes the browser show a generic error.
The flow
- 1. User types example.com
- 2. Browser asks the ISP resolver
- 3. Resolver checks its blocklist
- 4. Returns a fake IP or NXDOMAIN instead of the real record
- 5. User sees a block page or "can't reach this site"
You'll see a few flavors of this. Sometimes it's plain DNS poisoning — the resolver hands back a specific IP belonging to the regulator. Sometimes it's NXDOMAIN injection, which is sneakier because the browser just says "site not found" and most users assume the site is down. And sometimes it's sinkholing, where the query is redirected to a controlled server that quietly logs who tried to reach what.
Detecting this is straightforward in principle — ask the authoritative nameservers, ask the ISP resolver, compare the answers. In practice you also need a database of known regulator IPs per country, because a "different" IP isn't necessarily a block; it could just be GeoDNS.
2. HTTP-level filtering
Less relevant than it used to be, because almost nothing is plain HTTP anymore — but it still matters for legacy traffic, fallbacks, and the handful of weird embedded devices that never got TLS. The ISP middlebox sees the Host header or URL in cleartext and either tears down the connection or injects a redirect.
URL / Host filtering
The middlebox reads the HTTP request headers, matches against a blocklist, and drops or resets the connection if it hits. Only works when the traffic is unencrypted.
Response injection
The ISP races the real server and sends back its own 302 first. The user gets bounced to a government warning page long before the origin has a chance to respond.
Detection here is mostly about pattern-matching regulator block pages in response bodies, plus watching for unexpected 3xx responses that didn't come from your servers.
3. TLS certificate inspection
HTTPS closed the door on cleartext HTTP filtering, so regulators found another one. During the TLS handshake the server sends its certificate, and in TLS 1.2 that certificate is transmitted before the secure channel is fully established — meaning anyone sitting on the wire can read the CN and SAN fields. That's enough to make a blocking decision.
What happens on the wire
- 1. Client sends ClientHello
- 2. Server responds with its certificate
- 3. DPI device reads CN / SAN from the cert
- 4. If any of them matches the blocklist, it injects TCP RST packets
- 5. Browser shows ERR_CONNECTION_RESET or a timeout
This one is particularly annoying for site owners because there's no block page, no error message, nothing — just a reset in the middle of a handshake. Users don't report it well ("the site was weird, I dunno"), support teams can't reproduce it from the office, and if your monitoring doesn't specifically check for it, you'll never see it at all.
We detect this by looking at exactly when the RST arrives. A reset right after ServerHello, from specific ISP networks, that doesn't happen from other ISPs in the same country — that's the signature.
4. Deep packet inspection (and SNI filtering)
DPI is the umbrella. The interesting specific case is SNI filtering: even with HTTPS, the ClientHello contains the Server Name Indication field in plaintext — that's how the server knows which virtual host you want. DPI reads that field and makes a decision before the handshake even gets to the certificate stage.
Beyond SNI, DPI can match on protocol fingerprints, traffic shape, or specific byte patterns in known services. Russia's TSPU, China's Great Firewall, Iran and Turkey all use DPI at scale. The level of sophistication varies wildly between operators; one ISP's DPI might be a cheap appliance, another's might be nation-state-grade.
Encrypted Client Hello (ECH) is supposed to close the SNI hole, and it's slowly gaining traction — but adoption is still patchy, and regulators have been known to just block ECH negotiation entirely in response.
5. Plain IP blocking
The crudest version. The ISP drops packets to specific IPs, end of story. It catches the target but also everything else on that IP — shared hosting, CDNs, whole Cloudflare ranges. You see the collateral damage more in countries with less sophisticated censorship infrastructure, where "just null-route the /24" is apparently acceptable.
Why you can't detect this by hand
Reading the list above you might think "OK, I'll just have someone in each country ping the site every morning." That almost works until the moment something goes wrong. A few reasons it isn't enough:
- Blocks flap — they appear and disappear within hours, especially around regulator update cycles.
- ISPs inside a single country disagree. Vodafone might block while TIM doesn't; neither knows about the other.
- The detection technique has to match the blocking technique. Ping is useless against TLS RST.
- You need to check from the same network as real users. A VPN exit node or a Frankfurt datacenter proxy doesn't count.
- The combinatorics explode. 30 domains × 40 countries × a handful of major ISPs each = thousands of probes you'd need to run continuously.
That's the job we automate. Checks run from residential ISP connections in 50+ countries, the detection logic is per-country (what DNS filtering looks like in Italy is not what it looks like in Kazakhstan), and when something breaks we tell your team within minutes instead of weeks.