Start by identifying why the VPN keeps disconnecting
Repeated VPN disconnections are frustrating, but the symptom alone does not identify the failing component. A session can drop because the local Wi-Fi connection briefly changes, the operating system suspends the client, a mobile network moves between radio modes, or the selected route becomes unavailable. It can also be caused by a damaged subscription configuration, a protocol that the current network handles poorly, or a conflict with another firewall, proxy, security product, or VPN application.
Begin with observation rather than changing every setting at once. Note whether the disconnect happens immediately after connecting, after the device becomes idle, when the screen is locked, while switching between Wi-Fi and mobile data, or only when using a particular website or application. Also check whether the client reconnects automatically, whether all traffic stops, and whether only some applications fail. These details help separate a transport problem from a routing or DNS problem.
It is useful to distinguish a true VPN connection drop from an application-level failure. Some clients display a connected status when the local proxy process is running, even though a node cannot complete its handshake or the selected routing rule sends the target traffic directly. Conversely, the VPN tunnel may remain active while a website session expires, a browser request is blocked, or a remote server becomes slow. Verify the client status, open a new page, resolve a domain, and check the external IP address together instead of relying on one indicator.
| Observed symptom | Likely area | First action |
|---|---|---|
| Disconnects after the screen locks | Battery saving or background restrictions | Allow the VPN client to run in the background |
| Fails only on one Wi-Fi network | Router policy, captive portal, or local filtering | Test another network and review Wi-Fi permissions |
| Several nodes fail at the same time | Subscription, client, or local network issue | Refresh the subscription and test a different protocol |
| One node drops while others remain usable | Route overload or node-specific availability | Switch to another route in the same region |
| Client says connected but apps cannot load pages | DNS, routing mode, or system proxy conflict | Check proxy mode, DNS handling, and other network tools |
Check the local network before replacing the VPN client
A VPN cannot maintain a tunnel if the underlying network is repeatedly disappearing. Start by checking whether ordinary internet access remains available when the VPN disconnects. If the Wi-Fi icon changes, the router asks for a login again, or other devices lose access at the same time, the primary fault is probably local connectivity rather than the VPN service.
Public Wi-Fi deserves special attention. Hotels, airports, cafés, schools, and offices may use captive portals that require a browser sign-in before allowing normal traffic. Connect to the network without the VPN, complete the portal process, and then start the VPN. If the portal is not completed, the client may repeatedly attempt a handshake through a network that has not yet granted full access. Some managed networks also restrict unfamiliar ports or long-lived connections, so a protocol that works at home may fail there.
On a home network, restart the router only after checking whether the issue affects other devices. Review whether the router has parental controls, traffic filtering, a custom DNS service, or a second VPN configured at the gateway. If the router uses an unstable wireless band, move closer to the access point or test a wired connection on a supported computer. The goal is not to improve every aspect of the network at once; it is to determine whether the dropout follows the access network.
When moving between Wi-Fi and mobile data, the device may briefly lose its old address before receiving a new one. Some clients recover automatically, while others require a reconnect. Test the VPN while remaining on one network, then test it during a deliberate network change. If it fails only during handover, look for a client option related to reconnecting or allowing connections after network changes. Do not interpret a deliberate handover as evidence that every route is unstable.
- Open a normal website with the VPN off and confirm that the local connection is usable.
- Complete any captive-portal login before starting the VPN.
- Test another Wi-Fi network or a mobile hotspot to compare the access provider.
- Disable a second proxy, gateway VPN, or traffic-filtering application temporarily.
- Check whether the problem occurs only during Wi-Fi and mobile-data switching.
Fix battery, permission, and background settings
Battery optimization is one of the most common causes of VPN connection drops on mobile devices. Android and iOS may suspend background activity when the screen is off, the device is idle, or the battery level is low. The result can look like a remote server failure even though the operating system has stopped the client from maintaining its tunnel. Allow the VPN application to run in the background and remove aggressive battery restrictions for that application.
On Android, open the application settings for the VPN client and review battery usage, background data, unrestricted data access, and auto-start controls. The exact labels vary by device manufacturer. If the phone has a system-level memory manager or a security utility that closes unused applications, add the VPN client to its protected list. Also check whether a data-saving mode is blocking background traffic. After changing these options, lock the screen for a while and then confirm whether the tunnel remains active.
On iOS, review the VPN profile under the system network settings and confirm that the intended client is enabled. Low Power Mode and restrictions on background activity may affect how quickly the application can recover after a network change. If the profile appears damaged or belongs to an old client installation, remove the obsolete profile and import the current configuration again. Avoid installing several profiles that use similar names, because it becomes difficult to tell which tunnel is active.
On Windows and macOS, check whether the VPN client is allowed through the system firewall and whether it has permission to create a VPN or network extension. macOS may request approval for a network extension, while Windows security software can block a virtual adapter or terminate a background process. Apply the permission change, restart the client, and test again. If the client works only when security software is paused, create a narrowly scoped exception rather than leaving protection disabled.
Linux users should verify that the desktop environment, NetworkManager, system firewall, and the client are not fighting over the same route or DNS configuration. A command-line client, a graphical client, and a system WireGuard profile can all create overlapping interfaces. Keep one active connection method during testing. If a service manager starts an old tunnel automatically, stop that service before testing the current client.
Follow a clean repair sequence on the affected device
Once the local network and background permissions have been checked, use a controlled repair sequence. This avoids confusing a successful fix with the side effect of changing several variables. The same order works for an official application or a compatible client such as Clash Verge, sing-box, or Shadowrocket, although the menu names will differ.
- Record the current state. Note the selected node, protocol, routing mode, and whether the issue occurs on Wi-Fi, mobile data, or both.
- Stop competing network tools. Close another VPN, system proxy switcher, packet filter, or client that may be rewriting routes or DNS.
- Refresh the subscription. Import the subscription link again from the user panel if the client shows expired, incomplete, or duplicated node information. Keep the link private because it can identify the subscription.
- Choose one ordinary node. Test a different route in the same general region before making a large change in location. This helps reveal whether the failure belongs to one node.
- Change one protocol. If the client supports several options, test a compatible alternative such as Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard. These are not interchangeable labels: each has different transport and client requirements.
- Use a simple routing mode. Select global or rule-based behavior according to the client’s design, but avoid adding custom rules during diagnosis. A mistaken rule can make one application bypass the proxy while another uses it.
- Reconnect from a clean state. Disconnect first, close the client, reopen it, and establish one session. Do not repeatedly click connect while an older process is still shutting down.
- Verify real traffic. Open a new browser session, resolve a domain, and check the external IP. Then test the application that originally failed.
A subscription link distributes configuration; it is not itself a protocol or a guarantee that every node will work on every network. The client reads the available parameters and creates the connection. The protocol defines how the client communicates with the server, while the route describes the network path behind that server. Separating these layers makes troubleshooting much faster.
If you use Clash Verge or sing-box, inspect whether the selected profile is actually running and whether the system proxy is enabled. A running core with a disabled system proxy may leave browser traffic outside the intended route. If you use Shadowrocket on iOS, check the active configuration, global or rule mode, and the system VPN permission. For official Windows, macOS, Android, iOS, or Linux clients, confirm that the imported subscription is current and that only one application controls the VPN interface.
Test protocols, routes, DNS, and MTU methodically
Protocol conflicts often appear on restricted or highly managed networks. A protocol may fail during handshake, connect successfully but drop under sustained traffic, or remain connected while particular requests stall. Changing protocols can be useful, but it should be done one variable at a time. If a protocol change fixes the issue on the same device and network, record that result instead of assuming the new option is universally better.
Shadowsocks is commonly used as a lightweight proxy protocol and may be available in many compatible clients. VMess and Trojan require the client to correctly read their parameters and transport settings. Hysteria2 uses a different transport approach and may behave differently on networks that handle UDP-like traffic inconsistently. WireGuard is a modern VPN protocol that depends on a valid key, endpoint, and peer configuration. A client cannot make an incomplete or incompatible profile reliable by repeatedly reconnecting.
Route type also matters. Direct connections, relays, BGP-based paths, and IEPL dedicated lines describe different underlying paths and carrier arrangements. A route with a familiar region name can still experience congestion, while a different route in the same region may remain usable. If the client provides route labels, compare them under the same local network and usage pattern. Avoid switching nodes every few moments, because frequent changes make it difficult to distinguish route instability from normal session setup time.
DNS failures can resemble disconnections. If the external IP remains changed but domains fail to resolve, inspect the client’s DNS mode, system DNS, and routing rules. A secure DNS option may be useful, but it must be compatible with the client and the selected mode. If only one domain fails, clear the browser’s DNS cache and test another resolver path. If every domain fails while direct internet access still works, review whether another application has taken control of DNS.
MTU problems may cause pages to begin loading and then stall, video sessions to freeze, or larger requests to fail while small requests succeed. This is especially relevant when encapsulation adds overhead or when the local network filters certain packet sizes. Use the client’s documented MTU guidance or a conservative supported value, then test the original application again. Do not change multiple low-level parameters together, and do not treat a successful change as proof that every route needs the same MTU.
| Layer | What to compare | Failure pattern | Useful response |
|---|---|---|---|
| Protocol | Handshake and sustained session behavior | Connection fails or drops on one network | Test a compatible alternative |
| Route | Node region and route type | Only one node is unreliable | Choose another route and compare |
| DNS | Name resolution and DNS routing | IP access works but domain access fails | Review DNS mode and rule handling |
| MTU | Large-request behavior | Pages stall after partially loading | Use documented MTU guidance |
| Routing rules | Which applications and domains use the proxy | Only selected apps fail or bypass the tunnel | Temporarily simplify the rules |
Apply platform-specific fixes without losing your configuration
Windows
On Windows, check the virtual adapter, system proxy, firewall permissions, and sleep behavior. If the client uses a virtual network adapter, reinstalling or repairing that adapter may help after a major system update. Make sure another application has not set a manual proxy that overrides the client. If the VPN disconnects after sleep, enable the client’s reconnect option and test whether the network interface is available before the application starts reconnecting.
macOS
On macOS, review VPN profiles and network extensions in system settings. Remove old profiles only after confirming that you have the current subscription link or configuration. A network extension permission that was denied can prevent normal recovery. Also inspect whether a content filter, endpoint security product, or private relay-like feature is modifying DNS or proxy behavior. Keep one active network extension during diagnosis.
Android
Android troubleshooting should begin with battery and background data controls. Permit background operation, remove the client from battery optimization, and check whether a manufacturer’s cleanup tool closes it. Review “always-on” or “block connections without VPN” settings carefully: they can improve leak protection, but a misconfigured always-on profile may block traffic while the intended client is disconnected. Test after the device has been idle with the screen off.
iOS
On iOS, confirm the active VPN profile and remove obsolete configurations that belong to an uninstalled client. If the client offers on-demand behavior, check whether it is repeatedly trying to activate a profile that no longer has valid parameters. When switching networks, wait for the device to complete the handover before judging the reconnect result. Reimport the current subscription only after preserving any custom rules you still need.
Linux
On Linux, identify which process owns the active interface and default route. NetworkManager, a system WireGuard service, a command-line proxy, and a graphical client should not all manage the same connection. Check firewall rules, DNS resolvers, and service startup entries. If the client works from a clean user session but not after boot, an automatically started service is a likely source of the conflict.
For any platform, reinstalling should be a later step rather than the first response. Export or record custom routing rules, close the client, remove the damaged profile, install the current official version, and import the subscription again. If you use a compatible third-party client, confirm that it supports the protocol and subscription format supplied by the service.
Know when the problem needs service-side investigation
If several devices and networks show the same failure, the issue may not be limited to one operating system. Before contacting support, collect useful but non-sensitive information: platform, client name and version, selected node, protocol, network type, approximate time of failure, whether the subscription refreshes, and whether another node connects. Do not send the full subscription link, password, private key, or unrelated personal documents in a ticket.
A node-specific failure is different from a complete account or configuration failure. If one route disconnects while another remains stable, continue using the working route and report the affected node. If every node fails after a subscription update, check whether the client rejected the new format, retained duplicate profiles, or imported an incomplete response. If the client connects but a particular application remains unusable, include the routing mode and DNS behavior in the report.
Do not assume that a new client, protocol, or node will solve a local permission problem. Likewise, do not keep forcing a node that repeatedly fails when other compatible routes are available. Stability is a combination of the access network, device settings, client implementation, protocol, route, DNS, and destination service. A clear report helps support isolate the correct layer rather than recommending unrelated changes.