A VPN that disconnects repeatedly is frustrating, but the cause is often a local setting, a network handoff, or an unstable route—not a reason to reinstall everything immediately. Start by noting when the drop occurs: after the screen locks, when Wi-Fi changes to mobile data, during a particular activity, or at seemingly random times. That pattern narrows the checks and helps you avoid changing several settings at once.
Before troubleshooting the tunnel, confirm that the underlying internet connection works without it. If ordinary websites also stop loading, resolve the Wi-Fi, mobile-data, captive-portal, or router issue first. If the internet works normally but the VPN drops, use the checks below in order, changing one item at a time and testing the same situation again.
Identify the disconnect pattern before changing settings
“Disconnected” can describe several different failures. The VPN app may report that the tunnel has ended; the app may still say “connected” while websites fail; or only one application may stop working. These symptoms point to different causes. A status icon is useful, but it does not prove that every app is being routed correctly or that DNS requests are resolving.
When the problem happens, check the client’s status and the device’s internet connection. If the VPN reports a disconnection, note whether it happened immediately after a network change, screen lock, sleep, or wake. If it reports a live connection but a site or app fails, check routing, DNS, and the destination service before repeatedly reconnecting. Keeping a short note of the event and the change that preceded it is more useful than switching servers at random.
| What you notice | Check first | A useful test |
|---|---|---|
| The tunnel stops after the screen locks | Battery optimization, background activity, sleep behavior, and whether the client is allowed to keep running | Keep the route unchanged and test again with the client allowed to run in the background |
| The VPN drops when Wi-Fi changes to mobile data | Automatic reconnection and the new network’s availability | Confirm the new network can load a regular website, then reconnect the VPN |
| It disconnects on one Wi-Fi network only | Network restrictions, sign-in portals, router behavior, and local security software | Compare with another network while keeping the device and client settings the same |
| The client says connected, but one app fails | Per-app routing, domain rules, DNS, and the app’s own connection requirements | Test another destination, then review the affected app’s routing rules |
Do not assume that a connection problem is caused by the VPN simply because it appeared while the VPN was on. A hotel or public Wi-Fi network may require a browser sign-in before it grants internet access. A mobile connection may also be unavailable briefly during a handoff. First establish whether the device can reach the internet, then decide whether the tunnel itself needs attention.
Check background permissions and sleep settings
If the VPN works while you are actively using the device but stops after the screen turns off, check whether the operating system is suspending the client. Battery-saving features may limit background activity, pause network access, or close an app that appears idle. The available controls and their names vary between platforms, operating-system versions, and device manufacturers, so follow the instructions for your own device rather than relying on a screenshot from a different model.
On Android
Open the client’s app information and review its battery or background-usage settings. If an option permits unrestricted background activity, test whether allowing it changes the behavior. Also check manufacturer-specific controls for auto-start, background launch, or app cleanup. A setting in a memory-cleaning utility may be separate from Android’s battery controls; allow-listing an app in one place does not necessarily change the others.
A foreground service can help a client maintain a connection, but it cannot override every system or manufacturer restriction. Avoid disabling all power-saving features as a first step. Change only the client-specific setting you need, then lock the screen and reproduce the same conditions. If you recently force-stopped the app, open it again before testing: a force-stopped client cannot reconnect in the background until it is launched.
On Windows, macOS, iOS, and Linux
On a laptop, distinguish a VPN failure from the computer entering sleep. Check the device’s sleep and power settings and observe whether the tunnel drops only after sleep or also while the system remains awake. Some operating systems suspend network interfaces during sleep; the client may need to reconnect after wake. On mobile devices, review background activity permissions and any system setting that restricts networking when the screen is off. Linux desktop environments and network managers can handle sleep and interface changes differently, so check the client’s own status after waking before changing system-wide networking.
Do not leave a device’s display awake indefinitely just to mask a background restriction. That consumes power without identifying the cause. A better test is to allow the VPN client its necessary background permissions, leave other power settings unchanged, and check whether the disconnection still follows the same sleep pattern.
- ✅ Allow the VPN client to run in the background if your device offers a client-specific permission.
- ✅ Check both operating-system battery controls and any manufacturer or cleanup utility that manages background apps.
- ✅ Reopen the client after a force-stop or system restart before judging its reconnection behavior.
- ❌ Do not disable every battery-saving feature or install another “keep alive” app before testing the built-in settings.
Test reconnection after Wi-Fi or mobile-network changes
Moving between networks changes the connection underneath the VPN. A tunnel established over one Wi-Fi network may not survive a switch to mobile data, a different access point, or a network that has not finished connecting. The client may reconnect automatically, wait for the device to report a usable connection, or require you to reconnect manually. These behaviors depend on the client and operating system.
Use this practical sequence when a handoff causes a drop:
- Confirm that the new Wi-Fi or mobile-data connection is active. If you are on a network that requires a sign-in page, complete that step first.
- Open the VPN client and check whether it reports connected, connecting, or disconnected. Do not infer the tunnel state from a single status-bar icon.
- If the client offers an automatic-reconnect option, enable it and test the same network transition again. If the option is already enabled, disconnect once and reconnect after the new network is ready.
- Check whether ordinary websites load with the VPN paused. If they do not, troubleshoot the underlying network rather than repeatedly changing VPN settings.
- Reconnect and test more than one destination. If only one app or website fails, inspect its routing and DNS behavior instead of treating it as a full tunnel failure.
When you work across several networks, reliable recovery can matter as much as initial connection speed. If you are comparing connection options for regular use, VPNHear China VPN is the service home page; whichever provider or client you use, verify that its reconnect behavior fits your devices and network changes rather than assuming all clients handle handoffs identically.
On public Wi-Fi, some networks restrict VPN traffic until their access page has been completed. Connect to the network, open the required sign-in page, and confirm ordinary internet access before starting the VPN. If the network blocks or interrupts a tunnel, compare with a trusted alternative network where permitted. Do not repeatedly enter account credentials into a page unless you have verified that it belongs to the network you intended to join.
Automatic reconnection is not the same as forcing a permanent connection through every failure. If the underlying internet is down, restarting the tunnel cannot restore it. If a client offers a setting that blocks internet access when the VPN is disconnected, understand its effect before enabling it: it can protect against traffic leaving outside the tunnel, but it may also make a broken connection look like a total loss of internet access until the VPN recovers or the setting is changed.
Compare protocol and server options methodically
A protocol determines how a VPN tunnel is established and maintained. Clients may offer protocol choices, but the available options depend on the service, client, operating system, and configuration. Names such as WireGuard, Shadowsocks, VMess, Trojan, or Hysteria2 refer to different technologies or connection methods; they are not interchangeable labels, and a client showing an option does not prove that a particular subscription supports it. Use only protocols and configurations provided by your service or documented by the client.
If the client repeatedly disconnects and your current configuration allows a choice, test another supported protocol as a controlled comparison. Record the original setting, make one change, reconnect, and repeat the situation that caused the drop. If the new option fails differently or performs worse, restore the original setting. Changing protocol, server, DNS, and routing rules together makes it difficult to learn which change mattered.
A busy or unreliable route can also cause interruptions. If the problem occurs only on one server or location, try another available route in the client or dashboard, then test the same app and network. Avoid concluding that a route is overloaded from one failed request: a destination service, DNS lookup, or local network may be responsible. Conversely, if one route consistently fails while others work under the same conditions, keep that observation for support.
90+
Countries covered
210+
Available routes
5
Supported platforms
VPNHear lists coverage across 90+ countries and 210+ routes, and supports Windows, macOS, iOS, Android, and Linux. These figures describe service coverage, not a guarantee that every route or device will behave the same way on every network. Use the live options available to your account and the client’s documented settings. If a route is unavailable or a subscription configuration looks outdated, refresh or re-import it using the service’s instructions rather than editing connection details from guesswork.
After a protocol or route change, check whether the client remains connected and whether the specific task that previously failed now works. Test a normal website as well as the app you care about. If the VPN remains connected but only one destination fails, look at routing rules and DNS next; repeated route changes may not address the actual problem.
Rule out client configuration, DNS, and conflicting tools
If the client says it is connected but browsing fails, check whether the problem affects everything or just selected apps and domains. A per-app proxy list may exclude the application you are testing, while a domain rule may send one destination along a different path. Restart the affected app after changing a rule so it creates a new connection. If the problem is limited to name lookups, review the DNS settings in the VPN client and the operating system. Avoid layering several encrypted DNS options or manually entered DNS servers without understanding which one is active.
Running two VPN or proxy clients at the same time can lead to competing routes, DNS settings, or virtual network interfaces. Fully disconnect the other tool while testing, including background processes if the app provides a clear way to stop them. Also check whether firewall software or an endpoint-security product has recently changed its rules. Do not turn off essential protection broadly; use the product’s documentation or a narrow, temporary test, and restore the protection afterwards.
Subscription configurations can become stale if a client was imported incorrectly or the account configuration has changed. Use the official subscription link or configuration file shown in your account, and follow the client’s import or refresh instructions. Do not paste your account password into a subscription field, and do not share a subscription URL publicly: it may grant access to your connection configuration. If a client reports an expired or invalid configuration, resolve that message before diagnosing a route as unstable.
- Pause other VPN or proxy clients so only one routing tool is active.
- Confirm that the affected app is included in the client’s routing rules, if per-app routing is enabled.
- Refresh or re-import the official subscription configuration if the client reports it is invalid or outdated.
- Check DNS settings without stacking multiple manual overrides.
- Restart the affected app after changing routing or DNS settings, then repeat the test.
Keep a note of the client name and version, operating-system version, selected route, protocol if shown, and the event that triggers the failure. Avoid recording passwords, authentication tokens, or private subscription links in a support message. A clear symptom report is safer and more useful than sending secrets or a long list of changes that were made all at once.
Know when to contact support
Contact support if the client continues to disconnect after the underlying internet connection, background restrictions, reconnection behavior, and a controlled route or protocol comparison have been checked. Include the operating system and version, client name and version, whether the failure occurs on Wi-Fi, mobile data, or both, and what the client reports at the time. Explain what you tested and whether any other app or destination still worked. This gives support a reproducible description without requiring you to guess at the cause.
If the problem began after an operating-system update, client update, router change, or network-policy change, mention that timing. If it affects only one route or location, identify it as shown in the client; do not infer a technical route type unless the dashboard explicitly displays it. Keep any error text, but remove passwords, subscription URLs, and other credentials before sharing screenshots or logs.
Before reinstalling, confirm that you can access the account and obtain the correct subscription information again. Reinstallation may remove local settings or imported configurations, but it cannot fix a blocked network or a device that is stopping the client in the background. If you do reinstall, install the version offered through the official channel for your platform and import the configuration using the current instructions.
VPN disconnection FAQ
Why does my VPN disconnect when the screen locks?
Battery management or background-activity restrictions may suspend the client, especially on mobile devices. Review the client’s background permission and the device’s battery settings, then repeat the test without changing the route. On a computer, check whether the device is entering sleep rather than merely locking its screen.
Why does my VPN drop when I switch from Wi-Fi to mobile data?
The network handoff changes the connection underneath the tunnel, and the client may need to reconnect. Confirm that the new network has internet access, enable automatic reconnection if the client supports it, and test again. If the network requires a sign-in page, complete that step before starting the VPN.
The VPN says connected, but I have no internet. What should I do?
Check whether the failure affects all destinations or only one app or site. If regular internet also fails when the VPN is paused, troubleshoot the underlying network. If only selected apps fail, review per-app routing and DNS, and make sure another proxy client is not active at the same time.
Should I reinstall the VPN client?
Reinstalling is not the first step. First check background restrictions, network handoffs, supported protocol settings, routes, DNS, and conflicting tools. Reinstall only if there is evidence that the client installation is damaged or support recommends it, and make sure you can restore the correct configuration afterwards.