Why Is My VPN Slow? 10 Causes and Fixes for 2026

A VPN normally adds some network overhead, but a severe slowdown is usually caused by server distance or congestion, protocol choice, weak Wi-Fi, packet loss, MTU problems, device limits, or a poor route between your internet provider and the VPN server. The fastest way to diagnose the problem is to compare the same connection with the VPN off and on, then change one variable at a time.

Do not begin by changing advanced settings. Establish a baseline first. If the underlying connection is already slow, changing VPN servers, protocols, or packet sizes will not fix the real bottleneck.

Quick Fixes to Try First

These checks solve many VPN speed problems without changing low-level network settings. Work through them in order and retest after each change.

The important troubleshooting rule is to change only one variable before each test. If you switch the server, protocol, Wi-Fi band, and DNS settings simultaneously, you will not know which change actually affected performance.

First Confirm the VPN Is Actually the Problem

A VPN cannot provide more usable capacity than the connection underneath it. VPN traffic still has to cross your Wi-Fi or Ethernet connection, your internet service provider, and the wider internet before reaching the VPN server.

VPNs also add processing and an additional network path. Cloudflare’s explanation of VPN speed factors notes that encryption and routing through an intermediary VPN server can increase latency and affect performance.

Run a Baseline Speed Test

Disconnect the VPN and test the connection on the same device and network you normally use. Record at least:

• Download speed: how quickly data reaches your device.
• Upload speed: how quickly your device sends data.
• Latency or ping: how long a request takes to travel to a destination and return.
• Packet loss: the proportion of packets that fail to reach their destination, if the testing tool reports it.

Our internet speed testing guide explains how to read download, upload, ping, and jitter results if you need a baseline before starting the VPN-specific diagnosis.

Reconnect the VPN and repeat the test under otherwise similar conditions. One result can be noisy, so several runs are more useful than one unusually good or bad measurement.

Read the Pattern, Not Just the Number

If both VPN-off and VPN-on results are poor, investigate the underlying internet connection first. If the connection is fast without the VPN but consistently much slower with it, the VPN path deserves closer inspection.

Different patterns point toward different causes. One slow VPN server suggests server congestion or routing. Every server being slow may indicate protocol, device, router, or provider limitations. A fast speed test combined with websites that stall halfway through loading can point toward packet loss, Domain Name System issues, or Maximum Transmission Unit problems rather than raw bandwidth.

10 Reasons Your VPN Is Slow and How to Fix Each One

1. The VPN Server Is Too Far Away

Distance usually affects VPN performance because your packets have to travel to the VPN server before continuing toward their final destination. The longer that round trip becomes, the more latency is added.

Latency is the delay between sending network traffic and receiving a response. It matters especially for gaming, video calls, remote desktops, and interactive web applications because these activities depend on frequent back-and-forth communication.

For example, if you are in Washington, D.C. and connect to a VPN endpoint in Tokyo, traffic must cross a long international path even when the website you are opening is hosted nearby in the United States.

Fix: connect to the nearest suitable city or country unless you specifically need a distant exit location. Proton’s current VPN speed guidance similarly recommends nearby servers and notes that distance and server load affect connection performance.

The geographically closest server is not guaranteed to be the fastest. Internet routing depends on peering arrangements and network topology, so test two or three nearby options rather than assuming the nearest city will always win.

2. The VPN Server Is Overloaded

A VPN server and its network connection have finite capacity. When many customers use the same endpoint at once, they compete for processing resources and available bandwidth.

The resulting symptom can be confusing because the VPN may work normally in the morning and become much slower during evening peak hours.

Fix: switch to another server in the same general region. If your VPN app displays server-load indicators, compare alternatives from that provider. Load percentages should only be treated as relative indicators within the provider because different companies calculate and expose them differently.

Suppose one London server is slow but another London endpoint performs normally on the same device and protocol. That strongly points toward server-specific congestion or routing rather than a problem with your home connection.

ExpressVPN’s current slow-speed troubleshooting similarly recommends moving to another VPN location when one endpoint performs poorly.

3. Your VPN Protocol Is a Poor Fit for the Network

A VPN protocol defines how your device establishes and transports the encrypted tunnel. Common options include WireGuard, OpenVPN, Internet Key Exchange version 2, usually called IKEv2, and provider-specific protocols.

Different protocols behave differently across operating systems, networks, firewalls, and connection types. A protocol that performs well on fiber may not behave the same way on a restrictive hotel network or unstable cellular link.

Fix: start with the VPN application’s automatic or recommended protocol. If performance remains poor, test the alternatives your provider supports and record the result of each one.

WireGuard is often a sensible option to test because it has a relatively compact design, but it should not be described as universally fastest. Implementation, hardware, server capacity, route quality, and the underlying network still matter.

OpenVPN can operate over User Datagram Protocol, or UDP, and Transmission Control Protocol, or TCP. UDP generally avoids some retransmission behavior of TCP and is commonly selected for performance-sensitive VPN use. TCP can be useful where network restrictions or reliability requirements favor it, but tunneling TCP traffic inside another TCP transport can behave poorly on lossy connections because multiple reliability mechanisms react to the same packet loss.

4. Your Wi-Fi Is the Real Bottleneck

A stable VPN cannot repair a weak wireless connection. Distance from the router, walls, radio interference, crowded channels, and a weak access point can all reduce speed or increase packet loss before VPN traffic even reaches the internet.

Fix: if possible, repeat the same VPN test over Ethernet. A large improvement over the wired connection identifies Wi-Fi as an important part of the problem.

You can also:

• move closer to the access point;
• try the 5 GHz or 6 GHz band when signal strength is sufficient;
• use 2.4 GHz when you need greater range and higher frequencies are weak;
• reduce local interference;
• test another trusted network.

A common diagnostic result is a laptop reaching high throughput over Ethernet with the VPN enabled but slowing dramatically from a distant bedroom over Wi-Fi. In that case, changing VPN providers is unlikely to fix the wireless bottleneck.

If the issue appears mainly on airports, hotels, or cafes, the existing public Wi-Fi safety guide covers additional network-selection and security checks.

5. Your Base Internet Connection Is Congested

VPN performance depends on the internet connection underneath it. A household connection that is already saturated by large downloads, cloud backups, video calls, or operating-system updates has less capacity available for the VPN.

Upload congestion deserves particular attention. When upstream traffic is fully saturated, acknowledgments and other small packets can be delayed, making downloads and interactive applications feel slower even when substantial downstream bandwidth remains available.

Fix: pause large background transfers and retest. Check other computers, consoles, televisions, phones, network-attached storage devices, and cloud-sync applications on the same connection.

Also compare performance at another time of day. If both VPN and non-VPN speeds collapse during the same evening period, the root cause is more likely to be local or ISP congestion than the VPN tunnel itself.

6. Packet Loss or Poor Routing Is Reducing Throughput

Packet loss means some network packets fail to reach their destination. Reliable protocols have to recover from those losses, which can reduce effective throughput and increase delay.

Common symptoms include:

• video calls breaking up;
• gaming latency jumping unpredictably;
• downloads repeatedly speeding up and slowing down;
• one VPN region performing much worse than another;
• remote desktop sessions freezing briefly.

The route between your internet provider and a particular VPN data center may also be inefficient even when normal non-VPN traffic follows a better route to the same general part of the internet.

Fix: test another VPN server, preferably in the same region first. Then compare another network, such as Ethernet versus Wi-Fi or a trusted mobile connection. If one server is consistently problematic while nearby alternatives are normal, report that server and the approximate test time to the VPN provider.

Do not conclude that an ISP is deliberately throttling VPN traffic simply because one route performs poorly. Congestion, peering problems, packet loss, and temporary routing changes can produce similar symptoms.

7. MTU or Fragmentation Problems Are Affecting Larger Packets

This cause is less visible but important when a VPN connects successfully and then certain websites, uploads, or larger transfers stall.

Maximum Transmission Unit, or MTU, is the largest packet size an interface or network path can carry under a particular configuration. A VPN adds its own headers and encapsulation overhead, which increases the size of the packet sent across the underlying network.

If a path cannot carry that resulting packet and the network’s Path MTU Discovery process fails, larger packets may be dropped or repeatedly fragmented.

OpenVPN’s current OpenVPN 2.7 manual explicitly describes the classic symptom: the VPN starts correctly but stalls during active use when Path MTU Discovery is broken. It documents controls such as mssfix and fragmentation for specific OpenVPN UDP configurations.

Beginner fix: do not start by entering arbitrary MTU values. First update the VPN software, reconnect, try another protocol, and use the provider’s automatic configuration. A protocol change can alter encapsulation behavior enough to avoid the problematic path.

Practitioner fix: if you administer the tunnel or router, investigate the actual path MTU and Maximum Segment Size rather than copying a value from an unrelated connection. Cisco’s documentation on IPsec pre-fragmentation likewise describes how tunneling overhead can cause downstream fragmentation around near-MTU packets.

OpenVPN-specific options should not be copied into WireGuard, IKEv2, or proprietary VPN configurations. Each tunnel technology handles packet sizing differently.

8. Your Device or Router Cannot Process the VPN Fast Enough

Encryption and tunnel processing must happen somewhere. If the VPN application runs on a laptop or phone, that device performs much of the work. If the VPN is configured directly on a router, the router may have to encrypt and route traffic for every device in the home.

This becomes noticeable on fast internet connections because a low-power router can hit its processing ceiling long before the internet plan reaches its advertised maximum.

Fix: compare the router-based VPN with the VPN application’s performance on a reasonably modern computer using the same general network and nearby server. If the laptop reaches much higher throughput, router processing may be the bottleneck.

Other clues include unusually high processor use, a router interface becoming sluggish during large transfers, or a very consistent VPN speed ceiling regardless of which fast server you select.

There is no universal throughput limit for VPN routers. Processor architecture, hardware acceleration, cipher implementation, tunnel protocol, firmware, packet size, and thermal limits all affect the result.

Some VPN features intentionally prioritize privacy, censorship resistance, or filtering rather than maximum throughput.

Examples include:

• multi-hop VPN routing;
• privacy-focused hardened entry servers;
• Tor routing;
• traffic obfuscation;
• advanced filtering or inspection features.

Multi-hop is the easiest example. Instead of passing through one VPN server, traffic passes through additional infrastructure before reaching the wider internet. That creates more distance and additional processing opportunities.

Fix: compare a normal single-hop connection with the advanced feature disabled only if your security requirements allow it. Do not automatically disable privacy or anti-censorship features simply to gain speed if they are important to your threat model.

If performance returns to normal with the extra feature off, the slowdown may be an expected operational trade-off rather than a fault.

10. The VPN App, Provider, or Free Tier Is the Bottleneck

After eliminating local network problems, the limiting factor may genuinely be the VPN service.

Possible causes include:

• an outdated application;
• a buggy VPN network adapter or driver;
• a temporary provider outage;
• congested data-center connectivity;
• a small free-server pool;
• free-tier speed restrictions;
• an account or plan that provides access to fewer high-capacity servers.

Fix: update the VPN app, restart it, test multiple nearby servers, compare supported protocols, and check the provider’s official service-status information if available.

Free services require particular care. Some impose a formal speed restriction. Others do not throttle bandwidth directly but expose fewer servers, which can leave free endpoints more heavily loaded.

If the same device and connection perform well without the VPN but remain dramatically slower across several VPN servers and protocols, the provider becomes a more plausible bottleneck.

Troubleshooting Table: Match the Symptom to the Likely Cause

The symptom often tells you where to test next. Use this table to avoid changing unrelated settings.

The useful pattern is comparative. A result that changes when you alter one server suggests a different cause from a result that stays identical across every VPN location.

How to Test Whether a Fix Worked

A good troubleshooting test changes one factor and holds the others as steady as reasonably possible.

1. Use the same device.
2. Stay on the same Wi-Fi or Ethernet network.
3. Use the same VPN location unless the server itself is the variable being tested.
4. Use the same speed-test service and nearby test destination.
5. Run several measurements instead of relying on one result.
6. Record download speed, upload speed, and latency.
7. Record packet loss or jitter if the tool provides them.

Suppose you are testing protocols. Leave the VPN server unchanged, switch from protocol A to protocol B, reconnect, and repeat the same measurements. If you are testing servers, leave the protocol unchanged and move only to another nearby server.

Do not rely on a universal rule such as “a VPN should lose no more than 10%.” The relative difference depends on your internet speed, server distance, device, protocol, network path, and workload. A 30 Mbps loss has very different implications on a 50 Mbps connection than on a 1 Gbps connection.

Latency may also matter more than headline download speed. A remote worker could prefer 200 Mbps with stable low latency over 400 Mbps with severe jitter if the main workload is video conferencing and interactive remote sessions.

When Slower VPN Speed Is Expected

Some performance loss is a normal consequence of the route or security features you deliberately selected.

• Distant VPN server: longer round trips increase latency.
• Multi-hop routing: traffic crosses additional VPN infrastructure.
• Tor-related routing: additional relay hops prioritize anonymity properties rather than raw speed.
• Obfuscation: extra processing may be necessary on networks trying to detect or block VPN traffic.
• Busy shared server: available capacity may vary with demand.
• Router-level tunneling: low-power hardware can limit encryption throughput.

Expected overhead should not become an excuse for accepting a severe unexplained slowdown. If a nearby single-hop server performs dramatically worse than the same internet connection without the VPN, controlled troubleshooting is still worthwhile.

Contact support after you have established a repeatable pattern rather than sending only “the VPN is slow.”

Useful diagnostic information includes:

• operating system and version;
• VPN application version;
• VPN protocol;
• server name, city, or country;
• approximate time of the problem;
• VPN-off and VPN-on speed results;
• whether the connection uses Wi-Fi or Ethernet;
• internet provider or network type;
• whether another nearby VPN server behaves normally.

If the slowdown began immediately after a software update, say so. If only one server is affected, identify that server. These details help separate application problems from server, routing, or local-network issues.

Do not send passwords, recovery codes, private keys, authentication tokens, or other credentials in diagnostic messages.

Key Takeaways

Frequently Asked Questions