A VPN that keeps disconnecting is rarely caused by one universal setting. Repeated dropouts can come from a changing Wi-Fi network, mobile background restrictions, missing system permissions, DNS or routing conflicts, an overloaded route, or a protocol that does not fit the current network. The same symptom can also have different causes: a client may show “connected” while the system proxy is inactive, or it may reconnect successfully while a browser or app keeps using an old session.

The fastest way to troubleshoot is to change only one variable at a time. First identify whether the failure affects one device or every device, then check the local network, client mode, permissions, route, protocol, and destination application in that order. This prevents a common mistake: changing nodes repeatedly before confirming that the original connection was actually configured correctly.

Start with the connection path, not the speed test A stable VPN connection depends on the local network, client permissions, tunnel mode, protocol, route, DNS behavior, and destination service. Test each layer separately instead of treating every dropout as a server problem.

90+

Countries covered

200+

Available routes

5

Supported platforms

Unlimited

Simultaneous devices

Identify the type of disconnection first

Before changing any configuration, record what actually happens when the connection fails. Does the client change to “disconnected,” or does it still display an active tunnel while websites stop loading? Does the failure occur only after the device sleeps, after switching from Wi-Fi to mobile data, or when a particular application starts? These details separate a local network interruption from a client, route, or application problem.

A complete tunnel failure usually affects several services at once. Websites stop opening, DNS lookups fail, and applications that depend on the proxy become unreachable. A routing-rule problem is narrower: some websites work, while a specific domain or application uses the wrong path. An expired or invalid subscription may leave an old node visible in the client, but the handshake fails every time. A background restriction may disconnect the tunnel only after the screen is locked or the application is removed from the recent-apps list.

Check the same route with more than one simple request. Open a normal webpage, then open a second unrelated service. If one site fails while the others remain available, avoid concluding that the VPN has dropped. The issue may be the destination service, its DNS response, its account session, or a rule that sends only that domain through a different path.

Common symptoms and likely causes

Observed symptom Likely area to inspect First action
Disconnects after changing Wi-Fi or mobile data Network handoff or stale tunnel Reconnect after the new network is fully established
Disconnects after the screen is locked Battery or background restrictions Allow the client to run in the background
Client says connected but only some apps fail Routing mode, DNS, or application rules Compare system proxy, TUN, and rule settings
Every route fails during connection Subscription, permission, protocol, or local network Refresh the subscription and test another network
One route disconnects while others remain usable Route congestion or protocol compatibility Switch route type or protocol-supported configuration

Keep a short note of the network name, device, client, selected route, and trigger. You do not need a complicated monitoring system. A clear description such as “disconnects when the laptop wakes from sleep” is much more useful to support than “VPN unstable.”

Check the local network and device settings

Many apparent VPN failures begin before the encrypted connection reaches its route. Public Wi-Fi may require a captive portal, restrict UDP traffic, terminate idle sessions, or move devices between access points. A home router may have a changing upstream connection, aggressive firewall rules, or another proxy configuration left over from earlier testing. Mobile networks can switch between radio conditions and data modes while the device is moving.

After joining a new Wi-Fi network, pause the client and open a regular webpage. Complete any sign-in or terms confirmation shown by the network. Once ordinary internet access works without the tunnel, start the client again. Trying to establish the tunnel before completing the captive portal often produces a loop in which the client appears to connect but cannot reach the authentication page.

Also check whether another VPN, proxy, firewall, DNS changer, or traffic-filtering application is active. Two applications may compete for the same system proxy or virtual network interface. On desktop systems, old manual proxy settings can remain enabled after a client is closed. On mobile devices, a previously installed profile may continue to affect routing. Disable unused tools temporarily and test with one client only.

On Windows and macOS, confirm that the client is allowed through the operating system firewall when it first requests access. On Android and iOS, review the VPN profile permission and any system prompt that appears during connection. If a permission was denied earlier, reinstalling the client is not always necessary; checking the system VPN settings and granting the required permission may be enough.

Perform a clean reconnection step by step

A clean reconnection is more useful than repeatedly pressing the connect button. It closes the previous tunnel, clears the client’s active state, and establishes a new path after the local network has settled. The following sequence is suitable for Windows, macOS, Android, iOS, and Linux, although the names of individual buttons differ by client.

  1. Pause or disconnect the current route in the client.
  2. Wait until the device shows a normal local internet connection, then open an ordinary webpage without the VPN.
  3. Close applications that maintain long-lived sessions, such as browsers, messaging tools, cloud drives, or remote-work software.
  4. Check that only one VPN or proxy client is controlling the system network.
  5. Open the client again and refresh the subscription if the node list looks outdated or incomplete.
  6. Select a route appropriate for the destination and connect using the client’s recommended default mode.
  7. Test a new browser session first, then reopen the application that previously failed.
  8. If the device changed networks, repeat the test after the connection has remained stable on the new network.

Refreshing a subscription is different from reconnecting to a route. A subscription update retrieves configuration information; it does not repair a blocked Wi-Fi network or grant missing system permission. If the update itself fails, check the subscription address, account status, client format, and current network. If the update succeeds but every node fails to connect, investigate permission, protocol support, firewall behavior, and the local network next.

For supported clients, a subscription can be imported rather than entering each route manually. Clash Verge and sing-box generally require a compatible configuration format, while Shadowrocket uses the format provided for its platform. The official Windows, macOS, Android, iOS, and Linux clients may offer a direct account-based setup or a subscription import flow. Use the format explicitly supported by the selected client; a successful download does not guarantee that every protocol inside the configuration can be parsed or connected.

After importing, avoid editing several fields without knowing their purpose. A changed server address, port, transport, authentication value, or TLS-related parameter can turn a valid configuration into a handshake failure. If a manually edited node fails while an untouched node works, restore the original configuration before testing again.

Practical conclusion: Disconnect completely, verify ordinary internet access, remove competing network controls, refresh only when necessary, and then establish one clean tunnel before testing applications.

Fix background, sleep, and permission issues

Mobile operating systems are especially likely to suspend a client that is idle, running in the background, or using restricted battery settings. The result may look like a random VPN dropout: the connection works while the application is open, then stops after the screen is locked. Some devices also pause background data, restrict auto-start, or terminate applications aggressively when memory is limited.

On Android, open the client’s application settings and review battery usage, background activity, unrestricted data access, and auto-start options where the device manufacturer provides them. The exact labels differ between Android versions and device brands. Avoid enabling every unrestricted option blindly; grant the client enough permission to maintain the tunnel, then check whether the behavior changes.

On iOS, verify that the VPN profile is installed and that the system allows the client to establish the connection. Low Power Mode, network changes, and application-specific behavior can affect when a tunnel is rebuilt. If the VPN reconnects but one application still shows an old offline state, close and reopen that application rather than repeatedly reinstalling the VPN client.

Desktop systems have a different pattern. Sleep and wake cycles can invalidate the previous tunnel, especially when the network interface receives a new address after waking. Enable the client’s automatic reconnection option if available, and check whether the client starts with the operating system when continuous connectivity is important. If the connection drops only during sleep, do not interpret that event as evidence that every route is unstable; test a fresh tunnel after wake first.

Permissions also affect TUN mode and system-wide routing. A client may display a node list and even complete part of the connection process while lacking permission to create or maintain its virtual interface. On Linux, desktop environments, NetworkManager, firewall rules, and user privileges can interact with the client. Check the client’s documentation for the required permission model, then use the least privileged configuration that works.

Compare routes, protocols, and client modes

If the local network and client permissions are sound, compare another route. A single route can encounter congestion, maintenance, upstream filtering, or a path that does not suit the current carrier. A different country or city is not automatically better; choose according to the destination, physical distance, and the route type shown by the service. Where available, IEPL, BGP, or other route labels describe different transport paths, but the label alone does not guarantee a result on every local network.

Protocol compatibility matters as well. Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard use different connection and transport designs. A network that handles one protocol comfortably may restrict another, especially on public Wi-Fi or a managed office network. The client must support the protocol and its required parameters. A route can therefore fail because the client cannot parse the configuration, because the handshake is blocked, or because the selected transport is unsuitable—not because the account has no usable routes.

Start with the service-recommended client and default configuration. If that remains unstable, compare one alternative client or one protocol-supported route at a time. Clash Verge, sing-box, and Shadowrocket can be useful when you need rule groups, TUN mode, or more detailed routing control, but extra flexibility also creates more places for DNS, rules, and system proxy settings to conflict.

System proxy, TUN, and rule-based behavior

System proxy mode normally affects applications that respect the operating system’s proxy settings. TUN mode creates a virtual network interface and can capture a broader range of traffic, including applications that do not use the system proxy. Rule-based clients may send some domains directly, some through a proxy, and others to a rejected path. If a browser works but a native application does not, the issue may be coverage rather than tunnel stability.

Test with a simple, temporary configuration. Use one client mode, a standard rule set, and one route. Confirm that the client is the active system proxy or TUN controller. Then open the affected application in a new session. If the application works only in global proxy mode but not in rule mode, inspect its domains, DNS requests, background services, and content delivery endpoints before changing the route again.

DNS can create confusing symptoms. A client may send the main request through the tunnel while domain lookups still use the local resolver. This can produce inconsistent routing, old addresses after a route change, or an application that reaches its homepage but fails when it requests additional resources. Flush the relevant DNS cache, use the client’s supported DNS behavior, and retest after reconnecting. Do not assume that changing a browser DNS option changes the behavior of every native application.

When the problem is the application rather than the VPN

Long-lived sessions are more sensitive to brief interruptions than ordinary webpages. Video calls, remote desktop tools, file synchronization, messaging clients, and streaming applications may not recover cleanly after the underlying address changes. The VPN may already be connected again while the application continues using a stale socket or old authentication session.

After reconnecting, close and reopen the affected application. Sign in again only if the service requests it, and avoid opening several parallel sessions during diagnosis. Check whether only one application fails while a new browser session and another unrelated service work normally. If so, inspect the application’s proxy support, DNS behavior, account session, and its own network restrictions.

Some services use several domains for login, APIs, media, updates, and file delivery. A rule that covers the visible website may not cover the background endpoints. This is especially relevant when a page loads but images, messages, downloads, or playback stop. Review the client’s routing rules and keep all related requests on a consistent path when the application requires it.

Do not confuse a stale app session with a dead tunnel First test a new browser session and an unrelated service. If they work, restart the affected application and inspect its routing coverage before replacing the VPN configuration.

FAQ for repeated VPN dropouts

Why does my VPN disconnect whenever I switch networks?

Switching from Wi-Fi to mobile data, or moving between wireless access points, changes the underlying network path. The existing tunnel may no longer be valid even if the client still shows a connected state. Disconnect after the handoff, confirm ordinary internet access, and establish a fresh tunnel. If the behavior is frequent, enable automatic reconnection and avoid testing an old application session immediately after the switch.

Why does the VPN work while the phone screen is on but stop in the background?

Battery optimization, background data limits, auto-start restrictions, or manufacturer-specific task management may suspend the client. Review the client’s battery and background permissions, confirm the VPN profile is installed, and test again after locking the screen. Grant only the permissions needed to maintain the connection.

Should I keep changing routes when one route disconnects?

Try another route once, but first confirm that the local network, client permissions, and tunnel mode are correct. If only one route fails, congestion or protocol compatibility may be involved. If every route fails, changing routes repeatedly will not fix a captive portal, expired configuration, firewall conflict, or missing permission.

When should I refresh the subscription?

Refresh it when the node list is outdated, a configuration appears incomplete, or the service indicates that routes have changed. A subscription update does not replace a permission check or repair a local network. Use a client-compatible format, and avoid exposing the subscription address because it can provide access to account configuration.

A final stability checklist

Once the connection works again, repeat the original use case rather than stopping at the client’s connected indicator. Check a new browser session, the application that failed, and a short period of ordinary use. If the device will move between networks, test reconnection after the handoff. If the problem returns, compare the trigger with your notes: sleep, Wi-Fi change, one route, one protocol, one application, or one rule.

Bottom line: Reliable troubleshooting follows the path from local network to client permissions, tunnel mode, route, protocol, DNS, and application session. Once the failing layer is identified, the fix is usually simpler than replacing every setting at once.