A VPN that disconnects every few minutes is frustrating, but the cause is usually identifiable. The failure may come from unstable Wi-Fi, a phone’s battery-saving policy, a protocol that does not suit the current network, a crowded or unsuitable server, or two network tools competing for the same system VPN interface. Reinstalling the client immediately is rarely the best first step.

This guide uses a layered troubleshooting method for Windows, macOS, Android, iOS, Linux, and compatible router clients. Start by identifying when the disconnect happens, then isolate the local network, client, protocol, server, and device power settings one by one. The goal is not merely to reconnect once, but to make recovery predictable when the device changes networks, wakes from sleep, or temporarily loses a route.

Quick conclusion The fastest reliable fix is to test another network, switch to a compatible protocol, choose a different server, and remove battery or sleep restrictions. If only one device disconnects, troubleshoot that device first; if every device drops at the same time, investigate the router, local network, or service route.

First identify what is actually disconnecting

“The VPN disconnected” can describe several different events. The client may show an explicit disconnected status, or the tunnel may remain visually connected while DNS requests, browser traffic, or a particular application stop working. A laptop may also reconnect automatically so quickly that the interruption looks like a slow website rather than a tunnel failure.

Begin by recording the pattern without changing several settings at once. Note whether the problem appears after the screen locks, when the computer wakes from sleep, during a Wi-Fi to mobile-data switch, while streaming, or only when a specific application is open. Also check whether all websites fail or only services handled by a particular rule. This distinction separates a tunnel failure from a routing, DNS, or application-level problem.

Device If one phone or computer drops while other devices remain stable, inspect its power, sleep, Wi-Fi, and client settings.
Network If the same device is stable on mobile data but unreliable on Wi-Fi, test the router, access point, DNS, and local network path.
Route If only one server or protocol fails, keep the client installation and investigate route selection or protocol compatibility.

Check the client’s event log if it provides one. Useful messages include timeout, handshake failure, connection reset, network unavailable, DNS failure, authentication error, and server unavailable. These terms are more useful than a generic “disconnected” notification. Do not publish a complete subscription link or configuration file while requesting support, because it may contain access credentials.

  • ✅ Compare the VPN status with the device’s Wi-Fi or mobile-data status.
  • ✅ Test a normal website and a DNS or IP verification page after reconnecting.
  • ✅ Check whether the issue follows one server, one protocol, or one application.
  • ❌ Do not assume a VPN icon means every application is using the tunnel.
  • ❌ Do not run two clients that both try to create a system VPN or virtual network interface.

Check Wi-Fi, mobile data, and router behavior

An unstable local connection can make a perfectly healthy VPN appear unreliable. A VPN adds encryption and a long-lived tunnel on top of the existing network. If the device briefly loses its Wi-Fi association, changes access points, receives a new address, or encounters packet loss, the tunnel may need to renegotiate. A browser that eventually reloads may hide this interruption; a video call, remote shell, or persistent application usually exposes it immediately.

Test another network before changing advanced settings

Use a mobile hotspot or another trusted connection for a short comparison. If the VPN remains connected there, the original Wi-Fi network deserves attention. Restart the access point, move closer to it, and test both the 2.4 GHz and 5 GHz bands when they are available. Mesh systems can also move a device between access points, so temporarily testing near the main router can reveal whether roaming is involved.

Public or managed networks may restrict UDP traffic, terminate idle sessions, require a browser sign-in, or apply aggressive connection timeouts. In those environments, a protocol using TCP or a different transport may work more consistently, although it can have different performance characteristics. On a home router, inspect automatic updates, parental controls, traffic shaping, and any feature that filters encrypted traffic. Avoid changing many router options permanently before confirming the VPN works elsewhere.

Check DNS and network switching

DNS failure is sometimes mistaken for a VPN drop. If the client still reports connected but domain names stop resolving, temporarily compare a known IP-based connection or use the client’s DNS protection options. A successful DNS test does not prove that all traffic follows the intended route, but it helps separate name resolution from tunnel availability.

On laptops and phones, disable automatic network switching for the duration of a test. Some systems prefer a stronger Wi-Fi signal even when that network has no internet access, while others move between Wi-Fi and mobile data as signal quality changes. Every transition can interrupt a persistent tunnel. After the network becomes stable, reconnect the VPN rather than waiting for an old session to recover indefinitely.

Change the protocol and server methodically

A protocol is the transport and connection method used between the client and the server. Shadowsocks, VMess, Trojan, Hysteria2, and WireGuard are not interchangeable labels for the same technology. Their behavior can differ across restrictive networks, unstable Wi-Fi, roaming devices, and routers. A client must support the selected protocol, and the imported configuration must contain the matching settings.

Do not switch several protocols and servers simultaneously. First keep the same server and change only the protocol, if the client exposes that choice. Then reconnect and observe whether the failure pattern changes. If the problem remains, restore the original protocol and test another server. This simple sequence tells you whether the likely fault is protocol compatibility or a particular route.

Route names may also describe different transport arrangements. A direct route generally reaches the overseas exit without an intermediate relay. A relay route uses an intermediate entry point before continuing to the exit. IEPL describes an international private-line transport arrangement, while BGP and CN2 describe network or routing characteristics rather than application protocols. None of these route labels guarantees stability on every local network, so use them as comparison categories rather than promises of performance.

  • ✅ Keep a known working configuration available before editing or deleting profiles.
  • ✅ Test a different server in another location when only one route disconnects.
  • ✅ Try a client-supported TCP-oriented option when the current network appears to restrict UDP.
  • ✅ Consider WireGuard where the client, service, and network environment support it correctly.
  • ❌ Do not import a profile made for another client unless the format and protocol are explicitly compatible.
  • ❌ Do not judge a server only by its name; confirm whether the same issue occurs on another route.
Diagnostic rule A protocol change tests compatibility with the current network; a server change tests the route. Perform them separately so the result remains meaningful.

Fix battery, sleep, and system VPN restrictions

Mobile operating systems often suspend background activity to preserve battery life. The VPN may appear reliable while its app is open, then disconnect after the screen turns off. Android commonly places VPN clients under battery optimization, background-data limits, or automatic app management. iOS applies its own background and network rules, so the practical controls are different even when the symptom is similar.

Android

Open the client’s app settings and look for battery usage, background activity, unrestricted battery use, and background data. The exact labels depend on the device manufacturer. Allow the VPN client to run in the background, avoid force-stopping it, and check whether a system cleaner removes it from memory. If Android shows an always-on VPN or “block connections without VPN” option, confirm that it points to the intended client rather than an old profile.

Also inspect per-application proxy or split-tunneling rules. If the client itself is excluded from the tunnel, or if the application under test is assigned to a direct route, the result may look like a disconnection. After changing these options, disconnect and reconnect once instead of relying on a stale session.

iPhone and iPad

Check whether another VPN profile, security application, DNS filter, or device-management profile is active. iOS allows only one primary system VPN connection at a time, so competing profiles can cause unexpected switching. Low Power Mode and weak Wi-Fi can also make background recovery less predictable. Remove only profiles you recognize, and keep the subscription information available before deleting a client configuration.

Windows, macOS, and Linux

On desktop systems, test the effect of sleep and wake separately. A client may reconnect after wake, but applications opened before the reconnection can retain stale sockets. Fully close and reopen the affected application after the tunnel returns. Check whether another VPN, proxy manager, firewall, antivirus network filter, or virtual machine has installed a competing adapter.

Windows users should inspect the network adapter list and proxy settings. macOS users should check network locations, login items, and VPN configurations in system settings. Linux users should review NetworkManager, systemd-resolved, firewall rules, and any environment variables used by command-line tools. A browser using the system proxy does not prove that Git, package managers, or terminal applications use the same route.

Keep one connection owner Use one application to manage the system VPN tunnel during testing. If you need Clash Verge, sing-box, Shadowrocket, a vendor client, or a router tunnel, stop the others first and confirm which profile owns the active connection.

Follow this step-by-step repair sequence

Once the basic pattern is clear, use the following sequence. It is designed to change one meaningful variable at a time and works for official clients as well as compatible clients that import a subscription link.

  1. Save the current configuration. Record the client name, selected server, protocol, routing mode, and whether split tunneling is enabled. Never expose the complete subscription URL in screenshots.
  2. Close competing network tools. Exit other VPN clients, proxy managers, traffic filters, and virtual-machine networking tools. Restart the device if an old virtual adapter remains active.
  3. Reconnect the local network. Turn Wi-Fi off and on, or disconnect and reconnect the Ethernet cable. If possible, compare the same device on a mobile hotspot.
  4. Reconnect the VPN from a clean state. Disconnect, wait briefly for the system VPN indicator to disappear, then connect again. Do not repeatedly press connect while the client is still negotiating.
  5. Test another server. Select a route in a different location or with a different transport description. Keep the protocol unchanged for this test.
  6. Test another protocol. Use only options supported by both the client and the imported configuration. Reconnect after switching rather than editing several profiles at once.
  7. Remove power restrictions. Allow background activity on mobile devices and check sleep, wake, firewall, and adapter behavior on desktop systems.
  8. Verify actual traffic. Test the browser, the application that originally failed, DNS resolution, and any terminal process separately. Confirm that the selected routing mode matches your intention.
  9. Update or reinstall only if necessary. Export or note the subscription first. Reinstalling without preserving the configuration can turn a route problem into an avoidable import problem.

After each major change, run the same short test instead of switching activities. For example, keep one browser tab and one application open, allow the device to lock once, then observe whether the tunnel reconnects and whether the application resumes. This does not create a laboratory guarantee, but it gives you a repeatable comparison.

Best practice Change one variable per test: network, server, protocol, power policy, or routing mode. A complete reset may look fast, but it removes the evidence needed to identify the real cause.

Extra checks for routers and advanced clients

Router-based VPN connections fail differently from phone or desktop clients. The router may keep the tunnel alive while individual devices lose DNS, receive a new local address, or bypass the tunnel because of policy rules. Check whether the router is using policy-based routing, whether the affected device belongs to the intended rule group, and whether IPv6 traffic follows a different path from IPv4.

Review router logs for repeated handshakes, authentication failures, interface resets, or DHCP changes. If the router supports automatic profile switching, temporarily disable it during diagnosis. Confirm that the imported subscription was refreshed successfully and that the selected profile still contains valid server information. A subscription update is not the same as an active connection; the router may need to restart the tunnel after updating.

Advanced clients such as sing-box may separate inbound listeners, outbound routes, DNS rules, and system integration. Clash Verge may use a system proxy or a virtual network interface depending on its mode. Shadowrocket relies on iOS system VPN authorization and its own rule configuration. When troubleshooting, first test a simple global or full-tunnel mode if the client supports it, then return to rule-based routing. If full-tunnel mode works but rule mode fails, inspect the rule set rather than replacing the server immediately.

Linux users should confirm that the process has the permissions required to create its interface and that firewall rules allow return traffic. Check route tables before and after connection, then inspect DNS resolution separately. If command-line tools fail while the browser works, verify the relevant proxy environment variables and application-specific settings.

VPN disconnecting FAQ

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

The phone may suspend the client, restrict background data, or remove it from memory. Check battery optimization, background activity, always-on VPN settings, and automatic app management. Also make sure another security or DNS application is not replacing the system VPN profile.

Should I change the protocol or server first?

Change only one at a time. Test another server while keeping the protocol unchanged, then test a different supported protocol while keeping the server unchanged. This tells you whether the issue follows the route or the transport method.

The client says connected, but websites stop loading. Is that a disconnection?

It may be a DNS, routing, or application-proxy problem rather than a complete tunnel failure. Test DNS resolution, check the selected routing mode, and compare a browser with the application that originally failed. Reconnect after changing the relevant setting.

When should I contact support?

Contact support after testing another network, server, and supported protocol, and after recording the client version and non-sensitive error message. Include the device platform, approximate failure pattern, and whether the issue affects one device or several. Hide the subscription URL, account credentials, server secrets, and personal network information.

Persistent disconnects are best solved through isolation rather than repeated reconnect attempts. Stabilize the local network, keep one connection tool active, remove device power restrictions, compare servers and protocols separately, and verify the traffic path after every change. For platform-specific setup and subscription import details, consult the setup guide or get the client from the official service interface.