VPN protocols compared: WireGuard, OpenVPN, IKEv2 and VLESS

WireGuard is a small, modern, deliberately opinionated protocol. It fixes its cryptography rather than negotiating it, which removes a whole category of downgrade problems and keeps the implementation small enough to audit. It runs in kernel space on most platforms, and it is genuinely fast — usually the fastest option on a network that leaves it alone.

• Strengths: outstanding throughput, very low CPU and battery cost, near-instant reconnection after a network change, a codebase small enough to be reviewed properly.
• Weaknesses on a filtered network: the first handshake message has a fixed size and a constant type byte at a known offset. Identifying it takes one comparison. It is also UDP-only, and some networks restrict UDP by default.
• Privacy note: a plain WireGuard peer configuration stores the client's public key statically on the server, which some deployments wrap in additional layers for that reason alone.

None of this is criticism of WireGuard's design. Its authors were explicit that hiding from censors was not a goal. Deployments that need both its performance and resistance to filtering wrap it inside another transport, and pay for that in overhead.

OpenVPN is the long-standing generalist: mature, portable, supported everywhere, and configurable to a fault. It runs in user space, which costs performance relative to WireGuard but makes it available on platforms where a kernel module is not an option.

Its TCP mode on port 443 is frequently recommended as a way past restrictive networks. It genuinely helps on networks that only filter by port, and it does not help at all on networks that inspect. The control channel has a recognisable opcode structure, and running TCP inside TCP produces the well-known meltdown effect where two retransmission timers fight each other over a lossy link.

• Strengths: works nearly everywhere, extremely well understood, flexible enough to fit unusual requirements.
• Weaknesses: slower than WireGuard on identical hardware, heavier configuration, and detectable by inspection regardless of the port chosen.

IKEv2 is built into iOS, Android, Windows and macOS, which means no third-party client is needed. Its handling of network changes is the best of any protocol here: walking from Wi-Fi onto mobile data, the tunnel survives via MOBIKE without a visible interruption.

Against filtering it is the weakest of the group. It lives on UDP 500 and 4500, and the IKE exchange is unmistakable. Any network intending to block VPNs blocks it first, and there is no configuration that changes this.

Shadowsocks was designed for a different threat model from the start: an encrypted proxy whose traffic carries no recognisable handshake at all, looking as much like random bytes as possible. For a long time that was enough.

Its history is a useful illustration of how this contest proceeds. Early versions could be confirmed by active probing — a server would respond distinctively to deliberately malformed input — and the AEAD ciphers and later the AEAD-2022 revision were specifically a response to that. The current design is considerably more robust than the original.

Its remaining limitation is structural: random-looking traffic is not HTTPS-looking traffic. On a network that drops anything it cannot positively identify, being unclassifiable is the problem rather than the solution.

VLESS is a transport-agnostic tunnelling protocol whose defining decision is what it leaves out. It performs no encryption of its own and adds almost no framing: the security comes entirely from the layer it is carried over, normally TLS. Its predecessor VMess carried its own encryption and a timestamp-based authentication scheme, which added overhead and, in the case of the timestamp, an identifying quirk.

Because the protocol contributes so little of its own structure, there is very little for a classifier to latch onto beyond the TLS that wraps it. That places all of the burden on the TLS being convincing — which is exactly the point, and also the reason VLESS on its own is not a complete answer.

• Strengths: minimal overhead, nothing protocol-specific on the wire, flexible about the transport beneath it.
• Weaknesses: provides no confidentiality by itself — it must be carried over TLS or an equivalent, and a misconfiguration that omits that is a serious error rather than a performance trade-off.

1. 1

   Start with the fastest option that works

   On a network that is not filtering, WireGuard or IKEv2 will outperform anything wrapped in TLS, and there is no reason to pay for protection you do not need.

2. 2

   If it fails, establish how

   A connection that never establishes, one that establishes and dies, and one that works but crawls are three different problems with three different answers. The diagnostic guide walks through telling them apart.

3. 3

   Match the disguise to the network

   Against pattern matching, anything without a fixed handshake helps. Against a network that expects HTTPS to look like HTTPS, only a faithful TLS imitation helps. Against active probing, only a server that answers a stranger like an ordinary web server helps.

4. 4

   Re-evaluate rather than settling

   Filtering policy changes, and so does what is needed to work around it. A configuration that was necessary six months ago may now be costing throughput for nothing.