Is It Dropping, or Never Connecting?
VPN keeps disconnecting describes a different problem from a VPN that never establishes a tunnel. If the app connects for seconds, minutes, or until you lock the screen, the leading suspects are power management, network instability, or a protocol mismatch. A failed connection from the outset points more toward authentication, DNS settings, traffic filtering, or device compatibility.
Start with a quick self-check. Write down whether the connection lasts seconds or minutes, and whether it fails during gaming, video calls, large downloads, or a Wi-Fi change. Repeated drops on one VPN server suggest a server or routing issue; drops on every server suggest a device, router, ISP, or client configuration problem.
This guide addresses a tunnel that connects and then falls over. It doesn’t cover the separate “connected but no internet” symptom; for background, read how a VPN actually works. We researched recurring complaints across consumer devices and found that the same pattern can appear with NordVPN, IVPN, and other providers, so begin with the device and network rather than assuming a brand fault.
As of 2026, there isn’t one fix for every router, operating system, VPN protocol, and ISP combination. The fastest route is controlled testing: change one variable, run a timed test, and record the outcome.
Power Management Is the Number One Cause
When a VPN drops after the screen locks, the app is minimized, or the device enters a low-power state, battery management is the first setting to inspect. In our experience, this is one of the most common practical causes of a VPN keeps disconnecting complaint, particularly on Android phones and inexpensive tablets. A tunnel can look connected in the interface while its background process has been paused.
Android battery and background controls
Open Settings > Apps > your VPN app > Battery, then select Unrestricted or the closest equivalent. Also check whether Background data is allowed, Battery Saver is disabled for testing, and Adaptive Battery has placed the app in a restricted group.
Manufacturer controls can override the standard Android menu. Samsung may place sleeping-app controls under Battery and device care; Xiaomi commonly uses Autostart and battery-saving permissions; OnePlus may restrict background activity under battery optimisation; Huawei devices can use App launch or protected-app settings. Menu names differ across operating-system releases, so search Settings for “battery optimisation,” “background activity,” and “autostart.”
iPhone, Windows, and Fire OS
On iPhone and iPad, open Settings > Battery and disable Low Power Mode for one complete test session. Low Power Mode reduces background activity, so a VPN that works while the screen is active but drops after a 15-minute lock test may be affected by the operating system rather than defective software.
On Windows, open Device Manager > Network adapters > active Wi-Fi or Ethernet adapter > Properties > Power Management. Clear Allow the computer to turn off this device to save power, then check Windows power plans, sleep timers, and modern standby behavior. Microsoft provides additional battery guidance for power-related settings.
Fire tablets and compatible Fire OS devices can suspend background apps through battery optimisation, app sleep, or background restriction controls. Review the VPN app’s battery settings and test while the tablet is charging. A VPN that stays stable only when the display is on is a strong background-limit signal.
A repeatable power test
- Charge the device above 50% and disable Battery Saver or Low Power Mode.
- Set the VPN app to unrestricted background operation and allow background data.
- Connect to a nearby server, lock the screen for minutes, and wait another minutes after unlocking.
- Repeat once with the original settings and compare the timestamps.
Based on our analysis of support complaints, a drop tied precisely to screen locking is evidence of power management—not proof of a bad VPN server. Google documents related controls in Android Help battery settings. If the problem continues while the device is charging, the next suspects are protocol choice and wireless packet loss.
Protocol Choice and Unstable Connections
VPN protocols make different trade-offs. WireGuard and OpenVPN UDP generally provide lower latency and strong throughput, but lost UDP packets can make a tunnel fail visibly on a flaky wireless connection. OpenVPN TCP retransmits packets and may recover more gracefully, although TCP can add latency and reduce speed because it handles reliability on top of an already busy connection.
IKEv2/IPSec is another useful test, especially on mobile devices moving between Wi-Fi and cellular data. It can handle some network changes well, but results depend on the operating system and provider implementation. Obfsproxy is a specialist option when traffic filtering interferes with a handshake or tunnel; it adds overhead and isn’t the first choice for ordinary home-network instability.
To test protocol behavior, open the VPN app’s connection settings, change WireGuard or OpenVPN UDP to OpenVPN TCP or IKEv2/IPSec, reconnect to the same server, and run the connection for at least minutes. Change only one setting. We tested this approach in controlled comparisons and found that a stable direct connection with repeated loss on one protocol points toward protocol, MTU, or client compatibility rather than general internet failure.
Packet loss, MTU, and handshake diagnostics
Run continuous ping tests to your router and a reliable public host, first without the VPN and then with it. On Windows, ping -t 192.168.1.1 tests the local path; on macOS or Linux, ping 192.168.1.1 provides a similar check. Frequent loss to the router means Wi-Fi or local hardware is suspect, while loss only beyond the tunnel suggests the VPN path.
Advanced users can reduce UDP packet sizes or test a lower MTU, documenting the original value before changing it. Values around 1,400 bytes or lower help in some tunnels, but a lower number can reduce efficiency; restore the original setting if performance worsens. Inspect connection logs for fragmentation, handshake retries, or repeated rekey events.
Some providers now offer post-quantum encryption options. Newer cryptographic handshakes can affect setup or compatibility on older clients, so temporarily testing the provider’s standard compatible mode can isolate a client issue without suggesting that stronger security is unnecessary. Update the VPN app before drawing conclusions.
Wi-Fi Problems Masquerading as VPN Problems
Wireless instability can look exactly like a VPN fault. Weak signal, interference, crowded 2.4 GHz channels, limited GHz range, band steering, and mesh-node handoffs can interrupt an encrypted tunnel even when ordinary browsing recovers quickly. A webpage may reload after a two-second interruption; a persistent VPN session may not.
Use a controlled isolation test. Connect the same device to Ethernet for 20–30 minutes, then repeat using a mobile-data hotspot. If the VPN remains stable on Ethernet but drops on Wi-Fi, stop reinstalling the VPN and inspect the wireless network. Test 2.4 GHz and GHz separately, temporarily give each band a separate SSID, move within metres of the access point, and pause mesh roaming where the system allows it.
A drop at the same physical location is useful evidence of signal loss or a handoff. Older routers can also struggle with encryption-related traffic, NAT handling, overheating, outdated firmware, or dozens of simultaneous connections. Reboot the router, check uptime and temperature, reduce competing traffic, and install firmware updates only from the manufacturer.
Xfinity is a practical example. An Xfinity gateway isn’t inherently incompatible with VPNs, but a gateway update or wireless setting change may alter band steering or roaming behavior. Test the gateway directly before considering bridge mode; bridge mode disables routing functions, so use it only if you understand how your separate router will provide DHCP, Wi-Fi, and firewall services.
Check internet connection quality with packet-loss and latency tests, not speed alone. The FCC broadband guidance explains speed benchmarks, but a speed test that reports Mbps won’t reveal intermittent packet loss. We recommend recording latency, packet loss, and the exact time of each VPN drop before contacting your ISP.
Auto-Connect, Always-On and Kill Switch Settings
Auto-connect can make a brief interruption less noticeable by reconnecting when Wi-Fi changes, the device wakes, or a tunnel expires. Enable it only after the app has permission to run in the background; otherwise the operating system may suspend the process and leave auto-connect with nothing to restart.
On Android, where supported, open Settings > Network & internet > VPN > your VPN provider > Always-on VPN. Menu names vary, and Android’s Always-on VPN is an operating-system feature, not the same control as an app’s auto-connect toggle. Enable one, test it, then add the other so you can identify which behavior changes.
A kill switch blocks selected or all internet traffic when the encrypted tunnel drops. It protects against accidental direct traffic, but it doesn’t repair the connection. If the kill switch is active, you may interpret blocked internet access as another disconnection; test according to your privacy requirements and use the VPN app’s reconnect control instead of repeatedly toggling airplane mode.
- Choose a nearby, reliable server and enable auto-connect.
- Enable the kill switch if blocking unencrypted traffic is required.
- Briefly switch from Wi-Fi to mobile data or move out of range, then observe whether reconnection occurs.
- Check the app log and note how long reconnection took.
Custom DNS, local firewalls, antivirus web shields, and router filtering can interrupt reconnection. Test with the VPN’s default DNS first; only add a narrowly scoped antivirus exclusion for the VPN application if the provider documents that requirement. A streaming service showing a proxy error means the service detected a proxy; it doesn’t prove the VPN disconnected. For provider-specific steps, see this NordVPN troubleshooting resource.
Gaming and Long Sessions
Gaming exposes intermittent VPN failures because it creates sustained traffic, persistent UDP flows, rapid server communication, and sensitivity to even brief packet loss. A two-second interruption that goes unnoticed while reading web pages can disconnect a match or voice session. NAT timeouts and router connection tracking can make the problem more visible after minutes than after a quick speed test.
Compare two timed sessions: minutes of ordinary browsing and minutes in the same game, using the same VPN server and protocol. Record the exact time of each drop and whether it follows an idle period, router handoff, match transition, or voice-chat change. We found that timestamps often reveal a repeating NAT or roaming event that a generic “VPN failed” message hides.
Test a nearby VPN server, then switch from WireGuard or OpenVPN UDP to another supported protocol. OpenVPN TCP may reduce visible drops but can increase ping and lower throughput, so judge the result by both stability and in-game latency. A VPN may increase latency rather than reduce it; read more about how VPNs affect gaming lag.
Check router firmware, NAT behavior, and heat during the session. Older phones, consoles, streaming devices, and entry-level routers may have less processing capacity for sustained encryption than a modern computer. Test the VPN directly on the device before moving the configuration to the router, because router-level encryption can create a separate CPU bottleneck.
When It's the Provider, VPN Server, or ISP
Test three VPN servers before concluding that the provider is at fault: one nearby, one in your country or region, and one farther away. If only one server drops, report that server name and time rather than changing every device setting. Server congestion, maintenance, routing faults, and ISP traffic filtering can each produce a different pattern.
An ISP can deliver stable ordinary traffic while long-lived encrypted sessions experience filtering or unusual routing. That possibility needs evidence, though: compare the same protocol across Wi-Fi, Ethernet, and mobile data, and review packet-loss results. IVPN, NordVPN, and other services may use different protocols, server locations, DNS behavior, and reconnect logic, so one provider’s result doesn’t establish how every VPN will perform.
Collect useful information before contacting support:
- Device model, operating-system version, and VPN app version.
- Protocol, server name, connection duration, and exact drop timestamps.
- Wi-Fi, Ethernet, or mobile-data status and the tested network band.
- Ping results, packet-loss percentages, router model, and firmware version.
- Relevant diagnostic logs and whether post-quantum encryption is enabled.
Update the router, modem, and VPN client, downloading firmware only from the manufacturer or provider. This Surfshark troubleshooting guide offers a comparable provider-specific checklist. In 2026, support teams may ask about newer encryption settings, so record them before making changes.
Escalate when the VPN drops across three servers, two networks, and more than one protocol. Send the evidence to the VPN provider and ISP; detailed logs help them reproduce the issue instead of sending generic reset instructions.
Key Takeaways
Use these five checks in order, changing one setting at a time:
- Remove battery and background restrictions first; power management commonly stops a tunnel after screen lock or sleep.
- Test another protocol, especially OpenVPN TCP when UDP is unstable; consider MTU or UDP packet-size changes only after documenting the original settings.
- Compare Wi-Fi with Ethernet and mobile data to separate wireless, mesh, router, and ISP problems from VPN-client problems.
- Use auto-connect, Always-on VPN, and a kill switch deliberately: reconnect features restore access, while a kill switch blocks traffic during a drop.
- Try three VPN servers, update firmware and apps, and send detailed logs to support when the problem follows the device across networks.
Your next step is simple: change one setting, run a timed test, and record the result before changing anything else. If you later consider a router-level VPN, read how to set up a VPN on your router only after checking router performance, firmware, and device compatibility. A stable diagnosis comes from controlled comparisons, not from changing six settings at once.
Frequently Asked Questions
How do I stop my VPN from disconnecting?
Start by removing battery and background restrictions, then test the VPN on another protocol and network. Compare Wi-Fi with Ethernet or mobile data, try three VPN servers, and record when each drop occurs. If the VPN keeps disconnecting across multiple networks and protocols, send those details to the VPN provider.
Why won't my VPN stay on?
A VPN may not stay connected because the operating system suspends its background activity, the Wi-Fi connection loses packets, or the selected protocol does not handle network changes well. Authentication errors, DNS settings, traffic filtering, outdated firmware, and device compatibility can also prevent a stable connection.
How do I keep my VPN connected all the time?
Enable the VPN app’s auto-connect option and, where supported, Android’s Settings > Network & internet > VPN > provider > Always-on VPN feature. Remove battery restrictions first, because an operating system may suspend the VPN app even when auto-connect is enabled. A kill switch can block traffic during a drop but won’t repair the tunnel.
Why does my internet keep disconnecting when I'm connected to a VPN?
If the internet stops working when the VPN disconnects, a kill switch may be doing exactly what it was designed to do by blocking unencrypted traffic. Other causes include unstable Wi-Fi, DNS conflicts, router filtering, an incompatible protocol, or a VPN client that has been suspended by battery-saving controls.
How do you restart a VPN connection properly?
To restart a VPN connection properly, disconnect inside the VPN app, wait about seconds, and reconnect to the same server. If that fails, close and reopen the app, switch networks briefly, or restart the device before changing several settings at once. Record the protocol and server used so you can compare the result.
How do you change VPN protocols when the connection fails?
Change protocols in the VPN app’s connection settings, usually under Protocol, Connection, or Advanced settings. If WireGuard or OpenVPN UDP drops repeatedly, test OpenVPN TCP or IKEv2/IPSec on the same server for at least minutes. Change only one setting at a time so you know what affected the result.