Why Is My VPN So Slow? 9 Causes and How to Fix Each One

Why is my VPN so slow? Usually for one of nine reasons: the server is far away, the protocol is old (usually OpenVPN), the server is overloaded, the server's own network caps your connection, your network blocks or throttles VPN traffic, your Wi-Fi is the real bottleneck, the VPN runs on a router with a weak CPU, the packet size (MTU) is wrong, or DNS lookups take the long way. Most have a two-minute fix. Start by connecting to the nearest server and switching to WireGuard or VLESS + REALITY. Those two changes solve most slow VPNs.

First: measure how slow is "slow"

Before changing anything, find out what the VPN really costs:

1. Run a speed test with the VPN off (for example speed.cloudflare.com, which also shows latency).
2. Connect to the nearest server and run it again on.
3. Repeat off/on two more times, alternating. Your line changes from minute to minute, and alternating cancels that out.

A healthy, nearby VPN should cost you only a few percent of download speed and a few milliseconds of latency. If it costs half or more, work through the causes below in order.

The 9 causes, and how to fix each

1. The server is too far away

Every packet travels from you to the VPN server and then on to the website. Light in fibre covers about 100 km per millisecond of round trip. A server on another continent can add 100 ms or more to every round trip. Downloads suffer too, because TCP ramps up more slowly over long distances.

Fix: pick a server in your own city or region. Better still, use an app that pings every server and connects to the lowest-delay one automatically. Our low-latency VPN guide explains the numbers.

2. The protocol is old

OpenVPN traditionally runs in user space and slows down badly over TCP, where two layers of retransmission fight each other ("TCP meltdown"). One user who tested both protocols on the same server reported about 300 Mbit/s with OpenVPN against about 900 Mbit/s with WireGuard.

Fix: switch to WireGuard, or VLESS + REALITY with XTLS Vision if you're often on networks that block UDP. Both reach multi-gigabit speeds. See the fastest VPN protocols compared.

3. The server is overloaded

Shared servers slow down at peak hours, usually evenings, when everyone streams at once. If your speed is fine in the morning and drops at night, that's the likely cause.

Fix: switch to another server in the same region. If it happens every evening, the provider is overselling capacity.

4. The server's network caps your connection

This is the cause almost nobody talks about. When we qualified datacenters for our own servers, we found:

• one Tokyo datacenter capped every single TCP connection at about 300 Mbit/s, with no VPN involved, while a site in Osaka about 5 ms away did 3.7 Gbit/s;
• one host capped every UDP flow at about 35–65 Mbit/s, so UDP-based VPN protocols were slow there regardless of design.

Many speed tests open several connections at once and hide caps like these. A single large download doesn't.

Server tuning matters too. Google's BBR congestion control keeps throughput high when packets are lost at random, as on Wi-Fi. In a Google Cloud test with 1% loss, the older CUBIC algorithm reached about 3.3 Mbit/s and BBR over 9,100 Mbit/s.

Fix: try a server in another city. Choose a provider that tests single-connection speed on its hosts and runs modern TCP tuning. Ours run BBR.

5. Your network blocks or throttles VPN traffic

Hotel, café, school and office networks often block UDP, which stops WireGuard and IKEv2, or recognise VPN protocols and throttle or reset them. Your app may then fall back to a slow mode, or keep reconnecting.

Fix: use a protocol on TCP port 443 that looks like ordinary HTTPS, such as VLESS + REALITY. The full diagnosis is in VPN not working on hotel or café Wi-Fi.

6. Your Wi-Fi is the real bottleneck

Often the VPN isn't the problem at all. A weak signal, a crowded 2.4 GHz channel or an older Wi-Fi standard caps your speed before traffic ever reaches the tunnel. In our own home tests, the laptop's 40 MHz Wi-Fi channel was the limit: download through the VPN was about the same as direct, because both hit the Wi-Fi ceiling.

Fix: test with the VPN off. If that's slow too, move closer to the router, switch to 5 GHz or 6 GHz, or plug in a cable.

7. The VPN runs on a router with a weak CPU

Consumer routers often lack the processing power to encrypt at high speed. User reports on the Netgate forum show it starkly. One user got ~475 Mbit/s of a 600+ Mbit/s line in Surfshark's laptop app, but only 15–30 Mbit/s on a router. Another got about 5 Mbit/s of a 200 Mbit/s line with Proton VPN on a router.

Fix: run the VPN app on your devices instead, or use a router with a modern CPU.

8. The packet size (MTU) is wrong

A VPN adds its own headers to every packet. WireGuard adds 60 bytes over IPv4 and 80 over IPv6, and wg-quick lowers the interface MTU by 80 to make room. If your connection's real packet size is smaller (common on PPPoE broadband and some mobile networks), large packets get dropped. Some sites then hang or load halfway.

Fix: lower the MTU in your VPN app (1280 always works over IPv6 paths), or use a TCP-based protocol such as VLESS + REALITY, where the operating system sizes packets automatically.

9. DNS takes the long way

With a VPN on, your device asks the VPN's DNS resolver for every new domain. If that resolver is far away or slow, every new site starts with a delay, even though downloads are fast once they begin.

Fix: use the VPN's own resolver near the server, and don't chain extra DNS services on top. We pick each server's resolver by measured median response time from that server.

How SleekDart avoids these causes

• Nearest city, automatically. The app pings every SleekDart city when it opens and connects to the lowest-delay one.
• A modern protocol everywhere: VLESS + REALITY + XTLS Vision on TCP 443. It's fast, it connects on networks that block UDP, and it doesn't encrypt HTTPS traffic twice.
• Hosts tested before we buy them, for single-connection TCP and UDP speed. Servers run BBR.
• Measured results: on café Wi-Fi, 182–202 Mbit/s through the VPN against 183 Mbit/s direct. One connection between London and Frankfurt carried 2.0 Gbit/s.