How DPI blocks VPNs
A network that blocks VPNs is rarely doing one thing. It is running several detection methods at once, each cheap enough to apply to every connection, and a tunnel has to survive all of them to stay usable. This is what each one does.
Blocking is layered, not singular
It helps to think of a filtering deployment as a series of gates rather than a single wall. A connection is checked against an address list, then its protocol is classified, then its metadata is matched against rules, and then — possibly hours later — its endpoint may be probed to confirm what was running there. Defeating one gate means nothing if the next one catches you.
This also explains an experience many people find confusing: a tunnel that works perfectly for weeks and then stops without any change on your side. Nothing about your traffic changed. The endpoint was identified out of band and added to a list.
Gate one: protocol fingerprints
The oldest and cheapest method is to recognise a VPN protocol from its own handshake. Most VPN protocols were designed when the threat model was an eavesdropper, not a classifier, and they announce themselves clearly on the wire.
| Protocol | What gives it away | Difficulty to detect |
|---|---|---|
| PPTP / L2TP | Dedicated protocol numbers and fixed ports; the handshake is unmistakable. | Trivial |
| IPsec / IKEv2 | UDP 500 and 4500, with a distinctive IKE exchange. | Trivial |
| WireGuard | A fixed-size first handshake message with a constant type byte at a known offset, over UDP. | Trivial |
| OpenVPN | A recognisable opcode structure in its control channel, even in TCP mode on port 443. | Easy |
| Shadowsocks (original) | No handshake at all, which is itself unusual; early versions were also vulnerable to active probing. | Moderate |
| TLS-wrapped tunnels | Depends entirely on how faithfully the TLS is imitated; a mismatched handshake fingerprint is the usual tell. | Moderate to hard |
Gate two: the hostname in the handshake
For anything that presents itself as TLS, the next check is the Server Name Indication field — the hostname the client asks for, sent in the clear before encryption begins. It exists so that one server address can host many sites, and it is read by essentially every filtering system in operation.
- Blocklisting: the connection is dropped if the hostname appears on a list. This is how most site-level blocking works.
- Allowlisting: the connection is dropped unless the hostname appears on a list. Far more aggressive, used on some corporate and national networks, and much harder to work around.
- Consistency checking: the hostname is compared against the address it resolves to, or against the certificate the server presents. A mismatch is treated as suspicious.
Encrypted Client Hello is the standards-track fix for this: it encrypts the hostname so an observer cannot read it. Adoption is partial, it depends on DNS records the network may also control, and on some networks the mere use of it is itself a signal. It improves the situation; it does not close the gate.
Gate three: does the TLS look like a real browser?
Wrapping a tunnel in TLS is not enough if the TLS itself looks wrong. The client's opening message carries an ordered list of cipher suites, supported groups, signature algorithms and extensions. The exact combination differs between implementations — a Go program, an OpenSSL program and Chrome all produce recognisably different Client Hellos — and it can be hashed into a short fingerprint.
If a connection claims to be a browser talking to a web server but carries the TLS fingerprint of a Go networking library, that mismatch alone is enough to classify it. This is why serious implementations do not merely use TLS: they reproduce a specific browser's handshake byte for byte, and have to keep doing so as browsers change.
Gate four: active probing
The most durable detection method does not classify your traffic at all. The system notes that you connected to an unfamiliar address, and then connects to that address itself, pretending to be a client. What comes back decides the verdict.
Observe
A flow to an address with no reputation, no matching DNS history and an unusual traffic profile is recorded for follow-up.
Probe
The system opens its own connection to that address, sometimes replaying bytes it captured from your session, sometimes sending deliberate garbage.
Judge
A normal web server answers with a normal response, or a TLS alert, and behaves identically whatever nonsense it is sent. A naive proxy answers differently — it may hang, close immediately, or reply in a way no web server would.
Act
If the reply is anomalous, the address goes on a blocklist and the port stops working for everyone using it.
The defence is for the server to be genuinely indistinguishable from an ordinary site to anyone without valid credentials, including under adversarial input. Protocols in this family achieve it by forwarding unauthenticated connections to a real web server and letting that server answer — so the probe receives a real site, because it reached one.
Gate five: address reputation
Independently of anything on the wire, addresses themselves carry reputation. Ranges belonging to well-known hosting providers are widely tagged as datacentre space, and some networks restrict or challenge them by default. Addresses published in a public list — by the provider, in an app store listing, in a forum post — can be blocked without any inspection at all.
No protocol design addresses this. It is a property of the address, not of the traffic. It is the reason endpoint rotation exists, and the reason a widely shared public endpoint has a shorter working life than a narrowly distributed one.
Gate six: degrade rather than block
Blocking is visible and invites complaint. Slowing traffic is not. A flow classified as probably-a-tunnel can be shaped down to a few hundred kilobits, which leaves messaging usable and video impossible, and looks exactly like a congested network.
From the client side, the signature is a connection that establishes normally, transfers a burst at full speed, and then settles to a low, suspiciously stable rate — the stability is the tell, since real congestion fluctuates. Measuring against a control connection to an unrelated destination at the same moment is the way to confirm it.
What a protocol can and cannot fix
| Method | Can protocol design address it? |
|---|---|
| Protocol handshake fingerprint | Yes — by not emitting one, or by emitting a browser's. |
| TLS fingerprint mismatch | Yes — by reproducing a real client's handshake exactly. |
| Hostname in the handshake | Partly — by borrowing a plausible name, or encrypting it where supported. |
| Active probing | Yes — by responding exactly as an ordinary server would. |
| Address blocklists | No — this is about the address, not the traffic. |
| Statistical traffic analysis | Partly — padding and pacing raise the cost, at the price of throughput. |
| Default-deny allowlisting | No — nothing gets through a network that permits only named destinations. |
The honest summary is that protocol design handles the first four well, cannot do anything about the fifth, and only raises the cost of the last two. Any claim that a tunnel is undetectable is describing a system that has not yet met a determined operator.
Common questions
Why did my VPN work for months and then suddenly stop?
Most often the endpoint address was identified and blocklisted, rather than anything about your traffic changing. That identification can happen through active probing, through the address appearing in a public list, or through simple volume — a single address carrying an unusual amount of long-lived traffic attracts attention.
Is WireGuard blocked by DPI?
It is one of the easiest protocols to identify, because its first handshake message has a fixed size and a constant type byte at a known offset. On networks that filter by protocol fingerprint it is typically blocked early. This says nothing about its quality as a protocol on an unfiltered network, where it is excellent.
Does using port 443 make a VPN undetectable?
No. Port 443 stopped being a hiding place once inspection became routine; what matters is whether the traffic on it looks like the HTTPS that belongs there. A VPN protocol running unmodified on 443 is, if anything, more conspicuous, because it is claiming to be something it clearly is not.
Can a network block every VPN?
A network that permits only an explicit list of approved destinations can, at the cost of breaking a great deal of ordinary use. Most networks do not go that far because the collateral damage is unacceptable, which is what leaves room for traffic that resembles what is permitted.