RE:NODE

Networking12 min read

Xray vs WireGuard vs OpenVPN: which VPN protocol to use

WireGuard, OpenVPN and Xray with VLESS and Reality compared on speed, how easily networks spot them, ports, MTU and client apps - and which fits which job.

0 readers

If the network you are on lets VPNs through, WireGuard is the fastest and simplest of the three and the one to pick. If you need TCP, an old router or a corporate setup that already speaks it, OpenVPN still works everywhere and is understood by every firewall admin alive. If the network blocks VPNs - a hotel that drops anything that is not web traffic, an office firewall, a country that filters protocols by their shape - neither of those survives, and Xray with VLESS and Reality is the one built for that job: it makes the tunnel look like an ordinary HTTPS connection to a well-known website. The trade is that Xray is a proxy rather than a packet tunnel, so it carries web traffic beautifully and game traffic less well.

That is the short answer. The rest of this post is why, with the ports, the overheads, the client apps and the failure modes, so you can decide for your own case rather than taking a ranking on trust.

Three different designs, not three versions of one idea#

The three are often lined up as if they were competing brands of the same product. They are not. They make different decisions about the one thing that matters most: what the traffic looks like on the wire.

WireGuardOpenVPNXray (VLESS + Reality)
What it movesIP packetsIP packets (tun) or Ethernet frames (tap)Connections (TCP streams, UDP relayed)
TransportUDP onlyUDP or TCPTCP, usually port 443
Default port51820 by convention1194 (IANA assigned)443 in most setups
CryptoCurve25519, ChaCha20-Poly1305, BLAKE2sTLS via OpenSSL, AES-GCM or ChaCha20-Poly1305 data channelTLS 1.3, x25519 keys for Reality
Looks likeWireGuardOpenVPNHTTPS to a real website
Where it runsLinux kernel, userspace elsewhereUserspace, kernel offload in 2.6Userspace (Go)

WireGuard is a layer 3 tunnel. Your device gets a virtual network interface, every IP packet routed into it is encrypted and sent as a UDP datagram to the server, and the server unwraps it and forwards it. It is small - around 4,000 lines of kernel code - opinionated, and has no cipher negotiation at all: one fixed set of modern primitives, and a new protocol version if they ever need replacing. It has been in the mainline Linux kernel since 5.6.

OpenVPN is the old workhorse, around since 2001. It also gives you a virtual interface, but the control channel is a full TLS session with certificates, and the whole thing runs in userspace. It can run over UDP or TCP, which is its great practical strength: TCP on port 443 gets through firewalls that drop everything else. Its weakness is that it was never designed to hide; its packets have their own recognisable framing even on port 443.

Xray is a different animal. It started in 2020 as a fork of V2Ray, the proxy platform, and its VLESS protocol is a thin, stateless way of saying "connect me to this address" after the client proves who it is with a UUID. VLESS does no encryption of its own; it relies on whatever transport security sits under it. Reality, added in 2023, is that transport security: a TLS 1.3 layer that borrows the handshake of a real, popular website. The VLESS and Reality explainer goes through the handshake in detail. What matters here is that Xray does not move raw packets. It moves connections, which changes how it behaves with everything from MTU to games.

Detectability: the column that decides most cases#

Encryption hides what you are saying. It does not hide that you are using a VPN. Deep packet inspection does not need to decrypt anything to recognise a protocol by the shape, size and timing of its first few packets, and this is where the three part ways.

WireGuard is trivially identifiable. Its handshake initiation is always a 148-byte UDP payload starting with a fixed message type, and the response is always 92 bytes. That is a deliberate design choice - WireGuard was built to be secure and simple, not to hide - and it means a network that wants to block WireGuard can do so with one rule. Changing the port from 51820 to 443 does not help; UDP on 443 that does not look like QUIC is just as obvious.

OpenVPN is identifiable too. Every packet starts with an opcode byte and a session ID, and the TLS handshake travels inside that framing rather than as normal TLS. tls-crypt encrypts and authenticates the control channel, which stops casual fingerprinting of the certificate exchange, but the packet structure is still OpenVPN's. Running it over TCP 443 gets it through firewalls that only allow web ports; it does not get it through a firewall that checks whether the traffic on 443 is actually TLS.

Xray with Reality is built to be boring. The client opens a TCP connection to port 443 and sends a TLS 1.3 ClientHello that names a real website in its SNI field and mimics a mainstream browser's fingerprint (the fp=chrome you see in links). Anyone watching sees a TLS 1.3 connection to what looks like that site. Anyone who actively probes the server without the right key is passed through to the real site and gets its real certificate. There is no certificate of your own to look up, no domain of your own, nothing unusual to match.

Two practical points follow. First, on a network that blocks nothing, detectability buys you nothing and WireGuard's speed wins. Second, VPN use is restricted or regulated in some countries. Making traffic look ordinary does not change what the law says about it, so know the rules where you are before relying on any of this.

Speed and overhead#

On an unrestricted network with a short path, all three will fill an ordinary home connection. The differences show up at the edges: high bandwidth, weak CPUs, lossy links.

WireGuard is the quickest in practice. On Linux it runs in the kernel, avoiding copies between kernel and userspace, and ChaCha20-Poly1305 is fast even on CPUs without AES instructions, which is why phones and small routers do well with it. Each packet carries 60 bytes of overhead over IPv4 (20 IP, 8 UDP, 32 WireGuard header and authentication tag) or 80 over IPv6, which is why wg-quick defaults the tunnel MTU to 1420: 1500 minus the worst case.

OpenVPN has historically been the slowest, because it is single-threaded in userspace and every packet crosses the kernel boundary twice. OpenVPN 2.6 added data channel offload (DCO), which moves encryption into a kernel module on Linux and a driver on Windows and closes much of the gap, but only when both ends use it and only for the AEAD ciphers. Overhead depends on cipher and options, typically 50 to 70 bytes per packet.

Xray runs in userspace and is generally fast enough to saturate a typical home line on modest hardware. Its overhead story is different because it proxies streams: your TCP connection to a website is terminated at your client and re-created at the server, and the bytes travel inside a TLS session. There is no inner IP packet to fragment, so the MTU problems that dog WireGuard behind PPPoE or mobile carriers mostly do not arise. The cost is that everything travels inside one TCP connection per proxied connection, and TCP over a lossy path slows down sharply.

SituationBest fitWhy
Home or office network, nothing blockedWireGuardFastest, simplest, roams between networks
Firewall allows only web ports, no inspectionOpenVPN over TCP 443, or XrayBoth get out on 443
Network inspects and blocks VPN protocolsXray with RealityLooks like HTTPS to a real site
Very lossy mobile or satellite linkWireGuardUDP does not stall on loss
Existing company PKI and audit requirementsOpenVPNCertificates, mature tooling

Why is my VPN slow works through the cases where none of them is fast and how to find out which part of the path is to blame.

UDP, TCP and what that means for games and calls#

Games and voice calls run on UDP because a late packet is worthless and a lost one should be skipped, not resent. TCP vs UDP for game servers explains why.

WireGuard carries UDP as UDP. A lost packet is lost once, the game shrugs, and the next one arrives on time. OpenVPN over UDP behaves the same. OpenVPN over TCP does not: the game's UDP is wrapped in a TCP stream, a single lost segment holds back everything behind it until it is retransmitted, and the game sees a burst of lag followed by a flood of stale packets. Running TCP connections inside an OpenVPN TCP tunnel is worse still - two layers of retransmission timers fighting each other, the classic TCP meltdown.

Xray relays UDP too, but over its TCP connection, so UDP inherits TCP's head-of-line blocking whenever the path drops packets. On a clean path you will not notice. On a congested evening connection a game can stutter in a way it would not over WireGuard. This is the honest limit of a censorship-resistant design: it hides by looking like TCP web traffic, and TCP web traffic is not what games want. Does a VPN lower ping in games takes this further.

Ports and firewall rules#

ProtocolPortTransportNotes
WireGuard51820UDPConvention from the docs, not a requirement; any port works
OpenVPN1194UDP (or TCP)IANA-assigned; proto tcp and port 443 for restrictive networks
Xray Reality443TCPHas to be 443 to look like HTTPS
OpenVPN over TCP443TCPConflicts with a web server on the same address unless shared

WireGuard is silent to anything without a valid key: it does not answer unauthenticated packets at all, so a port scan sees nothing. OpenVPN with tls-crypt or tls-auth drops unauthenticated packets early too. Xray with Reality answers on 443 like the website it borrows, which is the point.

Sample server snippets, so you can see how little each needs at its core:

wg0.conf (server)
[Interface]Address = 10.8.0.1/24ListenPort = 51820PrivateKey = <server private key>[Peer]PublicKey = <laptop public key>AllowedIPs = 10.8.0.2/32
server.conf (OpenVPN, excerpt)
port 1194proto udpdev tundata-ciphers AES-256-GCM:CHACHA20-POLY1305tls-crypt ta.key

An Xray client is usually configured from a single share link rather than a file:

code
vless://<uuid>@203.0.113.10:443?encryption=none&flow=xtls-rprx-vision  &security=reality&sni=<borrowed site>&fp=chrome&pbk=<public key>  &sid=<short id>&type=tcp#my-server

The link is one line in practice; it is broken here only to fit. Every field matters: the UUID identifies you, pbk is the server's Reality public key, sid is a short ID the server accepts, and sni is the site whose handshake is borrowed.

Client apps on each platform#

PlatformWireGuardOpenVPNVLESS / Reality
WindowsWireGuard for WindowsOpenVPN Connect, OpenVPN GUIv2rayN, Hiddify, and on RE:NODE the Renode VPN app
macOSWireGuard (App Store)Tunnelblick, OpenVPN ConnectHiddify and other VLESS clients
AndroidWireGuardOpenVPN for Android, OpenVPN Connectv2rayNG, Hiddify
iOS / iPadOSWireGuardOpenVPN ConnectStreisand, Shadowrocket, Hiddify
Linuxwg-quick in the kernel toolsopenvpn package, NetworkManagerXray core, Hiddify

WireGuard and OpenVPN have official, first-party apps. Xray's ecosystem is community-built: many clients from many developers, most of them open source, some (Shadowrocket) paid. That makes it less tidy, but in practice the share link format is common to all of them, so the same vless:// link imports into each. The VLESS client setup guide walks through the four common ones.

One difference people trip on: WireGuard and OpenVPN apps create a system VPN and capture everything by default. Some VLESS clients default to a system proxy mode on desktop, which only covers applications that honour the proxy setting - browsers yes, many games and command-line tools no. Look for a VPN or TUN mode if you want everything to go through.

Which one, by situation#

  • You run a home lab and want to reach it from your phone. WireGuard. Nothing else is as quick to set up or as pleasant to live with.
  • Your workplace already runs OpenVPN. Stay with it. Certificates, revocation lists and existing tooling are worth more than a few percent of speed.
  • You travel through networks that block VPNs, or live behind one. Xray with Reality. WireGuard and OpenVPN will simply fail to connect, often silently.
  • You want the fastest possible game connection. Probably no VPN at all - see the gaming post linked above - and if you need one, WireGuard over UDP.
  • You want privacy from the network you are sitting on (hotel, cafe). Any of the three works if the network allows it. VPN on public wifi covers what that actually protects.

None of them makes you anonymous. Each moves trust from your local network and ISP to whoever runs the server. With your own server, that is you, and the address the world sees is yours too. What a VPN protects and what it does not sets out the threat model properly.

What RE:NODE runs, and why#

RE:NODE's private VPN line runs Xray with VLESS and Reality and nothing else - not WireGuard and not OpenVPN. The reason is the detectability column: a server that only works on friendly networks fails exactly where people most need it. Each server has its own address and its own key, with nobody else on it, and no traffic cap. Windows uses the Renode VPN app, which takes the link your server prints and connects; phones and Macs use any VLESS client - v2rayNG, Hiddify, Streisand or Shadowrocket - with the same link. The server is in Germany, so latency is set by your distance to it.

If WireGuard is the right answer for you - an unrestricted network, a game-first use - a general-purpose VDS where you install it yourself is the better fit, and the dedicated server line is where that lives.

FAQ#

Is WireGuard more secure than OpenVPN?

Neither has a known practical break when configured sensibly. WireGuard's advantage is a far smaller codebase with no cipher negotiation, which leaves less room for misconfiguration and downgrade attacks. OpenVPN's flexibility is also its risk: old configs with weak ciphers or no tls-crypt are common.

Can I hide WireGuard by running it on port 443?

No. The port is not what gives it away; the fixed handshake sizes and message types are. UDP on 443 that is not QUIC is, if anything, more conspicuous. Hiding WireGuard means wrapping it in something else, at which point you have built a worse Xray.

Is Xray slower than WireGuard?

On a clean, unrestricted connection WireGuard is usually somewhat faster, especially on weak CPUs and for UDP traffic. For browsing and streaming on a typical home line the difference is rarely noticeable. On networks that block WireGuard the comparison is moot - one connects and the other does not.

Does VLESS encrypt my traffic?

VLESS itself does not; it is deliberately a thin protocol. Encryption comes from the layer under it, which with Reality is TLS 1.3. A VLESS setup without TLS or Reality would send traffic in the clear, which is why no sensible configuration does that.

Which protocol do the big commercial VPNs use?

Most now default to WireGuard or their own WireGuard-based variant, with OpenVPN kept for compatibility. Some add an obfuscated mode for restrictive networks. Xray-based setups are more common among people running their own servers and in regions with heavy filtering.


Comments

Completely anonymous: no account, no email, no cookie. We store the name you type, the text and the time - nothing else. Links are limited and markup is not rendered.

0/2000