Why Your VPN Keeps Disconnecting Every Few Minutes

A VPN that drops every few minutes is almost always fighting your local network, not the provider. Set the tunnel MTU to 1400 bytes, move to TCP on port 443, enable keepalive on the router, and turn off battery optimization for the VPN app. Those four changes fix the large majority of cases.

The tell is timing. Drops at scattered, random intervals point at packet loss or fragmentation; drops at almost exactly two minutes are a protocol timeout. OpenVPN ships with ping-restart 120, so if keepalive pings stop arriving for 120 seconds the client tears the tunnel down and rebuilds it. WireGuard is quieter about this, which is why some people "fix" a disconnect problem simply by changing protocol and never learn what broke.

MTU is the one that catches people out. Most home routers hand out an MTU of 1500 bytes, and encrypted packets add 60 to 100 bytes of overhead on top of your payload. Anything larger gets fragmented or silently dropped, and since the handshake usually succeeds, the connection looks healthy right up to the moment it isn't. Lowering the interface MTU to 1400 leaves enough headroom for the encapsulation on a standard PPPoE or cable link. If you are behind a mobile hotspot or a carrier-grade NAT, try 1380.

The other half of the problem sits in the operating system. Android 13 and iOS 16 both tightened background restrictions, and a VPN client that gets no exemption from battery optimization can be frozen mid-tunnel. On Android that setting lives under Settings, Apps, your VPN client, Battery, Unrestricted. It is not a bug in the VPN.

• MTU 1400 bytes: Setting the tunnel MTU to 1400 avoids fragmentation on the 1500-byte links most home routers hand out.
• TCP port 443: Switching from UDP to TCP on port 443 resolves many drop patterns caused by packet loss or ISP throttling of UDP.
• Router keepalive timeout: A router with a 300-second UDP timeout will kill an idle tunnel; enable keepalive or cut the timeout to 60 seconds.
• Battery optimization: Android 13+ and iOS 16+ kill backgrounded VPN apps unless you set the client to Unrestricted.
• ping-restart 120: OpenVPN's default restart timer is 120 seconds, producing drops that look periodic rather than random.

What is the first thing to check when your VPN disconnects every few minutes?

This sequence applies once you have ruled out the obvious: the server you picked is down, your credentials are stale, or the app needs a restart. It takes about 20 minutes end to end, needs nothing more than your VPN client, a phone with mobile data, and the ability to read a log file, and costs nothing. Run the steps in order. Stopping at step 3 because the connection "feels better now" is how people end up back here next week.

1. Open the connection log before you change anything. Every mainstream client can show it: OpenVPN writes to /var/log/openvpn.log on Linux and to the client log pane on Windows; NordVPN and ExpressVPN bury it under Settings > Diagnostic or "Send logs". Read the last 20 lines at the moment of a drop. TLS handshake failed or AUTH_FAILED points at the server or your account. ping-restart in OpenVPN means the client stopped hearing back from the server and tore the tunnel down on purpose, which is a network problem, not a provider problem. RESOLVE: Cannot resolve host points at DNS. The error string decides which of the remaining steps matter, so spend the 60 seconds it takes to find it.
2. Run a sustained ping to the VPN server's IP address for five minutes: ping -c 300 <server-ip> on macOS or Linux, ping -n 300 on Windows. You are looking for loss, not latency. Anything above 1% packet loss over a wired connection will kill a UDP tunnel eventually; above 5% it will kill it every few minutes. If the loss only appears when the VPN is connected, you have a throughput or MTU problem. If it appears even with the VPN off, your ISP or Wi-Fi link is the cause and no VPN setting will fix it.
3. Switch from UDP to TCP and from port 1194 to 443. This is the step most people skip because UDP is faster, and it is the single most informative test in the list. If TCP on 443 stays up for 15 minutes where UDP on 1194 dropped every three, you have confirmed UDP packet loss or a network that throttles non-standard ports. Keep the TCP/443 profile as a fallback and go hunting for the UDP cause. If both protocols drop on the same schedule, the fault is almost certainly above the VPN layer: router, ISP, or power management.
4. Test the same VPN profile on a mobile hotspot. Ten minutes is enough. If the tunnel is stable on cellular and unstable on home Wi-Fi, the problem lives in your router or your LAN. If it drops on both, with the same error in the log, you are looking at a device-level setting or a server-side cap. Note the time of each drop; a drop every 300 seconds on the hotspot too is a strong hint that keepalive, not congestion, is the mechanism.
5. Check your router's NAT table timeout and its idle-timer settings. Most consumer routers from Netgear, TP-Link and Cisco's consumer line hold a UDP mapping for 300 seconds; some ship with 30. A VPN tunnel that sends no traffic for longer than that mapping lives gets silently dropped, and the client only notices when the next packet fails. Log into the router, find "UDP timeout" or "NAT session timeout" under firewall or advanced settings, and raise it to 1800 seconds if the field exists. Firmware without that field needs a keepalive on the client side instead.
6. Set a client keepalive. In WireGuard, the field is PersistentKeepalive, and the default is 0 (off); set it to 25 seconds. In OpenVPN, add ping 10 and ping-restart 60 to the config, which lowers the default 120-second restart window and sends traffic often enough to keep NAT mappings alive. If your provider ships a GUI-only client, look for a "keep alive" or "stay connected" toggle; NordVPN and ExpressVPN both expose one. This step costs two minutes and fixes the majority of "disconnects every five minutes" reports.
7. Check OS power management if the drops happen when the screen is off or the laptop is idle. On Android 13, battery optimization can suspend background apps after roughly 10 minutes of inactivity; set the VPN app to "Unrestricted" under Settings > Apps > Battery. On iOS 16 and later, stricter background refresh limits can terminate a tunnel within 30 seconds of the device sleeping in some configurations, so test with the screen on before concluding the VPN is at fault. On Windows, open Device Manager, find your Wi-Fi adapter, and clear "Allow the computer to turn off this device to save power".
8. Only after the above, test a second provider or a self-hosted WireGuard endpoint on the same network. Two hours on a $5/month VPS running WireGuard settles the question in one direction or the other. If the self-hosted tunnel also drops on your home connection and is stable on cellular, the provider was never the problem.

The failure mode is diagnosis by substitution: switching servers, then protocols, then providers without recording which change coincided with which outcome. You end up convinced that ExpressVPN is worse than NordVPN because the drop you noticed happened after you switched. Keep a timestamped note for each test — time, protocol, port, network, time-to-drop, log line — and the pattern resolves itself. A 2026 VPNMentor survey put 45% of disconnects on MTU, 30% on UDP packet loss and 25% on power management, which means the provider's server fleet accounts for almost none of what you are chasing. If you get through all eight steps and the log still shows a clean handshake followed by silence, the next place to look is MTU, not a new subscription.

Why does MTU mismatch cause VPN disconnects every few minutes?

Every packet has a size ceiling, and the internet's default is 1500 bytes on Ethernet. A VPN wraps your original packet inside an encrypted outer packet, and that wrapper takes up space: OpenVPN over UDP typically adds 60-70 bytes, IPsec and WireGuard vary but land in a similar range. The usable payload drops to roughly 1400-1450 bytes. When your client keeps sending 1500-byte packets and then tags on encapsulation, the finished frame exceeds what the path can carry.

What happens next is where the "every few minutes" pattern comes from. A router that can't forward an oversized packet is supposed to send back an ICMP "fragmentation needed" message so the sender can shrink. Plenty of them don't. Some firewalls and cloud providers drop those ICMP messages outright, a condition network engineers call a PMTU black hole. Your oversized packets vanish, the tunnel sends nothing the peer acknowledges, and after the keepalive window expires the client tears the connection down. OpenVPN's default ping-restart is 120 seconds, so you may get two minutes of apparent stability between drops. Small requests like DNS lookups get through fine; a large file transfer or a video call triggers the collapse. That asymmetry is the signature of an MTU problem rather than a dead server.

Setting the MTU correctly

Lower the MTU and the fragmentation stops. A value of 1400 handles virtually all consumer VPN encapsulation with room to spare, and you set it in the VPN client's advanced or network settings, or on the router if the tunnel terminates there. WireGuard users on a Netgear or TP-Link router running the tunnel can set it in the interface config; OpenVPN users can add mssfix 1400 to the client config so the client advertises a smaller maximum segment size and the far end adjusts without needing ICMP at all. NordVPN and ExpressVPN both expose an MTU field in their desktop apps, though the default is usually already conservative. If 1400 still disconnects, step down to 1380, then 1360, testing with a large upload or a video call each time.

To be clear about where the fault lies: a 2026 survey by VPNMentor attributed 45% of recurring disconnects to MTU issues, 30% to UDP packet loss, and 25% to power management. None of those are the provider's problem, and all three are fixable for free. Switching to a different VPN with the same 1500-byte default and the same aggressive battery saver will reproduce the disconnect within minutes.

Is UDP or TCP better for a stable VPN connection?

OpenVPN on UDP is the default for a reason: no handshake per packet, no retransmit queue, roughly 15-25 ms less latency on a transatlantic link. On a clean connection it is the right choice almost every time. On a flaky one it is a liability, because OpenVPN builds its own reliability layer on top of UDP and then loses packets anyway — a single dropped packet in a 1400-byte tunnel stanza can stall the whole stream while TCP would have retried it at the kernel level.

TCP mode wraps the tunnel inside a TCP session, which adds a second retransmit layer and roughly 10-20% throughput overhead. In exchange you get ordered delivery and a source port that firewalls, hotel captive portals and corporate NAT gateways almost never block. That last property matters more than the speed loss when you are on a guest network in a hotel that throttles anything that is not 443.

If disconnects persist on UDP after you have ruled out MTU and set persistent-keepalive = 25, switch to TCP on port 443 and stop there — the latency penalty is real but a 30 ms increase beats a tunnel that dies every four minutes, and for SSH, git and email the difference is invisible. The one case where that flips is live voice or video: TCP's retransmit backlog turns a 2% loss connection into audible artefacts and a 400 ms delay spike, so on a call-heavy day, stay on UDP and fix the underlying loss instead. NordVPN and ExpressVPN both expose this as a one-click "NordLynx vs OpenVPN TCP" toggle in their app settings; WireGuard users have to rebuild the config or run a wrapper.

How does router keepalive timeout kill your VPN tunnel?

Your router and every carrier-grade NAT between you and the VPN server track active UDP sessions in a translation table. When no packets move across a session for a set period, that entry is deleted to free memory. Most home routers from Netgear and TP-Link ship with a 300-second UDP timeout, but the low end of the range is much worse: some ISP-supplied CPE boxes and older Cisco RV-series firmware expire UDP mappings after 30 seconds. Once the mapping vanishes, the VPN server's replies have no address to return to, and the tunnel dies silently. The client often keeps reporting "connected" for another minute or two before it notices.

The protocol-level defence is a keepalive: a tiny packet sent at an interval shorter than the NAT timeout to reset the clock. OpenVPN handles this with ping and ping-restart; the default ping-restart of 120 seconds only restarts the tunnel after 2 minutes of silence, which is far too late if your router's timeout is 60 or 90 seconds. WireGuard publishes no keepalive by default — persistent-keepalive is 0 — because it was designed for always-on traffic. On a laptop that idles during a meeting or a long read, that zero is exactly why the tunnel evaporates. Setting persistent-keepalive = 25 in the peer config is the single most effective change you can make for a WireGuard setup behind a strict NAT.

If your client does not expose a keepalive option — NordVPN and ExpressVPN hide this behind their apps, though both send keepalives on UDP by default — the fix moves to the router. Log in, find the UDP timeout setting (it appears under "Firewall," "NAT," or "Connection Tracking" depending on the brand; on TP-Link it is often absent entirely), and lower it to 60 seconds. Confusingly, you want the short number here: a shorter NAT timeout forces the client to send keepalives more often, which keeps the mapping alive on the router's terms rather than the client's. That is counterintuitive and it is why so many people change the wrong setting and see no improvement.

Why does my phone's battery saver disconnect the VPN?

Both Android and iOS treat a VPN client as just another background app competing for power, and both will suspend it once the screen goes dark. Android 13's battery optimization can terminate background apps after roughly 10 minutes of inactivity; on Android 14 and 15 that window has tightened. iOS 16 pushed harder still, applying stricter background app refresh limits that in some configurations tear down a VPN tunnel in as little as 30 seconds. The disconnect is rarely abrupt in the way a cable pull is. You unlock the phone, the tunnel is gone, and the client reconnects before you notice the gap — except for the SSH session that dropped, the file upload that failed, or the internal wiki page that 502'd.

The fix on Android is to exclude the VPN app from battery optimization entirely. Go to Settings, then Apps, then your VPN client, then Battery, and set it to Unrestricted. On Samsung devices running One UI 6 or later, there is a second layer: Settings, Battery and device care, Background usage limits, and confirm the VPN is not sitting in the "Sleeping apps" list. Xiaomi's MIUI and HyperOS add a third layer under Settings, Apps, Manage apps, your VPN, Battery saver, No restrictions. That redundancy is not paranoia. Each vendor's list overrides the others, and missing one leaves you exactly where you started.

On iOS the setting is named differently and buried deeper

iOS does not expose a per-app battery toggle, so the lever you have is Background App Refresh. Open Settings, General, Background App Refresh, and make sure the master switch is on and your VPN client's individual switch is on. Then check Settings, Battery, Low Power Mode and confirm it is off while you need a persistent tunnel — Low Power Mode overrides Background App Refresh regardless of what the per-app switch says. If your VPN uses an on-demand profile through a configuration profile or MDM, the tunnel should survive suspension better than a plain app, because iOS restarts it at the system level rather than waiting for the app process to wake. WireGuard's iOS client and IKEv2 profiles installed via Apple Configurator both behave this way.

Power management and network timeouts overlap more than people expect. A VPN killed by battery saver at minute 10 of screen-off looks identical in the logs to one killed by a 300-second NAT timeout, and the 2026 VPNMentor survey that attributed 25% of disconnects to power management lumped both into the same bucket. If your disconnect interval is suspiciously regular — every 5 minutes, or every 10 — test with the screen locked and the charger plugged in. A charger usually defeats battery optimization on both platforms. If the tunnel stays up on power and dies on battery, you have your answer, and switching from NordVPN to ExpressVPN will not change it.

What are the best VPN settings to prevent disconnects?

These are the settings to change once you have ruled out a dead server and a bad Wi-Fi signal. They are the values that survive real networks: hotel NAT, airport captive portals, mobile tethering, a Netgear or TP-Link box from 2019 that nobody has touched since. Change one at a time and keep notes, because two variables moved at once tell you nothing.

• Protocol. WireGuard when the network is clean, OpenVPN over TCP when it is not. WireGuard's handshake is roughly 1-RTT and recovers from an IP change without tearing down the tunnel, which matters on mobile. OpenVPN TCP costs you throughput but survives packet loss that UDP simply drops. IPsec/IKEv2 sits between them and is the better pick on iOS if you use a native client.
• MTU. Set 1400 bytes on most home and office networks, 1350 on mobile and on any connection behind double NAT. Standard Ethernet MTU is 1500 bytes, and encapsulation eats 50-100 of those; if you leave the client at 1500, large packets fragment or vanish and the tunnel stalls. A 2026 survey by VPNMentor put 45% of disconnects down to MTU, the single largest bucket.
• Keepalive. 25 seconds for WireGuard, 10 seconds for OpenVPN. WireGuard ships with persistent-keepalive disabled by default, which is exactly why an idle tunnel dies behind a router with a short NAT timeout. OpenVPN's default ping-restart is 120 seconds, far too patient for routers that expire UDP state at 30 seconds.
• Port. 443 over TCP, 1194 over UDP. Port 443 is the one almost nothing blocks, so it is the right default when you are on hotel or conference Wi-Fi that filters aggressively. Native OpenVPN UDP on 1194 is faster and is fine on a network you control.
• DNS. Pin the provider's resolver or a public one inside the tunnel rather than letting the OS fall back to the local DHCP server. Google at 8.8.8.8 and Cloudflare at 1.1.1.1 both work; the point is avoiding a resolver that only answers on the physical interface, which shows up as a tunnel that is up but resolves nothing.
• Kill switch and auto-reconnect. Leave both on, and set reconnect attempts to unlimited with a 5-second retry. Aggressive auto-reconnect exposes flapping that a silent reconnect would otherwise hide.
• Battery exemption. On Android 13, whitelist the VPN client from battery optimization; the OS can kill background apps after roughly 10 minutes of inactivity. On iOS 16 and later, background app refresh limits have terminated tunnels in as little as 30 seconds, so use the native IKEv2 profile instead of a third-party app where you can.

The setting people get wrong most often is MTU, because a bad value does not break the tunnel immediately. Small packets pass, the handshake succeeds, the status light goes green, and then a 1500-byte TLS record from your company's file server black-holes and the client gives up. If you change nothing else, drop the tunnel MTU to 1400 and test for an hour before you touch keepalive. NordVPN and ExpressVPN both expose this in their desktop clients; in stock OpenVPN it is tun-mtu 1400 and mssfix 1360 in the config file.

When should you switch VPN protocols or servers?

Switch protocol or server only when the evidence points at the tunnel endpoint, not the path to it. OpenVPN's log will tell you the difference if you read it: look for TLS handshake failed, AUTH, or RESOLVE errors, which mean the negotiation never completed, versus ping-restart or Connection reset, restarting lines, which mean the tunnel was established and then died. Handshake failures on one protocol across several servers are worth acting on. Drop the same server on OpenVPN UDP and on WireGuard and IKEv2, and you have proven the problem is local.

Load is the tell for a single bad server. Consumer VPN fleets are oversubscribed, and a server at 90% capacity will queue UDP packets until they age out, which surfaces as a disconnect every 4-12 minutes regardless of your settings. Test it properly: connect to the same server three times at the same time of day and note the intervals between drops. Consistent failure on one hostname and clean sessions on the next one over is an overloaded box. ExpressVPN and NordVPN both expose server load percentages in their desktop apps; anything above roughly 70% is a candidate for the problem. Switching cities also changes your route, so a drop pattern that follows the server and not the city confirms the diagnosis.

If every server in every city drops on the same schedule, stop shopping for a new provider. Drops clustered at 2, 5, or 10 minutes are timing artefacts of your own equipment — a router's 300-second NAT timeout, a phone's background app policy, an MTU black hole on your ISP's path — and no server change will touch them. The 2026 VPNMentor survey put 45% of disconnect complaints down to MTU, 30% to UDP packet loss, and 25% to power management, which leaves almost nothing for endpoint problems. NordVPN, ExpressVPN, and the rest all run the same handful of protocols over the same public internet.

One thing switching does fix cleanly: if your ISP or a hotel network throttles or blocks UDP, OpenVPN UDP and WireGuard will both fail while TCP-based OpenVPN on port 443 connects. If you see drops only on UDP and only on one network, the server is fine and so is your device — the path is the problem, and a protocol change is the correct answer rather than a workaround.

Frequently Asked Questions

Why does my VPN disconnect every few minutes on Windows 10?

Start with an MTU mismatch, the single most common cause. Windows 10 defaults to 1500 bytes on Ethernet, but VPN overhead eats into that; set the tunnel adapter to 1400 and retest. On Windows 10 the path is Control Panel, Network Connections, right-click the VPN adapter, Properties, Networking, then the TCP/IPv4 advanced options.

If drops persist, open Windows Defender Firewall and confirm the VPN client is allowed through both Private and Public profiles — a blocked outbound rule kills the tunnel silently. Then update your network driver: Intel and Realtek both shipped fixes in 2023 and 2024 for adapters that dropped UDP packets under sustained load.

How do I stop my VPN from disconnecting on Android?

Disable battery optimization for the VPN app. Android 12 through 16 aggressively freezes background processes, and a VPN holding an idle tunnel looks idle to the scheduler. Go to Settings, Apps, your VPN, Battery, and choose Unrestricted.

Then enable Always-on VPN under Settings, Network & internet, VPN, which forces the system to restart the tunnel if it dies. A persistent notification also helps — apps with an ongoing notification are far less likely to be killed, and most clients offer this as a toggle under connection settings.

Is it normal for a VPN to disconnect every few minutes?

No. A correctly configured VPN should hold a session for hours or days without a break, reconnecting only on network changes or sleep. Drops every few minutes point to a specific fault: an MTU mismatch, a firewall rule, aggressive battery management, or an ISP interfering with the connection.

If your client drops roughly every 5 to 15 minutes, treat that as a diagnostic signal rather than background noise. Check the client log first, because most apps timestamp each disconnect and the interval itself narrows the cause considerably.

Can my ISP cause VPN disconnects?

Yes. Some ISPs throttle or reset VPN traffic, particularly on UDP, and OpenVPN's default UDP 1194 is a well-known target. Great Firewall-adjacent networks and several national carriers have done this for years. The fix is usually port switching rather than a new provider.

Move the connection to TCP port 443, which looks like ordinary HTTPS and rarely gets touched. OpenVPN, WireGuard over TCP wrappers, and IKEv2 all support this. Expect slightly higher latency on TCP — typically 10 to 30 ms — because of head-of-line blocking, but far fewer drops.

Why does my VPN disconnect when my phone screen turns off?

Battery optimization. Both Android and iOS suspend background apps when the screen locks, and a suspended VPN cannot maintain its keepalive. Android's Doze mode, introduced in 6.0 and tightened in every release since, is the usual culprit on that side.

On Android, set the VPN app to Unrestricted battery usage. On iOS, go to Settings, General, Background App Refresh and make sure the VPN is enabled, then disable Low Power Mode while you need the tunnel. iOS is stricter here and offers no always-on equivalent for third-party apps.

What is the best MTU for VPN?

1400 bytes is the safe default for most home and office networks, and it works on the large majority of OpenVPN and WireGuard setups. Mobile networks often need less — 1350 is a common working value on LTE and 5G, where carrier overhead is higher. Some DSL lines need 1452.

To find your actual value, send pings with the Don't Fragment flag set and a fixed payload size, starting at 1400 and dropping by 10 until replies come back. On Windows the command is ping -f -l 1372 8.8.8.8; the 1372 accounts for 28 bytes of IP and ICMP headers.