Do VPNs Slow Down Internet Speed? Causes and Fixes

Short answer: do VPNs slow down internet speed?

Yes, to some degree: your traffic does more work and travels farther. How much depends on the server's distance and load, the protocol, your device and your own connection, so a percentage quoted online says little about your setup. What matters is the gap you measure yourself.

The slowdown shows up in two ways:

• Lower throughput (Mbps): large downloads and uploads take longer, usually because of server capacity, the protocol or your local network.
• Higher latency (ping): each request waits longer for a reply, so sites that make many small requests feel sluggish even when a speed test looks fine; distance and routing are the usual causes.

What counts as normal

Will a VPN slow down your internet enough to notice? On a nearby, healthy server with a suitable protocol, browsing usually feels close to normal. The pattern of your results says more than any single figure:

• Expected: ping rises by roughly what the detour to the server suggests, and results are similar from one test to the next.
• Worth investigating: speeds swing widely between runs, ping is far higher than the distance explains, or large downloads stall.

A VPN cannot raise the ceiling of your internet plan or make up for a weak Wi-Fi signal, so always compare against your own baseline.

Why does a VPN slow down your internet speed?

The slowdown is the sum of several small costs, and sometimes one of them dominates.

Encryption and encapsulation

Each packet is encrypted on your device, wrapped in extra headers and decrypted at the server. The headers take space that would otherwise carry data, and encryption takes processor time. On current phones and laptops that cost is rarely the limit; it shows on older or low-power hardware, such as a budget router running a VPN client.

The extra hop

Without a VPN, traffic goes from your provider straight toward the website. With one, it goes to the VPN server first, and replies return the same way. If the server is roughly on the way, the detour is small; if not, every request pays for it in both directions.

Shared server capacity

Everyone connected to a VPN server shares its network link and processor, so at busy hours a loaded server can become the bottleneck, however fast your own line is.

DNS lookups and connection setup

With the VPN on, name lookups usually go through the tunnel to a resolver on the VPN side, so an uncached lookup costs a round trip to the server. Some protocols also add round trips whenever a new connection opens.

Protocol overhead: WireGuard-based vs TLS-based

The protocol decides how your traffic is packaged and how the tunnel reacts to lost packets. Flex-VPN offers two types of profile with different trade-offs.

WireGuard and AmneziaWG over UDP

WireGuard sends each packet as an encrypted UDP datagram with a small fixed overhead: about 60 bytes per packet over IPv4 and 80 over IPv6. That is why a common default tunnel MTU is 1420 bytes, 1500 minus the 80-byte worst case. UDP does not retransmit, so lost packets are recovered by the apps inside the tunnel, just as without a VPN. AmneziaWG is based on WireGuard and adds extra masking of its service packets while keeping WireGuard's encryption and lean design, so its overhead stays small too.

VLESS + Reality over TCP and TLS

A VLESS + Reality profile carries your traffic inside a TLS connection over TCP, so it looks like ordinary HTTPS. For bulk data the extra bytes are small; the costs show up elsewhere. Each new connection needs extra round trips to the server for the TCP and TLS handshakes. When a packet is lost on the way to the server, later data waits until it is resent, and TCP lowers its sending rate. App traffic sent over UDP, such as voice calls, inherits those delays too.

These costs grow on a lossy mobile or Wi-Fi link. The reverse also happens: some networks handle UDP poorly, and there a TCP-based profile can be quicker.

If one profile feels slow, test the other on the same network. See AmneziaWG vs VLESS + Reality for the full comparison and WireGuard vs OpenVPN for how tunnel designs affect speed.

Server distance, load and routing

Distance matters mainly through latency. Light in optical fiber covers roughly 200 km (125 miles) per millisecond, so every extra 1,000 km of cable adds about 10 ms to each round trip. Real cable routes are longer than a straight line, so a server on another continent adds noticeable delay.

Latency also limits throughput. A single TCP connection keeps only a limited amount of unacknowledged data in flight and speeds up one round trip at a time, so the longer the round trip, the lower the speed one download can reach. That is why a distant server can post decent numbers in a multi-connection speed test yet feel slow for a single large file.

Load

If speed drops in the evening and recovers late at night, server load is the likely cause, and another server or location is the practical fix.

Routing

Distance on the map is not distance in the network: your provider may reach a nearby data center by an indirect path and a slightly farther one directly. Websites and content delivery networks also tend to answer from a node near the VPN server, so its location shapes the second half of the route too. Flex-VPN has locations in Europe, including Germany, the Netherlands, Finland, Denmark and Romania; compare a few and keep the one that performs best from where you are.

How to measure VPN speed fairly

A single test with the VPN on tells you little. What you need is the gap against your normal connection under the same conditions.

1. Use the same device and network throughout, and pause downloads, cloud sync and updates.
2. Run a baseline test with the VPN off and note download, upload and ping.
3. Connect the VPN and test against the same speed-test server. Many tools auto-select one near the VPN server, so pick it manually.
4. Repeat each test two or three times and use the typical result, not the best one.
5. If results jump around, repeat the set at another time of day to separate server load from a local problem.
6. Note the location and protocol for every run so you compare like with like.

Look beyond the download figure:

• Ping shows the cost of the extra hop; a large rise points to distance or routing.
• Jitter, the variation in ping, points to an unstable link, often Wi-Fi or a weak mobile signal.
• Upload is easy to overlook but matters for video calls and cloud backups.
• Real use is the final check: time a page load or one large download, because a speed test's parallel connections can hide single-connection problems.

Device and network bottlenecks: Wi-Fi, MTU, battery saver

Many slow VPN connections are really slow local connections that only get noticed while the VPN is on.

Wi-Fi

Signal strength, interference and the band set the ceiling for everything else. The 2.4 GHz band is crowded and slower; 5 GHz is faster at short range but weakens quickly through walls. Test once next to the router, or over a cable, to see what your line really delivers.

MTU

Every tunnel packet must fit inside the largest packet the network path can carry; when it does not, packets are fragmented or silently dropped. The symptom is odd behavior rather than evenly low speed: small pages open, but large pages or downloads stall and some apps hang while connecting. This mostly affects UDP tunnels such as AmneziaWG, since a TCP-based profile adjusts its segment size itself. If your client lets you set the MTU, lower it in small steps and test again; 1280, the minimum MTU for IPv6, is a conservative value.

Change the MTU only if you see stalls or half-loaded pages, and note the original value first. Lowering it on a healthy connection reduces efficiency slightly and makes nothing faster.

Battery saver and background limits

Low-power modes reduce processor performance and limit background activity. On some Android phones, aggressive battery optimization pauses or restarts the VPN app, which looks like random slowdowns or reconnects; excluding the app from battery optimization often fixes it.

Step by step: how to make a slow VPN faster

Start from your measurements, then work through these in order and re-test after each change, so you know what actually helped.

1. Switch location. If your subscription includes several locations, try two or three nearby ones and keep the one with the lowest, steadiest ping.
2. Try the other protocol. If you use AmneziaWG, test a VLESS + Reality profile on the same network, or the other way round.
3. Fix the local link. Move closer to the router, switch to 5 GHz, or test over a cable or another network.
4. Remove competing tunnels. Running two tunnels at once is a common cause of slow connections, so disconnect other VPNs and proxies. Pause web-traffic inspection in security software while testing, then turn it back on.
5. Check power and MTU settings. Turn off battery saver, exclude the VPN app from battery optimization, and lower the MTU in small steps only if pages stall.
6. Keep apps and servers current. Update your VPN apps (see the download page); in Happ, the Flex-VPN subscription link keeps the server list up to date.
7. Route heavy traffic around the tunnel with split tunneling.

Split tunneling as a speed lever

The VPN does not have to carry everything. With split tunneling, available in the compatible clients, you choose which apps or sites use the VPN and let the rest go direct. Large system and app updates rarely need the extra hop; routing them directly leaves more capacity for traffic you want protected. Traffic outside the tunnel is not covered by the VPN's encryption, so choose exclusions deliberately. The split tunneling guide explains how the rules work.

If the gap stays large on every location and protocol, send your measurements (with and without the VPN, plus location, protocol, device and network type) to support. If the VPN does not connect at all, start with Why is my VPN not working? instead.