A VPN that keeps disconnecting is rarely caused by a single universal fault. The drop may come from a changing Wi-Fi or mobile connection, a phone placing the VPN app into sleep mode, a protocol that does not suit the current network, damaged local configuration, DNS or routing conflicts, or a busy server path. The most useful approach is to identify what changes at the exact moment of failure instead of repeatedly pressing Connect and switching nodes at random.

This guide follows a practical order: observe the symptom, stabilize the local network, check permissions and power settings, test another protocol or route, refresh the client configuration, and then verify whether the problem is limited to one device or one network. The same method applies to official Windows, macOS, Android, iOS, and Linux clients, as well as compatible clients such as Clash Verge, sing-box, and Shadowrocket when they are using a subscription profile.

Identify the Disconnect Pattern Before Changing Settings

First record what “disconnecting” actually means. Some clients show a clear disconnected state and stop forwarding traffic. Others remain visually connected while the tunnel has lost access to the relay, causing websites to load slowly or fail. A third situation is a normal reconnection: the client briefly renegotiates the tunnel, then restores service without requiring manual action. These cases point to different causes.

Notice whether the problem appears during a particular activity. A connection that survives ordinary browsing but fails during a large download may be affected by sustained traffic, route congestion, or a protocol timeout. A connection that drops when the screen locks is more likely related to background restrictions. A tunnel that fails only inside a corporate, school, hotel, or public Wi-Fi network may be affected by firewall rules or blocked transport methods. A failure limited to one application may instead involve that application’s own proxy, DNS, or network permissions.

90+

Countries covered

200+

Available routes

Unlimited

Simultaneous devices

5

Supported platforms

Use a simple comparison rather than changing several variables at once. Test the same device on the same network with one route, then test another route while keeping the protocol unchanged. After that, test another protocol while keeping the route unchanged. This makes the result more meaningful. If you change the network, server, protocol, DNS mode, and client at the same time, you may restore the connection but learn nothing about the original cause.

Separate Local and Remote Faults

Check whether ordinary internet access works with the VPN turned off. If the base connection is already unstable, the VPN cannot make it reliable. Restart the router or reconnect the device, then observe whether the local connection remains stable without the tunnel. On a laptop, move closer to the access point or try a wired connection. On a phone, compare Wi-Fi with mobile data without changing anything in the VPN profile.

Next, check another VPN route. If one route disconnects while another remains stable on the same device and network, the issue is probably route-specific rather than a general problem with the client. A server name is only a label; the actual result depends on the entry path, relay capacity, exit network, and current congestion. Keeping a backup route in the same broad region is usually more useful than jumping between unrelated locations.

Quick diagnosis: Reproduce the failure with one variable changed at a time. This is faster and more reliable than repeatedly reinstalling the app without identifying the trigger.

Check Network Switching and Router Behavior

Many apparent VPN failures happen during a change in the underlying network. A phone may move from Wi-Fi to mobile data when leaving home, a laptop may roam between access points, or a router may renew its public connection. The tunnel was created over the old path and may need to be renegotiated over the new one. Some clients handle this automatically; others briefly disconnect or require a manual reconnect.

For testing, turn off automatic Wi-Fi switching, disconnect from one network completely, and connect to the other before starting the VPN again. If the tunnel becomes stable after this controlled handoff, the cause is probably network transition rather than a bad account or subscription. On mobile, check whether the operating system permits the VPN application to use mobile data. A client can appear configured correctly but fail as soon as Wi-Fi disappears if cellular access is restricted.

Routers can also interfere with long-lived tunnels. Aggressive idle timeouts, unstable NAT behavior, guest-network isolation, or firewall inspection may interrupt a connection that remains open for a long time. Public networks may restrict UDP traffic or only allow web-like TCP traffic. In those environments, a protocol using a different transport may work better, although it may have different performance characteristics.

Test the Base Connection First

Disconnect the VPN and use several ordinary websites or applications for a short observation period. You do not need a single speed-test result to make this diagnosis. Look for Wi-Fi signal changes, repeated reconnects, pages that fail without the VPN, or the router losing its upstream connection. If the base network has packet loss, changing the VPN route may only hide the symptom temporarily.

On Windows and macOS, try another access point or a wired connection when available. On Android and iOS, disable any data-saving mode that restricts the VPN app during testing. On Linux, inspect whether NetworkManager or another network service is repeatedly replacing the interface configuration. Do not run two network managers that both attempt to control the same connection.

Remove Conflicting Proxies and Tunnels

Only one primary VPN tunnel should normally control system traffic. Running an official VPN client at the same time as Clash Verge, sing-box, Shadowrocket, a browser proxy, or another VPN can create competing routes and DNS settings. The result may look random: some applications work, others fail, and the client may report a disconnect even though a different proxy process is still active.

Close other proxy tools completely, not only their windows. Check the system proxy setting and disable an old manual proxy if the current client is intended to handle traffic itself. If you use a compatible client, import the subscription profile into that client and let it manage the selected mode. Avoid importing the same profile into multiple clients and leaving all of them enabled.

Review Battery, Background, and System Permissions

Mobile operating systems are designed to reduce background activity. A VPN must maintain a service, renew credentials, handle network changes, and keep its tunnel alive even when the screen is off. If the operating system suspends the client, removes it from memory, or restricts background data, the VPN may disconnect after the device has been idle.

On Android, open the application settings and review battery usage, background activity, unrestricted data access, and permission to run when the system starts if that option is available. The exact names vary by manufacturer. Battery-saver modes, device-cleaning utilities, and vendor security tools may also terminate background services. Add the VPN client to the relevant exception list for testing, then lock the screen and see whether the tunnel remains active.

On iOS, check the VPN profile under the system settings and allow the application to use cellular data if you expect it to work away from Wi-Fi. Low Power Mode can alter background behavior, and switching between networks can require the VPN to reconnect. If the client asks to add or update a VPN configuration, approve the system prompt and confirm that the profile shown in settings belongs to the intended application.

Desktop systems have their own background controls. Windows security software may block a newly installed tunnel driver or prevent the client service from starting. macOS may require approval for a network extension, system extension, or VPN configuration. Linux distributions can have permission differences between a graphical client, a command-line service, and a desktop session. If the client connects only after you manually start a service, check whether that service is enabled and whether it is running under the expected user or system account.

Check Sleep and Power Events

Ask whether the failure happens after closing a laptop lid, waking a computer, locking a screen, or leaving a phone untouched. If yes, compare the behavior with sleep disabled temporarily. A tunnel may need to be rebuilt after the network interface sleeps; this is not necessarily a sign that the account or server is invalid. Enable the client’s reconnect or auto-start option where available, but avoid aggressive repeated retries if the base network has not returned.

Also check whether a firewall, endpoint security product, or parental-control tool changes its policy when the device moves from a private network to a public network. Temporarily pause one nonessential filter only for diagnosis and restore it afterward. Do not permanently weaken system security merely to keep a VPN connected.

Mobile rule: If the VPN fails after screen lock or network handoff, review battery, background-data, cellular, and VPN-profile permissions before replacing the subscription or changing every route.

Compare Protocols, Routes, and DNS Settings

VPN protocols do not behave identically on every network. WireGuard is lightweight and often reconnects efficiently, but a restrictive network may interfere with the transport it uses. OpenVPN can operate over different transport choices and is widely supported, though the selected mode affects compatibility and overhead. Shadowsocks is a proxy protocol rather than a full system VPN by itself, while VMess, Trojan, and Hysteria2 are commonly used by compatible clients with their own transport and routing configurations. The correct choice depends on the client, server profile, and network conditions.

Do not assume that a protocol with a familiar name is automatically faster or more stable. A profile may include transport, encryption, multiplexing, DNS, and routing rules that matter as much as the protocol label. A configuration designed for a compatible client may not be directly interchangeable with an official client. Import a subscription using the format supported by the selected application, then verify that the client has actually loaded the updated server list and not an old local copy.

Begin by selecting a recommended or automatic protocol if the client offers one. If the connection still drops, compare a second supported protocol on the same route. Then compare another route while keeping the protocol fixed. Record whether the drop happens during connection setup, after idle time, during sustained traffic, or after a network change. This pattern helps distinguish transport incompatibility from route congestion.

Choose a Sensible Backup Route

A route that is geographically close is not always the most stable. The effective path includes your local access provider, the VPN entry, any relay or dedicated segment, the exit network, and the destination service. A nearby entry with a good cross-border path can outperform a route that looks close on a map but crosses a congested segment. IEPL, BGP, and CN2 labels describe possible network paths, but the label alone is not a guarantee; current capacity and routing conditions still matter.

If a selected route repeatedly disconnects, switch to another route with a similar destination region before making a large geographic jump. A same-region backup makes it easier to tell whether the problem is server-specific. If the service you are accessing uses regional rules, frequent changes between distant exits can also make account sessions appear inconsistent. Stabilize the connection first, then verify the destination service separately.

Review DNS and Routing

DNS problems can look like a disconnected VPN because domains stop resolving even though the encrypted tunnel remains present. Test whether an already known IP-based service or the client’s connection indicator behaves differently from a new domain lookup. If only domain names fail, review the client’s DNS mode and system resolver settings. Avoid leaving a manually configured DNS server from an old proxy tool active after switching clients.

Split tunneling can create another misleading symptom. With split tunneling enabled, some applications use the VPN while others use the ordinary connection. A browser may work while a game, update service, or desktop application does not. Confirm that the affected application is included in the intended rule set. In Clash Verge or sing-box, inspect routing rules, DNS mode, and system proxy status. In Shadowrocket, check the selected global, rule, or proxy mode and confirm that the relevant domain is not being sent through a failing policy group.

Perform a Clean Reconnect and Configuration Refresh

When basic checks do not help, perform a controlled reset. Disconnect the VPN, close the client, and stop any companion proxy process. Reconnect the underlying network, then reopen only the intended client. Select one route and one protocol, connect, and test ordinary browsing before launching a high-traffic application. This sequence removes stale network states without immediately deleting useful configuration.

If the issue continues, refresh the subscription profile. Subscription links can contain updated routes and settings, but the client must actually perform an update. Confirm that the profile update completed, check its last refresh status if shown, and select a newly loaded route. Do not paste a subscription link into an untrusted website or share it publicly: it can provide access to your service configuration.

As a last local step, remove and recreate the VPN profile or network extension using the client’s own settings. On Windows, check whether the tunnel adapter is present and whether security software blocked its driver. On macOS and iOS, remove an obsolete VPN configuration only after confirming that it is not required by another service. On Android, revoke and approve the VPN permission again if the system profile appears damaged. On Linux, inspect the service logs and interface state rather than deleting system networking files without a backup.

When Reinstallation Helps

Reinstallation is useful when the application cannot save settings, the tunnel adapter is missing, or an update left incompatible components behind. It is less useful when the real cause is an unstable router, a restricted battery policy, or an overloaded route. Before uninstalling, note the current protocol, routing mode, and whether the profile is stored locally or retrieved from a subscription. After reinstalling, import the profile again and run a clean single-route test.

Keep the client and operating system reasonably current, but do not install unofficial modified builds. Official Windows, macOS, Android, iOS, and Linux clients are generally easier to diagnose because their tunnel components and permission flows are documented by the provider. Compatible clients are valuable when you need advanced routing, but their logs and rule sets require more careful inspection.

Final Checklist and Frequently Asked Questions

Before contacting support, collect useful details: the device platform, network type, whether the VPN is the official client or a compatible client, the selected route, the selected protocol, and what action immediately preceded the drop. Include whether ordinary internet access works without the VPN and whether another route behaves differently. Avoid sending your password or exposing a private subscription link. Clear, reproducible information is more helpful than a message that only says “it disconnects.”

Why does the VPN disconnect when my phone screen turns off?

The operating system may be suspending the VPN service, restricting background data, or applying a battery-saving policy. Review battery optimization and background permissions for the VPN app, allow cellular data if needed, and test again with power-saving mode disabled. If the connection returns after unlocking the phone, the timing strongly suggests a background-management issue rather than a server failure.

Should I change the protocol immediately?

Change it after checking the local network and conflicting applications, not before. A protocol change is useful when one network blocks or disrupts the current transport, but changing protocol, route, DNS, and routing mode simultaneously makes the result difficult to interpret. Keep the route fixed while comparing protocols, then keep the protocol fixed while comparing routes.

Why does one route disconnect while another works?

Routes can differ in entry distance, relay capacity, cross-border path, exit network, and current congestion. A route name does not reveal every part of that path. If another route works on the same device and network, keep the stable route as the primary choice and retain a backup in a similar region. Report the unstable route and the time or activity associated with the failure.

What should I check in Clash Verge, sing-box, or Shadowrocket?

Check that the subscription was refreshed, the intended profile is active, and only one client controls the system proxy. Then inspect global or rule mode, DNS settings, split-tunneling rules, and the policy group assigned to the affected domain. A tunnel can be healthy while a rule sends one application directly or through a failed proxy. If diagnosis becomes difficult, temporarily use a simple single-route configuration before restoring advanced rules.

Bottom line: Reliable VPN troubleshooting is a process of controlled comparison: stabilize the underlying network, protect the client from system restrictions, remove competing proxies, test protocols and routes separately, and refresh configuration only after the cause is narrowed down.