VPN Keeps Disconnecting? Troubleshooting Fixes That Work

A VPN that keeps disconnecting is usually not a single problem. The interruption may come from an unstable Wi-Fi or mobile connection, an overloaded route, a protocol that does not suit the current network, battery restrictions, a conflicting proxy, or a system setting that suspends the tunnel. Reinstalling the client can remove corrupted local data, but it does not repair a weak network, an unsuitable route, or an operating system that is deliberately stopping the background connection.

The most efficient troubleshooting method is to change one variable at a time. First establish whether the access network itself is stable. Then refresh the subscription, try another route, compare protocols, and inspect device permissions. If the VPN drops only when the screen turns off, the cause is different from a tunnel that fails immediately on every network. Recording when the disconnection happens makes the diagnosis much faster.

main areas to check

110+

countries covered

240+

available routes

∞

device limit

Identify the Disconnection Pattern

Before changing a setting, describe the failure precisely. “The VPN is unstable” can mean several different things. A client may fail during the initial handshake, connect successfully and drop after browsing begins, disconnect whenever the phone locks, or remain connected while selected applications stop loading. Each pattern points to a different layer of the connection.

Check when the tunnel drops

If the connection fails before it reaches the connected state, examine the subscription, credentials, protocol compatibility, route availability, and local firewall. If it connects and then drops during ordinary use, focus on packet loss, route quality, sleep behavior, and transport compatibility. If it works while the screen is active but stops after the device locks, battery optimization and background permissions are more likely than the server itself.

A connection that drops only on one website or in one application may not be a full VPN failure. The app could be using a direct rule, a separate secure DNS feature, an internal proxy, or a connection type that the selected route does not handle well. Test a normal browser request and another application before concluding that the entire tunnel has failed.

✅ Note whether the failure occurs during connection, during browsing, after idle time, or after the screen locks.
✅ Test the same route on the same device before changing additional settings.
✅ Check whether every application is affected or only one application.
❌ Do not judge stability from one short page load.
❌ Do not assume a connected icon proves that all traffic is using the same policy.

First conclusion: The timing of a drop is diagnostic evidence. Identify the pattern before replacing the client or repeatedly pressing Connect.

Test the Local Network First

A VPN cannot maintain a tunnel if the underlying connection repeatedly loses reachability. Wi-Fi roaming, weak signal, captive portals, congested public networks, and mobile networks moving between connection types can all interrupt a session. In this situation, the VPN may be reporting the symptom rather than causing it.

Disconnect the VPN and use the same browser or application for a while. Open several ordinary sites, observe whether the network pauses, and check whether the device changes from Wi-Fi to mobile data or back again. On a laptop, temporarily move closer to the access point or test another trusted network. On a phone, compare Wi-Fi with mobile data without changing the VPN route at the same time. A stable result on one access network and repeated drops on another is a strong indication that the local path needs attention.

Public Wi-Fi often requires a sign-in page before allowing normal traffic. Connect to the Wi-Fi first, complete the captive portal in a browser, and only then start the VPN. Some networks block unknown UDP traffic or aggressively close idle sessions. That does not mean every protocol is broken; it means the access network may require a different transport or a more conservative keep-alive behavior.

Also check whether another network utility is active. A browser proxy extension, system proxy, security suite, enterprise access tool, DNS filter, or second VPN client can alter the same traffic path. Two clients may compete for the system tunnel, while a proxy extension may affect only the browser and make testing results look inconsistent.

For an additional comparison, use the site’s network test page while disconnected and again after connecting. A changed exit IP confirms that the tested request reached a different exit, but it does not prove that every application is covered. If the IP never changes, investigate the client mode, routing rules, system permission, and local proxy settings before focusing on speed.

Refresh the Subscription and Change the Route Carefully

Subscriptions can contain multiple protocols, route types, and server entries. A route that worked previously may become unavailable, be temporarily congested, or no longer match the current configuration. If the client has not refreshed its subscription for a long time, the displayed list may contain outdated entries. Refresh the subscription from inside the official client or compatible client, wait for the update to finish, and reconnect using a newly listed route.

Do not paste a subscription link into an unknown conversion website or send it to another person for testing. A subscription link can contain access information. Treat it like a password: import it only into a trusted client, avoid public screenshots, and remove old links from notes or chat histories when they are no longer needed.

When choosing another route, begin with a route geographically appropriate for your normal location and application needs. A route that is much farther away may introduce more network segments and more opportunities for packet loss. At the same time, the nearest route is not always the most suitable. A route can be close but affected by the current access provider, while another route with a different upstream path may be more stable.

Route labels can also contain useful technical information. IEPL is generally used to describe a private international leased-line arrangement, while BGP describes how networks exchange and select routes. CN2 is an operator-related network designation. These labels are useful clues, not universal guarantees. Stability still depends on the complete path between your access network, the selected entry, and the destination.

✅ Refresh the subscription before judging an old route.
✅ Compare more than one route while keeping the device and access network unchanged.
✅ Prefer a route with protocol and transport details that your client clearly supports.
✅ Record which route remains connected when the device is active and when it is idle.
❌ Do not repeatedly reconnect to a route that fails during the handshake.
❌ Do not treat a country label as proof of exact geographic location or guaranteed performance.

Route conclusion: Refresh first, compare routes second, and evaluate the complete path rather than trusting a location name or a single successful connection.

Compare Protocols and Transport

Different protocols behave differently when the access network is restrictive or unstable. Shadowsocks is commonly used as an encrypted proxy method. VMess and Trojan use different authentication and transport designs, while VLESS is another protocol with its own client requirements. Hysteria2 and TUIC depend on UDP-based transport and may perform well on suitable networks, but a network that filters or mishandles UDP can make them appear unreliable. WireGuard is a VPN protocol with efficient operation, but it still depends on correct keys, allowed addresses, endpoint reachability, and the behavior of the underlying network.

Compatibility must be checked at both ends. A client may accept a subscription link but support only some of the protocols inside it. A node can therefore appear in the list while failing to connect because the client does not support its transport, TLS settings, authentication fields, or required options. Update the client from its official source, confirm the protocol shown for the selected node, and compare a compatible alternative rather than editing unknown fields randomly.

UDP-based transport can be sensitive to public Wi-Fi, office firewalls, and some mobile network conditions. If a UDP-based route disconnects repeatedly, test a compatible TCP-based option when one is available. The reverse can also be true: a TCP route may remain connected but feel unusable when the path is congested, while a suitable UDP route may recover more efficiently. The correct choice depends on the network and destination, not on a universal ranking.

Keep the test controlled. Select one protocol, connect, perform the same browser and application checks, and observe whether the drop pattern changes. Then disconnect completely before selecting another profile. Switching profiles without closing the previous session can leave stale routes or a temporary conflict in the operating system.

What you observe	What to inspect	Practical next step
Handshake fails immediately	Credentials, protocol support, endpoint, firewall	Refresh the subscription and try a compatible route
Only UDP-based profiles drop	Wi-Fi, office filtering, mobile transport behavior	Compare a compatible TCP-based profile
Browser works but one app fails	Rules, app proxy settings, secure DNS, direct mode	Inspect per-app policy before changing the server
Connection stops after idle time	Keep-alive, sleep, battery optimization	Review background permissions and power settings

Follow a Controlled Fix Checklist

The following sequence is designed to isolate common causes without destroying useful evidence. The menu names vary across Windows, macOS, Android, iOS, and Linux, but the logic remains similar. Apply a change, reconnect, and test the same application before moving to the next change.

Stop competing network tools. Disconnect other VPN clients, disable browser proxy extensions temporarily, and check whether a system proxy or security product is intercepting traffic.
Confirm the local network. Complete any Wi-Fi sign-in page, test ordinary browsing without the VPN, and compare Wi-Fi with mobile data or another trusted network when available.
Refresh the subscription. Update the node list inside the trusted client. If the update fails, check the subscription address, account status, and current network access rather than importing a link from an unknown source.
Reconnect with a compatible route. Start with another route from the refreshed list. Disconnect fully between attempts so that the operating system is not holding the previous tunnel.
Compare transport behavior. If a UDP-based profile repeatedly fails on the current network, test a compatible TCP-based profile. If only one protocol family fails, the network or client compatibility is more relevant than reinstallation.
Inspect routing mode. Check whether the client is in rule, global, proxy, or direct mode. A direct rule can make one application bypass the tunnel while other traffic remains connected.
Review DNS behavior. Browser secure DNS, system DNS settings, and third-party filters can follow a different path from the VPN. Use a consistent diagnostic page and compare results after the tunnel is active.
Check background operation. Allow the client to run in the background, remove battery optimization for the client where the platform provides that option, and permit background data on mobile devices.
Restart only after recording the result. A restart can clear a stuck network extension or stale tunnel, but note what happened before rebooting so that the diagnosis is not lost.

On Windows and macOS, inspect login items, firewall permissions, system proxy settings, and sleep behavior. On Android, review battery optimization, background data, unrestricted data access, and the always-on VPN or block-without-VPN options. On iOS, check the VPN profile, low-power behavior, cellular data permission for the client, and whether another configuration profile is installed. On Linux, inspect the NetworkManager profile, systemd service state, firewall rules, and whether another process is managing the same interface.

Do not enable a kill switch and then interpret blocked traffic as a failed VPN without checking the status. A kill switch is designed to prevent traffic from escaping outside the tunnel. If the tunnel drops, blocking is expected until the connection returns. This is a safety feature, not evidence that the selected route is continuously connected.

✅ Change one setting at a time and repeat the same test.
✅ Keep the kill switch enabled when privacy is more important than uninterrupted access.
✅ Use rule mode when local services need direct access and only selected traffic needs the proxy.
✅ Use global mode only when you understand that more applications will enter the tunnel.
❌ Do not run two system-level VPN clients simultaneously.
❌ Do not delete every profile before checking which protocol and route actually worked.

Device-Specific Stability Checks

A desktop client usually has more persistent background access than a mobile application. Windows and macOS may still suspend network activity during sleep, switch Wi-Fi access points, or apply firewall rules after an update. If drops happen when the lid closes or the computer sleeps, test the power profile and reconnect behavior rather than immediately changing the subscription. Confirm that the client is allowed through the firewall and that the operating system has not reset its network permission.

Mobile systems are more aggressive about saving power. Android vendors may stop background processes, restrict background data, or place rarely opened applications into a deep sleep list. Remove the VPN client from those restrictions where appropriate and permit it to operate on the network being tested. Also check whether the phone is automatically switching between Wi-Fi and mobile data. That transition can interrupt a tunnel even when both networks work normally on their own.

iOS uses a managed network extension and may ask for permission to add a VPN configuration. If that permission was denied, partially removed, or replaced by another profile, the client may show an inconsistent state. Review the installed VPN configuration and remove obsolete profiles only when you know they are no longer needed. A configuration profile from work, school, or a security application can also affect routing and DNS.

Linux users should check which service owns the connection. A graphical client, NetworkManager, a command-line WireGuard profile, and a system service should not all attempt to manage the same tunnel. Examine logs around the exact time of the drop, look for authentication or endpoint errors, and verify that the system clock is correct. Incorrect time can interfere with certificate validation and make a valid route look like a protocol failure.

Device conclusion: If the VPN fails when the screen locks, the computer sleeps, or the device changes networks, inspect background and power behavior before blaming the route.

When to Reinstall or Contact Support

Reinstalling becomes reasonable when the client crashes, its configuration screen is missing, an update left behind a broken network extension, or every profile fails after permissions were reset. Before uninstalling, record the subscription source, selected protocol, route name, and any custom settings that you are allowed to recreate. Do not export or share private access links through untrusted tools. After reinstalling, import the subscription again, approve the system VPN permission, and test with a single compatible route.

Contact support when the same account fails on multiple supported platforms and networks, the subscription cannot refresh, all newly listed routes reject the connection, or the client reports a specific authentication or server-side error. Include the platform, client version, protocol, route label, approximate time of failure, and whether the drop occurs during sleep or network switching. Do not include your password, full subscription URL, private keys, or unrelated personal information.

A useful support report separates facts from assumptions. “The client disconnects every time the screen locks” is actionable. “The server is slow” is less useful unless you also explain which route, protocol, access network, and application were involved. Screenshots should hide subscription tokens and account credentials.

If you need a clean starting point, review the site’s setup tutorial for the correct import and permission flow. For a broader comparison of client behavior, use an official client for Windows, macOS, Android, iOS, or Linux, or choose a compatible client such as Clash Verge, sing-box, or Shadowrocket according to your platform and the protocols in the subscription. Compatibility is more important than the name of the application.

Frequently Asked Questions

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

Battery optimization, background data restrictions, and vendor-specific sleep management are common causes. Allow the client to run in the background, permit background data, and review any always-on VPN or block-without-VPN setting. If the problem continues, compare Wi-Fi and mobile data separately because a network transition may occur when the screen locks.

Should I change the server or the protocol first?

Refresh the subscription first, then try another compatible route while keeping the protocol unchanged. If the failure pattern remains, compare a different compatible protocol or transport. This order helps distinguish a route-specific problem from a protocol or access-network problem.

Why does the client say connected while an app has no network?

The app may be covered by a direct rule, using its own proxy or secure DNS, or blocked by a kill switch while the tunnel is reconnecting. Check the client’s routing mode and per-app rules, then test the application again after confirming that the tunnel is active.

Can reinstalling the VPN fix repeated disconnections?

It can fix a damaged local profile, missing network permission, or a broken client update, but it cannot repair an unstable access network or an unsuitable route. Record your configuration first, remove obsolete profiles carefully, reinstall from a trusted source, and repeat a controlled test before changing several variables.

A stable VPN connection is normally the result of several compatible parts working together: a reliable access network, a current subscription, a suitable route, a supported protocol, correct routing rules, and permission to remain active in the background. Start with observable symptoms, test one variable at a time, and verify the result with an actual request rather than the client icon alone.

When the problem is isolated to one route, switch routes. When it is isolated to one transport, compare protocols. When it appears after sleep or network changes, review device permissions. When every route and device fails, collect a privacy-safe diagnostic report and contact support. This method is usually more effective than repeatedly reinstalling the application without narrowing down the cause.