A VPN that keeps disconnecting is frustrating, but the cause is usually identifiable. The problem may come from an unstable Wi-Fi connection, a phone or laptop stopping the VPN app in the background, an overloaded server, a protocol that does not suit the current network, or a conflict with another security tool. Reinstalling the app immediately is rarely the best first move. A more reliable approach is to isolate one variable at a time, test the connection after each change, and keep a backup configuration ready.
First, identify when the VPN disconnects
Before changing settings, note the exact pattern. A VPN that drops immediately after connecting needs a different solution from one that disconnects only when the screen is locked. Likewise, a connection that fails only on one Wi-Fi network points to a different cause from a connection that fails on every network and every device.
Start by observing four conditions:
- ✅ Does the VPN disconnect immediately, after several minutes, or only after the device sleeps?
- ✅ Does the issue happen on Wi-Fi, mobile data, or both?
- ✅ Does changing to another server restore the connection?
- ✅ Does the problem affect one device or every device using the same account?
- ❌ Do not change the protocol, server, DNS, and firewall settings all at once, because you will not know which change solved the problem.
If only one server disconnects while other servers remain stable, the client and account are probably working correctly. The issue is more likely related to that server, route, or protocol combination. If every server disconnects on one network, inspect the local network and background permissions first. If the same account disconnects on several devices and networks, refresh the subscription or contact support after completing the basic checks.
Check the local network and change the server
An unstable VPN connection is often an unstable underlying connection in disguise. Wi-Fi interference, a weak mobile signal, overloaded public Wi-Fi, router power-saving behavior, or frequent switching between Wi-Fi and mobile data can interrupt the encrypted tunnel. When the underlying link changes, some clients reconnect automatically; others need a few seconds or a manual reconnect.
Begin with simple network checks. Move closer to the router, temporarily disable any Wi-Fi extender, and test again. If possible, compare the same device on mobile data and Wi-Fi. On a laptop, also check whether the operating system is switching between two saved networks. A short interruption may be enough to make a tunnel appear disconnected even though ordinary browsing resumes quickly.
Public and office networks can introduce another limitation. Some networks restrict UDP traffic, block unfamiliar ports, require a browser-based login, or terminate long-lived connections. Connect to the network normally first and complete any captive-portal sign-in. If the VPN still drops, try another supported protocol or a line that is designed for a different transport path.
Server selection matters as well. A nearby region is usually a sensible first choice for everyday browsing, while a service located in a particular country may require a line in that country. However, the nearest server is not automatically the most stable. A popular line may be busy, while a slightly less popular line in the same region may provide a steadier session.
| Observed behavior | Likely direction | First action |
|---|---|---|
| Only one server disconnects | Server or route issue | Switch to another line in the same region |
| All servers fail on one Wi-Fi network | Local network restriction or instability | Compare with mobile data or another Wi-Fi network |
| Disconnects when moving between Wi-Fi and mobile data | Network handoff | Reconnect after the network change and test auto-reconnect |
| Disconnects during busy periods | Congestion or route fluctuation | Try another line type or a backup region |
| Disconnects only after the screen locks | Background restrictions | Allow the client to run without battery restrictions |
Different route types also behave differently. IEPL dedicated lines use a more controlled private path and are less exposed to ordinary public-backbone congestion. BGP relay routes pass through a relay before reaching the exit network, which can offer a useful alternative when a direct path is unstable. Direct connections may be perfectly adequate on a clean network, but they can fluctuate more when the access network is congested.
Fix background permissions and battery restrictions
Mobile operating systems are designed to preserve battery life. They may pause a VPN client when the screen is off, restrict background data, remove the app from memory, or prevent it from restarting automatically. This is one of the most common reasons a connection appears stable while the device is in use but disappears after the phone has been idle.
On Android, open the system settings for the VPN client and check battery usage, background activity, and unrestricted data access. The exact menu names differ between manufacturers, but the relevant options usually include battery optimization, auto-start, background activity, and data saver. If the client has an always-on VPN or block-without-VPN option, use it only after confirming that the client reconnects correctly; otherwise, a temporary interruption may also block ordinary network access.
On iPhone and iPad, check whether Low Power Mode or a network transition is affecting the connection. iOS controls background behavior more strictly than desktop systems, so reconnecting after a network change may be normal. Keep the official client updated, allow its VPN configuration, and avoid force-closing it from the app switcher if you expect it to maintain a tunnel.
On Windows and macOS, inspect sleep settings, startup behavior, and security software. A laptop that enters sleep mode may suspend the tunnel and need a fresh connection after waking. Antivirus software, endpoint security, and another proxy utility may also create a conflict. Test with only one VPN or proxy client active. Running Clash Verge, sing-box, Shadowrocket through a compatible environment, an official client, and a browser proxy at the same time can produce competing routes and unpredictable reconnects.
- ✅ Permit the VPN client to run in the background on mobile devices.
- ✅ Disable battery optimization for the client when persistent connectivity is important.
- ✅ Allow the official client through the desktop firewall when prompted.
- ✅ Close other VPN, proxy, traffic-filtering, or network-acceleration applications before testing.
- ❌ Do not keep multiple clients connected to the same network interface.
- ❌ Do not assume that force-closing the app improves stability; on mobile, it can prevent automatic reconnection.
If you use a subscription link with a compatible client, check that the subscription was imported correctly and that the profile still contains available lines. A stale profile can show old entries, missing protocol parameters, or routes that are no longer preferred. Refresh the subscription, restart the client, and test a newly listed line. Keep one official client or one compatible client as your baseline so that troubleshooting does not become a comparison between several unknown configurations.
Change the protocol and tunnel settings carefully
A protocol is not simply a speed label. It determines how traffic is transported, how the client handles packet loss, and how the connection behaves on a restrictive or unstable network. A protocol that works well on home broadband may be less reliable on public Wi-Fi or a mobile network that treats UDP traffic differently.
Common options include WireGuard, OpenVPN, Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and other provider-specific combinations. WireGuard is lightweight and efficient, but its UDP-based transport may be affected by networks that restrict or deprioritize UDP. OpenVPN can be useful as a compatibility fallback, particularly when a network handles TCP traffic more consistently. Shadowsocks is lightweight and widely supported in compatible clients, while VMess and Trojan depend heavily on the complete server profile rather than the protocol name alone. Hysteria2 uses QUIC and UDP and can perform well on high-latency or lossy networks, but it is not automatically the best choice where UDP is filtered.
Change one protocol at a time. First record the current protocol and server. Then switch to the provider's recommended alternative, reconnect, and observe whether the failure pattern changes. If a protocol connects but drops whenever the network becomes busy, try another transport rather than repeatedly reconnecting to the same profile. If the protocol does not connect at all, restore the previous profile before moving to the next test.
MTU and DNS settings can also matter, but they should be treated as advanced options. An MTU that is too large may cause fragmentation or stalled requests on certain paths. DNS problems usually appear as websites failing to resolve while the VPN icon still reports an active connection. They do not always mean the tunnel itself has disconnected. Change these settings only when the client documentation or support team provides a suitable value for the specific profile and platform.
A practical repair sequence
The following sequence is designed to reduce guesswork. It works for the official Windows, macOS, Android, iOS, and Linux clients, and it can also help when diagnosing a compatible client such as Clash Verge or sing-box. Menu names differ, but the order remains useful.
- Reconnect the ordinary network. Turn Wi-Fi off and on, or switch briefly between Wi-Fi and mobile data. Complete any public-network sign-in before launching the VPN.
- Close competing tools. Exit other VPN clients, system proxies, browser proxy extensions, traffic filters, and network accelerators. Keep one client active for the test.
- Refresh the profile. If you use a subscription link, update it in the client and confirm that the profile has not expired or become empty. Do not edit imported parameters unless you know what each field controls.
- Choose a different line. Start with another line in the same region. If that fails, compare a different route type or another region suited to your destination.
- Check background access. Remove battery restrictions on mobile, allow startup where appropriate, and confirm that desktop security software is not blocking the client.
- Test one alternative protocol. Use a documented profile rather than an unverified configuration. Reconnect after the change and observe whether the disconnect pattern improves.
- Restart the client and device. This clears some stuck tunnel interfaces and stale network routes. It is more useful after the earlier checks than as the only troubleshooting method.
- Record the result. Note the device, network type, server, protocol, and approximate time of failure. This information makes support requests much easier to diagnose.
Do not judge stability from a single successful connection. Use the same basic activity for each comparison, such as opening several pages or keeping a normal work session active. The aim is to identify a repeatable pattern, not to manufacture a speed test result. If one configuration remains stable while another repeatedly drops under the same conditions, keep the stable profile and report the unstable one.
When to contact support and what to include
Contact support when every available line fails across more than one network, when the subscription cannot refresh, when the client repeatedly loses its configuration, or when the account behaves differently on supported platforms. Before writing, collect useful diagnostic information without sending passwords or private content.
- The operating system and client name, such as Windows official client, macOS official client, Android, iOS, Linux, Clash Verge, or sing-box;
- Whether the connection was using Wi-Fi, mobile data, or another managed network;
- The server region and protocol shown in the client;
- Whether the failure happens immediately, after sleep, during network switching, or during ordinary use;
- Whether another line or protocol works under the same conditions;
- The time of the most recent failure and any error message displayed by the client.
A screenshot of the client status can help, but remove usernames, subscription URLs, access tokens, and other private information first. If the issue started after a client update, mention that clearly. If it started after changing a router, firewall, DNS, or security application, include that context as well. Support can usually distinguish an account or profile problem from a local network issue much faster when the report includes a comparison rather than only the sentence “the VPN keeps disconnecting.”
VPN disconnection troubleshooting FAQ
Why does my VPN disconnect when my phone screen turns off?
The phone may be stopping the client to save battery or limiting its background data. Remove battery optimization for the VPN app, allow background activity, and check whether a data-saving mode is enabled. After changing the setting, reconnect and lock the screen briefly to confirm whether the tunnel remains active.
Should I change the server or protocol first?
Change the server first when only one line disconnects. Try another line in the same region so that you are testing the server or route rather than changing several variables. If multiple lines fail on the same network, then test one alternative protocol recommended by the provider.
Can two VPN clients cause repeated disconnections?
Yes. Multiple clients can create competing virtual interfaces, routes, DNS rules, or system proxy settings. Close every other VPN and proxy tool, restart the main client, and test again. Only add the second tool back after the first connection has been confirmed stable.
What should I do if every line disconnects?
Compare another network first, then refresh the subscription profile and check background permissions. If every line still fails across different networks and supported devices, collect the client, protocol, network, and error details and contact support. Avoid repeatedly importing random profiles, since that can make the original configuration harder to diagnose.