Does a VPN Slow Down Internet Speed? Why It Happens (and When It Doesn't)

Does a VPN slow down internet speed? The short answer

Yes, in the overwhelming majority of cases, a VPN slows down your internet speed at least a little. That's not a flaw specific to one app or one provider — it's a direct consequence of what a VPN structurally does to your traffic. Instead of your data traveling the shortest available path from your device to whatever server you're trying to reach, a VPN routes it through an additional stop — the VPN server — and wraps it in an extra layer of encryption before it leaves your device. Both of those things take time and computing work, and both of them are the entire point of using a VPN in the first place. The real question isn't whether a VPN slows you down; it's how much, and whether that amount is normal or a sign that something — your server choice, your protocol, your own network — is working against you more than it needs to.

This guide walks through where that slowdown actually comes from, what a reasonable amount of speed loss looks like, which factors matter most in practice, and the specific circumstances where a VPN's effect on speed is negligible or, in rarer cases, where it can even make a connection feel faster than going without one.

Why does a VPN slow down your connection in the first place?

Four separate mechanical factors combine to produce whatever slowdown you experience. None of them is exotic — each one is a direct, unavoidable consequence of how a VPN tunnel works, and understanding them individually makes it much easier to diagnose a slow VPN connection later, rather than just shrugging and assuming "VPNs are slow."

Extra distance and extra hops

Without a VPN, your traffic takes a route determined by your ISP's and the internet's normal routing — generally something close to the shortest practical path to the destination server. With a VPN active, your traffic instead goes from your device to the VPN server first, and only then onward to its real destination, before the response makes the same trip in reverse. If the VPN server sits between you and the destination geographically, this detour is minor. If it sits in the opposite direction — say, you're in Chicago, connecting to a VPN server in Singapore, to reach a website hosted in New York — you've added a genuinely long physical detour, and the extra distance shows up directly as added latency, measured in milliseconds of round-trip time.

Encryption and decryption overhead

Every byte of data your device sends through the tunnel needs to be encrypted before it leaves, and every byte arriving back needs to be decrypted. On modern hardware this overhead is usually small — current processors, including the ones in mid-range phones, typically include dedicated instructions for common ciphers like AES, so the actual cryptographic work happens extremely fast. But it isn't zero, and on older or lower-powered devices — an aging router, a budget phone, a computer running several other CPU-heavy tasks at once — encryption overhead can become a genuinely measurable part of the slowdown rather than a rounding error.

Packet encapsulation overhead

A VPN doesn't just encrypt your data — it wraps each packet in additional header information needed to route it through the tunnel correctly, then unwraps it at the other end. This adds a small amount of extra data to every single packet, which very slightly reduces the effective payload your connection is delivering per unit of raw bandwidth. It's a minor factor compared to distance and server load, but it's a real, physical reason a VPN connection can't ever be mathematically as fast as the same connection with no tunnel at all, even under perfect conditions.

The VPN server itself as a bottleneck

All of your encrypted traffic passes through a single server before continuing to its destination, and that server has finite capacity — a fixed amount of bandwidth and a limit on how many simultaneous connections it can handle well. If a lot of other users are connected to the same server at the same time, or the server's own upstream connection to the wider internet is saturated, your traffic queues behind everyone else's, and your measured speed drops regardless of how fast your own device and internet connection are. This factor, more than any other on this list, is usually the biggest single driver of a VPN connection feeling unexpectedly slow.

How much speed loss from a VPN is actually normal?

There isn't one universal number, because the honest answer depends heavily on your baseline connection, your chosen server, and your protocol — and any provider or article claiming a single fixed percentage across every setup is oversimplifying. That said, a useful way to think about it is in rough bands, based on the factors above rather than a benchmark claim:

• Best case (nearby server, modern protocol, low load): a small, often barely perceptible reduction — commonly in the single-digit to low-teens percentage range relative to your non-VPN baseline speed. On a fast broadband connection, this is unlikely to be noticeable during normal browsing, streaming, or video calls.
• Typical case (moderate distance, decent server load): a moderate reduction, potentially noticeable if you're doing something bandwidth-intensive, but usually still workable for most everyday tasks.
• Worst case (distant or overloaded server, older protocol, weak device): a severe reduction — potentially cutting your usable speed by half or more, to the point of buffering video, laggy calls, or downloads that crawl.

Rather than memorizing a percentage, the more useful mental model is this: your VPN speed is a ceiling set by whichever factor is currently the tightest bottleneck — your own connection speed, the server's available capacity, the physical distance and resulting latency, or the protocol's efficiency. Identifying which one is actually limiting you in a given moment is far more useful than comparing your result against a generic industry figure, because your specific bottleneck is the one thing you can usually do something about.

Does server distance affect VPN speed the most?

Distance is one of the most consistently influential factors, and it's also one of the easiest for you to control directly, which is why it's worth understanding in some depth. Every additional mile your traffic has to travel adds a small amount of latency — the time it takes a packet to make the round trip — and while the speed of light imposes a hard physical floor, real-world networks add further delay at each router and exchange point the traffic passes through along the way.

This matters differently depending on what you're doing. For raw download throughput on a high-bandwidth connection, moderate added latency often has a smaller effect than you might expect, because modern transfer protocols can still push a lot of data through a longer pipe. But for anything latency-sensitive — video calls, competitive online gaming, or any interactive application where responsiveness matters more than raw volume — added latency from a distant server is felt immediately and directly, even if your measured download speed number still looks reasonable on a speed test. This is why the practical guidance for speed-sensitive users is almost always the same: pick the nearest server that also has good capacity, rather than the server geographically closest to whatever content you're trying to access, unless accessing that specific region is the actual goal.

Does server load or congestion slow down a VPN connection?

Server load is arguably the single most underappreciated factor in VPN speed, because it's invisible from the outside — two servers in the exact same city, running the exact same software, can perform completely differently depending on how many other users are actively pushing traffic through each one at that moment. A server that's handling far more simultaneous connections than its bandwidth comfortably supports will produce a slow, sometimes inconsistent connection for everyone using it, independent of your own internet plan's speed or your device's capability.

Server load also tends to follow predictable daily and weekly patterns — a server tends to be busier during regional peak evening hours, for instance, than in the middle of the local night. If your VPN app displays a load indicator or a list of recommended servers, that's usually a genuinely useful signal rather than a cosmetic feature, since it reflects real-time conditions that a static "closest server" choice can't account for. Trying a second or third server in the same region, rather than assuming the first one you tried represents the provider's overall performance, is one of the single most effective troubleshooting steps for a VPN that feels unexpectedly slow.

Do different VPN protocols affect speed differently?

Yes, meaningfully so, and this is one of the few speed factors you can usually control directly from a setting inside your VPN app rather than something dictated by your location or plan.

WireGuard

WireGuard is generally the fastest widely available protocol in current use, for a combination of reasons: it uses a smaller, more efficient codebase than older alternatives, a streamlined and modern set of cryptographic primitives, and a leaner packet structure that reduces per-packet overhead. It also tends to re-establish a dropped connection faster than older protocols, which matters in practice whenever you switch networks — moving from Wi-Fi to mobile data, for example. If your provider offers WireGuard and you don't have a specific reason to avoid it, it's the sensible default for anyone prioritizing speed.

OpenVPN

OpenVPN is older, more configurable, and has a larger codebase and more processing overhead than WireGuard, which generally makes it somewhat slower in direct comparison, all else being equal. It also offers a meaningful internal choice: OpenVPN over UDP is typically faster than OpenVPN over TCP, because TCP's reliability guarantees — retransmitting lost packets, strict in-order delivery — add overhead that isn't necessary for most VPN traffic. TCP mode exists mainly for situations where UDP traffic is blocked or heavily restricted by a network (some restrictive corporate or public networks fall into this category), and it's worth checking which mode your app is using if OpenVPN feels unexpectedly slow.

IKEv2/IPsec

IKEv2/IPsec generally performs well on mobile devices in particular, and its efficient handling of network changes — switching between Wi-Fi and cellular without dropping the connection — makes it a reasonable default on phones even when it isn't necessarily the absolute fastest option in a head-to-head throughput test against WireGuard.

Practical guidance

If speed is your priority and your provider supports it, WireGuard is the sensible default choice today. If you're on a restrictive network where WireGuard's traffic pattern is blocked or throttled, OpenVPN over UDP is typically the next-fastest fallback, with OpenVPN over TCP reserved for networks that block UDP traffic outright. Checking which protocol your app is actually using — rather than assuming it defaulted to the fastest one — is a genuinely useful first troubleshooting step whenever a connection feels slower than expected.

Does encryption strength (AES-256 vs. ChaCha20) affect VPN speed?

Less than most people assume. Both AES-256 and ChaCha20 are considered strong, modern ciphers, and on the overwhelming majority of current devices, the raw cryptographic processing itself is fast enough that it isn't the bottleneck limiting your speed. Most modern processors include dedicated hardware acceleration for AES specifically, which makes it run extremely quickly on that hardware; ChaCha20 was designed to run efficiently even without that kind of hardware support, which is one reason it performs comparatively well on devices that lack AES acceleration, including some lower-end or older mobile chipsets.

In practice, if you're comparing two connections using the same protocol but different ciphers, the speed difference between them is usually small relative to the effect of server distance and load. Cipher choice is worth knowing about for completeness, but it should rarely be the first place you look when troubleshooting a slow VPN — protocol, server distance, and server load are almost always bigger levers.

Does your own internet connection or device affect how much a VPN slows things down?

Yes, and this factor is easy to overlook because it's so easy to assume the VPN itself is entirely responsible for a slow result. A VPN can only work with the connection and hardware it's given, and several conditions on your side of the connection compound whatever overhead the VPN itself adds.

• Wi-Fi vs. wired connections. Wi-Fi is inherently more variable than a wired ethernet connection — signal strength, interference from other devices and networks, and distance from the router all introduce their own overhead before the VPN even enters the picture. A weak Wi-Fi signal combined with a VPN can make it hard to tell which factor is actually responsible for a slow result without testing each one separately.
• Mobile data and cellular conditions. Cellular networks already have more inherent latency and variability than fixed broadband in many conditions, and a weak signal compounds whatever overhead a VPN tunnel adds on top.
• Older or resource-constrained devices. A phone or router with a slower processor and no hardware acceleration for the cipher in use will spend proportionally more of its available processing power on encryption and decryption, leaving less headroom for the result to feel fast even if the network path itself is fine.
• Background bandwidth usage. Other devices on the same network doing bandwidth-heavy things — a large cloud backup running, another device streaming in 4K, a download in progress elsewhere on the network — reduce what's actually available for your VPN connection, independent of the VPN's own overhead.

Before concluding that a VPN itself is the sole cause of a slowdown, it's worth ruling out these factors first, since a VPN running over a weak Wi-Fi signal or a congested home network will feel much slower than the same VPN over a clean, wired connection, even though the VPN's own overhead hasn't changed at all.

Can a VPN ever make your internet faster instead of slower?

In most conditions, no — a direct, unencrypted connection to a nearby destination will almost always be at least marginally faster than the same connection routed through a VPN, simply because the VPN adds a hop and processing overhead that a direct connection doesn't have. But there are specific, real situations where a VPN can make a connection feel faster in practice, and they're worth understanding rather than dismissing as impossible.

Bypassing ISP throttling

Some internet service providers slow down specific types of traffic on purpose — a practice sometimes applied to video streaming or peer-to-peer traffic during peak usage hours, whether to manage network congestion or for other business reasons. Because a VPN encrypts your traffic and hides what type of traffic it is from the ISP's inspection systems, a connection that was previously being deliberately slowed down for being identifiable as a specific traffic type can sometimes see its speed effectively restored once it's routed through a VPN and no longer identifiable as that traffic type. This is a genuine mechanism, not a myth, though whether it applies to your situation depends entirely on whether your specific ISP is throttling your specific type of traffic in the first place — something you'd need to notice as a pattern (a particular service consistently underperforming compared to a general speed test) rather than assume.

Avoiding a poorly peered or congested network path

Occasionally, the normal, non-VPN routing path between your ISP and a specific destination is itself congested or inefficiently peered, for reasons entirely outside your control — a transit agreement between networks, for instance, or a temporary congestion point somewhere along the standard route. In these specific cases, routing through a VPN server that happens to have a better-connected path to that same destination can occasionally result in a faster connection to that particular service than going direct, even though this is the exception rather than the rule.

Neither of these scenarios is common enough to be a reason to use a VPN specifically for speed — they're situational exceptions to an otherwise consistent rule, not a guaranteed outcome. If your everyday connection isn't being throttled and your normal routing isn't unusually congested, expect a VPN to cost you some speed, not add to it.

Does a "double VPN" or multi-hop connection slow things down more?

Yes, noticeably. Multi-hop or "double VPN" configurations route your traffic through two VPN servers in sequence rather than one, with a separate encryption layer applied for each hop. This is a genuine architectural feature with a real privacy benefit — no single server in the chain has visibility into both your real IP address and your final destination at the same time — but it comes at a real cost: your traffic now travels a longer physical path and gets encrypted and decrypted twice instead of once, which compounds both the latency and processing overhead discussed earlier in this guide. For most everyday browsing, streaming, or work tasks, a single well-chosen server already provides strong protection against realistic threats, and multi-hop is better reserved for the narrower set of situations where its specific privacy benefit genuinely matters more than the speed trade-off.

Does split tunneling help with VPN speed?

Split tunneling lets you choose which apps or traffic route through the encrypted VPN tunnel and which travel over your normal internet connection directly. Used deliberately, it can improve your overall experience without technically making the VPN portion itself any faster: traffic that's routed outside the tunnel — a bandwidth-heavy app that doesn't need VPN protection, for instance, or local network traffic like printing — travels at full, unaffected speed, while only the traffic you actually want protected pays the VPN's overhead cost. This doesn't change the underlying tunnel's performance, but it can meaningfully improve how fast your overall connection feels day to day if you're selective about what actually needs to go through the VPN and what doesn't.

How can you tell whether your VPN is actually the cause of a slowdown?

Rather than assuming, a short, structured test sequence isolates the VPN as a variable far more reliably than a single before-and-after comparison.

1. Run a baseline speed test with the VPN off. Use a reputable speed test tool, on a wired connection if possible, to establish your actual non-VPN speed as a reference point. Run it two or three times, since normal variation is common even without a VPN.
2. Connect to the VPN's nearest, least-loaded server and test again. If your app shows a load indicator or a "recommended" server, use it; if not, pick the server geographically closest to your actual location rather than any distant one.
3. Compare the results as a ratio, not just an absolute number. Losing 20% of a very fast connection may still leave you with more than enough speed for anything you're doing; losing 20% of an already-modest connection is more likely to be noticeable.
4. Test a second and third server in different regions. If your nearest server performs poorly but a different one performs well, the issue is likely that specific server's load or routing rather than the VPN or protocol in general.
5. Switch protocols if your app allows it. Testing the same server with WireGuard versus OpenVPN, for instance, isolates whether the protocol itself is a meaningful factor in your specific case.
6. Test on a wired connection if you originally tested over Wi-Fi. This rules out your local Wi-Fi signal as a confounding factor contributing to what looked like a VPN problem.

If, after working through this sequence, every server and protocol combination still performs far worse than your non-VPN baseline, that's a reasonable signal to look at the provider itself — an overloaded network across the board, an outdated app, or a genuine technical issue — rather than assuming the slowdown is simply an unavoidable cost of using a VPN at all.

What can you actually do to speed up a slow VPN connection?

Once you've identified that a VPN genuinely is the bottleneck rather than your own network or device, a handful of concrete adjustments tend to produce the most noticeable improvement, roughly in order of how much difference they typically make.

• Switch to a nearer server. This is usually the single highest-impact change available to you, since it directly reduces both physical distance and, often, congestion at the same time.
• Try a different server in the same region. If your provider offers multiple server locations within the same country or region, a second option can sidestep a specific overloaded server without sacrificing proximity.
• Switch to WireGuard if it isn't already selected. If your app defaults to OpenVPN or another older protocol, manually switching to WireGuard (where available) is often the second-highest-impact change.
• Switch OpenVPN from TCP to UDP, if you're using OpenVPN and have that option. UDP mode avoids the extra reliability overhead that makes TCP mode slower, and it's the default choice unless your specific network blocks UDP traffic.
• Use split tunneling for apps that don't need VPN protection. Routing bandwidth-heavy but non-sensitive traffic outside the tunnel reduces the total load the VPN connection has to carry.
• Switch from Wi-Fi to a wired connection, or move closer to your router. This addresses local network conditions that compound whatever overhead the VPN itself adds.
• Restart the VPN app and, if needed, your router. A stale connection state or an accumulated resource issue on either the app or the router can quietly degrade performance over time in ways a fresh connection resolves immediately.
• Update the VPN app. Provider apps periodically ship performance improvements and bug fixes to their tunneling implementation; running an outdated app version occasionally means missing out on a real, already-shipped speed improvement.

If you've worked through this list and a specific provider's connection remains consistently and substantially slower than reasonable expectations across multiple servers and protocols, that's meaningful evidence about that provider's network specifically, worth weighing alongside whatever else matters to you in choosing a VPN.

Are there situations where a VPN will always feel meaningfully slow, no matter what you do?

Yes — a few underlying conditions impose a hard ceiling that no amount of server-picking or protocol-switching can fully overcome, because the bottleneck sits outside the VPN's control entirely.

• An already-slow or high-latency base connection. Satellite internet, for instance, has substantial inherent latency built into the physical distance a signal travels to and from an orbiting satellite, regardless of the VPN; adding a VPN's own overhead on top of an already latency-heavy connection compounds a problem that started well before the VPN entered the picture. Similarly, a low-bandwidth mobile data connection in an area with weak signal has little headroom to begin with.
• A genuinely distant destination with no nearby VPN server option. If the service you're trying to reach is only available by connecting to a VPN server on a different continent — accessing region-specific content, for example — the physical distance itself imposes a latency floor that no protocol optimization can eliminate.
• A severely under-provisioned or overloaded provider network. If a provider genuinely doesn't have sufficient server capacity relative to its user base in a given region, no individual troubleshooting step available to you as a user resolves that — it's a structural issue with that provider's infrastructure investment, not something a setting change fixes.

In these situations, the honest expectation to set is that a VPN will cost you a noticeable, sometimes substantial amount of speed as an unavoidable trade-off for whatever benefit you're using it for, rather than treating persistent slowness as evidence that something is broken and needs fixing.

Do extra features like a kill switch or ad-blocker slow down a VPN further?

Most of the extra features bundled into modern VPN apps — a kill switch, split tunneling controls, an ad- or tracker-blocking layer, a malware-scanning add-on — have a negligible direct effect on throughput speed once they're active, because they aren't doing the same kind of continuous, per-byte processing that encryption itself requires. A kill switch, for instance, mostly sits idle, watching for the VPN connection to drop rather than actively processing your ongoing traffic, so it doesn't meaningfully add overhead while your connection is healthy. An ad- or tracker-blocking feature that filters DNS requests against a blocklist can, in some implementations, even modestly improve perceived page-load speed by preventing your device from ever loading blocked trackers and ad content in the first place, offsetting at least part of the VPN's own overhead for that specific use case.

The exception worth knowing about is any feature that actively inspects or reroutes your live traffic in real time beyond the base encryption — some malware- or content-scanning features, for example, work by inspecting traffic content as it passes through, which does add incremental processing overhead proportional to how much data you're moving. This is generally a small effect on modern hardware, but if you notice a speed difference after enabling an optional security add-on specifically, toggling it off as a test is a reasonable way to confirm whether that specific feature, rather than the VPN tunnel itself, is the source.

Do published VPN speed test numbers match what you'll actually experience?

Speed test figures published in reviews — including on comparison sites like this one — are a useful reference point, but it's worth understanding what they can and can't tell you before treating a specific number as a guarantee of your own results. A published test reflects one tester's specific connection, specific server choice, specific time of day, and specific testing tool, run at one point in time. Your own baseline connection speed, geographic distance from the servers being tested, local network conditions, and the exact moment you connect are all different variables, any one of which can shift your real result meaningfully away from a published figure.

This isn't a reason to ignore published speed comparisons entirely — a provider that consistently tests well across many independent reviews, many server locations, and multiple points in time is a meaningfully stronger signal than one that tests well in a single review. But the most reliable number for predicting your own experience is still one you generate yourself, on your own connection, using the specific server and protocol combination you actually intend to use day to day. Treat published benchmarks as a rough guide for which providers are worth testing yourself, not as a substitute for testing your own setup directly — and be equally skeptical of any number, published or from a provider's own marketing, that isn't accompanied by the conditions it was measured under.

Does running a VPN on your router instead of one device change the speed impact?

Router-level VPN setups — where the VPN connects once at the router and every device on your home network shares that single tunnel — introduce a few speed considerations that don't apply when a VPN runs individually on a phone or laptop.

The most significant one is that router hardware is generally far less powerful, computationally, than a modern phone or computer, and many consumer routers lack any hardware acceleration for VPN encryption at all. This means the encryption and decryption overhead discussed earlier in this guide, which is often negligible on a modern phone or laptop, can become the dominant bottleneck on an underpowered router — sometimes capping your effective speed well below what your internet plan or the VPN server could otherwise support, regardless of server distance or load. Routers marketed specifically for VPN use, or running more capable firmware with dedicated processing for this purpose, handle this far better than a stock budget router.

The second consideration is shared load: every device connected through the router-level VPN is sharing the same single tunnel's effective bandwidth, rather than each device potentially connecting to a different, less-loaded server independently. A household running several bandwidth-heavy activities simultaneously through one router-level VPN connection — video calls, streaming, large downloads, all at once — will feel that shared bottleneck more acutely than the same activities spread across separate per-device VPN connections to different servers. This is a genuine trade-off against the real convenience router-level VPN setups offer (protecting every device automatically, including ones like smart TVs and game consoles that can't run VPN apps directly), and it's worth factoring in if speed is a priority for a busy, multi-device household specifically.

Practical takeaway

Does a VPN slow down your internet? In practical terms, almost always yes, by some amount — the encryption and the extra server hop are not optional parts of how a VPN provides its core privacy and security benefits, so some overhead is inherent rather than a sign of a poorly built product. What varies enormously is how much that slowdown actually is, and that variance is driven overwhelmingly by a short list of factors you can actually influence: how far away and how loaded your chosen server is, which protocol you're using, and the condition of your own local network and device. A VPN on a nearby, lightly loaded server over WireGuard is often close to unnoticeable for everyday browsing and streaming; the same VPN on a distant, congested server over an older protocol can feel dramatically slower for reasons that have very little to do with the VPN's core technology and everything to do with those specific, addressable choices. Testing methodically — baseline speed, then server, then protocol, then local network — before concluding a slowdown is simply the unavoidable cost of using a VPN at all will usually reveal a fixable cause rather than a fundamental limitation.