Slow VPN speeds: ten fixes ranked by impact

VPN connections are inherently slower than your bare internet connection—encryption overhead and extra routing hops guarantee that. But when you're seeing speeds 80% below your baseline or buffering on standard-definition video, something's actually wrong. Most users try random fixes. This chapter ranks ten interventions by real-world impact, starting with the changes that actually move the needle.

Before troubleshooting, establish your baseline. Run a speed test without the VPN active using a consistent testing server (Speedtest.net or Fast.com work fine—just use the same one each time). Note your download/upload speeds and ping. Then connect your VPN and test again using the same server. The difference tells you whether you're dealing with normal VPN overhead (20-40% speed reduction is typical) or an actual problem.

Fix 1: Switch protocols (high impact, 30 seconds)

Protocol choice matters more than almost anything else for speed. Your VPN client probably defaults to OpenVPN, which is mature and secure but computationally expensive. Modern protocols like WireGuard deliver 40-60% faster speeds in typical scenarios because they use leaner cryptographic operations and less code.

Most current VPN apps let you switch protocols in settings. Look for options like "Connection protocol" or "VPN protocol." If you see WireGuard, select it. NordVPN calls theirs "NordLynx," which is their WireGuard implementation. If WireGuard isn't available, try IKEv2—it's faster than OpenVPN for most use cases and handles network transitions better.

Run your speed test again after switching. If you're seeing 50%+ improvements, you've found your fix. If WireGuard makes your connection unstable (rare but happens on some networks with aggressive UDP filtering), you'll need to fall back to OpenVPN or IKEv2.

One warning: avoid PPTP even if it's the fastest option in your settings. It's cryptographically broken and defeats the point of using a VPN.

Fix 2: Change server locations (high impact, 15 seconds)

Physical distance between you and the VPN server directly affects latency and often throughput. A server 5,000 miles away adds minimum 100-150ms latency from physics alone—light takes time to travel through fiber.

Connect to the geographically closest server that meets your needs. If you're in Chicago and need a US IP address, choose Chicago or Indianapolis, not Los Angeles. Most VPN apps show server load percentages—avoid servers above 80% capacity. A nearby server at 90% load will perform worse than a slightly more distant one at 40%.

For streaming, the calculation changes. You need an IP address from the content's region, so geography matters for access rather than pure speed. If you're in London accessing US Netflix, you'll accept the transatlantic latency penalty. But within that constraint, choose East Coast US servers over West Coast to minimize distance.

Test 3-4 different servers in your target region at different times of day. Server performance varies significantly based on load, and what's fast at 3 PM might crawl at 8 PM when everyone's streaming.

Fix 3: Use split tunneling for heavy bandwidth apps (medium-high impact, 2 minutes)

Split tunneling routes some apps through the VPN and others through your regular connection. If you're running a large download or streaming 4K video while trying to browse privately, the bandwidth-heavy app can choke everything else.

Configure your VPN to exclude high-bandwidth applications that don't need privacy protection. Game clients, OS updates, and video streaming services are common candidates. You'll find split tunneling in your VPN app's settings, usually under "Advanced" or "Split tunneling."

The privacy tradeoff: those excluded apps expose their traffic and your IP address. Only exempt applications where you've consciously decided the speed gain is worth reduced privacy. Never exempt your torrent client or anything transmitting sensitive data.

Some providers implement this better than others. Good split tunneling operates at the application level (you select specific programs). Weaker implementations only work at the IP or domain level, which requires more technical knowledge and creates maintenance overhead.

Fix 4: Adjust MTU settings (medium impact, 5 minutes, technical)

Maximum Transmission Unit (MTU) defines the largest packet size your connection can send without fragmentation. VPN encryption adds overhead to each packet, and if your MTU is too high, packets fragment and require retransmission, killing throughput.

Your router probably defaults to 1500 bytes MTU. VPN tunnels work better with 1400-1450 bytes to accommodate encryption overhead. Most VPN apps don't expose MTU settings in their interface—you'll need to modify system network settings.

On Windows, open Command Prompt as administrator and run: `netsh interface ipv4 set subinterface "VPN_CONNECTION_NAME" mtu=1400 store=persistent` (replace VPN_CONNECTION_NAME with your actual connection name from network settings).

On macOS/Linux, the approach varies by VPN implementation. If you're using WireGuard configurations directly, add `MTU = 1400` to your configuration file's `[Interface]` section.

Test speeds with MTU values between 1400 and 1450 in increments of 10. The optimal value depends on your specific network path. This fix particularly helps if you see good speeds for small transfers but terrible performance for large downloads—classic fragmentation symptoms.

Fix 5: Disable unnecessary VPN features (medium impact, 1 minute)

Modern VPN apps bundle features that consume resources: ad blocking, malware scanning, double-VPN routing, Tor-over-VPN. Each additional feature adds processing overhead and potential bottlenecks.

Open your VPN settings and disable anything you're not actively using. CyberSec, Threat Protection, multi-hop routing—turn them off unless you specifically need them. Test your speeds after each change.

Double-VPN features route your traffic through two VPN servers in sequence. This roughly doubles latency and cuts throughput significantly. Unless you're in a situation requiring that level of traffic obfuscation, it's overkill.

Built-in ad blockers vary wildly in efficiency. If your VPN's ad blocker is slowing things down, consider disabling it and using a browser extension instead—you can often achieve the same result with less overhead.

Fix 6: Update your VPN client (low-medium impact, 3 minutes)

Outdated VPN software contains unoptimized code and sometimes bugs that cap throughput. Providers regularly release performance improvements, but most apps don't auto-update aggressively.

Check your VPN provider's website for the latest version number and compare it to what's shown in your app's "About" section. If you're more than one major version behind, update. Some providers publish changelog notes mentioning speed improvements—scan these before updating to confirm it's worth the effort.

After updating, you may need to reconfigure protocol settings. Some updates reset preferences to defaults, which might put you back on OpenVPN when you had previously selected WireGuard.

Fix 7: Check for bandwidth throttling (low-medium impact, 10 minutes)

Some ISPs throttle VPN traffic or specific protocols, particularly UDP (which WireGuard and many OpenVPN configurations use). This shows up as initially good speeds that degrade after a few minutes of sustained transfer.

Test if your ISP throttles VPNs by running a long download (a Linux distribution ISO works well). Monitor whether speeds start high and gradually drop. If you see this pattern, try switching your VPN protocol to TCP mode (slower in theory but immune to UDP throttling) or using port 443, which carries HTTPS traffic and is less likely to be throttled.

Your provider's support documentation should explain how to force TCP mode and change ports. These options aren't usually in simplified settings menus—look for "Advanced connection settings" or similar.

Fix 8: Configure DNS settings (low impact, 2 minutes)

Slow DNS resolution causes delays before connections even start. Your VPN probably routes DNS queries through its own servers, which can be slow if they're distant or overloaded.

Most VPN apps let you specify custom DNS servers. Try switching to providers known for speed: Cloudflare (1.1.1.1) or Google (8.8.8.8). The privacy-conscious prefer Cloudflare's DNS over Google's, given Cloudflare's better track record on not logging queries.

This fix primarily reduces latency when establishing new connections rather than improving transfer speeds. You'll notice it most when browsing (loading new websites) rather than downloading large files.

Be aware that using third-party DNS servers creates a privacy consideration—those DNS providers can see which domains you're requesting even though your VPN encrypts the subsequent traffic. Some users prefer slower DNS from their VPN provider to minimize the number of parties that can correlate their browsing patterns.

Fix 9: Check local network factors (low impact, varies)

Your local network's limitations often masquerade as VPN problems. WiFi connections, especially on congested 2.4GHz bands, cap your maximum possible speed regardless of how you optimize VPN settings.

Test with an ethernet connection if possible. If speeds improve dramatically, your WiFi is the bottleneck, not the VPN. Solutions include switching to 5GHz WiFi, moving closer to your router, or using ethernet for bandwidth-intensive activities.

Background applications consuming bandwidth also matter. Close torrent clients, pause cloud sync services, and verify that system updates aren't downloading while you're testing. Task Manager (Windows) or Activity Monitor (macOS) show network usage by application.

Router-level VPN connections deserve special mention. Running your VPN on your router instead of individual devices creates a single point of encryption/decryption, and consumer router hardware often lacks the CPU power for good VPN throughput. If you're running your VPN at the router level and seeing poor speeds across all devices, consider switching to per-device VPN apps and only using the router VPN for devices that can't run VPN software natively.

Fix 10: Consider switching providers (low impact for troubleshooting, high impact long-term)

If you've systematically worked through fixes 1-9 and still see poor performance, your provider's infrastructure might be the problem. Oversold servers, poor peering agreements, or outdated hardware on the provider's end can't be fixed from your side.

Before switching, contact support with your testing data—speeds without VPN, speeds with VPN on different servers, protocols tested, and times of day. Quality providers can sometimes redirect you to less-congested server clusters or identify configuration issues you've missed.

Testing a different provider requires care. Most offer 30-day money-back guarantees, but check the fine print—some exclude bandwidth testing or have data caps that trigger refund exclusions. When evaluating alternatives, compare performance reviews from the same time period (server infrastructure changes quickly, so 2022 reviews don't reflect 2024 reality). Tools comparison sites like ours maintain current speed testing data, but always verify with your own tests during the guarantee period.

Look specifically at whether alternative providers have servers in the geographic locations you need, support the protocols you want, and have good independent security audits. Speed matters, but not at the expense of the privacy you're using a VPN to achieve. Our comparison pages break down these tradeoffs across popular providers.

Key takeaways

Protocol choice matters most: Switching to WireGuard typically delivers larger speed improvements than any other single change. Make this your first test.
Geography and server load compound: A nearby server at high capacity often performs worse than a more distant server with available bandwidth. Test multiple options in your target region.
Layer your fixes: Apply high-impact changes first, test after each change, and only proceed to the next fix if you're still seeing problems. Changing everything simultaneously makes it impossible to identify what actually helped.
Establish baselines before calling anything "slow": A 30% speed reduction on a VPN is physics and cryptography, not a problem. Focus troubleshooting on speeds below 50-60% of your baseline.
Local factors often masquerade as VPN issues: WiFi limitations, router CPU constraints, and ISP throttling frequently cause problems users attribute to their VPN provider.
Keep records of what works: Network conditions change, and server performance varies over time. Document which servers and settings deliver good speeds so you can quickly revert when performance degrades in the future.