A VPN making internet noticeably slower — pages loading sluggishly, downloads half their normal speed, video calls dropping quality — is one of those problems where expectations and reality often don’t match. The first question worth asking: how slow is “slow”? If you’re getting 70% of your normal speed through a VPN, that’s actually excellent. Most VPNs cause some overhead. But if you’re getting 10-20% of normal speed, something specific is wrong and it’s fixable. For a broader walkthrough, our Complete Guide to Fixing Windows, Browser, and Software Errors is a good next read.
Run a baseline test. Normal speed test without VPN → note the result. Speed test through VPN → compare. A 10-20% reduction is typical encryption overhead. A 50%+ reduction means there’s a specific bottleneck worth investigating.
Server choice — the biggest single variable
VPN speed is dominated by two things: the distance to the server and how loaded that server is. A server 10ms away nearly always outperforms one 200ms away, regardless of other configuration. Many VPN clients default to “automatic” server selection that sometimes picks suboptimally.
Manually try several servers in your own country or a neighbouring one. In most VPN apps: open the server list → sort by load (lower is better) or distance → connect to a few and run speed tests on each. Keep the one that performs best. Returning to “automatic” after this often helps because the client recalibrates, but a manually-chosen low-load nearby server typically beats automatic selection.
WireGuard vs older protocols
The VPN protocol determines how much CPU overhead each packet of encrypted traffic requires. WireGuard is the modern standard: leaner code, fewer CPU cycles per packet, lower latency. OpenVPN TCP is at the opposite end: reliable but computationally heavy. If your VPN client defaults to something other than WireGuard: switching is often the fastest single improvement.
Check your VPN client’s settings for a “Protocol” or “Connection” menu. If you see WireGuard, NordLynx, Lightway, or a similar modern-lightweight name: try it. If you’re currently on OpenVPN TCP: first try OpenVPN UDP (same protocol, less overhead), then WireGuard if available. The performance difference can be dramatic on older hardware.
Split tunnelling — the practical speed saver
Not all traffic needs VPN protection. Video streaming, music, large downloads — these benefit from the VPN’s privacy on public Wi-Fi but can run unencrypted on your home network without meaningful risk. Split tunnelling routes only specific traffic through the VPN and lets everything else use the direct connection.
Most premium VPN clients (NordVPN, ExpressVPN, Mullvad, ProtonVPN) have split tunnelling in their settings. Add bandwidth-heavy applications to the “bypass” list: your streaming service, Steam, Spotify, cloud backup clients. These then run at full speed while your browser and other apps stay VPN-protected.
This approach achieves a good balance: privacy where you need it, full performance where you don’t. Worth trying before upgrading hardware or switching providers.
ISP interference and throttling
Some ISPs deprioritise traffic they identify as VPN on congested networks, or throttle specific ports associated with VPN protocols. If VPN speed drops specifically during peak evening hours but is fine at 3am: ISP congestion shaping is likely.
Mitigation: use a VPN protocol that disguises traffic as regular HTTPS (port 443). Some providers call this “Obfuscation” or “Stealth” mode — it wraps VPN traffic in HTTPS so it’s indistinguishable from web browsing. This bypasses protocol-specific throttling. Not all VPN apps support it; check your provider’s documentation for the option.
Our guide on network connectivity issues covers the connection-level problems that sometimes worsen with VPN active, and our VPN connection failure troubleshooting covers situations where the VPN won’t connect at all rather than just being slow. For protocol comparisons and security trade-offs across VPN options, Mullvad’s documentation and ProtonVPN’s blog cover technical protocol details accessibly without requiring deep networking knowledge.
DNS inside the VPN tunnel
DNS lookups happen even when using a VPN. If VPN DNS is slow (the VPN provider’s DNS server is overloaded or geographically far): every page load has an extra 100-500ms of DNS lookup time. This doesn’t show up in speed tests but makes browsing feel sluggish even when download speed looks fine.
Check: run a DNS benchmark. Gibson Research Corporation’s DNS Benchmark (free) tests response times from your current connection. While connected to VPN: run the test → see if your VPN’s DNS server appears significantly slower than alternatives. If yes: check whether your VPN client allows custom DNS (some do, some don’t) and try entering 1.1.1.1 as a custom DNS server. This uses Cloudflare’s fast DNS rather than the VPN provider’s potentially-slower resolver.
Local network and router configuration
Running the VPN client on the laptop rather than the router means the laptop’s processor handles all encryption. For older laptops (particularly those without AES-NI hardware acceleration), this creates a CPU bottleneck that limits VPN speed.
Quick test: watch CPU usage during a VPN speed test. Task Manager → Performance → CPU. If CPU spikes to 80-100% during the test: you’ve hit the encryption bottleneck. WireGuard is significantly lighter than OpenVPN on this metric — switching protocols often resolves CPU-limited VPN speed on older hardware.
For users who want VPN protection for the whole home network without performance overhead on individual devices: running the VPN on the router offloads all encryption to the router’s CPU. This frees the laptop from encryption work entirely. Routers with dedicated VPN hardware (ASUS with ASUS AI protection, GL.iNet routers, Synology RT) handle this more efficiently than running VPN clients on every device.
Provider quality actually matters
Free VPNs and very cheap VPNs often oversell server capacity. With thousands of users sharing the same servers, peak-time speeds drop dramatically. The bandwidth-per-user ratio is the underlying factor, and budget providers have poor ones.
Provider reputation for speed (with supporting evidence):
- Mullvad: consistently fast, no-logs verified, flat pricing
- ProtonVPN: fast on paid plans, free tier adequate for occasional use
- ExpressVPN: fast, though expensive
- NordVPN / Surfshark: variable, generally good, best with servers not in peak demand
If you’re paying for a premium VPN and seeing less than 50% of your native speed at off-peak hours: either switch server locations or consider switching providers. The cost difference between a mediocre and a good VPN is often £2-3/month — the performance improvement is usually worth it.
MTU and packet fragmentation
VPN tunnels add encryption headers to every packet, reducing the usable payload per packet. If the resulting packet size exceeds the network’s MTU (Maximum Transmission Unit), packets get fragmented and reassembled, which adds latency and overhead.
Most modern VPN clients auto-configure MTU to avoid this. If yours doesn’t, or if you’re on a network with non-standard MTU (some mobile data networks, some corporate connections): manually set the MTU in the VPN client to 1380-1420. This leaves enough room for VPN overhead without fragmentation. Check your VPN client’s advanced settings — most expose MTU configuration.
When VPN speed is “fine” but feels slow
Sometimes measured speed looks good (say, 80% of normal) but browsing feels noticeably slower. Usually DNS latency or round-trip time is the culprit rather than bandwidth. A VPN server on the other side of the world adds 150-200ms of latency to every server request. Pages with many separate assets (images, scripts, fonts from different domains) each incur this latency, compounding the effect. The page feels slow even though each individual file downloads at normal speed.
The fix: choose a geographically closer server. Within 50-100ms of your real location, the perceptual latency added by the VPN is negligible. Across continents, it’s unavoidable physics — light doesn’t travel faster than that through fibre. Accepting a slightly closer server country (instead of insisting on connecting through a distant preferred location) resolves perceived slowness without changing measured speed.
| Scenario | Likely cause | Fix |
| 50%+ speed reduction all the time | Protocol overhead or distant server | Switch to WireGuard; choose closer server |
| Speed fine but pages feel slow | High latency (distant server) | Use geographically closer server |
| Slow during evening, fine at night | ISP throttling or server congestion | Try different server; enable obfuscation mode |
| Only streaming is slow through VPN | CDN detection / geo-blocking | Split tunnel streaming apps; or try different VPN endpoint |
| CPU 100% during VPN speed test | Encryption bottleneck on older CPU | Switch to WireGuard; or run VPN on router |
| Fine yesterday, slow today | Server load spike or provider issue | Switch to a different server in same country |
VPN speed issues are rarely permanent problems — they’re configuration choices. Server selection, protocol choice, and split tunnelling together resolve the majority of real-world VPN performance complaints without needing to change providers or hardware. The baseline speed test (with and without VPN) is the essential starting point, because it defines what “slow” actually means for your specific connection.
VPN and gaming — a special case
Gaming through a VPN has specific considerations. Ping (latency) matters far more than download speed for online games. A VPN that delivers 80% of download speed but adds 40ms of round-trip latency makes fast-paced multiplayer noticeably worse. Competitive games are sensitive to even 20ms of added latency.
For gaming: use a VPN only when there’s a specific reason (accessing games in other regions, protecting against DDoS attacks on your home IP, accessing game servers that are restricted in your location). For routine gaming: bypass the VPN via split tunnelling for your game client and game servers. This keeps your general browsing protected while gaming at full native performance.
Some VPN providers specifically market “gaming VPN” features — dedicated gaming servers with low latency routing. These are sometimes genuinely faster for gaming workloads because they prioritise low-latency routing over throughput optimisation. If gaming performance through VPN matters specifically, test providers that offer game-focused servers.
Mobile devices and VPN speed
VPN behaviour on mobile (phone, tablet) differs from desktop. Cellular data connections have variable MTU, higher baseline latency, and carrier-level traffic shaping that interacts unpredictably with VPN protocols. IKEv2 is generally better than WireGuard on mobile for maintaining connections through network switches (moving between Wi-Fi and cellular, or between cell towers).
Battery impact is also a consideration on mobile. WireGuard uses less CPU per packet, which means less battery drain for equivalent VPN usage. OpenVPN is noticeably heavier on mobile batteries during sustained use. If you run a VPN constantly on your phone: WireGuard is the right protocol choice for both speed and battery.
When the simplest explanation is right
Most VPN speed complaints come from users who are connecting to servers far away and expecting no performance impact. VPNs add at minimum the round-trip time to the VPN server (which can’t be reduced) plus encryption overhead (which can be reduced with WireGuard). Setting realistic expectations alongside correct configuration produces a VPN experience that genuinely works well for everyday use.
The practical outcome most users should aim for: WireGuard protocol → closest available server with low load → split tunnelling enabled for streaming and gaming → speed at 70-85% of native connection. This is achievable on virtually all premium VPN providers and represents a good balance between protection and performance. Getting closer to native speed requires dedicated hardware (VPN at router level) or accepting zero-overhead VPN isn’t possible — encryption costs something.
Multihop and double VPN — when more security means less speed
Some VPN providers offer “double VPN” or “multihop” routing: your traffic goes through two VPN servers before reaching the destination. This adds a second layer of encryption and makes traffic analysis much harder. It also adds significant latency (two hops instead of one) and further reduces throughput.
If multihop is enabled and speed is poor: disable it. Single-hop VPN is adequate privacy for virtually all everyday use cases. Multihop is for specific high-security scenarios (journalists, activists) where the additional security justifies the performance cost. For routine privacy from ISP surveillance or public Wi-Fi: single-hop is the right choice and runs significantly faster.
Testing with iperf for accurate local measurement
Standard speed tests (Speedtest.net, fast.com) measure performance to a specific server. Through a VPN, your traffic routes through the VPN endpoint, which changes which speed test servers are reachable and how. For a more accurate measure of VPN overhead specifically: use iperf3 to test throughput between two points you control.
iperf3 running on a home server or a VPS gives you a direct measurement of VPN throughput without CDN or speed test server variables. Run iperf3 without VPN → note bandwidth. Run with VPN → compare. The difference is purely VPN overhead, isolated from internet connection quality and test server location. This is a more accurate way to measure the actual cost of the VPN versus your native connection.
Most users don’t need this level of measurement — comparing fast.com results with and without VPN is sufficient for practical purposes. But for diagnosing a specific VPN performance problem, iperf3 provides cleaner data that clearly identifies whether the bottleneck is the VPN itself or something else in the network path. You might also run into VPN Slow Internet.
