WireGuard, OpenVPN, and REALITY: what I actually use

The night airport Wi‑Fi made me rethink “best protocol”

I was sitting on the floor next to an outlet, waiting for a delayed flight, watching my VPN connect… and then instantly die.

Same server. Same phone. Different network.

That’s the day I stopped asking “what’s the best protocol?” and started asking “what does this network allow, and what can my device keep alive without cooking the battery?”

Protocols aren’t vibes. They’re trade-offs. Some are fast and fragile. Some are slow and stubborn. Some are built for places where the network is actively trying to ruin your day.

WireGuard is the daily driver, until it isn’t

When someone says “use WireGuard,” I get it. It’s clean, modern, and usually the fastest thing you can run on consumer hardware. It uses UDP, it keeps the crypto tight, and it tends to feel snappy on mobile.

It’s also picky.

A lot of public Wi‑Fi setups are weird about UDP. Some carriers do aggressive traffic shaping. And in places with heavy filtering, WireGuard handshakes can stick out unless you wrap them in something else. If the network drops UDP packets or plays games with NAT timeouts, you’ll see the classic symptom: it connects, you get a few seconds of traffic, then nothing.

Battery is where WireGuard shines. On Android and iOS, it usually holds a tunnel with less overhead than OpenVPN. That matters if you’re tethering, walking around, or flipping between LTE and Wi‑Fi. WireGuard’s roaming is genuinely good in practice.

Latency tends to be lower too, partly because it’s simpler and partly because many providers tune their WireGuard stacks well. But you can still get bitten by MTU issues. If you see sites half-load on mobile data, it’s often PMTUD being blocked somewhere in the path. Dropping the MTU a bit on the client can make the “random” breakage disappear.

If you’re the type who runs a router VPN, WireGuard on OpenWrt is hard to beat. Low CPU, predictable behavior, and it doesn’t turn your little ARM box into a space heater.

OpenVPN: slower, louder, annoyingly reliable

OpenVPN is old enough to have scars. That’s not an insult. It’s why it still works in networks that hate you.

If WireGuard is the sports sedan, OpenVPN is the dented pickup truck that starts every morning.

The big trick is TCP 443. When you run OpenVPN over TCP and stick it on port 443, a lot of captive portals and corporate networks treat it like “just more HTTPS.” It’s not really HTTPS, and deep inspection can still spot it, but you’d be surprised how often basic filtering gives up.

There’s a catch, and it’s an annoying one: TCP over TCP can get ugly. If your OpenVPN tunnel is TCP and the traffic inside is also TCP (which is most web traffic), packet loss can trigger backoff on both layers. That’s when the connection feels like it’s wading through mud. On shaky mobile links, you can watch latency spike and pages stall.

So I tend to think of OpenVPN like this:

• When the network is hostile or locked down, OpenVPN TCP is my “make it work” option.
• When the network is normal, OpenVPN UDP is fine, but I’d rather use WireGuard.

On desktops (Windows, macOS), OpenVPN clients are mature and boring, which is a compliment. On iOS, it’s okay. On Android, it works, but I notice more battery drain compared to WireGuard when I leave it connected all day.

REALITY, Shadowsocks, and the stuff you use when blocking gets serious

If you’ve never had your VPN protocol blocked outright, you can skip this section and enjoy the simpler world. For everyone else: this is where VLESS+REALITY and Shadowsocks-2022 come in.

VLESS+REALITY is commonly used in the Xray ecosystem. The idea, in plain English, is to make the handshake look like something it isn’t, using real TLS fingerprints and server-side behavior that blends in better than a textbook VPN handshake. It’s not magic. It’s just harder to pattern-match.

REALITY setups can be fiddly. Certificates, SNI choices, picking a plausible destination, making sure your server’s clock isn’t drifting, keeping configs in sync across devices. When it works, it’s excellent. When you typo one field, it’s a silent failure and you’ll waste 30 minutes staring at logs.

Shadowsocks-2022 is a different angle. It’s a proxy rather than a full VPN tunnel, and it can be lighter weight. On constrained networks, it sometimes survives where classic VPNs get flagged. It’s also handy when you only need specific apps tunneled, not your whole device.

Client apps matter a lot here. On Android, I keep seeing people rotate between V2RayNG, NekoBox, and Hiddify depending on which one behaves with the current config format. On iOS, Shadowrocket is the one you’ll hear about constantly because it’s flexible and doesn’t get in your way.

If you’re building your own stack, Streisand is still a useful starting point for spinning up servers and configs, even if you’ll probably end up customizing things anyway. Just be honest with yourself about maintenance. These setups aren’t “set and forget.”

Choosing based on your day, not a Reddit ranking

Here’s how I decide, and it’s mostly boring.

If I’m at home, on a normal ISP, and I care about speed: WireGuard.

If I’m on sketchy Wi‑Fi, behind a corporate firewall, or something is blocking UDP: OpenVPN on TCP 443.

If I’m somewhere that actively fingerprints and blocks VPNs: VLESS+REALITY first, then I try Shadowsocks-2022 depending on what I’m doing.

That’s not a moral stance. It’s just time management.

Also, think about what you’re protecting. If you want full-device tunneling on a laptop, a VPN protocol fits naturally. If you mainly want a couple apps to behave (a browser, a messenger), a proxy-based approach can be simpler and sometimes faster.

One more real-world detail: packet loss hurts different protocols differently. Mobile networks can be bursty, especially when you move between towers or switch from LTE to 5G. WireGuard usually recovers quickly, but if UDP is being mangled you’ll feel it. OpenVPN TCP will “work” but feel sluggish. REALITY-based flows can be surprisingly stable, but only if the server is well tuned and not overloaded.

And yes, server location still matters. Even with the perfect protocol, physics is physics.

Small setup habits that save me from support tickets (including my own)

I test protocols the same way every time: connect, open a few heavy sites, start a video, then walk out of the room and let the phone switch to mobile data. If it survives that, it’ll survive most days.

A few habits I’ve learned the hard way:

1. Keep at least two options configured on each device (one VPN like WireGuard or OpenVPN, one censorship-resistant option like VLESS+REALITY). 2. On mobile, watch battery and heat for a day before declaring a protocol “fine.” 3. If things feel randomly broken, try adjusting MTU before you blame DNS or the app. 4. Don’t ignore the client app: V2RayNG vs NekoBox vs Hiddify can change stability even with the same server.

One-sentence truth: the “best protocol” is the one that stays connected.

If you don’t want to babysit configs across Android, iOS, Windows, macOS, and maybe an OpenWrt router, I get why people pick a managed service for the messy parts; I’ve pointed friends at DuduVPN via https://t.me/duduvpnsbot when they just need working profiles without learning Xray parameters.

When you’re troubleshooting, change one variable at a time, and start by switching UDP to TCP (or the other way around) before you touch anything else.