A VPN that keeps disconnecting is frustrating because the symptom looks simple while the cause may be several layers away. The problem can come from an unstable Wi-Fi signal, mobile network handoffs, a phone’s battery policy, a protocol that does not suit the current network, a duplicate system proxy, or an outdated client. A server can also be temporarily congested, but changing servers repeatedly before checking the device often hides the real issue.
The most efficient approach is to identify when the connection drops and what changes at the same moment. Does it disconnect when the screen turns off, when the device moves from Wi-Fi to mobile data, when the computer wakes from sleep, or only when a particular application starts? Does the client itself report a disconnection, or does the client still say connected while websites stop loading? These details separate a local device problem from a route, protocol, or subscription problem.
Identify the disconnection pattern before changing settings
First, observe the exact failure. A genuine VPN tunnel failure usually appears as a status change in the client, a reconnect notice, or a visible change in the selected server. A routing failure is different: the client may remain connected, but certain websites, applications, or domains fail to open. A DNS problem can produce the same impression, especially when direct IP access works but domain names do not resolve.
Use a simple observation sequence. Connect to the VPN and open a normal website. Then test the application that usually fails. Note whether all traffic stops or only one service is affected. If the client disconnects immediately after the device sleeps, focus on background permissions and battery optimization. If it happens during movement, focus on Wi-Fi roaming and mobile handoffs. If it occurs only on one router, compare that router with a mobile hotspot or another trusted network.
Also check whether another VPN, proxy, firewall, DNS utility, ad blocker, or traffic filter is active. Two applications may try to control the same system proxy or virtual network interface. On computers, an old client can leave behind a service or adapter even after its window is closed. On phones, a private DNS setting, security application, or always-on VPN profile can interfere with the newly selected connection.
- ✅ Confirm whether the client status changes or only the target application fails.
- ✅ Compare the same server on Wi-Fi and mobile data when both are available.
- ✅ Test a browser and the affected application separately.
- ✅ Close other VPN, proxy, DNS, firewall, and traffic-filtering tools.
- ❌ Do not assume that “connected” in the client proves every application is routed correctly.
- ❌ Do not keep switching servers without recording which conditions produced the failure.
Check the network and device settings
A VPN depends on the underlying connection. If the Wi-Fi access point is losing packets, the router is changing channels, or the mobile network is handing the device between towers, the encrypted tunnel may be interrupted even though ordinary browsing seems usable. Test the local connection first: move closer to the access point, reconnect to Wi-Fi, restart the router if appropriate, and compare with another network. If the VPN is stable on a different network, the client is probably not the first place to look.
On Windows and macOS, pay attention to sleep and wake behavior. A laptop may suspend network interfaces while the lid is closed or while the system enters a low-power state. After waking, the client may need to renegotiate the tunnel, but a stale network interface can prevent that process from completing. Disconnect manually, wait for the operating system to restore normal connectivity, and then connect again. If the problem occurs after every sleep cycle, inspect power management and network adapter settings rather than repeatedly reinstalling the client.
On Android and iOS, screen-off behavior is especially important. Battery-saving modes may restrict a VPN client’s background activity, and some manufacturers add additional battery management beyond the standard operating-system setting. Allow the VPN client to run in the background, exclude it from aggressive battery optimization where the system provides that option, and permit background data if your use case requires a persistent connection. Also check whether the system is configured to use an always-on VPN or a block-without-VPN mode that conflicts with the client.
Mobile networks introduce another variable. Moving between Wi-Fi and cellular data can invalidate the current tunnel. If your client has a setting that reconnects automatically after a network change, enable it only after confirming that the client itself is reliable. Otherwise, disable automatic switching during diagnosis and reconnect manually after the device changes networks. This creates a clearer test and avoids mistaking a normal handoff for a server failure.
Routers require a separate check. A router-based VPN may lose its tunnel when the WAN address changes, when the router renews its connection, or when its firmware handles long-lived sessions poorly. Confirm whether every device behind the router is affected. If only one device disconnects, investigate that device. If all devices lose access at the same time, inspect the router’s WAN status, firmware, clock, DNS behavior, and VPN service logs. Avoid changing several router rules at once; save the existing configuration before making a change.
Perform a controlled client and protocol test
Once the underlying network looks stable, check the client. Update the official Windows, macOS, Android, iOS, or Linux application through its normal distribution channel. An outdated client may contain an old tunnel driver, obsolete network permissions, or a subscription parser that no longer handles the current configuration correctly. Restart the device after a major client or driver update, then perform a clean connection test.
For Linux, confirm that the service process, permissions, and virtual interface are all in a normal state. A command-line client and a desktop client should not both try to manage the same route table. If you use a system service, stop the competing graphical client before testing. On Windows, look for leftover virtual adapters from older clients. On macOS, review VPN profiles and network extensions. Removing an unused profile can be more effective than reinstalling the active application over the top of old settings.
Protocol choice matters because networks treat different traffic patterns differently. WireGuard is lightweight and generally efficient, but a particular network may handle its UDP traffic poorly. OpenVPN can use UDP or TCP, and TCP may behave more consistently on some restrictive networks at the cost of extra overhead. Shadowsocks is a proxy protocol rather than a full system VPN by itself, so the client’s routing mode determines which applications use it. VMess and Trojan are commonly used through compatible proxy clients, while Hysteria2 uses a modern UDP-based transport that may perform well on some networks but not every network.
Do not select a protocol simply because it is newer or because another user recommends it. Test the protocols available in the same client, using the same server or the same region when possible. If one protocol remains connected while another repeatedly renegotiates, keep the stable option and continue testing before making further changes. If every protocol fails on one network but works elsewhere, the network is a stronger suspect than the protocol.
Third-party clients need their own checks. In Clash Verge, verify that the active profile is current, the selected mode is intentional, and another system proxy is not overriding it. In sing-box, check that the configuration uses the correct inbound, outbound, DNS, and routing relationships; a syntactically valid profile can still route the wrong traffic. In Shadowrocket, review the active configuration, global or rule mode, and any on-demand or connectivity rules that may repeatedly toggle the tunnel. Import a fresh subscription only when you have confirmed that the subscription itself is accessible and current.
- Close every other VPN and proxy application.
- Update the selected client and restart the device if the client changed its network component.
- Connect with one known server and record the selected protocol.
- Keep the device awake and test a browser together with the affected application.
- Repeat the test with one alternative protocol, changing nothing else.
- Restore the more stable configuration and remove unused profiles only after comparison.
Subscription links deserve a separate distinction. A subscription update usually downloads configuration information; it does not guarantee that every imported route is currently suitable for your network. If a subscription refresh fails, check whether the account plan is active, whether the link was copied completely, and whether the client supports the subscription format. If the refresh succeeds but connections drop, the next test should involve the client, protocol, route, or local network rather than repeatedly refreshing the link.
Choose a more stable route and routing mode
A route can be reachable but unsuitable for sustained use. Congestion, maintenance, geographic distance, and the route type between networks all affect stability. IEPL, BGP, and CN2 describe different network arrangements and should not be treated as automatic guarantees. An IEPL route may provide a more consistent path in a particular direction, while BGP-based routing can vary according to upstream conditions. CN2 may be useful for certain network paths, but the correct choice still depends on the destination and current conditions.
When a server disconnects, first try another route in the same region. This helps determine whether the issue is tied to one entry point or to the entire region. If all routes in one region fail while another region remains stable, the problem may be regional congestion or a path issue. If only one imported profile fails, delete and re-import that profile after confirming that the subscription is current. Avoid editing server parameters manually unless the client documentation specifically requires it; one incorrect field can create repeated handshake failures.
Routing mode also affects what you perceive as a disconnection. Rule mode sends selected domains or applications through the proxy while leaving other traffic direct. Global mode sends much more traffic through the selected route and can expose capacity or DNS problems sooner. Direct mode bypasses the proxy. If a website works in global mode but not rule mode, inspect the rule set. If the client shows a connected status but one application cannot connect, check whether that application is included in the intended rules.
DNS deserves attention because DNS requests may follow a different path from application traffic. A local DNS response can point an application toward an unreachable address, while a remote DNS response may produce a different result. Use the client’s documented DNS settings rather than stacking several DNS tools. On a router, confirm that the router and endpoint are not advertising contradictory DNS policies. On mobile devices, review private DNS and any content-filtering profile.
For streaming, development tools, and real-time applications, select a route based on the destination and connection pattern rather than a generic “fast” label. A route that is suitable for short web requests may be less suitable for a long video session or a persistent development connection. Keep a small personal record of which region, protocol, and routing mode work on each network. This is more useful than treating a large route list as a quality ranking.
Fix platform-specific disconnects
Windows and macOS
On desktop systems, check whether the client starts before the network is ready. A client launched during startup may attempt to connect against an incomplete Wi-Fi or Ethernet state. Automatic connection can be useful after the system is stable, but it can create a reconnect loop during startup. Test a manual connection after the desktop is fully loaded. Also inspect sleep settings, firewall permissions, network extensions, and virtual adapters left by previous software.
If only one browser or application fails, clear its proxy setting and confirm that it is not using a separate proxy configuration. Some applications ignore the operating-system proxy, while others use their own. This is why a client can appear connected while one application remains direct or cannot resolve domains. Do not disable the firewall permanently as a first response; create the smallest necessary permission change and restore normal protection after testing.
Android and iOS
On phones and tablets, allow the client to run in the background and review battery restrictions. Check whether the system pauses the application when the screen is locked. Also review automatic Wi-Fi selection, mobile-data restrictions, private DNS, and always-on VPN settings. If the client reconnects whenever the screen turns on, the battery policy is a strong lead.
iOS manages VPN profiles and network extensions tightly. Remove only obsolete profiles, keep the active configuration, and reconnect after confirming the client has permission to add or use a VPN configuration. On Android, manufacturer-specific power managers may use different names, so look for background activity, auto-start, and battery optimization controls. The aim is not to disable every power feature, but to prevent the active client from being suspended during the intended session.
Linux and routers
On Linux, inspect whether NetworkManager, a system service, and a third-party client are competing for control. Use one connection manager during each test. On routers, verify the firmware, WAN stability, system time, DNS settings, and tunnel logs. If the router cannot maintain a tunnel, test the official client directly on one endpoint. That comparison quickly shows whether the router or the upstream network is responsible.
- ✅ Use one active VPN manager at a time on Linux and desktop systems.
- ✅ Review background and battery permissions on Android and iOS.
- ✅ Check sleep, wake, and network-extension behavior on Windows and macOS.
- ✅ Compare a router-based connection with a direct endpoint connection.
- ❌ Do not leave several automatic-connect rules enabled while diagnosing reconnect loops.
Know when to reset or contact support
A reset is appropriate when the configuration has become difficult to understand, not as a substitute for diagnosis. Before resetting, save the account credentials, note the selected client, and record which network and route produced the failure. Then remove unused profiles, update the client, and import a fresh configuration through the supported method. Reconnect with the simplest available mode before restoring custom rules.
Contact support when the account status is unclear, the subscription cannot be retrieved, several compatible clients fail on the same network, or the problem affects many routes at once. Provide useful context: operating system, client name and version, network type, selected protocol, selected region, approximate time of failure, and whether another network changes the result. Do not send passwords or private authentication details. A precise report is much easier to investigate than “the VPN is broken.”
14VPN supports Windows, macOS, iOS, Android, and Linux, with subscription import available for compatible clients. It also supports common third-party workflows such as Clash Verge, sing-box, and Shadowrocket when the imported format and client settings are compatible. The service lists coverage across 110+ countries and 210+ routes, but a larger list should not replace controlled testing. Plans allow unlimited device count, so you can compare a phone and computer without treating the number of devices as the likely cause. If you need setup instructions, use the setup guide; for current plan details, review pricing.
VPN disconnection FAQ
Why does my VPN disconnect when my phone screen turns off?
The phone may suspend the VPN client to reduce battery use or restrict background data. Review battery optimization, background activity, auto-start, and always-on VPN settings. If the connection remains stable while the screen is awake but drops after locking, test the battery and background permissions before changing servers.
Should I change the VPN protocol first?
Not usually. First determine whether the underlying network is stable and whether another VPN or proxy is active. Then compare protocols one at a time using the same route. WireGuard, OpenVPN UDP or TCP, Shadowsocks, VMess, Trojan, and Hysteria2 have different transport behavior, so the most suitable option depends on the network and client.
Why does the client say connected when applications do not work?
The tunnel may be active while routing or DNS is incorrect. Check rule, global, and direct modes, then verify whether the affected application is included in the intended route. Also review DNS settings and application-specific proxy settings. If only one service fails, it is not automatically a complete VPN disconnection.
When should I reinstall the client?
Reinstall after checking network conditions, closing competing tools, updating the client, and removing obsolete profiles. Reinstallation is useful when a network extension, virtual adapter, or local configuration is damaged, but it will not fix a congested route or an unstable Wi-Fi connection. Record the working settings before removing the existing installation.