VPN protocols compared: what actually gets blocked
Every other comparison ranks these on speed and security. Both are close to settled — the modern ones are all fast enough and all cryptographically sound — which is why those rankings come out the same everywhere and tell you nothing about why your tunnel stopped working.
Two questions, routinely merged into one
Can anyone read this? is a question about cryptography, and every protocol below except one obsolete case answers it well. Can anyone tell what this is? is a question about traffic analysis, and the answers differ enormously. A protocol can be excellent at the first and hopeless at the second — WireGuard is the clearest example, and it is the most widely recommended protocol there is.
A censor blocking your VPN is almost never breaking its encryption. It is matching a pattern: a packet of a particular size, a constant in a particular position, a port, a handshake that looks like no browser. So the column that matters is what gives each protocol away.
| Protocol | What gives it away | Cost to block |
|---|---|---|
| WireGuard | A single UDP packet. The handshake initiation is always 148 bytes and begins with the message type 1; the response is always 92. A censor needs one rule, and it never needs updating. | One static rule |
| AmneziaWG | Nothing fixed, if configured correctly. Junk packets precede the handshake, padding changes the sizes, and the four message type constants are replaced — so the one rule that catches WireGuard catches nothing. | Traffic analysis |
| OpenVPN | The opcode in the first byte of its first packet, unless tls-crypt is enabled — that encrypts the control channel and removes the giveaway. Running on TCP port 443 does not by itself make it resemble HTTPS; there is no browser-shaped TLS hello for an inspector to find. | A rule plus upkeep |
| IKEv2/IPsec | Its ports. IKEv2 lives on UDP 500 and 4500, both fixed and both well known. Closing two ports is not really filtering; it is housekeeping. | One static rule |
| Shadowsocks | Historically, by having no handshake at all: a connection that is high-entropy from its first byte is itself a category, and one a censor can block. Current AEAD and 2022-edition implementations resist this; old stream-cipher configurations do not. | Traffic analysis |
| VLESS + Reality (Xray) | Nothing at the handshake. A prober without the key is passed through to the real site being impersonated and receives its real certificate, so probing confirms the cover story instead of breaking it. | Collateral damage required |
“Cost to block” is the censor's effort, not yours. One static rule means a line of configuration that never needs revisiting. Collateral damage required means the only reliable block also breaks something the network wants to keep.
WireGuard
The modern default: fast, small, and built on one fixed set of cryptography with nothing to negotiate.
What gives it away
A single UDP packet. The handshake initiation is always 148 bytes and begins with the message type 1; the response is always 92. A censor needs one rule, and it never needs updating.
Under active probing
Not required. It is identified from the first packet it sends, so nobody has to knock on the server.
Reach for it when
The network is not filtering. On an ordinary connection this is the one to use — nothing else gives you this much speed for this little complexity.
Its design philosophy was to remove choices: no cipher negotiation, so no downgrade attack and no way to configure it badly. The same decision produces the fixed packet shape that makes it trivial to fingerprint, and there is no setting that changes this, because having settings is the thing it was avoiding. Countries that block WireGuard are not defeating its cryptography; they are matching a constant. Excellent security and no camouflage is a coherent position, not a contradiction.
Terms: wireguard · deep-packet-inspection · handshake
AmneziaWG
WireGuard with the fingerprint removed: same cryptography, configurable packet shape.
What gives it away
Nothing fixed, if configured correctly. Junk packets precede the handshake, padding changes the sizes, and the four message type constants are replaced — so the one rule that catches WireGuard catches nothing.
Under active probing
Holds up. There is no distinctive reply for a prober to recognise, though a server that answers only this and nothing else is still a server doing one unusual thing.
Reach for it when
WireGuard is blocked and you control both ends. This is the lowest-cost step up from a working WireGuard setup.
The important caveat is not cryptographic. Both peers must agree on every parameter, and a configuration that is merely wrong rather than invalid connects and passes traffic while still carrying the pattern the padding existed to hide. Two specific traps: the header values H1 to H4 must all differ, and S1 + 56 must not equal S2 — the handshake initiation is 148 bytes against the response's 92, longer by exactly 56, so that combination pads them into being the same size as each other. Neither mistake produces an error message.
Terms: amneziawg · junk-packets · header-magic
OpenVPN
The long-established one: slower and far more configurable, able to run over TCP on the port HTTPS uses.
What gives it away
The opcode in the first byte of its first packet, unless tls-crypt is enabled — that encrypts the control channel and removes the giveaway. Running on TCP port 443 does not by itself make it resemble HTTPS; there is no browser-shaped TLS hello for an inspector to find.
Under active probing
Depends on the configuration. With tls-auth or tls-crypt a server will not respond to a prober lacking the key; without them it answers and identifies itself.
Reach for it when
You need to run on equipment or an operating system that will never have WireGuard, or you need TCP because UDP is blocked outright.
Its reputation for being blockable is really a reputation for being deployed with defaults. tls-crypt changes the picture considerably and is a single configuration line, yet most consumer setups do not use it. The flexibility cuts both ways: the same configurability that allows a hardened deployment allows a much weaker one, and from the outside the two look identical.
Terms: openvpn · sni-filtering · active-probing
IKEv2/IPsec
Built into phones and laptops, and the reason a tunnel survives the walk from Wi-Fi to mobile data.
What gives it away
Its ports. IKEv2 lives on UDP 500 and 4500, both fixed and both well known. Closing two ports is not really filtering; it is housekeeping.
Under active probing
Not required, for the same reason as WireGuard.
Reach for it when
Nothing is blocking you and you want a tunnel with no client to install, on a device that moves between networks.
Genuinely good at the problem it was designed for. MOBIKE keeps a session alive across a change of network, which is why it is the quiet default in corporate deployments. Against censorship it has no story at all: no obfuscation, no port flexibility worth the name, and a handshake as recognisable as WireGuard's without the compensating speed.
Terms: ikev2 · ip-blocking
Shadowsocks
An encrypted proxy written in China for exactly this problem — not a VPN, and the difference matters.
What gives it away
Historically, by having no handshake at all: a connection that is high-entropy from its first byte is itself a category, and one a censor can block. Current AEAD and 2022-edition implementations resist this; old stream-cipher configurations do not.
Under active probing
Modern versions hold. The 2020 attacks on stream ciphers worked by replaying altered traffic at a suspected server and reading its reaction; authenticated encryption closes that.
Reach for it when
You want a light, per-application tunnel and you are prepared to handle everything it does not cover.
Because it proxies applications rather than carrying the device, anything not configured to use it keeps travelling normally — frequently including DNS, which quietly undoes the point. It is also not one thing: naming the implementation and the cipher says more than naming the protocol. Treat any advice about Shadowsocks written before 2022 as being about a different protocol.
Terms: shadowsocks · proxy-vs-vpn · dns-leak
VLESS + Reality (Xray)
Not encryption but impersonation: the server presents a genuine third-party website's TLS, so inspection sees a visit to that site.
What gives it away
Nothing at the handshake. A prober without the key is passed through to the real site being impersonated and receives its real certificate, so probing confirms the cover story instead of breaking it.
Under active probing
Designed against it. This is the property that made Reality the default recommendation in the most heavily filtered networks.
Reach for it when
Everything else is blocked, including AmneziaWG, and you are willing to run and maintain a server.
The remaining signals are behavioural rather than cryptographic, and they are real. The cover site has to be one you plausibly visit; hours of sustained traffic to a site nobody browses for hours is a pattern, as is a residential connection talking to it at volumes no reader would generate. Reality moves the problem from the protocol layer to the traffic layer, which is a large improvement and not a solution.
Terms: reality · vless · tls-fingerprinting · active-probing
Choosing one
There is no ranking, because the right answer depends on what is being done to your connection. On an unfiltered network, use WireGuard and stop thinking about it. When WireGuard stops connecting, AmneziaWG is the smallest change that helps, because it is the same tunnel with its shape altered. When that stops working too, the remaining approach is to stop looking like a tunnel at all, which is what Reality does and why it costs more to run.
Work upward, not downward. Each step adds latency, configuration and ways to be silently misconfigured, and none of them adds security — the cryptography was already fine at the bottom of the ladder.
What we use
Unblock Master runs AmneziaWG and Reality, for the reasons above rather than as a feature list: the countries our users connect from are the ones where plain WireGuard is matched on sight. We are not a neutral party here, which is why this page describes the detection mechanisms concretely enough for you to check the claims against someone else's documentation.