A VPN that keeps disconnecting is rarely caused by one mysterious fault. In most cases, the connection is being interrupted when the device changes networks, the operating system limits background activity, another proxy tool takes control of the same traffic, or the selected protocol does not suit the current network. A useful troubleshooting method is to change one condition at a time and test again, rather than reinstalling several clients or replacing every server at once.
Start by identifying the pattern. Does the connection drop immediately after the screen locks, when the device switches between Wi-Fi and mobile data, after the computer wakes from sleep, or only when using one particular server? Does the client show a timeout, a failed handshake, a lost tunnel, or an apparently active connection with no traffic? These details help separate a local device problem from a route, protocol, or subscription problem.
7
checks in this guide
5
supported platforms
90+
countries available
200+
routes available
Identify the disconnect pattern first
The first fix is diagnostic rather than technical. A connection that fails only after sleep is usually affected by power management or a network-interface change. A connection that fails whenever you move from home Wi-Fi to mobile data points toward roaming behavior, captive portals, or a client that does not automatically reconnect. A connection that works on one route but repeatedly fails on another may indicate route congestion, an unsuitable protocol, or a server-side issue.
Test the same client on a stable network before making major changes. Connect with one route, open a normal website, and leave the client window visible long enough to observe whether the status changes. Then try another route from the same group. If all routes fail on one device but another device works on the same network, focus on local permissions, firewall rules, background restrictions, or competing network tools. If several devices fail at the same time, check the subscription status and service notices before changing local settings.
Also distinguish between a real tunnel failure and an application-level interruption. A video player may stop because its own session expired, while the VPN remains connected. A browser may show a timeout because its proxy setting is wrong even though a virtual network interface is active. Check the client status, the system network indicator, and another ordinary website before concluding that the tunnel itself has dropped.
- ✅ Note whether the drop follows sleep, screen locking, network switching, or route changes.
- ✅ Test one other website or application to confirm whether traffic is generally affected.
- ✅ Compare a different route while keeping the device and network unchanged.
- ❌ Do not change the client, protocol, subscription, and firewall settings simultaneously.
- ❌ Do not assume that a route list proves that the system is using the selected connection.
The timing of the disconnect is often more useful than the error message. Repeated drops after sleep or network switching usually require device-side changes, while route-specific failures require route or protocol testing.
Fix network switching and automatic reconnect
Wi-Fi and mobile networks can change their interface, address, DNS response, or gateway while the device is moving between access points. A VPN tunnel created before that change may no longer have a usable path to its server. This is especially common when a laptop wakes from sleep, when a phone leaves a home router, or when a public network displays a sign-in page.
First disconnect the VPN, confirm that the underlying network itself works, and complete any captive-portal login in a regular browser. Then reconnect the client. If the client includes an automatic reconnect option, enable it only after confirming that the profile and route are correct. Some clients also offer a “connect on system startup” or “reconnect on network change” setting. These settings are useful, but they cannot bypass a network that requires browser authentication.
On Windows and macOS, inspect the active network adapter when the problem occurs. A computer may have Ethernet, Wi-Fi, a virtual adapter, a corporate security filter, and a second proxy application active at the same time. On Android and iOS, confirm whether the VPN permission is still enabled and whether the system has changed from Wi-Fi to cellular data. If reconnecting works immediately after the network is stable, the main problem is likely transition handling rather than the subscription itself.
Do not repeatedly press Connect while the previous tunnel is still shutting down. Wait for the client to show a fully disconnected state, then reconnect once. Repeated connection attempts can leave stale routes or duplicate virtual interfaces, making later tests less reliable. If the client offers a reset network or clear temporary state function, use that before reinstalling the application.
Remove power-saving and background restrictions
Mobile operating systems are designed to suspend applications that consume network, battery, or processor resources in the background. A VPN client may therefore appear stable while its screen is open but disconnect shortly after the phone locks. The exact menu names vary by system version and device manufacturer, but the relevant controls usually include battery optimization, background activity, unrestricted data, and automatic startup.
On Android, open the application settings for the VPN client and review battery usage. If the client is restricted, allow background activity or choose the less restrictive battery mode available on the device. Also check mobile-data permissions, background data, and any manufacturer-specific task-cleaning feature. Some Android interfaces close background services aggressively even when the standard battery menu appears correct.
On iOS, the system manages background behavior more tightly. Confirm that the VPN profile is present, that the client has permission to establish a VPN connection, and that Low Power Mode or a network-filtering conflict is not interfering with the connection. If the client provides an on-demand or always-on option, read what it changes before enabling it. A setting that forces reconnection can be useful for a personal device but may be unsuitable on a network with frequent captive-portal transitions.
On Windows and macOS, power-saving can suspend network adapters or pause applications during sleep. Review whether the disconnect happens only after closing the lid or locking the screen. A desktop client should also be allowed through the operating system firewall when prompted. If a security suite contains web protection, traffic inspection, or its own VPN component, test with that feature temporarily disabled according to the vendor’s instructions. Do not permanently weaken security controls; the purpose of the test is to identify a conflict.
| Observed behavior | Likely area to inspect | Practical action |
|---|---|---|
| Drops after the phone screen locks | Battery and background limits | Allow background activity and review battery optimization |
| Drops after a laptop wakes | Network adapter and sleep handling | Wait for the network to stabilize, then reconnect |
| Works on Wi-Fi but not mobile data | Mobile-data permission or carrier filtering | Check data access and test another compatible route |
| Connects but applications have no traffic | System proxy, DNS, or routing mode | Verify the selected mode and disable competing proxy tools |
Remove client conflicts and verify traffic mode
Running two network clients at the same time is one of the most common causes of unstable behavior. For example, an official VPN client may create a virtual network interface while Clash Verge, sing-box, or Shadowrocket is also changing proxy rules. A browser extension, enterprise security agent, ad-blocking DNS application, or another VPN can create a similar conflict. The result may be a connection that shows as active but loses traffic, reconnects repeatedly, or routes only some applications.
Close every other proxy or VPN application before testing. On a computer, check the system tray, menu bar, startup list, and background processes. On a phone, look for another active VPN profile or a local filtering application. Keep one client and one connection mode active. If the chosen client supports both system-proxy mode and virtual-interface mode, test the mode appropriate for the application you need. System-proxy mode generally affects applications that respect the operating system proxy, while virtual-interface mode can handle traffic from applications that do not use those proxy settings, subject to the client’s routing rules.
After changing modes, fully disconnect and reconnect. Check whether the browser, terminal, game launcher, or streaming application is using the intended path. A browser can retain its own proxy settings, and some applications cache DNS or connection results. Restart the affected application after the tunnel is established rather than interpreting an old session as a new failure.
With Clash Verge or sing-box, confirm that the selected configuration is enabled, the correct group is selected, and the core process is running. With Shadowrocket, verify the active configuration, routing policy, and VPN permission. With an official Windows, macOS, Android, iOS, or Linux client, confirm that the imported subscription is attached to the current profile. Do not import the same subscription into several active clients and leave them all attempting to manage the device.
Test the protocol, route, and subscription
A protocol that works well on one network may be unreliable on another. Shadowsocks is commonly used for encrypted proxy transport. VMess and VLESS are frequently found in configurations based on compatible proxy cores. Trojan uses a TLS-oriented connection model, while Hysteria2 uses a QUIC-based transport. WireGuard is a VPN protocol with its own key and peer configuration model. These protocols are not interchangeable, and a client that supports subscription import may still lack support for every protocol contained in that subscription.
If the client disconnects on every route, update the subscription and confirm that the profile contains usable entries. If only one route fails, try another route in the same region before changing the whole client. A route can be temporarily unsuitable because of congestion, maintenance, address reputation, or a transport path that does not match the current network. Avoid judging stability from a single connection attempt.
When a client offers protocol or transport choices, keep the test controlled. Select one compatible route, connect, and observe whether the failure pattern changes. Then test another protocol or route while keeping other settings unchanged. Do not manually edit ports, server addresses, UUIDs, passwords, or transport fields unless the provider’s documentation specifically instructs you to do so. A small typo can look identical to a network block or authentication failure.
Subscription links should be treated as account credentials. If the link was copied from a chat application, verify that it was not truncated or altered. If the panel provides a refreshed subscription link, remove the old entry from the client and import the new one. A successful update message is not enough: confirm that route names, groups, protocol labels, and usable configuration details are displayed.
- ✅ Update the subscription from the client’s subscription manager.
- ✅ Confirm that the client core supports the protocol used by the selected route.
- ✅ Test a different route while keeping the same client and network.
- ✅ Use the official client or a compatible third-party client for your platform.
- ❌ Do not paste a private subscription URL into a public conversion website.
- ❌ Do not mix fields from different protocols or copy credentials from an unrelated profile.
Run a controlled connection test
Once the basic settings have been reviewed, use a short, repeatable procedure. The purpose is not to produce an impressive speed result; it is to determine whether the connection can remain established under a known set of conditions.
- Disconnect every VPN, proxy, and traffic-filtering client except the one being tested.
- Confirm that the ordinary network works without the VPN and complete any captive-portal login.
- Open the chosen client and check that its subscription or configuration is current.
- Select one compatible route and one connection mode. Avoid automatic route switching during the first test.
- Connect and verify that the client reports an active tunnel, not merely an imported profile.
- Open a normal website and one application that previously showed the problem.
- Lock the phone or let the computer sleep only after the active-state test succeeds, then check whether the client reconnects correctly.
If the connection survives while the device is active but fails during sleep, return to battery and background settings. If it fails immediately, return to protocol compatibility, firewall permissions, and subscription validity. If it remains connected but one application cannot communicate, inspect that application’s proxy settings and the client’s routing rules instead of repeatedly changing servers.
Linux users should also check whether NetworkManager, a desktop environment network service, or another tunnel manager is replacing routes after the VPN connects. A command-line client may establish a tunnel without automatically configuring every application. Review the client’s logs for authentication, DNS, handshake, and routing errors, but remove private addresses and credentials before sharing the log.
Stabilize the underlying network, remove competing clients, relax background restrictions, confirm subscription and protocol support, then compare routes. This order prevents a local power-saving problem from being mistaken for a server failure.
Know when to contact support
Contact support when the problem remains after a clean test on more than one compatible route, when the subscription cannot update, or when the client reports a consistent authentication or server-side error. Include the platform, client name and version, protocol or route label, network type, time of the failure, and the exact non-sensitive error text. Explain what you already tested so that support does not repeat the same basic steps.
Do not send your password, complete subscription URL, access token, private key, or full configuration file. If a diagnostic file is necessary, redact credentials and identify only the relevant error lines. Screenshots should hide account identifiers and subscription data. Support can usually work more efficiently with a clear sequence such as: “The connection works on Wi-Fi, drops after screen lock, and remains stable when the client stays open,” rather than a screenshot showing only a disconnected status.
If you are using an unofficial client, first reproduce the issue with the official Windows, macOS, Android, iOS, or Linux client when available. For third-party tools, provide the client core and import format as well as the operating system. Clash Verge and sing-box configurations may require different fields or core versions, while Shadowrocket uses its own profile and rule presentation. A route that is valid in one format may not be fully represented after an incorrect conversion.
FAQ: VPN connection drops
Why does the VPN disconnect when my phone screen locks?
The most common causes are battery optimization, restricted background activity, mobile-data limits, or a system task cleaner closing the client. Review the client’s battery and background permissions first. If the issue appears only when switching from Wi-Fi to mobile data, also check mobile-data access and reconnect after the new network is fully available.
Should I change the protocol immediately?
No. First confirm that only one client is active, the subscription is current, and the selected route is compatible with the client. Then compare one alternative route or protocol at a time. Changing several parameters together makes it impossible to know which change solved or worsened the problem.
The client says connected, but applications have no traffic. What should I check?
Check whether the client is using system-proxy mode or virtual-interface mode, and whether the affected application follows that mode. Inspect browser-specific proxy settings, DNS rules, routing policies, and competing VPN applications. Restart the application after reconnecting so that it does not reuse a failed session.
What information should I provide to support?
Provide the operating system, client, route or protocol label, network type, approximate failure time, and exact error message. Describe the result of testing another route and whether the failure occurs after sleep or network switching. Keep passwords, subscription URLs, access tokens, and private configuration fields hidden.
A stable VPN connection usually comes from a simple baseline: one client, one current configuration, one compatible route, and device settings that allow the client to remain active. Work through the checks in order, change only one variable at a time, and use support when the same failure can be reproduced after local conflicts and power restrictions have been ruled out.