A VPN that disconnects repeatedly is not always failing for the same reason. The trigger may be an unstable Wi-Fi link, a phone putting the app to sleep, a laptop changing networks, a protocol that does not suit the current connection, or a client that is running alongside another proxy tool. Reinstalling the app immediately can remove useful evidence while leaving the real cause untouched.
A better approach is to change one variable at a time. First determine whether the underlying network is stable, then check power and background permissions, confirm that only one traffic controller is active, and finally test another protocol or route. This guide follows that order so you can separate local-device problems from route and service problems.
Identify the real disconnection
Many users describe every access problem as a “VPN disconnection,” but several different states can look identical. The client may show a disconnected status, while a kill switch is correctly blocking traffic. It may still show a tunnel as active, while the underlying Wi-Fi has lost access to the internet. A browser may fail because of DNS resolution even though the encrypted tunnel is still established.
Before changing settings, check three things. Look at the VPN client’s status rather than relying only on the browser. Test an ordinary website or service that does not require the remote route you are trying to use. Then disable the VPN temporarily and confirm whether the same network can browse normally. If the connection fails without the VPN, investigate the router, Wi-Fi signal, captive portal, or mobile carrier first.
100+
countries covered
250+
available routes
14 days
refund period
Unlimited
device count
Route diversity is useful during troubleshooting, but it should not be confused with a guarantee that every route behaves identically on every local network. A route can be reachable from one ISP or Wi-Fi network and unreliable from another. A nearby endpoint is often a sensible first test, while a route in the target region can then be tested separately.
Separate device and route failures
If the same account connects successfully on another device using the same network, the first device is the likely source of the problem. Check its background permissions, system time, firewall, sleep behavior, and other network software. If several devices fail on the same Wi-Fi but work on mobile data, inspect the router or local network policy. If one route fails while other routes connect, treat it as a route or protocol-selection issue rather than immediately blaming the whole client.
Record simple observations in a note: network type, device, operating system, client name, selected protocol, selected route, and the moment the tunnel dropped. This is more useful to support staff than a general statement such as “it disconnects all the time.” Do not include passwords, private keys, or a complete subscription URL when sharing diagnostic information.
Check Wi-Fi, sleep, and background settings
A VPN tunnel depends on the device maintaining a usable underlying connection. A weak wireless signal, crowded channel, router roaming, or a phone moving between access points can interrupt the transport connection. The VPN may reconnect automatically, but applications can still experience a pause, failed request, or apparent logout during the transition.
Begin with a controlled comparison. Move closer to the access point, reconnect to Wi-Fi, and test again without changing the VPN route. If possible, compare the same device on another Wi-Fi network and on mobile data. The purpose is not to collect a speed score; it is to determine whether the dropout follows the device or follows the local network.
- ✅ Reconnect to Wi-Fi before judging the VPN client
- ✅ Test with the device awake and the screen unlocked
- ✅ Compare another network without changing several VPN settings at once
- ❌ Do not run two VPN or proxy clients during the same test
- ❌ Do not assume a browser error proves that the tunnel itself dropped
On Android, battery optimization can suspend a VPN application or restrict its background activity. Open the system battery settings, find the VPN client, and allow the background behavior required by the app. Menu names vary by manufacturer, so look for battery optimization, unrestricted battery use, background activity, or an equivalent setting. Also check whether a device-management profile or “deep sleeping apps” list is overriding the permission.
On iOS, background execution is more tightly controlled. A VPN profile can remain managed by the operating system, but the app that controls it may still need permission to operate correctly. Check the VPN configuration in system settings, confirm that the profile belongs to the intended client, and avoid repeatedly installing profiles from different applications. If the problem begins after switching between Wi-Fi and cellular data, reconnect manually once and observe whether automatic recovery works afterward.
On Windows and macOS, inspect sleep and network-adapter behavior. A laptop may suspend its Wi-Fi adapter while sleeping, then restore the network before the VPN client has rebuilt the tunnel. Enable the client’s automatic start or auto-reconnect option if it provides one, and test after waking the device. If a desktop firewall, endpoint-security product, or corporate management profile is installed, check whether it blocks the VPN process after network changes.
Perform a clean troubleshooting test
A clean test removes variables that can produce misleading results. Close browsers and applications that maintain long-lived connections. Quit every other VPN, proxy, network accelerator, and traffic-filtering tool. In particular, do not run the official client at the same time as Clash Verge, sing-box, Shadowrocket, or another client configured with the same subscription. Two applications may compete for the system tunnel, TUN interface, DNS service, or system proxy.
Next, update the client from its official distribution channel and confirm that the device date and time are set automatically. Incorrect system time can interfere with certificate validation and authentication. Check that the subscription configuration is current as well. If you imported a subscription link into Clash Verge, sing-box, or Shadowrocket, update the profile and confirm that the selected proxy group still contains usable entries. A successful subscription import does not prove that every entry is reachable.
- Disconnect the VPN and close other network-control applications.
- Restart the device or, at minimum, restart the network adapter and the VPN client.
- Connect to a single route and keep the protocol setting unchanged.
- Test ordinary browsing, DNS resolution, and the application that originally failed.
- Repeat on another route, then compare the results.
Use the client log when available. Look for messages such as authentication failure, handshake timeout, connection reset, route unavailable, DNS error, certificate problem, or network interface change. These terms are not interchangeable. An authentication error suggests account or configuration trouble; a handshake timeout points more toward reachability, filtering, or protocol compatibility; a DNS error may leave the tunnel intact while name resolution is broken.
Do not paste a full log into a public forum without reviewing it. Logs may contain account identifiers, server names, local addresses, or configuration details. Redact credentials and subscription URLs, and preserve the timestamp and error line because those are usually the most useful parts for diagnosis.
A clean test means one device, one network path, one VPN client, one route, and one controlled change at a time. Without that discipline, every new setting makes the result harder to interpret.
Choose a suitable protocol and route
Protocols handle transport differently, so a connection that fails with one option may work with another. WireGuard is designed for efficient modern tunneling and can recover well from some network changes, but its behavior still depends on the client and server configuration. OpenVPN is widely supported and can be useful as a compatibility fallback, although its transport mode and implementation affect how it behaves on restrictive networks. IKEv2/IPsec is commonly integrated into operating systems and can be convenient for mobile roaming.
Other compatible ecosystems use protocols such as Shadowsocks, VMess, Trojan, or Hysteria2. These are not interchangeable labels for the same mechanism. They may require different client types, transport settings, or profile fields. A subscription link created for a sing-box or Clash-compatible profile should be imported into a client that supports that profile format. Shadowrocket has its own supported formats and rules, while the official Windows, macOS, Android, iOS, and Linux clients may present protocol choices differently.
Change only the protocol first, keep the route constant, and test again. If the connection becomes stable, the original protocol may not suit the local network or current transport conditions. If it remains unstable, restore the original protocol and test another route. A route change can help when an endpoint is congested or temporarily unreachable, but repeatedly switching routes without recording the result hides the pattern.
| Observed behavior | First checks | Reasonable next test |
|---|---|---|
| Drops after sleep or screen lock | Battery, background, and sleep settings | Enable auto-reconnect and repeat the wake test |
| Fails only on one Wi-Fi network | Router stability, captive portal, and local filtering | Compare mobile data or another Wi-Fi network |
| One route fails while others connect | Route status and endpoint reachability | Keep the protocol and select another route |
| All routes fail in one client | Profile validity, permissions, firewall, and conflicting software | Test the official client or a compatible alternative |
| Tunnel says connected but websites fail | DNS, system proxy, browser cache, and kill-switch state | Test DNS separately and inspect client logs |
IEPL, BGP, and CN2 describe network or route characteristics, not universal guarantees against disconnects. A route with a favorable label can still be affected by the local ISP, Wi-Fi loss, device sleep, DNS behavior, or application conflicts. Treat those labels as selection information, then verify the route in your own environment.
Repair DNS, kill switch, and auto-reconnect behavior
A kill switch is designed to block traffic when the VPN tunnel is unavailable. That is useful for preventing accidental direct traffic, but it can look like the internet has stopped working. If the client reports a disconnect and every application immediately loses access, check whether the kill switch is operating as configured. Do not leave it disabled permanently if preventing direct connections is important; instead, use it to understand the symptom and then restore the preferred protection after testing.
DNS problems can create a different illusion. The tunnel may be active, but the device cannot translate a domain name into an address. Test with a known service, compare domain access with a direct address only when appropriate, and inspect whether the client is offering its own DNS mode. Browser secure DNS, operating-system DNS, router DNS, and VPN DNS settings can compete. Change one DNS layer at a time and clear the browser’s cached state only after confirming the tunnel status.
Auto-reconnect also has limits. It cannot restore a connection if the account is rejected, the profile is invalid, the device has no underlying internet access, or the selected route is unavailable. Enable automatic reconnection, but avoid an aggressive loop that constantly tears down and rebuilds the tunnel. Frequent retries can make diagnosis harder and may consume battery on mobile devices.
After modifying DNS, kill-switch, or reconnect settings, restart the client and perform the clean test again. Confirm that local services behave as expected, that the VPN status changes correctly, and that the system does not retain an old proxy setting after the client closes.
Know when to reset or escalate
Resetting a profile is appropriate when configuration files are outdated, corrupted, or imported with incompatible fields. Export anything you intentionally customized, remove the old profile, obtain a fresh subscription configuration, and import it into the correct client. A reset should be targeted: deleting every network profile or changing unrelated operating-system settings can create more work without addressing the cause.
Use the official client when you need the simplest baseline. Use Clash Verge or sing-box when you need rule-based routing and understand how profiles, DNS, and TUN mode interact. Use Shadowrocket when its supported configuration format and system integration match your device. In every case, run only one system-level traffic controller during the test. Rule-based clients can route different applications or domains through different policies, so a single failed application does not necessarily indicate a fully disconnected VPN.
- ✅ Keep the working route and protocol recorded before experimenting
- ✅ Refresh an imported subscription when entries or parameters appear outdated
- ✅ Verify whether the client is using system proxy, TUN mode, or an operating-system VPN profile
- ✅ Contact support with the device, network type, client, protocol, route, and redacted error message
- ❌ Do not share passwords, private keys, or an unredacted subscription URL
Contact support when multiple clean tests fail across different networks, when the account cannot authenticate, or when the client repeatedly produces the same error after a fresh configuration. Include the approximate time, operating system, client version, protocol, route, and whether another network was tested. If you are still within the applicable service terms, review the 14-day no-questions-asked refund policy before making a longer commitment. A refund policy is not a technical fix, but it reduces the cost of evaluating whether the service fits your network.
If the problem follows one device, repair local permissions and network software. If it follows one Wi-Fi connection, investigate the underlying network. If it follows one route or protocol, switch that variable. If every controlled test fails, preserve the logs and escalate instead of endlessly reinstalling clients.
VPN disconnection FAQ
Why does the VPN disconnect when my phone screen turns off?
Battery optimization and background restrictions are the most common causes, although the mobile network may also change during the same period. Allow the VPN client the required background access, check the system VPN profile, enable auto-reconnect, and repeat a screen-lock test. If the issue occurs only on one manufacturer’s battery-management mode, compare the result after excluding the app from that mode.
Should I change the protocol immediately?
Not immediately. First confirm that the underlying internet connection is stable and that another VPN or proxy client is not competing for control. Then change one protocol while keeping the route constant. Protocol compatibility depends on the provider, client, transport, and local network, so a controlled comparison is more meaningful than choosing a protocol based only on its name.
Why does the client say connected while there is no internet?
Check DNS resolution, the kill switch, system proxy settings, and whether the application is routed through the expected policy. In Clash Verge or sing-box, inspect the active rule and TUN or system-proxy mode. In an official client, reconnect after confirming the profile and permissions. If only one website fails, the tunnel may be working and the issue may be destination-specific.
When should I try another client?
Try another compatible client after confirming that the account and subscription configuration are valid. This is useful when the official client has a platform-specific issue or when you need rule-based routing. Import the profile into a client that supports its format, avoid running both clients together, and keep the original configuration available so you can return to a known baseline.
A stable VPN connection is usually restored by narrowing the cause rather than applying every possible fix at once. Check the local network, allow the client to remain active, eliminate software conflicts, test protocol and route changes separately, and use logs when the result is still unclear. That process gives you a repeatable answer—and a safer fallback—when the first troubleshooting attempt does not work.