A VPN that keeps disconnecting — dropping every few minutes, losing connection after sleep, or cycling through connect/disconnect loops — is worse than no VPN at all because it gives a false sense of security. The fix depends on which type of disconnection is happening. We go deeper on the whole subject in our Complete Guide to Fixing Windows, Browser, and Software Errors.
Identify the pattern first: random disconnections during use, or disconnections specifically after sleep/idle? These are different problems. Random disconnections during active use → server load, network instability, or keepalive settings. After sleep/wake → power management or Windows firewall resetting the VPN tunnel. Exactly every X minutes → server-side session timeout.
The fastest general fix: reconnect settings
Most VPN clients have an auto-reconnect or “reconnect on disconnect” setting. If this is enabled and the VPN keeps reconnecting: something is causing the disconnection and the client keeps repairing it. If auto-reconnect is disabled and you have to reconnect manually each time: enable it first — this solves the user experience even if it doesn’t address the root cause.
The setting location varies: NordVPN → Settings → Auto-connect; ExpressVPN → Preferences → Network Lock/Auto-connect; Mullvad → Settings → VPN Settings → Reconnect. Enable auto-reconnect and confirm it’s actually reconnecting when the VPN drops.
Server selection and load
Overloaded VPN servers drop connections more frequently. Choosing a server with lower load — the VPN app typically shows server load percentage — reduces disconnection frequency. Servers geographically closer to you usually have lower latency and more stable connections. If you’re connecting to a specific country for streaming or privacy: try different servers in that country rather than the one the app selects automatically.
Network adapter power management
Windows suspends the network adapter during idle to save power. When the adapter wakes after sleep: the VPN tunnel is broken and the client can’t always re-establish it automatically. Device Manager → Network Adapters → right-click the network adapter (both Wi-Fi and Ethernet if applicable) → Properties → Power Management → uncheck “Allow the computer to turn off this device to save power.” Apply this to the physical adapters and to the VPN virtual adapter if it appears in the list.
Protocol and port changes
VPN protocols that use UDP (WireGuard, OpenVPN UDP, IKEv2) are sometimes blocked or rate-limited by ISPs or corporate firewalls. When UDP packets are dropped, the VPN tunnel drops. Switching to TCP-based protocols (OpenVPN TCP) is more reliable through restrictive networks even though it has higher overhead.
Try: switch to a different protocol in the VPN app settings → reconnect → observe stability. WireGuard on UDP is fastest; OpenVPN TCP is most reliable through restrictive networks. For corporate VPNs where IT controls the protocol: they need to investigate whether the corporate network is filtering VPN traffic.
Keepalive settings
Some VPN protocols (particularly WireGuard) use persistent keepalive packets to maintain the tunnel when no traffic is flowing. Without keepalive packets, routers and NAT devices can close idle tunnels. The WireGuard client has a “persistent keepalive” setting (typically set to 25 seconds) that prevents this.
For WireGuard configurations: check the [Peer] section of the WireGuard config file for “PersistentKeepalive = 25” (or similar). If it’s missing: add it. The 25-second interval is shorter than most NAT timeout periods and keeps the tunnel alive through idle periods.
Firewall interference
Windows Defender Firewall and third-party security software can block or reset VPN connections, particularly after a firewall rule change or software update. Windows Security → Firewall and network protection → Allow an app through firewall → confirm the VPN client executable has both Private and Public network access.
Also: third-party firewall products sometimes classify VPN traffic as suspicious and apply packet inspection that disrupts the tunnel. Disabling the third-party firewall temporarily and testing VPN stability confirms whether it’s the cause. Adding the VPN client to the firewall’s trusted application list resolves this without permanently disabling the firewall.
Corporate VPN and Always-On configuration
Corporate Always-On VPNs (configured through Windows’ built-in VPN client or Cisco AnyConnect, GlobalProtect) should reconnect automatically. If they’re disconnecting: the certificate used for authentication may have expired, or the VPN gateway has changed its configuration. IT needs to investigate Always-On VPN disconnections rather than users troubleshooting locally — the gateway and certificate management is server-side.
Signs of certificate expiry: VPN connects briefly then disconnects with an authentication error. Contact IT with the specific error message from the VPN client.
For the network adapter and driver issues that affect VPN alongside Wi-Fi stability, our Wi-Fi stability guide covers the adapter settings and driver rollback that apply equally to VPN transport. For the DPC latency and CPU scheduling issues that cause UDP packet drops affecting VPN tunnels, our network latency guide covers the performance monitoring approach. Microsoft’s Windows VPN client documentation covers the Windows built-in VPN client’s reconnect settings, the IKEv2 Mobility and Multihoming Protocol (MOBIKE) that allows VPN tunnels to survive network changes, and the event log entries generated by VPN disconnection events.
ISP deep packet inspection and VPN sessions
Some ISPs use deep packet inspection (DPI) to detect and throttle VPN traffic. DPI-based throttling can cause intermittent disconnections — the VPN works initially, gets detected, and the ISP applies rate limiting or connection resets. The symptom: the VPN connects, works for a few minutes, then slows dramatically before disconnecting.
VPN obfuscation mode disguises VPN traffic as regular HTTPS, bypassing DPI detection. NordVPN calls it “Obfuscated servers,” ExpressVPN calls it “Lightway,” and Mullvad offers “Shadowsocks” as obfuscation options. Enabling obfuscation adds overhead but maintains more stable connections on networks with aggressive DPI.
Split tunneling and routing conflicts
Split tunneling (routing only some traffic through the VPN) can cause routing table conflicts that destabilise the VPN tunnel. When local network traffic and VPN traffic share similar IP ranges: Windows’ routing table can get confused, sending traffic through the wrong interface and causing the VPN to detect a routing conflict and disconnect.
Disable split tunneling temporarily → test VPN stability without it. If stability improves: the split tunneling configuration has a routing conflict. Review which IP ranges are excluded from the VPN and ensure they don’t overlap with the VPN server’s IP range or the VPN’s assigned IP range.
VPN client log analysis
When disconnections happen repeatedly: VPN client logs show the exact error that precedes each disconnection. Most VPN clients store logs in their installation folder or in %appdata%:[VPNClientName]logs. Look for error messages that occur a few seconds before each disconnection:
- “Timeout” or “keepalive timeout” → server overload or network latency spike caused keepalive failure
- “TLS handshake failed” → certificate or protocol negotiation issue
- “Connection reset by remote host” → server-side disconnection (overloaded server or policy timeout)
- “Authentication failed” → credentials or certificate expired
Each log message points at a specific fix, making log analysis far more efficient than trying all possible fixes.
Session timeout limits
VPN servers often have session timeout limits — maximum connection duration (8 hours, 24 hours) or maximum idle time (30 minutes, 1 hour) before forcing disconnection. This is by design for security in corporate VPNs and by necessity for free/budget VPN services that need to manage server resources.
If disconnections happen at very consistent intervals: check the VPN server’s documentation for session timeout settings. For corporate VPNs: IT configures these timeouts. For consumer VPNs: upgrading to a paid plan may remove or extend the timeout, or selecting a different server may have different timeout settings.
VPN and Wi-Fi switching
Laptops that switch between Wi-Fi networks (moving from home Wi-Fi to a hotspot, for example) drop the VPN because the underlying network changes. Most VPN protocols rebuild the tunnel when the underlying network changes, but this takes 5–30 seconds and appears as a disconnection. IKEv2 with MOBIKE (Mobility and Multihoming Protocol) handles network switching most gracefully — the tunnel survives network changes without requiring a complete reconnection.
For VPNs that disconnect every time the network changes: switch to a VPN protocol that supports network mobility (IKEv2/MOBIKE). If the VPN client doesn’t support MOBIKE: the reconnection delay after network changes is inherent to the protocol.
MTU (Maximum Transmission Unit) and fragmentation
VPN tunnelling adds overhead to packets. When the original packet plus VPN overhead exceeds the network’s MTU, packets must be fragmented. Fragmentation under heavy traffic causes packet loss and VPN instability. The VPN client should automatically detect and adjust MTU, but it doesn’t always do this correctly.
Manual MTU optimization: in the VPN client settings, look for an MTU option → try setting it to 1300 bytes (which accommodates most VPN overhead). This is smaller than the default 1500 bytes for most connections, reducing fragmentation. Performance may decrease slightly (smaller packets = more packets for the same data) but connection stability improves on networks that cause frequent fragmentation.
VPN kill switch and network interruption cycles
Some VPN clients have a “kill switch” that blocks all internet access when the VPN disconnects. If the kill switch engages during a brief VPN interruption (network glitch, server momentarily unreachable), it blocks the client’s ability to reconnect — creating a situation where the VPN is down, the kill switch blocks internet, and the VPN can’t reconnect because it needs internet access to reach the VPN server. A kill switch cycle keeps the machine completely offline until the VPN client is manually restarted.
Check: does internet access stop completely during VPN disconnections, and does it restore only after the VPN reconnects? This is the kill switch cycle pattern. Configure the kill switch to allow VPN client reconnection traffic even when the tunnel is down, or temporarily disable the kill switch if immediate reconnection is more important than leak prevention during brief disconnections.
Windows network profile changes triggering VPN resets
Windows classifies networks as Private, Public, or Domain. When the network profile changes (the same Wi-Fi is reclassified from Private to Public, for example), Windows’ firewall rules change, which can disrupt the VPN tunnel. This happens when the network’s configuration changes or when the machine reconnects to a known network that Windows now classifies differently.
Settings → Network → your connection → Network profile → ensure it’s consistently set to “Private” for trusted home networks. Consistent network profile classification prevents Windows from resetting firewall rules mid-session, which reduces VPN disruptions caused by firewall state changes.
The pattern-to-fix mapping at the start saves significant troubleshooting time: random disconnections during active use → server selection, protocol, obfuscation. After sleep → power management on the network adapter. Exactly every X minutes → session timeout limit on the server. After switching Wi-Fi networks → IKEv2/MOBIKE. Complete internet loss when VPN drops → kill switch cycle, configure reconnect path. Each pattern maps to a specific set of fixes, and addressing the pattern directly is far more efficient than working through all possible fixes.
VPN and DNS resolution during reconnection
After a VPN disconnects and reconnects: DNS may not immediately update to the VPN server’s DNS configuration. During this 2–5 second window, DNS queries go through the standard network rather than the VPN’s DNS servers. Applications that make DNS queries during this gap resolve to real IP addresses rather than VPN-routed addresses — which some corporate VPN setups interpret as a security violation and immediately disconnect the newly-reconnected VPN to prevent data leakage.
This creates a rapid connect-disconnect-connect cycle after any initial disconnection. The fix: ensure the VPN client’s DNS leak prevention is enabled, and configure the VPN to use DNS over HTTPS (DoH) if the client supports it — DoH prevents the brief DNS leak window by maintaining an encrypted DNS channel that’s separate from the VPN tunnel state.
Reinstalling the VPN client
VPN client software accumulates configuration state, cached certificates, and driver files that can become inconsistent after OS updates or multiple VPN server changes. When disconnections persist through all configuration changes: a clean reinstall removes this accumulated state. Uninstall the VPN client (Settings → Apps) → restart → download and install the current version → sign in → configure settings fresh → test stability.
Clean reinstallation also updates the VPN virtual adapter driver, which is particularly relevant for WireGuard and OpenVPN clients that install their own kernel-level drivers. An outdated virtual adapter driver causes stability issues that won’t be resolved by reconfiguring client settings.
Finally, for persistent disconnections that survive everything: try a different VPN provider for comparison. A 7-day or 30-day trial of a different service (different server infrastructure, different client software, different protocols) immediately tells you whether the disconnection problem is fundamental to your network environment (affecting any VPN provider) or specific to the original provider’s infrastructure. If the new provider is stable: the original provider has infrastructure issues. If it also disconnects: your local network, ISP, or Windows configuration is the variable to investigate. This provider comparison is a more efficient test than exhaustive troubleshooting of any single provider’s settings. See also How to Fix Wi-Fi Keeps Disconnecting on Windows 11 for a related case.
