A VPN that repeatedly disconnects is not always suffering from a bad server. The interruption may come from an unstable local network, a battery-saving rule, a revoked system permission, an outdated client, an incompatible protocol, or a route that cannot remain healthy on the current connection. Reinstalling the app without identifying the failing layer often changes nothing.
This guide presents a practical troubleshooting sequence for Windows, macOS, Android, iOS, and Linux. Start with the simplest checks, record what changes, and test one variable at a time. The goal is to determine whether the failure occurs before the client connects, during the protocol handshake, after the tunnel is established, or when the operating system suspends the connection.
Identify the disconnection pattern first
“The VPN keeps disconnecting” can describe several different symptoms. A client may fail to connect at all, connect for a short period and then stop, show as connected while applications have no access, or reconnect successfully only after changing networks. Each pattern points toward a different part of the configuration.
5
Supported platform families
6
Common protocol examples
100+
Countries covered by VPNLP
160+
Available routes
First, note whether the problem affects every node or only one route. If every route disconnects on the same device, investigate the client, operating system, permissions, or local network. If only one node fails, the selected route, protocol, or server-side configuration is more likely to be involved. If the issue appears only on mobile data, Wi-Fi, a workplace network, or a public hotspot, compare network conditions before changing the subscription.
| Observed symptom | Most likely area | First useful check |
|---|---|---|
| Connection never completes | Permission, protocol, credentials, or network blocking | Read the client log and try another supported node |
| Disconnects when the screen locks | Battery optimization or background restrictions | Allow the client to run in the background |
| Disconnects after changing Wi-Fi or mobile data | Network handover or stale tunnel state | Reconnect after the new network is fully active |
| Only one node repeatedly fails | Route or protocol-specific problem | Test a different region and protocol family |
| Client says connected but apps stop working | DNS, routing mode, kill switch, or split-tunnel rule | Check mode, DNS handling, and application rules |
Keep a short record containing the device, network type, selected node, protocol, time of failure, and whether the client reconnects automatically. This information is more useful than repeatedly pressing Connect because it reveals whether the problem follows the device, the network, or the route.
Check the network and system basics
A VPN cannot maintain a tunnel if the underlying connection is already dropping packets or changing its address repeatedly. Open a normal website without the VPN and observe whether the local connection remains usable. If ordinary traffic also fails, restart the router or switch temporarily between Wi-Fi and mobile data before changing VPN settings.
On a computer, disable unnecessary network adapters temporarily if several virtual adapters, old VPN clients, virtual machines, or security products are installed. Multiple tunnel drivers can compete for routing priority. Do not run two VPN clients at the same time while troubleshooting. Close the second client completely, including its background process, then restart the first client.
On a phone, test the connection while the device is awake and close to the access point. Some public networks require a browser sign-in page before they permit normal traffic. Complete that sign-in without the VPN first, then connect the VPN. Captive portals, restricted guest networks, and networks that limit UDP can all make a protocol appear unstable even when the client is correctly configured.
Check that the device date and time are set automatically. TLS-based protocols such as Trojan, VLESS, VMess, and Hysteria2 rely on certificate or security parameters that can fail when the system clock is substantially wrong. Also install pending operating-system updates and use a client version that supports the configuration format delivered by the subscription.
- ✅ Test ordinary internet access before starting the VPN
- ✅ Compare one Wi-Fi connection with mobile data or another trusted network
- ✅ Close other VPN, proxy, tunnel, and virtual-network applications
- ✅ Confirm automatic date and time are enabled
- ❌ Do not change several protocol and routing options at the same time
- ❌ Do not assume a browser sign-in network can carry a VPN immediately
If the connection becomes stable on another network, the VPN client may not be the main cause. The original network may restrict certain ports, UDP traffic, persistent connections, or unfamiliar TLS patterns. In that situation, select a compatible route or transport offered by the service rather than forcing a node that the network cannot carry reliably.
Review client permissions and background rules
Mobile operating systems are designed to limit background activity, especially when the screen is off or the battery is low. A VPN application may connect normally while open and disconnect after it is minimized because the system pauses its process. Look for battery, background activity, auto-start, and unrestricted data settings for the VPN client.
Android commonly provides a battery setting such as “Unrestricted,” “Allow background activity,” or “Don’t optimize.” The exact label differs by manufacturer. Also inspect the system VPN page and confirm that the intended client is the active VPN service. If an always-on VPN or “block connections without VPN” option is enabled, verify that it refers to the correct application and configuration.
On iOS, review the VPN profile under the system settings and confirm that the client has permission to create a VPN configuration. If iOS displays a permission prompt, approve it rather than dismissing it. Low Power Mode, background refresh behavior, and network switching can affect how quickly an application restores its tunnel, although the labels and available controls vary by system release.
On Windows and macOS, check whether the client is allowed to start with the system and whether a firewall or security suite is blocking its core process. macOS may request approval for a network extension. Windows may display a permission prompt for a virtual adapter or firewall rule. If the permission was previously denied, remove the old profile only through the client or system settings and then create a fresh profile through the normal workflow.
Linux users should check the service status, user permissions, NetworkManager integration, and whether another service is rewriting routes after the VPN connects. A command-line client can remain active while its route disappears, so compare the process status with the routing table and resolver configuration instead of relying only on a tray icon.
Refresh the subscription and verify protocol support
A subscription link supplies configuration; it is not itself the tunnel. The client reads the link, retrieves node information, and then uses a supported protocol to establish the connection. If the subscription was imported incompletely, cached incorrectly, or opened in a client that does not support its protocols, the result may be repeated handshake failures or an apparently connected session that drops quickly.
Open the client’s configuration or subscription section and check the last update result. If an update fails, verify that the subscription address was copied completely and that the device can open ordinary web pages. Do not edit protocol fields randomly. If the service provides a one-click import for the official client, Clash Verge, sing-box, or Shadowrocket, use the format intended for that client.
| Protocol | Important configuration areas | Typical compatibility concern |
|---|---|---|
| Shadowsocks | Server, port, encryption method, and password | The client does not support the encryption method in the profile |
| VMess | User ID, transport, TLS, and server name | The client core handles the transport parameters differently |
| Trojan | Password, TLS, server name, and certificate validation | A server-name or certificate check prevents the handshake |
| VLESS | User ID, transport method, and security settings | The selected core lacks support for the profile combination |
| Hysteria2 | Authentication, TLS, and UDP transport parameters | The current network restricts or mishandles UDP traffic |
| WireGuard | Private key, peer key, endpoint, and allowed IPs | Incorrect route or key parameters interrupt the tunnel |
After refreshing, select a node that clearly shows as supported by the client. Try a second node from another region, but keep the same client and mode. If one node remains unstable while another works, the issue is probably route-specific. If every node fails after the refresh, inspect the client log for messages such as unsupported protocol, TLS error, authentication failure, timeout, or DNS resolution failure.
For a structured setup sequence, see the quick-start guide. Avoid converting a private subscription through an unknown online service merely to change formats. Conversion can expose credentials and may remove fields required by the original protocol.
Change protocol, route, and routing mode carefully
Different networks tolerate different transports. A UDP-based protocol may perform well on a network that permits UDP but fail on a restrictive hotspot. A TCP-based option may connect more consistently in that environment, although the appropriate choice depends on the configurations actually provided by the service and supported by the client.
Change one item at a time. First keep the same node and test another supported protocol profile. If that does not help, restore the original profile and test a different node. This method prevents a successful change from becoming impossible to identify. Do not manually replace a protocol name or port unless the service documentation explicitly provides the required values.
Routing mode also matters. Global mode sends a broader range of traffic through the tunnel, while rule-based mode sends only matching destinations through it. Direct mode may intentionally bypass the VPN. If only some applications appear disconnected, the VPN may actually be working while the application is excluded by a rule, a split-tunnel setting, or a local proxy exception.
Review DNS behavior as well. A tunnel can remain established while domain lookups fail because the resolver is unreachable, overridden by the local network, or blocked by an incorrect rule. If the client offers a documented DNS mode, test it according to the client’s instructions. Avoid adding random public DNS addresses as a universal fix; that may create leaks, slower lookups, or a mismatch with the selected route.
- ✅ Test a supported TCP or UDP profile according to the network conditions
- ✅ Compare rule mode with global mode when only selected apps fail
- ✅ Read the log after each test and note the exact error category
- ✅ Restore the previous setting if a change produces a worse result
- ❌ Do not mix settings from different protocols
- ❌ Do not enable two system-level VPN services simultaneously
Perform a controlled reconnect and log review
Once basic settings have been checked, perform a clean reconnect rather than repeatedly tapping the connection button. Disconnect from the client, wait for the system VPN indicator to disappear, close the client, and reopen it. On a computer, confirm that the old tunnel adapter or process is not still holding the route. On a phone, restart the device only after checking the permissions and battery rules so that the restart does not hide the actual cause.
- Disconnect the active VPN profile.
- Close any other proxy or VPN applications.
- Confirm that the underlying network works without the tunnel.
- Open the intended client and update its configuration if necessary.
- Select one supported node and connect with the default documented mode.
- Open a few ordinary sites and check whether the system VPN indicator remains active.
- If it disconnects, save the relevant log lines before trying another setting.
Logs should be read by category rather than by isolated technical words. “Timeout” often suggests reachability or packet loss. “Authentication failed” points toward credentials or a stale configuration. “Certificate” or “TLS” errors suggest the server name, time, or security parameters. “Unsupported” indicates that the client core cannot parse the selected profile. “Route” or “DNS” errors suggest that the tunnel exists but traffic is not being directed or resolved correctly.
Check the exit IP, DNS behavior, and routing result only after the client reports a stable connection. If the exit result does not change, the selected application may be bypassing the VPN, the client may be in direct mode, or the operating system may have another proxy rule. If the connection drops only during sleep, large downloads, or network switching, record that trigger separately instead of describing it as a random failure.
Know when to reset or contact support
A reset is appropriate when the profile is clearly corrupted, permissions are stuck, or old adapters and rules remain after multiple client changes. Export any configuration that is safe to retain, remove only the affected profile, restart the client, and import the official subscription again. Do not delete every network setting immediately; a full operating-system reset can remove useful evidence and create new problems.
Contact support when all supported nodes fail across more than one network, the subscription update consistently returns an error, or the client log shows a server-side authentication or account status problem. Provide the platform, client name and version, selected node label, protocol family, network type, time of failure, and the relevant redacted log message. Never send the complete subscription URL or private keys.
VPNLP supports Windows, macOS, iOS, Android, and Linux, with clients and import workflows varying by platform. The account can be used on an unlimited number of devices, but each device still needs its own compatible client, permission approval, and correctly imported configuration. A stable connection on one device does not prove that another device has identical system rules.
Frequently asked questions
Why does my VPN disconnect only when my phone screen turns off?
The most common causes are battery optimization, background restrictions, automatic cleanup, or an always-on VPN setting assigned to another client. Allow the intended client to run in the background, confirm its system VPN permission, and test again without switching between multiple VPN applications.
Should I change the server or the protocol first?
Start by identifying whether every node fails. If only one node fails, test another supported route first. If every route fails on one network, test a protocol profile that the client supports and that is suitable for the network. Change only one variable at a time so the result remains meaningful.
Why does the client show connected while websites do not load?
The tunnel may be established while routing, DNS, or application rules are incorrect. Check whether the client is in direct, rule, or global mode, review split-tunnel exclusions, and inspect DNS behavior. Also confirm that the affected application is not using its own proxy or a separate network permission.
Is reinstalling the VPN client a reliable fix?
Reinstallation can help when a profile or permission is corrupted, but it does not fix an unstable Wi-Fi connection, restricted UDP traffic, an unsupported protocol, or a battery rule. Record the error first, then reinstall only after closing other tunnel software and removing the affected profile through the normal system workflow.
Repeated disconnections become easier to solve when each test has a clear purpose. Verify the local connection, protect the client from being suspended, refresh the correct subscription format, choose a protocol the client supports, and compare routes without changing several settings together. This process is safer, faster, and more informative than repeatedly reinstalling applications or copying private configuration into untrusted tools.