Your mental model of a VPN is probably wrong for this fight
Most people picture a VPN as a dumb pipe. Your traffic goes in encrypted, comes out encrypted somewhere else, and whoever owns the wires in between just shuffles bits around without looking too hard. That model is fine if your adversary is an ISP trying to throttle your torrent traffic on a Tuesday night.
It falls apart the second the network operator is the state, and identifying VPN traffic is the actual job description, not an accident of infrastructure.
Here’s the thesis, up front: if the adversary controls the network itself, encryption was never the thing protecting you. Shape was. Nobody at that level is trying to read your traffic in real time. They’re trying to recognize it. Your cipher suite can be flawless and it won’t matter, because the censor isn’t cracking your crypto. They’re looking at the outline of the box it came in, and a lot of VPN protocols ship in a box shaped exactly like “VPN.”
That distinction changes everything about how you should evaluate a tunnel, and it’s the reason a huge chunk of self-hosting advice about VPNs is quietly obsolete the moment you leave a network with a neutral operator.
The threat model when the network itself is the adversary
If you’ve only ever thought about VPNs from inside a country with a mostly hands-off ISP, here’s the upgrade you need to make. A state-level censor typically has four capabilities working together, and most Western writeups only ever mention the first one.
Nationwide real-time DPI. Deep packet inspection at the ISP or backbone level, watching for known protocol signatures as traffic passes through. This is the part everyone assumes is the whole story: a big filtering box somewhere that pattern-matches your packets.
Active probing. This is the one that catches people off guard, and it’s the star of this whole conversation. It’s not passive. The censor’s infrastructure will actually open a connection to your server and start talking to it, the same way your VPN client would, to see how it responds. If your server answers like a VPN endpoint answers, that’s a flag. If it hands back a legitimate website’s real certificate because that’s genuinely what’s running on port 443, that’s a very different outcome. Most people running a home VPN have never once considered that the far end of their tunnel might get interrogated by the network itself.
Geographic null-routing of whole ASNs. Rather than fight individual connections, entire foreign IP ranges get dropped at the border. Doesn’t matter what protocol you’re speaking or how good your disguise is if the destination address itself is in a block that never gets routed at all.
Whitelist-mode kill switches. The nuclear option: instead of blocking known-bad traffic, the network only permits known-good destinations, and everything else, disguised or not, simply doesn’t route. We’ll come back to this one, because it’s the topic of its own article and it changes the whole calculus.
Put those four together and you get a completely different design problem than “pick a VPN protocol that isn’t blocked yet.” You’re not hiding content from a reader. You’re trying to look boring to an interrogator who is actively poking at you and comparing you against a whitelist of things it already trusts.
Protocol silhouettes: why the old standbys lose
Every protocol has a silhouette: a shape it makes on the wire that exists whether or not the payload is encrypted. Packet sizes, message ordering, timing, handshake structure. DPI doesn’t need to break your encryption to spot the silhouette. It just needs a ruler.
Ordinary HTTPS to a CDN: variable record sizes, bursty timing, mixed request/response patterns [ ~340B ][ ~1200B ][ ~89B ][ ~4096B ][ ~212B ] ...irregular, boring
Stock WireGuard tunnel: [ Handshake Init: fixed size ][ Handshake Resp: fixed size ][ data packets ] ^ same layout, ^ same layout, every session every session
A census taker doesn't need to open the envelope. The envelope's shape already told them what's inside.Stock WireGuard loses this game because it was never designed to hide, only to be fast and simple. The handshake messages have a fixed layout and a distinctive size. Data packets fall into a recognizable size distribution. None of that requires decryption to notice, and in the harshest environments, that fingerprint alone gets it blocked outright.
OpenVPN has an even more basic problem: its opcode bytes, the header data that identifies message type, sit unencrypted in the packet. A censor can read them directly. And even if you wrap OpenVPN in TLS to hide that, statistical flow analysis, looking at packet timing, sizes, and the rhythm of the conversation rather than the bytes themselves, still catches it. The wrapper hides the wrapper. It doesn’t hide the thing moving underneath it.
This is the part people miss when they think “encrypted” means “invisible.” Encryption protects content. It does nothing about shape unless the protocol was specifically engineered to disguise its own shape, and most of the protocols people default to were never built with that goal in mind.
Why “just wrap it in TLS” buys you weeks, not years
The instinct once you understand the silhouette problem is obvious: wrap the tunnel in TLS so it looks like ordinary HTTPS. And for a while, that works, because building a detector for a new wrapping trick takes real engineering time on the censor’s side.
But “for a while” is the operative phrase. Censorship infrastructure at nation-state scale gets funded, staffed, and updated. A generic TLS wrapper around a fundamentally unchanged protocol still has tells underneath: the timing pattern of a proxy handshake still doesn’t match a real browser’s handshake, the certificate behavior still doesn’t match a real site, and once someone bothers to build a detector for your specific wrapper, that detector gets deployed everywhere at once. You’re not fighting one curious analyst. You’re fighting an org that ships updates.
Treat any single trick, TLS wrapping included, as a temporary advantage with a shelf life measured in months, not a permanent solution. That reframing alone will save you from a lot of false confidence.
The landscape that replaced the old stack
The tools that actually hold up in 2026 were built around the silhouette problem from day one, not retrofitted onto something else. Here’s where things stand, described qualitatively rather than with invented benchmark numbers, because most of the “stealth scores” floating around comparison sites aren’t measuring anything rigorous.
| Option | What it hides | Where it still leaks | Complexity | Best fit |
|---|---|---|---|---|
| AmneziaWG | WireGuard’s fixed handshake shape, via junk padding and header replacement | Not built for the harshest active-probing environments | Low-medium | Mild to moderate filtering, keeping WireGuard’s simplicity |
| Shadowsocks-2022 | Payload behind modern AEAD encryption, lightweight footprint | Simpler protocol overall, less mimicry sophistication | Low | Small VPS, simplest setup, many regions |
| VLESS + REALITY | Real TLS handshake behavior via genuine certificate borrowing | SNI/cert-switch probing, datacenter IP reputation | High | Serious DPI plus active probing, the hardest environments |
| Hysteria2 / TUIC | Payload over QUIC, tuned for lossy links | UDP itself is easy to rate-limit or block outright | Medium | Fast, jittery, or congested connections where speed matters most |
| obfs4 (Tor) | Traffic shape via obfuscation layer | Lower throughput than the above | Low-medium | Reliable workhorse against active probing when speed isn’t critical |
| Snowflake | Traffic inside volunteer WebRTC sessions | Not a stable high-throughput daily tunnel | Low (as a user) | Emergency access, getting online when nothing else works |
A few honest notes on that table. AmneziaWG keeps WireGuard’s actual cryptography (Curve25519, ChaCha20-Poly1305) unchanged and just disguises the handshake and, in its newer version, the data phase too. It’s a genuinely good “I want WireGuard but hidden” option, reported to hold up fine against milder filtering while not being the tool you’d pick against the harshest active probing. Shadowsocks-2022 is the easiest thing on this list to actually stand up and keep running, and it’s still effective in plenty of regions, which is worth remembering before you reach for the most complicated option out of habit.
VLESS paired with REALITY is the strongest answer to DPI and active probing specifically, and it’s also the most complex to configure correctly, which is exactly why it gets its own article. Hysteria2 and TUIC are the speed option: QUIC over UDP handles lossy and jittery links well, but UDP itself is a much easier thing for a network operator to simply rate-limit or block wholesale, so it’s a poor fit where UDP traffic already draws attention. obfs4 and Snowflake come out of the Tor project’s pluggable transport work: obfs4 is a slower but dependable workhorse, and Snowflake is genuinely great for getting somebody online in an emergency, not for running a household’s daily traffic.
The verdict: match the tool to the actual threat
Be honest with yourself about which situation you’re actually in, because over-engineering here has a real cost in complexity and maintenance, and under-engineering has a real cost in getting blocked.
Mild filtering, some keyword or domain blocking, no active probing: Shadowsocks-2022 or AmneziaWG. Get something running today and don’t overthink it. This is most people’s actual situation, even people who assume they’re in the hard category.
Serious nationwide DPI, protocol fingerprinting is actively enforced: AmneziaWG if you want to keep things simple, VLESS with REALITY if you want the strongest available answer and are willing to deal with the configuration complexity that comes with it.
Active probing is confirmed or suspected, the network is connecting back to your endpoints to interrogate them: VLESS with REALITY. This is genuinely the tool built for exactly this scenario, and it’s worth the setup effort. That’s the entire subject of the next article in this series.
Whitelist-mode shutdown, where the network only permits a pre-approved list of destinations: none of the above help you. Not one. This is the uncomfortable answer that most guides won’t give you, because it’s not a satisfying one to sell. When the network stops asking “is this traffic suspicious” and starts asking “is this destination on the list,” protocol mimicry stops being the relevant variable. You can have the most convincing TLS handshake ever engineered and it still won’t matter if the destination address isn’t one of the roughly 500 services the state has decided are the only things allowed through. That’s not a protocol problem anymore. It’s a routing and infrastructure problem, and it needs a completely different kind of planning.
Where this goes next
The next article in this series digs into how VLESS and REALITY actually pull off convincing mimicry under the hood, the cryptography, the certificate borrowing trick, and the specific ways it’s still detectable despite being the strongest option on the table today. The one after that tackles the routing problem this article just flagged and refused to paper over: what a domestic relay actually buys you against geographic null-routing, and why none of that saves you once a network moves to whitelist-only mode. That third piece is the one that matters most if you’re planning for the worst case rather than the common one.
Encryption was never your shield here. Recognition was always the actual battlefield, and once you see the network that way, the rest of your tunnel choices get a lot more obvious.
