Get a VPN past deep packet inspection

“DPI” sounds like an intelligence problem. Most of the time it is a string match. A filter sitting on a national link cannot afford to think hard about every flow, so it leans on the cheapest signals that work, in roughly this order:

• A protocol fingerprint at a fixed offset. The first packet of a WireGuard session is a handshake initiation: exactly 148 bytes, first byte 0x01, next three bytes zero. OpenVPN announces itself with an opcode in the first byte and a session id that never varies in position. Matching either is a few instructions per packet with no state to keep, which is why it is always the first thing deployed.
• Entropy, when there is no fingerprint to find. If a flow’s first bytes are uniformly random — no printable ASCII, no recognisable header — that itself is a signal, because almost nothing legitimate looks like that from byte zero. Filters have blocked whole categories of “fully encrypted” traffic on this basis alone, which is exactly the trap the randomising protocols fall into.
• Active probing. The filter notes your server’s address, then connects to it itself, from somewhere else, and watches how it replies. A proxy that answers, errors in a characteristic way, or simply holds the connection open confirms the suspicion. This is how an address moves from “maybe” to a blocklist.
• Behaviour over time. A single long-lived flow to one foreign address carrying a few hundred megabytes with a residential-looking day/night curve is a distinctive thing to be. No amount of payload obfuscation changes it.
• The address itself. Known VPS ranges, addresses seen in public subscription lists, anything a commercial provider advertises. This one costs the censor nothing and is the reason a shared proxy address dies faster than a protocol does.

The useful takeaway is that the first three are the ones you can do something about, and they are the ones this guide addresses. The last two are why the section on protecting your address is not an afterthought.

It is the most repeated piece of advice on the subject and it has almost no effect, for a reason worth stating plainly: the signature is in the payload, not in the port number. A filter that matches 0x01 at offset zero of a 148-byte UDP datagram finds it on port 443 exactly as easily as on 51820.

Worse, the move can make you stand out. Port 443 carries HTTPS, which is TCP, and HTTP/3 over QUIC, which is UDP but begins with a recognisable QUIC long header and a TLS ClientHello inside it. A UDP flow on 443 that is neither is a small anomaly on a link where everything else on that port is one or the other.

The same goes for the rest of the folklore. Changing MTU alters fragmentation, not the handshake bytes. Adding a pre-shared key to WireGuard strengthens the cryptography and leaves the wire format untouched. Putting the tunnel on a non-standard high port buys you nothing against payload matching, though it does cut the background noise from opportunistic scanners.

What changes the answer is changing what is on the wire: either make the bytes look like nothing recognisable, or make them look like something the censor has decided not to block. Everything below is one of those two moves.

There are four practical approaches. They are not ranked by strength alone, because the right one depends on what is being done to your traffic.

• Randomised, header-free traffic — Shadowsocks-2022. The 2022 AEAD ciphers (2022-blake3-aes-128-gcm and friends) put no plaintext header on the wire at all: from the first byte a session is indistinguishable from random data, and a wrong key produces no reply to probe. Cheap, fast, ten minutes to deploy, excellent almost everywhere. Its one weakness is the entropy signal above — against a filter that blocks unclassifiable random flows on principle, looking like nothing is not the same as looking innocent.
• Borrowed TLS — VLESS with Reality. The strongest option in general use today. Your server performs a genuine TLS 1.3 handshake, and any client that cannot authenticate is handed transparently to a real third-party site, whose real certificate it duly receives. A prober sees an ordinary visitor connecting to an ordinary website, because that is precisely what happened. You need no domain, no certificate and no certificate-transparency footprint — there is nothing registered anywhere that points at you.
• TLS you own — Trojan, or VLESS over WebSocket behind a web server. The tunnel hides inside your own HTTPS site, on your own domain and certificate. Conceptually simpler and it coexists with a real website on the same address. The cost is that the domain is now a burnable identifier, the certificate is a public record in CT logs, and blocking one hostname is a cheap move for a censor.
• QUIC-shaped — Hysteria2 and TUIC. These pass for HTTP/3 and can serve a real website to anything that fails authentication. The reason to choose them is usually not censorship at all but loss: on a path that drops five or ten percent of packets, they hold throughput where anything TCP-based collapses. The trade-offs are real — some networks throttle or drop UDP wholesale, and Hysteria’s aggressive congestion control is a poor neighbour if you set the bandwidth figures dishonestly.

If you want a default: deploy Reality as the primary, keep Shadowsocks-2022 on a second port as the fallback, and add Hysteria2 only if your problem turns out to be a lossy path rather than a filtered one. All three run from one daemon, and the steps below configure each in turn.

Less than you would expect. This is a light workload; the constraint is bandwidth and latency, not the server.

• A small plan. Encryption and TLS termination are cheap on any modern vCPU with AES-NI. Pup (1 vCPU / 1 GB / 25 GB NVMe, $3.50/mo) carries a personal tunnel comfortably; Cub (1 vCPU / 2 GB / 40 GB, $5.00/mo) is the sensible size if several people share it; Scout (2 vCPU / 4 GB / 70 GB, $9.00/mo) if it is a household or a small team and you want headroom. Traffic is unlimited at 1 Gbps on every tier, which is the specification that actually matters for a tunnel.
• The right location, chosen for the path. This is the decision people get wrong. Pick the nearest jurisdiction whose route from you is not filtered rather than the most exotic one: for most readers that is Amsterdam, Paris, Bucharest or Sofia, and for anyone in Asia, Kuala Lumpur. Reykjavik and Zurich buy legal distance, not speed — useful for what you host, less useful for what you tunnel through.
• Debian 13 or Ubuntu LTS from the template library. Full KVM virtualisation means a real kernel and your own network stack, which is what lets you bind low ports and shape UDP without asking anyone.
• A dedicated IPv4 with no history. Every plan ships one, plus an IPv6 /64. An address that has never sat in a shared proxy pool is the single most valuable thing here, and it is the reason recycled budget-cloud addresses fail within days.
• Ten minutes of hardening first. SSH keys only, no password logins, default-deny firewall. The Debian hardening checklist covers it; an obfuscated tunnel on a box with a guessable root password is an elaborate lock on an open door.
• A domain — only if you choose the TLS-you-own route. Reality and Shadowsocks need none, which is a large part of their appeal.

Fingerprinting finds candidates; probing confirms them. Once a filter suspects an address it will open its own connection from an unrelated network and see what comes back. Everything hinges on the answer.

A server that returns a distinctive error, closes at a characteristic moment, or accepts a connection it cannot possibly authenticate has confirmed the guess. This is not theoretical: it is the documented mechanism by which large-scale filters have retired earlier obfuscation protocols en masse, and it is why obfs-style plugins that simply scrambled a header did not survive contact with it.

The modern designs answer the probe in one of two correct ways:

• Say nothing. Shadowsocks-2022 cannot produce a valid response without the key, so it produces none. To a prober the port is a black hole, which is the same thing a firewalled port looks like. It also carries replay protection with a bounded time window, so a captured session cannot be resent later to elicit behaviour.
• Say something true, about somebody else. Reality forwards the unauthenticated handshake to a genuine third-party host and relays that host’s real certificate back. The prober gets a valid chain for a site that plainly is not you. Pick a handshake target that is popular, plausibly reachable from your server’s country, and unlikely to be blocked itself — and keep the server’s clock in sync, because Reality rejects handshakes outside a narrow time window.

Test this yourself before you trust it. From an unrelated machine, run curl -v https://YOUR_IP against a Reality port: you should see a certificate belonging to the handshake target and nothing that hints at a proxy. Against a Shadowsocks port, nc should hang and then time out with no bytes returned. Anything else is a finding.

Protocols are replaceable in ten minutes. Addresses are not. Once an IPv4 is blocked inside a country it usually stays blocked long after whatever triggered it is gone, because nobody on the other side is paid to review the list. Treat the address as the asset and the protocol as a consumable.

Three habits follow from that. Do not publish it. An address posted in a public subscription list, a channel, or a shared configuration is enumerable, and enumeration is the cheapest attack there is — this is why private tunnels outlive free public ones by a wide margin. Do not put a burnable name on it. If you run the TLS-you-own route, a domain that also serves anything attention-getting drags the address down with it. Do not mix roles. A single-purpose box, with your tunnel and nothing else, does not inherit a listing earned by something else you were running.

The other half is where the address came from. High-churn budget clouds recycle IPv4 through thousands of short-lived customers, so a “new” address may already carry someone else’s reputation before your first packet. Every plan here ships a dedicated, screened IPv4 rather than a slice of a shared pool — see what a clean IP actually means for the definition and how to verify it yourself. If yours is ever flagged, or blocked somewhere that matters, request a swap through the panel; you should not have to place a new order to get a working address. And when you want to know whether a problem is a censor or a reputation list, our guide to checking whether an IP is blacklisted tells the two apart.

The honest accounting, because the rest of this guide is only worth reading if this part is in it.

• It does not hide that you are sending encrypted traffic somewhere. A network operator still sees a flow to a foreign address, its volume, its timing and how long it lasts. Reality makes that flow look like an ordinary visit to an ordinary website; it does not make it disappear.
• It does not defeat traffic analysis. Sustained high-volume flows with a distinctive day/night pattern remain distinctive. Against an adversary willing to spend real resources on correlation rather than pattern-matching, payload obfuscation is the wrong tool, and Tor with a pluggable transport is the better-studied answer.
• It does not protect the endpoints. A compromised device, a logged-in account, browser fingerprinting and everything you type on the other side are untouched by any of this.
• It does not make the server anonymous. The host knows which address is yours, and a no-KYC signup limits what there is to know rather than eliminating it. We set out exactly what is and is not visible in is a crypto-paid VPS really anonymous, and it is worth ten minutes before you rely on assumptions.
• It is not permanent. This is an arms race with a release cycle. A configuration that works today may need replacing in a year, which is the real argument for a setup you control and can change in ten minutes rather than a subscription you can only cancel.

What it does do, reliably, is raise the cost of blocking you from “a byte match at line rate” to “a decision to break a lot of ordinary traffic”. In practice that is usually the whole game.

The protocol decides whether packets get through. Everything else about whether the tunnel keeps existing is decided off the wire.

Jurisdiction determines who can compel what. Our footprint is eight locations across the Netherlands, France, Romania, Bulgaria, Sweden, Iceland, Switzerland and Malaysia; a request that carries weight in one carries none in another, and no US-style takedown notice has force in any of them. That is operational policy stated honestly, not legal immunity — local court orders still apply, and there is a hard abuse floor we do not move. Offshore hosting explains the distinction properly.

The account is the part people underestimate. A tunnel is only as private as the record of who rented it. Signup here takes an email address for credential delivery and nothing else — no ID, no card, no address, no phone. There is no verification file to hand over because we never collected one.

The payment is the other half of that. A card links a server to a bank record and a legal name in a database neither of us controls. Checkout here settles on chain, and Monero is first-class rather than an afterthought: our guide to paying for a VPS with XMR walks the whole flow, and buying without a credit card covers getting there from zero crypto. Deploy is about sixty seconds after confirmation, so a replacement address is minutes away if you ever need one.

Put together, that is the shape of a tunnel that survives: a protocol a filter cannot cheaply match, an address nobody else has burned, a jurisdiction outside the filter’s reach, and an account that never held anything worth demanding. If you want the plain version of the same tunnel first, the WireGuard setup guide is ten minutes and a good place to start — come back here when something stops connecting.