VPN slow on Windows 11 when your regular internet is fast is a frustratingly common situation. The VPN is supposed to secure your connection, not cut it in half. Before optimising anything, it helps to understand what’s actually causing the slowdown — because the fix varies significantly depending on the cause. We go deeper on the whole subject in our Complete Guide to Fixing Windows, Browser, and Software Errors.
Run a speed test without the VPN connected, then immediately run one connected. Note both download and upload. A 30–40% reduction is normal overhead. 70%+ reduction suggests something fixable. Also note latency (ping) — VPN always adds some latency from routing through the VPN server, but 500ms+ ping with an acceptable server is abnormal.
Server selection is the biggest lever
The VPN server location matters more than any protocol setting. Connecting to a server that’s physically closer to you reduces latency and typically increases throughput. Connecting to a server in a different continent because it’s the “fastest” in the app’s list is often misleading — “fastest” means least load, not physically closest.
Try two or three different server locations and run a speed test after each. The fastest server is almost always within 500–1000km of your location. VPN apps with automatic server selection sometimes choose poorly — override it manually and test.
Protocol choice
VPN speed is heavily affected by the encryption protocol. From fastest to most secure:
- WireGuard: fastest modern protocol, built into the kernel, minimal overhead
- IKEv2: fast and stable, good for mobile users, uses UDP
- OpenVPN UDP: reliable but more overhead than WireGuard or IKEv2
- OpenVPN TCP: slowest — TCP overhead compounds with VPN overhead
In the VPN app settings: if WireGuard or IKEv2 is available, switch to it. OpenVPN TCP is the slowest option and is often chosen as a fallback when firewalls block UDP — if you’re not behind such a firewall, don’t use it.
Split tunneling — the underused solution
By default, most VPNs route all traffic through the tunnel: Netflix, Windows Update, local file sharing, everything. Split tunneling lets you specify which applications or IPs use the VPN and which go directly through the local connection.
For most use cases — accessing a work network, bypassing geo-restrictions on specific sites — only specific traffic needs the VPN. Streaming video directly without VPN while routing only work applications through it dramatically improves effective speeds because 80%+ of typical bandwidth usage (video streaming, software updates) bypasses the VPN entirely.
Enable split tunneling in the VPN app settings. Most major VPN providers (NordVPN, ExpressVPN, Mullvad) support this. Set work applications and specific IP ranges to use the VPN; let everything else go direct.
Windows network adapter settings
Device Manager → Network Adapters → right-click your primary adapter → Properties → Advanced tab → “Large Send Offload” → confirm it’s enabled. Also check “Receive Side Scaling” is enabled. These offload network processing to the NIC hardware rather than the CPU — important when VPN encryption is already loading the CPU.
Also: right-click the VPN adapter (visible in the adapter list when connected) → Properties → confirm the adapter uses optimal settings. Some VPN drivers disable offload features by default on their virtual adapters.
MTU adjustment
VPN tunnelling adds overhead to each packet, reducing the effective Maximum Transmission Unit (MTU). When packets exceed the MTU, they get fragmented — two packets instead of one, doubling the overhead for that data. Speed drops noticeably for sustained transfers (file downloads, video) when MTU is misconfigured.
Find the optimal MTU: Command Prompt →
ping -f -l 1472 google.comIf it says “needs to be fragmented”: reduce the packet size until it doesn’t fragment. Set the MTU to that value plus 28 (header overhead). Apply: netsh interface ipv4 set subinterface "VPN Adapter Name" mtu=1400 store=persistent (adjust the adapter name and MTU value). Most VPNs perform well with MTU between 1380–1420 for WireGuard and 1450–1480 for OpenVPN.
DNS resolution and speed
VPNs typically use their own DNS servers for queries. If these servers are slow or overloaded, every page load starts with a DNS delay. Configure the VPN’s DNS settings to use faster resolvers if the VPN allows it: 1.1.1.1 (Cloudflare) or 8.8.8.8 (Google) are fast and reliable. DNS-over-HTTPS also improves DNS speed and privacy — check whether the VPN app supports it.
Hardware and connection baseline
VPN encryption consumes CPU. On older machines (pre-2015, single-core smartphones), encryption overhead is significant and unavoidable — WireGuard’s efficiency helps, but a slow CPU limits VPN throughput regardless of other settings. Check CPU usage during the VPN speed test: Task Manager → CPU. If it’s at 80%+ during the test, the CPU is the bottleneck.
For Wi-Fi users: the combination of Wi-Fi overhead and VPN overhead compounds. Testing VPN over ethernet almost always shows faster speeds than Wi-Fi, which helps confirm whether the Wi-Fi is part of the bottleneck.
For general network performance that complements VPN speed, our Ethernet performance guide covers the NIC offload settings that help with encryption throughput. If VPN is needed for corporate access and speed is a consistent issue, our Wi-Fi performance guide covers the adapter settings that affect VPN-over-Wi-Fi performance specifically. Microsoft’s VPN documentation covers the Always On VPN configuration for enterprise users where corporate IT manages VPN policy, which affects which optimisations are available at the user level.
VPN provider server infrastructure
Not all VPN providers are equal in their infrastructure. A budget VPN with 50 servers globally will be slower than a premium VPN with 5,000+ servers because more users share fewer server resources. Server capacity directly affects throughput. If you’re on a budget VPN plan and consistently see slow speeds despite optimising all local settings: the provider itself is the bottleneck. Comparing speed tests across different VPN providers — most offer trial periods — quickly reveals whether it’s a provider infrastructure issue or a local configuration issue.
AES-256 vs AES-128 and speed trade-off
OpenVPN and other protocols commonly use AES-256 encryption. On machines with hardware AES acceleration (most modern Intel and AMD CPUs, and ARM CPUs on recent Windows on ARM devices), AES-256 adds minimal overhead. On older CPUs without AES-NI instruction support: AES-256 consumes significant CPU and reduces throughput. AES-128 is faster and still secure for most purposes.
Check: does the VPN app offer an AES-128 encryption option? If yes and the machine is older (pre-2012): try AES-128 and compare speeds. Also check whether the CPU supports AES-NI: Task Manager → Performance → CPU → right-click → “CPU features” or check with a CPU-Z tool. Modern CPUs with AES-NI handle AES-256 at near-wire speeds — on these, the cipher strength choice doesn’t meaningfully affect performance.
Background VPN processes consuming CPU
VPN clients often run background processes even when not actively browsing. Kill switch monitoring, automatic connection retry, DNS leak monitoring, and telemetry processes all consume some CPU. On systems where CPU is already constrained, these background processes compete with the VPN’s encryption operations.
Task Manager → Details → look at VPN-related processes during slow speed tests. If any process is consuming 5–15% CPU consistently during the test: that process is competing with the encryption. VPN app settings often allow disabling specific features like automatic kill switch testing and connection monitoring during active sessions.
ISP throttling of VPN traffic
Some ISPs throttle VPN traffic specifically — recognising the VPN protocol’s signature and applying bandwidth limits. Obfuscation mode (also called stealth mode, traffic masking, or obfsproxy) makes VPN traffic look like regular HTTPS, bypassing ISP-level throttling.
Test: enable obfuscation mode in the VPN app settings (if available) → run a speed test. If speed improves significantly with obfuscation: ISP throttling was the cause. Not all VPN providers offer obfuscation — it’s more common in privacy-focused providers like Mullvad, Proton VPN, and NordVPN. The tradeoff: obfuscation adds slightly more overhead than standard VPN modes, so it should only be used when ISP throttling is confirmed as the cause.
TCP CLOSE_WAIT and connection pooling issues
On Windows, VPN connections that stay open for extended periods can accumulate TCP connections in CLOSE_WAIT state — connections that aren’t being actively used but aren’t fully closed. These connections consume resources and can cause new connections to be slower as the system manages the backlog.
Fix: disconnect the VPN → wait 30 seconds → reconnect. This clears all connection state. Also: running netstat -an | findstr CLOSE_WAIT from Command Prompt while on the VPN shows how many CLOSE_WAIT connections exist — more than 50 is unusual and suggests the application (browser, communication tool) isn’t properly closing connections through the VPN tunnel.
Windows Defender Firewall and VPN UDP
WireGuard and IKEv2 use UDP for their connections. Windows Defender Firewall occasionally blocks UDP on specific ports, forcing VPN clients to fall back to TCP — which is slower. Check: Windows Security → Firewall and network protection → Allow an app through firewall → find the VPN application → confirm both Private and Public are checked. Also verify the VPN’s specific UDP ports aren’t blocked by any custom outbound firewall rules.
Measuring real VPN overhead accurately
For a precise measurement of how much VPN is actually costing in speed: use iperf3 to measure local network throughput (without internet variables), and then measure speed test results with and without VPN across three different servers. The difference between the iperf3 local throughput and the VPN speed test shows you both the VPN overhead and the internet contribution to the slowdown — useful for distinguishing “VPN is slow” from “internet is slow through VPN” from “internet would be slow without VPN too.”
Most “VPN is slow” situations fall into one of three categories: wrong server location (fix by switching servers), wrong protocol (fix by switching to WireGuard or IKEv2), or ISP throttling (fix by enabling obfuscation). The more advanced fixes — MTU, TCP state, firewall UDP blocks — apply when the main three have been addressed and slowness persists.
VPN on metered connections and bandwidth limits
Windows marks some connections as “metered” — mobile hotspots and some Wi-Fi connections — and limits background data. When VPN traffic is routed over a metered connection, Windows’ metered connection limits affect VPN throughput even though the VPN isn’t aware of the metered status. Settings → Network and internet → your connection type → ensure “Set as metered connection” is off for the connection the VPN is using.
Antivirus and VPN traffic inspection
Security software that performs deep packet inspection scans VPN traffic before it reaches the VPN client’s encryption layer. Since VPN traffic appears as encrypted data to the antivirus scanner, the scanner either passes it through (adding some overhead from the inspection attempt) or, in some configurations, attempts to decrypt it for scanning — which interacts badly with the VPN’s own encryption.
Configure the antivirus to exclude the VPN application from network scanning: most security suites allow adding specific applications to network scanning exclusions without disabling the protection entirely. The VPN is already encrypting all traffic, so the antivirus inspecting it again adds overhead with minimal additional security benefit.
VPN client version and compatibility
VPN clients release regular updates that include performance improvements, driver updates, and Windows compatibility fixes. Running an outdated VPN client on Windows 11 can cause throughput limitations that newer versions resolve through updated virtual adapter drivers.
Check for updates in the VPN app itself, or download the latest version from the provider’s official website. After updating: test speed again before adjusting any other settings — the update alone sometimes explains the entire slowdown if the previous version had a known performance regression on Windows 11.
For businesses using corporate VPNs managed by IT: many of the optimisations above require VPN configuration changes that only IT can make (split tunneling policies, server infrastructure, protocol selection). Reporting specific speed metrics — with VPN vs without VPN, on which server, at which times of day — gives IT the data they need to identify whether the slowdown is infrastructure capacity, routing, or configuration. Anecdotal “the VPN is slow” without measurement data makes the problem harder to investigate and fix. A screenshot of a speed test result with and without VPN is more useful to IT than a verbal description. If this sounds familiar, VPN Slow Internet is worth a look.
One more practical point: if you’re using a VPN primarily for streaming geo-restricted content and speed is the issue — not security — a streaming-specific DNS proxy or Smart DNS service (rather than a full VPN) routes only the geo-detection portion of traffic through the proxy while all actual content delivery goes directly. Smart DNS services are faster than full VPNs for streaming use cases because they don’t encrypt traffic; they only change the DNS responses that determine which region’s content you see. For pure streaming bypass use, this is often a better tool than a full VPN regardless of how well-optimised the VPN is. Our guide on VPN Slowing Internet Speed covers an adjacent issue.
