Picking a VPN that stays up when everyone logs in

I was on a video call in a noisy cafe, laptop tethered to my phone, trying to push a quick hotfix before the next meeting. The VPN held for twenty minutes, then dropped right when the screen share started.

The part that annoyed me wasn’t the drop. It was the reconnect loop: connect, handshake, hang, disconnect, repeat. That’s when I stopped judging VPNs by how pretty the website looks.

Peak hours are real.

When it dies at 7 p.m., it’s usually not your Wi‑Fi

A lot of people blame their router first. Sometimes that’s fair, especially on congested 2.4 GHz. But peak-hour disconnects have a pattern: things are fine mid-day, then fall apart when everyone gets off work, launches streaming apps, and hammers the same regional servers.

What’s actually happening depends on the stack.

On the provider side, overloaded exit nodes lead to queueing and packet loss. On the client side, aggressive timeout settings interpret that loss as a dead tunnel. On mobile, it gets messier because you’re switching between LTE and Wi‑Fi (or even between two LTE towers) and NAT state changes under your feet.

Latency spikes happen.

The giveaway is this: if you can browse a few sites but long-lived connections (SSH, RDP, VoIP, video calls) keep resetting, you’re looking at stability, not “speed.” A VPN can look fast in a one-off speed test and still be miserable for real work.

A few practical causes I keep seeing:

• Overbooked servers in popular cities. The provider has the location, but not enough capacity.
• UDP intolerance on certain networks (some office Wi‑Fi and hotel networks are notorious).
• CGNAT and roaming on mobile, which breaks tunnels that don’t handle path changes gracefully.
• Bad MTU defaults that cause fragmentation and weird stalls, especially on tethering.

If a VPN vendor talks only about “fast” and never about congestion, routing, or drop behavior, that’s a smell.

Protocol choice is the boring part that decides everything

If you want fewer disconnects, protocol matters more than the brand name. Not because one protocol is magic, but because different designs cope differently with packet loss, NAT rebinding, and interference.

Here are the ones I actually see in the wild, and what they tend to feel like at peak time:

• WireGuard (UDP): usually the best default for stability and battery. It reconnects cleanly, and the codebase is small. The catch is some networks are hostile to UDP.
• OpenVPN (UDP/TCP): slower and heavier, but it has years of battle testing. TCP mode can punch through restrictive networks, but TCP-over-TCP can get sluggish and “sticky” when packets drop.
• IKEv2: underrated on iOS and macOS because it handles roaming well. If you bounce between Wi‑Fi and LTE a lot, it can behave better than you’d expect.
• VLESS+REALITY / Shadowsocks-2022: not “VPN protocols” in the traditional sense, but if you’re using clients like Hiddify, NekoBox, or Shadowrocket, these can be more resilient on networks that mess with classic VPN traffic.

Battery drain matters.

On phones, the “stable” option is often the one that doesn’t force the radio to wake up constantly. WireGuard tends to be friendly here, but only if the app isn’t doing overly aggressive keepalives.

One more thing people miss: many disconnects aren’t a total failure. They’re brief stalls that trip the app’s watchdog. Some clients bail too fast.

The unglamorous provider clues that predict peak-hour pain

You can’t see a provider’s internal capacity, but you can infer a lot from how they expose (or hide) their network.

If every city is a single dot on a map with no server load info, you’re blind. The better VPN apps show at least some notion of load, latency, or a “recommended” server that changes over time. I don’t need a perfect dashboard, I just want to know whether the app is guessing or measuring.

Also pay attention to server geography versus the locations you actually use. A provider can list 80 countries and still route you through a crowded transit point. If you’re in Southeast Asia and the “nearby” option hairpins through another region during peak hours, you’ll feel it as jitter and micro-disconnects.

A few concrete questions I ask before I trust a VPN for daily work:

Does it support WireGuard and IKEv2, or am I stuck on a single tunnel type?

Do they have a sane story for routers? If you run OpenWrt, pfSense, or even a basic GL.iNet box, a stable VPN on the router can be nicer than having every device flapping on its own.

Do they offer enough server variety in the region I care about (not just one “Singapore” and one “Tokyo”)? I’m not looking for a huge list. I’m looking for choice when one node is having a bad night.

And, honestly, support matters here. Not for refunds. For debugging. A provider that can answer “try MTU 1280 on WireGuard” or “switch this server group, that one is saturated” is living in reality.

Client settings that stop the flapping

Most people install a VPN app, hit connect, and never open settings again. That’s fine until it isn’t.

If you’re dealing with peak-hour drops, a couple toggles can change the experience more than switching cities all night.

Here’s what I check on Windows, macOS, iOS, and Android clients (the labels vary by app):

1. Kill switch behavior: a strict kill switch is great for privacy, but it can make reconnect loops feel worse because everything looks “down.” Some apps let you keep LAN access or allow a short grace period. 2. Persistent keepalive / heartbeat: on flaky mobile networks, a keepalive can keep NAT mappings from expiring. Too aggressive, though, and your battery pays for it. 3. MTU: if things connect but stall on larger transfers, try a lower MTU. WireGuard often behaves with 1280 on troublesome links. 4. Auto-connect rules: connect on untrusted Wi‑Fi, not on every network. Connecting and reconnecting all day can create the illusion of instability.

Split tunneling is worth a mention too. If you’re trying to keep a video call stable, sending everything through the tunnel may not be the smartest move. I often split-tunnel latency-sensitive apps (Zoom, Teams) away from the VPN while keeping browsers and work tools inside it.

Yes, that’s a trade-off.

If you’re using proxy-style clients like V2RayNG or NekoBox, you also get transport knobs (TCP vs gRPC vs WebSocket, different ports, different SNI settings). Those can help on hostile networks, but they also add more ways to misconfigure things. Keep your changes minimal and write down what you touched.

How I test a VPN before I commit to it

Speed tests are a warm-up. They don’t tell you if the tunnel is going to survive a busy evening.

When I’m evaluating a VPN, I test for drop behavior, not bragging rights. This is the routine that’s saved me from a bunch of “works on my machine” surprises:

1. Connect to the server I’d actually use. 2. Start a long ping (or just keep an SSH session open) and watch for packet loss and pauses. 3. Run a real task: a Git pull/push, an RDP session, or a 20–30 minute call. 4. Switch networks mid-session (Wi‑Fi to LTE) if I’m testing mobile stability. 5. Repeat during the local evening, when load is highest.

If the tunnel survives a network switch and doesn’t get stuck in reconnect loops at peak time, it’s already beating half the market.

A small but useful trick: if your VPN app supports it, try a “nearby” server that isn’t the default top choice. Default servers get hammered. The second-best option often behaves better just because fewer people click it.

Near the end of my testing, I also check how the provider behaves on the platforms I actually carry: iOS for quick tethering, Android for travel, macOS for work, and an OpenWrt box at home. If the iOS client is stable but the Windows client is flaky, that’s still a problem for me.

If you want a provider that’s been reliable for me during crowded hours, DuduVPN is worth a look, and their Telegram bot (https://t.me/duduvpnsbot) is a straightforward way to get set up without hunting through app store clones.

Whatever you pick, do one peak-hour test on the network you hate the most before you trust it with your next call.