VLESS vs WireGuard: when speed meets censorship resistance
WireGuard is probably the best VPN protocol ever designed for unrestricted networks. VLESS Reality is probably the best protocol for networks where someone is actively trying to stop you. These are different problems, and the protocols that solve them look nothing alike.
Most comparison articles pick a winner. We won't, because the answer depends on where you are and what the network between you and the server looks like. We ship both protocols in Fexyn and auto-switch between them for this reason. (For a higher-level overview of what a VPN protocol actually is, start there.)
Here's what actually matters when choosing between them.
WireGuard: why it became the default
WireGuard earned its reputation. The entire protocol is roughly 4,000 lines of kernel code. For comparison, OpenVPN is over 100,000 lines. IPsec implementations run even longer. Smaller codebases mean fewer places for bugs to hide, which matters enormously for security-critical software.
The cryptographic choices are opinionated and fixed: ChaCha20-Poly1305 for symmetric encryption, Curve25519 for key exchange, BLAKE2s for hashing. There's no cipher negotiation, no configuration matrix, no "pick your favorite algorithm" menu. This is a deliberate design decision by Jason Donenfeld, and it eliminates an entire class of downgrade attacks that plague protocols with configurable cipher suites.
Performance follows from the architecture. WireGuard operates at the kernel level (or in userspace via boringtun), processing packets with minimal context switching. UDP transport avoids TCP's head-of-line blocking problem entirely. On a 500 Mbps fiber connection, WireGuard consistently delivers around 480 Mbps in our testing. That's 96% of the baseline throughput. You're barely paying a tax for the encryption.
Connection establishment is fast too. A WireGuard handshake is a single round trip: initiator sends an encrypted message, responder sends one back, and the tunnel is live. In Fexyn's implementation on Windows, the full connection sequence from "user clicks connect" to "traffic flowing through the tunnel" averages about 611 milliseconds. Most of that time is spent setting up the TUN adapter and configuring routes, not waiting on the protocol itself.
For the majority of users on the majority of networks, WireGuard is the correct choice. It's fast, it's simple, and it has had years of production hardening across Linux, Windows, macOS, iOS, and Android.
The 148-byte problem
WireGuard has a weakness that no amount of clever engineering can fix, because it's a direct consequence of the protocol's design philosophy.
Every WireGuard handshake initiation message is exactly 148 bytes long. The first byte is 0x01 (message type 1: handshake initiation). The next three bytes are 0x00 0x00 0x00 (reserved, always zero). This is followed by a 4-byte sender index and then a 32-byte unencrypted ephemeral Curve25519 public key.
This structure never varies. It cannot vary; the protocol specification requires it.
Deep packet inspection systems exploit this. The detection logic is embarrassingly simple. Here's what nDPI, an open-source DPI library used by network equipment vendors worldwide, actually checks:
if (message_type == 1 && packet_length == 148)
→ classify as WireGuard
That's it. One conditional. The 148-byte handshake with a leading 0x01 0x00 0x00 0x00 is a unique fingerprint that no other protocol produces. You don't need machine learning or statistical analysis. A first-year networking student could write this filter.
Russia's TSPU (Technical Systems for Countering Threats) has been blocking WireGuard with near-100% accuracy since mid-2024. Not throttling, not degrading. Blocking. The UDP packets carrying WireGuard handshakes simply disappear. China's Great Firewall does the same thing. Iran blocks it. Any government running modern DPI equipment can add WireGuard to its blocklist in an afternoon.
The WireGuard project is aware of this. It's not a bug. The protocol was designed for speed and simplicity, not for stealth. Making the handshake variable-length or adding padding would complicate the protocol and violate the core design principle of minimal complexity. These are reasonable tradeoffs for the threat model WireGuard targets. They just mean WireGuard is the wrong tool if you're on a network where someone is actively inspecting traffic.
AmneziaWG: a partial fix
AmneziaWG 2.0 attempts to address the fingerprinting problem by adding random padding to WireGuard packets, using dynamic headers, and injecting junk packets. It does make detection harder. But it's still working within WireGuard's UDP-based framework, which means censors can apply statistical analysis to the packet size distribution, timing intervals, and entropy characteristics. UDP traffic that doesn't match any known protocol is suspicious by default in heavily censored environments.
AmneziaWG is a step forward. It's not a solution to the fundamental problem.
VLESS Reality: hiding in plain sight
VLESS takes the opposite approach to WireGuard in almost every way. Where WireGuard is a purpose-built VPN protocol with a unique wire format, VLESS is a proxy protocol that delegates its encryption entirely to TLS 1.3. The VLESS header itself adds only 25 to 50 bytes of overhead, containing a version byte, a UUID for authentication, and routing information.
The protocol only makes sense inside a TLS connection. Strip away TLS and VLESS has no encryption, no integrity protection, nothing. This dependency on TLS is often criticized as a weakness. It's actually the source of VLESS's greatest strength.
VLESS Reality with the Vision flow extends the base protocol with a camouflage system that makes the connection genuinely indistinguishable from normal HTTPS traffic. When you connect to a Fexyn server using Reality+Vision, the server performs a real TLS handshake with an actual website, like www.microsoft.com, and forwards that site's legitimate certificate to your client. Your client uses the uTLS library to produce a ClientHello message that is byte-for-byte identical to what Chrome or Firefox would send.
If a censor probes the server, they get forwarded to the real microsoft.com. Real certificate. Real content. Real HTTP headers. There's no simulation involved. The server functions as a transparent reverse proxy for unauthenticated connections and as a VLESS tunnel for authenticated ones.
The result is that no passive DPI system can distinguish a VLESS Reality session from someone browsing Microsoft's website. Active probing also fails because the probe receives genuine responses from a genuine website. Detection would require the censor to somehow differentiate between "a user visiting microsoft.com" and "a Reality server proxying to microsoft.com," which from a network perspective are the same thing.
This works in Russia. It works in China. It works in Iran. Not theoretically. Right now, in production, for real users.
What VLESS gives up
VLESS Reality isn't free. You trade things to get that invisibility.
The biggest cost is TCP. VLESS runs over TCP (via TLS), which means it inherits TCP's head-of-line blocking problem. If a single packet is lost, every subsequent packet in that TCP stream waits for retransmission. WireGuard avoids this by running on UDP. On lossy connections, the kind you get on crowded Wi-Fi or mobile networks with spotty coverage, the difference is measurable. VLESS is also TCP-only, period. XHTTP (a newer transport option in XRay-core) adds multiplexing but doesn't change the underlying TCP constraint. For gaming or real-time voice, where latency matters more than reliability, WireGuard's UDP transport is better suited.
The connection path is more complex too. A VLESS Reality session involves a TLS 1.3 handshake (1-RTT or 0-RTT), the VLESS protocol negotiation, and potentially a TUN adapter setup with tun2socks routing. More moving parts than WireGuard's single-roundtrip handshake. On the server side, Reality maintains a TLS connection to the camouflage destination and manages the proxy logic for unauthenticated connections. That costs more memory and CPU per client than WireGuard's kernel-space packet processing. At scale, the difference adds up for server operators.
Then there's auditability. WireGuard's 4,000 lines of code have been formally verified and widely audited. XRay-core is a large Go codebase with significantly more surface area. The core VLESS protocol is simple, but the surrounding implementation (Reality, uTLS fingerprinting, multiple transport modes) has not received the same level of independent security review.
These are real costs. They're acceptable when the alternative is having your connection blocked. They're not costs you should pay when you don't have to.
Head-to-head: Fexyn's performance numbers
We tested both protocols on the same hardware, same server, same network conditions. Windows 11, 500 Mbps fiber, connecting to our Frankfurt server. These numbers come from automated benchmarks, not cherry-picked runs.
| Metric | WireGuard | VLESS Reality |
|---|---|---|
| Cold connect time | ~611 ms | ~627 ms |
| Warm reconnect time | N/A | ~42 ms |
| Disconnect time | ~108 ms | ~100 ms |
| Throughput (500 Mbps baseline) | ~480 Mbps (96%) | Lower (TCP overhead) |
| Transport | UDP | TCP (TLS 1.3) |
| Handshake rounds | 1 round trip | 1-RTT TLS + VLESS header |
| DPI detectable | Yes, trivially | No, with Reality |
| Protocol overhead per packet | ~32 bytes (Poly1305 tag + counter) | 25-50 bytes (VLESS) + TLS record |
The connect times are closer than most people expect. The 16-millisecond difference between 611 ms and 627 ms for a cold connection is not something a user would perceive. Most of that time in both cases is adapter setup, route configuration, and verification, not protocol-level latency.
VLESS has an interesting advantage on warm reconnects. Because XRay-core can be kept running as a persistent process between connections, a reconnect (switching servers or recovering from a network change) only requires re-establishing the TLS session. That takes about 42 milliseconds in our testing. WireGuard reconnects are also fast, but the full adapter teardown and recreation cycle in our Windows implementation doesn't have the same warm-path optimization.
Where WireGuard pulls ahead clearly is throughput. UDP transport with kernel-level (or high-performance userspace) packet processing gives WireGuard a measurable edge, especially on high-bandwidth connections. The gap widens on lossy networks where TCP's retransmission behavior adds latency spikes.
When to use which
This is simpler than the rest of the article might suggest.
Use WireGuard if you're on a network where VPN traffic isn't blocked or throttled. Home internet in most Western countries, office networks that allow VPN use, mobile networks in countries without active censorship. WireGuard gives you the best throughput, the lowest latency, and the simplest connection model. It's the right default.
Use VLESS Reality if you're on a network that blocks or degrades VPN protocols. University networks that block WireGuard. Corporate firewalls that only allow HTTPS on port 443. Public Wi-Fi with DPI-based restrictions. And obviously, anywhere in Russia, China, Iran, or other countries with active internet censorship. VLESS Reality is the only production protocol we've tested that reliably gets through all of these.
Use automatic rotation if you travel between both environments or if you're not sure what your network allows. This is Fexyn's default mode: try WireGuard first for speed, fall back to VLESS Reality if WireGuard fails, then fall back to OpenVPN as a last resort. The switch happens automatically without dropping your kill switch protection.
Why Fexyn ships both
Most VPN providers ship one protocol and maybe offer OpenVPN as a legacy fallback. NordVPN's NordLynx is WireGuard with a NAT layer (see Fexyn vs NordVPN for the full breakdown). ExpressVPN's Lightway is a custom protocol that's still detectable by DPI. None of the major Western VPN providers ship VLESS Reality because it comes from the XRay/V2Ray ecosystem, which is primarily Chinese-language and requires deep familiarity with a codebase that has no formal specification.
We think a VPN should work everywhere. On your home Wi-Fi where nothing is blocking you, yes. Also on the hotel network in Moscow that's running TSPU. On the university campus that only allows HTTPS. On the coffee shop Wi-Fi that blocks UDP entirely.
That requires multiple protocols with different properties. WireGuard for speed when nothing is in the way. VLESS Reality for invisibility when something is. OpenVPN for the rare networks where neither works but legacy TLS-based VPN traffic is still allowed.
Fexyn's protocol rotation engine tries them in order based on your connection mode setting. "Speed first" starts with WireGuard. "Stealth first" starts with VLESS Reality. Either way, you end up connected. The protocol selection is automatic, the kill switch stays active during rotation, and the user doesn't need to understand any of the differences described in this article.
They just need their internet to work. Even when someone is trying to make sure it doesn't.
You can try both protocols today with a Fexyn subscription.