A VPN that repeatedly disconnects is frustrating, but the symptom alone does not identify the cause. The interruption may come from an unstable Wi-Fi link, a mobile network transition, a sleeping device, an overloaded or incompatible route, a protocol blocked by the current network, or a client setting that conflicts with another proxy tool. Reinstalling the app or switching nodes at random can hide the real pattern without fixing it.
The most efficient approach is to troubleshoot from the outside in: confirm whether the local network is stable, isolate the client and route, check protocol and subscription compatibility, then review device-specific power and background settings. This method works across official Windows, macOS, Android, iOS, and Linux clients, as well as compatible tools such as Clash Verge, sing-box, and Shadowrocket.
Identify the disconnection pattern before changing settings
Begin by recording what “disconnecting” actually means. A client may show a completely closed tunnel, while the tunnel remains active but selected applications cannot reach their destinations. In other cases, the client reconnects successfully but the system proxy is disabled, DNS requests follow the direct connection, or a split-tunneling rule sends only part of an application outside the tunnel. These cases require different solutions.
Watch the client status while reproducing the issue. Note whether the failure happens immediately after connecting, after the screen locks, when the computer wakes, when switching between Wi-Fi and mobile data, during large downloads, or after the same amount of idle time. Also check whether all applications fail or only one browser, game, messaging app, or desktop program. A single application failure is more likely to involve rules, DNS, application-level proxy support, or a service-side session than a completely failed VPN tunnel.
5
main areas to check
3
common client layers
90+
available countries
200+
available routes
The three client layers are the application itself, the local system proxy or virtual network interface, and the remote route. A route change cannot repair a disabled system interface, and reinstalling a client cannot repair a congested home uplink. Separate these layers during testing instead of changing several variables at once.
- ✅ Check whether the interruption affects every application or only selected apps
- ✅ Compare the behavior on Wi-Fi, mobile data, and another trusted network when available
- ✅ Record whether the screen lock, sleep mode, or network handoff triggers the failure
- ❌ Do not change the client, protocol, route, DNS, and rule mode simultaneously
- ❌ Do not treat a connected icon as proof that every application is using the tunnel
Check the local network, router, and firewall first
A VPN depends on the network beneath it. If the local connection frequently loses packets, renews its address, changes access points, or blocks the transport used by the selected protocol, the encrypted tunnel may close even though ordinary websites appear to work. Test the local network without the VPN enabled. Open several normal websites, observe whether the Wi-Fi icon changes, and check whether other devices on the same router experience brief interruptions.
On a computer, temporarily connect through a different network, such as a phone hotspot or another trusted Wi-Fi connection. On a phone, switch between Wi-Fi and mobile data without changing the VPN client or imported configuration. This is not a speed comparison; it is an isolation test. If the VPN stays stable on one network but repeatedly disconnects on another, focus on the failing network's router, DNS behavior, firewall, captive portal, carrier restrictions, or wireless interference.
Routers can create additional complications. Some routers have aggressive UDP timeout settings, overloaded connection tables, outdated firmware, or security features that inspect and interrupt unfamiliar traffic. A router-level VPN configuration may also conflict with a device-level VPN application. Disable duplicate tunnels during testing. If the router is already running a VPN client, do not start a second full-tunnel client on the same device unless the design specifically requires it.
Public Wi-Fi and hotel networks may require a browser sign-in before any persistent connection can work. Complete the captive-portal login with the VPN disconnected, then start the VPN. If the network requires an explicit proxy, blocks UDP, or limits long-lived connections, a UDP-based option such as Hysteria2 or another QUIC-related transport may fail while a TCP-based option remains usable. The correct response is to select a compatible configuration, not to disable certificate validation or other security checks.
Verify the client, subscription, and imported configuration
Clients are not interchangeable. An official client may retrieve and manage a provider subscription directly, while Clash Verge, sing-box, or Shadowrocket may require a compatible subscription format or a converted profile. A link can be valid in a browser and still be unsuitable for a particular client. Likewise, a client can support a protocol in general while the selected core, operating system version, or imported profile does not support the exact transport parameters.
Update the subscription from inside the client and confirm that the refresh completes. If the update fails, check whether the link was copied completely, whether the client has permission to access the network, and whether an old profile is still selected. Avoid pasting a subscription link into public conversion websites or sharing it in screenshots. A subscription link can retrieve route and authentication information, so treat it as sensitive.
After refreshing, select one route manually instead of using automatic selection. Automatic tests may select a route that is reachable at the moment but unsuitable for a persistent session. Test a second route from a different region only after the first test is complete. If all routes fail in the same way, the issue is unlikely to be one individual route. If only one route fails, remove it from the test and review its protocol, transport, server name, and authentication parameters.
| Layer | What to verify | Typical symptom | Practical next step |
|---|---|---|---|
| Subscription | Complete link, successful update, current profile selected | Routes disappear or old settings remain active | Refresh the subscription and confirm the active profile |
| Client core | Protocol and transport support, current application version | Connection starts but closes during negotiation | Try a compatible profile or another supported client core |
| System integration | System proxy, virtual network interface, permissions | Client says connected but selected apps stay offline | Review proxy mode, VPN permission, and split-tunneling rules |
| Route | Region, transport, authentication, and server-name settings | Only one node repeatedly disconnects | Compare another route without changing other variables |
Protocol and transport checks
Shadowsocks uses an encrypted proxy structure and depends on a compatible cipher and server configuration. VMess includes identity and transport parameters, so an incomplete or outdated profile can prevent negotiation. Trojan commonly relies on TLS and requires the correct server name and certificate validation. VLESS is a lightweight authentication framework whose behavior depends heavily on its transport and security settings. Hysteria2 and other UDP-based options can perform differently on networks that restrict UDP or QUIC-like traffic. WireGuard uses a separate VPN architecture and depends on correct keys, peer settings, and allowed routes.
Do not choose a protocol only because its name sounds faster or newer. Check whether the current client supports the exact configuration and whether the underlying network permits its transport. If a TCP-oriented profile stays connected but a UDP-oriented profile disconnects on the same Wi-Fi, that difference is useful evidence about the network path.
Hands-on recovery workflow for desktop and mobile
Use the following sequence and change only one factor at a time. The objective is to create a clean baseline, not to collect many unverified speed results.
- Close duplicate networking tools. Quit other VPN applications, proxy assistants, network accelerators, and manually configured system proxies. Two tools attempting to manage the same route can repeatedly overwrite each other's settings.
- Reconnect the underlying network. Disconnect and reconnect Wi-Fi, or toggle mobile data once. Finish any captive-portal sign-in before starting the VPN.
- Restart the client cleanly. Stop the tunnel, exit the client if the platform allows it, reopen it, and grant the requested VPN or network permission. Do not keep reconnecting rapidly while the previous session is still closing.
- Refresh the subscription. Confirm that the update succeeds, select one known-compatible route, and avoid automatic switching for this first test.
- Test the default mode. Start with the client's normal system proxy or VPN mode. Only after that works should you test rule mode, split tunneling, or a virtual network interface.
- Check a second route. Keep the protocol and client unchanged. If the second route is stable, the original route or its transport is the likely cause.
- Review the log at the moment of failure. Look for timeout, TLS, DNS, handshake, permission, or network-change messages. The timestamp and error type are more useful than a long unfiltered log.
On Windows and macOS, also check whether sleep, wake, a firewall, endpoint-security software, or a manually configured system proxy changes the connection state. On Linux, review the desktop network manager and any existing WireGuard, system proxy, or command-line service that may be running in parallel. On Android and iOS, check whether the operating system has revoked VPN permission or restricted background activity.
Android devices may stop a client when battery optimization, background limits, or vendor-specific task management is enabled. Exempt the client from aggressive battery restrictions where the system provides that option, allow background network activity, and keep the VPN permission active. On iOS, inspect the VPN profile and reconnect after switching networks. If the connection fails only after locking the screen, the pattern strongly suggests a background or power-management setting rather than a bad subscription.
- ✅ Use official clients when you want the simplest subscription management path
- ✅ Use Clash Verge, sing-box, or Shadowrocket only after confirming profile and protocol compatibility
- ✅ Keep one route and one protocol unchanged while testing another variable
- ❌ Do not enable global proxy mode and a second system proxy at the same time
- ❌ Do not delete every configuration before saving the error message and test result
Fix sleep, DNS, and routing conflicts
A tunnel can be technically connected while applications fail because the routing layer is inconsistent. Check whether the client is using global mode, rule mode, or a direct mode. In rule mode, the main website may use the VPN while a login endpoint, media domain, update server, or API endpoint uses the direct network. This can look like a disconnection even though the tunnel remains active.
DNS is another common source of confusion. A browser may resolve a domain through one resolver while another application uses the operating system resolver. If a domain resolves to an address that is unreachable from the selected route, the application may report a timeout. Review the client's DNS option and determine whether direct and proxied domains are intentionally separated. Avoid changing several DNS providers at once; first establish whether the failure follows one rule or affects every domain.
When troubleshooting, temporarily simplify the rule set. Use a clear global or equivalent test mode, disable custom bypass rules, and test the affected application again. If the problem disappears, restore rules gradually until the conflicting domain or process is identified. For a work application, printer, local NAS, or banking site that must remain direct, create a narrow exception rather than disabling routing protection for the entire device.
On routers, verify that the device is not receiving a second default route from another VPN, DNS service, or mesh system. On desktops, check system proxy settings after disconnecting: some clients leave a manual proxy enabled, causing browsers to appear offline when the tunnel is stopped. On mobile devices, inspect per-app routing and confirm that the affected application is included in the intended profile.
Know when to change routes and when to contact support
Changing routes is reasonable when one region, protocol, or transport fails while another remains stable under the same conditions. Choose a route based on the destination, the local network's transport compatibility, and session stability. For long-lived activities, frequent automatic route changes can be less useful than a consistently working route because a new exit may interrupt authentication sessions, downloads, or persistent connections.
Use the provider's available route information and client logs rather than assuming that the nearest country is always best. IEPL, BGP, and CN2 describe different network paths and carrier arrangements; they are not universal guarantees of stability. A route advertised as a particular line type can still behave differently depending on the local carrier, time, destination network, and protocol transport. Treat the label as one selection factor, not as a replacement for testing.
Contact support when the subscription cannot refresh, every compatible route fails across multiple networks, authentication repeatedly fails after a clean import, or the client reports a service-side error. Include the operating system, client name and version, protocol, selected route, approximate failure time, network type, and a short sanitized log excerpt. Remove usernames, subscription URLs, server addresses, keys, tokens, and other reusable credentials before sharing anything.
For vpnLe, supported platforms include Windows, macOS, iOS, Android, and Linux. The service supports subscription-based workflows and offers access to 90+ countries / 200+ routes, while simultaneous online device count is unlimited. These specifications make it possible to test the same account across devices, but they do not remove the need to match the client, protocol, route, and local network correctly.
FAQ: VPN keeps disconnecting
Why does my VPN disconnect when the phone screen locks?
Battery optimization, background restrictions, and manufacturer-specific task management are common causes on Android. Allow the client to run in the background, remove aggressive battery limits where available, and confirm that the VPN permission remains enabled. On iOS, check the installed VPN profile and reconnect after a network transition. If the issue occurs only during screen lock, compare the result after adjusting background settings before changing protocols.
Why does the client say connected but websites still do not load?
The system proxy or virtual interface may not be active, or DNS and split-tunneling rules may be sending traffic through the wrong path. Test a simplified global mode, review the affected application's route, and check whether a second proxy tool is running. If only one application fails, inspect its per-app rule and domain dependencies rather than assuming the entire VPN is disconnected.
Should I switch protocols when the VPN disconnects repeatedly?
Switch protocols only after testing the local network and confirming that the client supports the imported configuration. A TCP-based option and a UDP-based option can react differently to firewall and carrier policies, but switching without reading the log makes the result difficult to interpret. Keep the route and client unchanged while comparing protocols so that the comparison remains meaningful.
Why does a router VPN conflict with a device VPN?
Both layers may try to create a tunnel, alter DNS, or install a default route. This can produce loops, incorrect DNS resolution, or repeated reconnects. Disable one layer during diagnosis, confirm which device should manage the connection, and add the second layer only when the routing design is intentional and documented.