A VPN that connects successfully but drops after the screen locks, the computer sleeps, or the device moves between Wi-Fi and mobile data is often reacting to a change in the device’s network state—not necessarily a failed account or unusable server. Mobile operating systems may pause background activity to save power, while a network handoff can briefly replace the interface, address, or DNS settings the VPN was using. Desktop sleep and adapter changes can produce similar interruptions.
The most useful approach is to identify when the drop happens, then check the matching layer: power management, background permissions, the network transition, the VPN client, and finally the selected route and protocol. Avoid changing all of these at once. If you make one change and test the same situation again, you are more likely to find the actual cause and avoid breaking settings that were already working.
Identify when the VPN drops
Before changing settings, note what you can observe. Does the client show “Disconnected,” or does it still say “Connected” while apps stop loading? Does the drop happen as soon as the screen turns off, only after the device has been idle for a while, or at the moment Wi-Fi disappears? Does the VPN recover by itself, or do you have to open the client and reconnect? These clues separate a tunnel interruption from a routing or DNS problem.
Check the client’s connection log if one is available. Look for events around the interruption, such as a network becoming unavailable, a new network being detected, a handshake failure, a timeout, or the client being stopped by the operating system. Log wording varies by app, so treat it as a clue rather than a diagnosis. If the client has no useful log, record the time and the action that preceded the problem; reproducing the same action is often more informative than repeatedly reconnecting at random.
Also test whether the issue affects every app or just one. If the VPN client remains connected and some apps still work, the tunnel may be active while a particular app, routing rule, or DNS request is failing. If all network traffic stops and the client reports a disconnect, focus on the tunnel and network transition. When safe to do so, compare behavior on a stable Wi-Fi connection and a stable mobile connection. The aim is to isolate the trigger, not to assume that either access network is always more reliable.
Check mobile background and sleep settings
On Android, battery optimization and background restrictions can limit what an app is allowed to do after it is no longer on screen. The exact menu names depend on the manufacturer and Android version. In the system settings, open the VPN client’s app information and review its battery or background-usage options. If the system offers an unrestricted or unrestricted-background option, allow it for the VPN client when you need the connection to remain active while the screen is off. Also check whether a device-management tool, battery saver, or manufacturer-specific cleaner is allowed to put the client to sleep.
Android clients may offer an always-on VPN option, and some devices also provide a setting to block connections that do not use the VPN. These are separate choices with different consequences. Always-on behavior can ask the system to keep or restore the VPN connection; blocking non-VPN traffic can prevent traffic from using the ordinary network when the tunnel is unavailable. Before enabling a blocking option, confirm that you understand how it affects access if the VPN cannot reconnect. The VPN app must also be permitted to create a system VPN connection.
On iPhone, look at the VPN app’s own connection and reconnection options, then review system settings that affect background activity, low-power behavior, and cellular data. iOS manages background work differently from Android, and not every VPN app exposes the same controls. Do not expect a generic “unrestricted battery” switch to exist. If a setting is unavailable, keep the app updated and check the app’s documentation rather than installing a profile or configuration from an unknown source.
On a Windows laptop, check whether the VPN client is allowed to start with the system and whether a power-saving state suspends the network adapter during sleep. On macOS, review the VPN client’s launch or reconnection options and whether the Mac disconnects Wi-Fi or sleeps when the lid is closed. Exact controls vary with the operating-system release, hardware, and client. A computer that has fully entered sleep cannot be assumed to maintain an active tunnel; a reconnect after wake is often more realistic than trying to keep the connection alive throughout sleep.
- ✅ Allow the VPN app to run in the background when the device needs a persistent connection.
- ✅ Review battery saver, app-sleep, and device-cleaner rules that target the VPN client.
- ✅ Use an operating-system or client reconnect option when it is available and appropriate.
- ❌ Do not disable every power-saving feature on the device just to troubleshoot one app.
- ❌ Do not enable traffic-blocking options without understanding what happens during a VPN outage.
Test Wi-Fi and mobile network switches
Moving between Wi-Fi and mobile data is not always a seamless handoff for a VPN. The device may change its network interface, address, route, and DNS resolver. The VPN client then has to detect the new network and establish or restore its tunnel. During that transition, some apps may pause, retry, or time out. This does not automatically mean the subscription has expired or that the selected server is permanently unavailable.
First, reproduce the change deliberately. Connect on Wi-Fi and confirm that ordinary browsing works through the VPN. Then, with the client visible, disconnect Wi-Fi or move out of range so the device uses mobile data. Watch whether the VPN client reports a network change, attempts reconnection, or remains disconnected. Repeat the test in the opposite direction if practical. On a laptop, a similar test can be made by changing between Wi-Fi networks or moving from Wi-Fi to a wired connection. Avoid combining this test with a route change or a client update, because that makes the result harder to interpret.
Next, review any option in the client that controls reconnecting when the network changes, switching between Wi-Fi and cellular, or using a particular network type. The wording and availability vary by client. If you need the VPN to reconnect automatically, enable the relevant option and confirm that the operating system allows the client to run in the background. Some clients may need a moment to establish a new tunnel after the network changes; if the status remains disconnected, use the client’s reconnect control once rather than tapping connect repeatedly.
If the interruption happens only during handoff, consider whether you need the tunnel to block traffic during that short period. A kill switch or system-level “block connections without VPN” setting may prevent unprotected traffic from leaving the device, but it can also make apps appear offline while the VPN is reconnecting. If your priority is uninterrupted access rather than blocking all non-VPN traffic, review the client’s behavior and the risks before changing that setting. Either way, test with an app that makes a fresh connection; an app may keep displaying cached content even when its network request has failed.
- Connect to the VPN on a stable network and confirm that the client shows an active connection.
- Open the client’s log or status details so you can see whether a network change is detected.
- Switch from Wi-Fi to mobile data, or between available Wi-Fi networks, and observe the client.
- Wait for the client’s normal reconnect attempt, then use its reconnect control if it stays disconnected.
- Repeat under the same conditions after changing only one relevant setting.
- Test a fresh page load or another app, and distinguish a tunnel drop from one app’s own retry behavior.
Check the client, route, and protocol
If sleep and network-transition settings do not explain the interruption, check the client itself. Confirm that it is the intended app for your operating system, that it has permission to create a VPN connection, and that it is not being closed by a task manager or security tool. If you use a third-party client, verify that it supports the imported configuration format and the protocol used by the selected route. A subscription can import successfully while a client still lacks support for a particular protocol feature or transport option.
Update the subscription if the service uses one, then check whether the route list and groups load correctly. A stale or incomplete configuration can leave the client trying to connect with outdated information. If the client shows a configuration parsing error, address that before repeatedly changing routes. Keep the subscription link private: it may provide access to connection configuration, and sharing it in a screenshot or public support request can expose that access.
Try a different route after confirming the client configuration. Choose an available route that suits your location and purpose, and compare its behavior under the same network conditions. One route may be affected by a local network’s handling of a particular path, while another may connect successfully. This is a diagnostic comparison, not proof that a route is universally better. If the same disconnect occurs across different routes, return to device power management, client permissions, and network stability.
Protocol choice can also matter because protocols and transports behave differently across network environments. Depending on the configuration, clients may use protocols such as Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard. Do not assume that changing the protocol will always fix a sleep-related issue: if the operating system has stopped the client, a different protocol will not restore its background permission. If the client supports more than one compatible option, compare them one at a time while holding the route and network constant. Avoid manually editing advanced transport or TLS parameters unless you know the expected values; a small mismatch can prevent a connection from being established.
For desktop users, also check whether another proxy, VPN, firewall, or network-filtering app is active. Multiple tools may compete to control routes, DNS, or the system VPN interface. Temporarily disable only tools you recognize and can safely restore, then test again. If the issue persists, save the relevant client log and note the operating system, client version, network type, and the action that caused the drop before contacting support. Never include passwords, authentication tokens, or a complete private subscription URL in an unprotected report.
Use a practical troubleshooting order
A consistent order keeps troubleshooting reversible and makes each result useful. Start with a simple baseline: restart the VPN client, confirm that the device has ordinary internet access without the tunnel, and reconnect using the current configuration. If the client cannot connect even while the device is awake and the network is stable, a sleep setting is unlikely to be the only cause. Check the displayed error and configuration before moving to background behavior.
When the baseline works, test the trigger that usually causes the drop. For a screen-off problem, leave the client connected, lock the screen, and check what happens after returning to the device. For a network-switch problem, change only the access network and watch the VPN status. Make a note of whether the tunnel disconnects, reconnects, or remains active while apps fail. A short, repeatable test is more useful than changing settings and waiting without knowing what to observe.
After that, adjust the matching setting: background permission for screen-off interruptions, automatic reconnect for network changes, or a different compatible route or protocol for failures that happen while awake on a stable network. Retest the original trigger after each adjustment. If a change makes things worse, restore the previous setting rather than stacking more changes on top of it. Finally, update the client or subscription only when there is a reason to do so, and note what changed. This gives you a clear explanation to share if you need help.
- Confirm ordinary internet access and the VPN client’s current status.
- Reproduce the specific trigger: screen lock, sleep, Wi-Fi loss, or network handoff.
- Check the log and the operating system setting that matches that trigger.
- Change one setting, then repeat the same test.
- If the device remains awake and the network is stable, compare a compatible route or protocol.
- Record the result and seek support with sensitive credentials removed.
Frequently asked questions
Does the VPN disconnect whenever my phone screen turns off?
Not necessarily. The client and operating system may be able to maintain or restore the tunnel, but battery management, background restrictions, low-power behavior, or the app’s own settings can affect it. Check the client’s status and the operating system’s app-specific controls. A screen turning off is different from the device entering a deeper sleep state.
Why does the VPN drop when I leave Wi-Fi?
The device has to move to a different network interface, and the VPN may need to establish a new tunnel using the new connection. Check whether the client detects network changes and whether background operation and automatic reconnection are allowed. If the tunnel comes back on a stable network, the handoff is a more likely trigger than a permanently failed route.
Should I enable always-on VPN or a kill switch?
These features can help maintain or protect a connection, but their behavior depends on the operating system and client. A setting that blocks traffic outside the VPN may make apps unavailable during reconnection. Enable it only when that trade-off fits your needs, and test what happens if the VPN is temporarily unable to connect.
When should I change the server or protocol?
Try another compatible route or protocol when the client is permitted to run, the device is awake, and the network is stable, but the connection still fails. Change one at a time and keep the test conditions consistent. If the problem occurs only after sleep or during Wi-Fi switching, address those triggers first; changing routes may not resolve an operating-system background restriction.