If your VPN disconnects whenever your computer or phone wakes from sleep, the cause is often the device’s power management or a lost network transition—not necessarily a faulty server. Start by checking whether the VPN app is still running and allowed to work in the background. Then test reconnection on the same network before changing protocols or routes. These steps cover Windows, macOS, Android, and iPhone, with a controlled way to narrow down what is actually failing.
Identify where the disconnection happens
“The VPN disconnects after sleep” can describe several different situations. The app may have been stopped while the device was asleep, the app may still be open but have lost its tunnel, or the tunnel may appear connected while traffic is not passing through it. These cases need different fixes. Before changing anything, observe the app’s state immediately after waking and check whether ordinary websites load.
Start with a simple baseline. Connect the VPN while the device is awake, open a site or app you normally use, and confirm it works. Put the device to sleep in the usual way, wake it, and check the VPN app before repeatedly pressing its connection button. Note whether the app reports disconnected, connecting, connected, or an error. Also note whether Wi-Fi changed, mobile data took over, or you moved between access points while the device was asleep.
If the VPN app says it is connected but a page does not load, briefly test whether the issue affects all traffic or only one app or site. A browser cache, DNS change, captive portal, or app-specific routing rule can make one destination fail without the entire VPN tunnel being down. If the app says disconnected, focus first on background permissions and automatic reconnection. If it says connected but traffic stalls, check the network transition, DNS, and client logs.
Keep a short record of the device, operating-system version, VPN client, connection mode, network type, and what the app showed after waking. Do not include passwords, private keys, or a complete subscription URL in notes shared with anyone. A redacted error message and the approximate time of the event are usually more useful for troubleshooting than a screenshot containing account credentials.
Check background and battery permissions
Battery-saving features can limit network access or stop background activity during idle periods. The names and locations of these controls vary by operating-system version, device manufacturer, and VPN client. Look for settings related to battery optimization, background activity, app sleeping, automatic startup, or network access. Change only settings that apply to the VPN app, and avoid turning off broad power protections unless you understand the effect on battery life.
Android
On Android, open the system settings for the VPN client and review its battery usage and background permissions. If the system offers a choice such as unrestricted background use, consider allowing it for the VPN client when the problem reliably happens after the screen turns off. Some manufacturers add separate app-launch or autostart controls. If present, check whether the VPN client is allowed to start and remain active in the background.
Also check whether the client has a persistent notification or another status indicator when connected. Its absence does not prove the tunnel has stopped, but it can be a useful clue that the operating system has suspended the app. Retest after changing one permission. If your device offers per-app proxy rules, confirm that the app you use for testing is included in the VPN’s routing scope.
Windows and macOS
On Windows, check whether the VPN client is allowed to run at startup or in the background, if the client provides those options. If the problem occurs only after the computer sleeps, review the power settings for the wireless or network adapter using the controls available on your version of Windows. Avoid registry edits or undocumented power tweaks as a first step. They can create new problems and are difficult to reverse if you have not recorded the original values.
On macOS, check the VPN client’s own reconnect options and any system permission it requests to manage its network connection. If you use a client installed outside the App Store, make sure its background item has not been disabled in system settings. Menu wording changes between macOS releases, so search system settings for the app name or background items rather than assuming every Mac has an identical menu.
iPhone
iOS manages background activity differently from a desktop operating system. A VPN app may not be able to keep its interface running continuously while the phone is locked. Depending on the client and configuration, an on-demand or automatic connection option may be available to reconnect when network conditions change. Check the app’s documented settings and the VPN entry in iOS settings; do not assume that repeatedly reopening the app is required or that every client exposes the same controls.
If the issue happens when switching between Wi-Fi and cellular data, test each network separately. On iPhone, confirm that the VPN configuration is still present and that the client has the permissions it needs. If an organization, school, or managed profile controls the VPN, contact the administrator before changing or removing the configuration.
Run a controlled reconnect test
Once you have checked the relevant background settings, use the same sleep-and-wake sequence to test whether the change helped. Keep the network, route, and app the same during the first retest. When considering a VPN service or supported client for your everyday devices, VPNOB is one place to review the available platform information; whichever option you use, verify its own reconnection behavior rather than relying on a generic setting name.
- Confirm the foreground baseline. Connect the VPN while the device is awake. Visit a destination you can test consistently and confirm that it loads. Record the client’s connection mode and whether the app reports a successful connection.
- Reproduce the usual sleep event. Lock the phone or put the computer to sleep in the same way that normally causes the issue. Keep the device on the same network if possible. If it routinely changes from Wi-Fi to mobile data or reconnects to another access point, note that instead of treating it as an identical test.
- Inspect before restarting the app. After waking, check the client status and the network indicator. If the client is disconnected, note whether it begins reconnecting on its own. If it says connected, test more than one destination to distinguish a tunnel problem from a single app or website issue.
- Change one relevant setting. If the client was restricted in the background, adjust that permission and repeat the test. Do not also change the protocol, server, DNS mode, and routing rules in the same attempt; doing so removes the useful comparison between tests.
- Restore settings that do not help. If a change has no effect, return it to its previous value before trying another option. This keeps the device configuration understandable and limits unnecessary battery use or changes to other apps.
For a useful comparison, include the time of the test, the app’s state after waking, and whether the connection recovered without manual action. You do not need to run a speed test after every wake event. The immediate question is whether the tunnel reconnects and whether ordinary traffic passes; speed testing is a separate step if performance remains poor after reconnection.
Check network changes and client settings
Sleep often coincides with a network change. A laptop may wake on a different Wi-Fi access point, a phone may move between Wi-Fi and cellular data, or a router may renew its network connection. In such cases, the VPN tunnel that worked before sleep may need to be established again. Test the VPN on one stable network first. Then test the transition that usually triggers the failure, such as moving from Wi-Fi to mobile data.
If the problem follows one network only, restart that network connection before editing VPN settings. On Wi-Fi, disconnect and reconnect to the network, and check whether a sign-in page or captive portal appears. A captive portal may require you to complete a network login before the VPN can pass traffic. Do not enter sensitive credentials into an unexpected page; verify that it belongs to the network you intended to use.
Next, review the VPN client’s automatic reconnect option, if available. Some clients distinguish between reconnecting after a temporary tunnel failure and connecting automatically when the device starts or the network changes. These options have different effects. Use the client’s own documentation to understand each setting, and avoid enabling duplicate connection managers that may compete to control the same VPN profile.
If the client supports more than one protocol, protocol testing can help when the tunnel repeatedly fails to recover on a particular network. First confirm that the service and client both support the alternative protocol and that it is available in your configuration. Change only the protocol, keep the same network and route, and repeat the sleep test. A different protocol is not automatically faster or more reliable on every connection; firewall policies, network conditions, and client implementation can all affect the result.
Likewise, switching servers is a diagnostic step, not a guaranteed fix. Try another available route only after checking background permissions and the network transition. If one route fails while another works under the same conditions, note the difference for support. If every route disconnects at the same moment, the cause is more likely to involve the device, client, or local network than a single server.
Do not run two VPN clients at the same time while testing. Multiple apps or system profiles may compete for the same network interface, making it unclear which connection is handling traffic. Disconnect the first client cleanly before testing another one.
When to check logs or contact support
If the problem continues after background settings and controlled network tests, collect the client’s diagnostic information. Look for a connection log around the time the device woke. Useful details include whether the client detected a network change, attempted a reconnect, received an authentication or configuration error, or established a tunnel without passing traffic. Log labels differ by client, so include the app name and version when describing what you see.
Before sharing logs, review them for subscription URLs, access tokens, usernames, private keys, or other account details. Redact secrets rather than posting a complete configuration publicly. Support teams may need the client and operating-system versions, the general type of network, the selected protocol, and the exact error message. They usually do not need your account password.
Contact support when the same failure can be reproduced, when the app reports a persistent configuration error, or when one route behaves differently from others under the same conditions. State what you already tested and what you changed, including whether restoring the original settings altered the result. This makes it less likely that troubleshooting will repeat steps that have already been ruled out.
- ✅ Record the VPN client’s status immediately after waking.
- ✅ Test one change at a time on a consistent network.
- ✅ Check whether the tunnel is disconnected or only one app cannot reach its destination.
- ❌ Do not share an unredacted subscription URL, password, or private key.
- ❌ Do not assume a server switch will fix a background-permission problem.
If the VPN reconnects but a specific app still fails, test that app with the client’s routing rules in mind. Per-app proxying, split tunneling, DNS settings, and local network access can affect individual destinations. Keep the routing configuration unchanged during the basic reconnect test; investigate app-specific rules separately after you have confirmed that the VPN tunnel itself recovers.
Frequently asked questions
Should I leave the VPN app open?
Not necessarily. Many clients can maintain or re-establish a system VPN connection without keeping their main screen open. The exact behavior depends on the operating system, client, and configuration. Check the client’s background and automatic reconnect options, then test whether it reconnects after sleep without manually opening the app.
Will changing the protocol stop the disconnections?
It may help if the failure is specific to a network or protocol, but it is not the first thing to change when the operating system is suspending the app. Confirm that the client supports the alternative and test it separately. If the app stops running in the background, a protocol change may leave the underlying cause untouched.
Why does it happen only on Wi-Fi?
The Wi-Fi network may be changing during sleep, applying a sign-in requirement, or handling VPN traffic differently from cellular data. Test on a stable Wi-Fi connection and then on another network if available. If the problem occurs only on one Wi-Fi network, report that distinction along with any client error rather than assuming the VPN is failing everywhere.
What should I send to support?
Provide the device and operating-system version, VPN client and version, general network type, selected protocol, approximate time of the failure, and a redacted error message or diagnostic log. Explain whether the app showed disconnected or connected after waking and list the changes you tested. Never include passwords or unredacted credentials.