A VPN that keeps disconnecting is rarely caused by one universal fault. The drop may come from an unstable Wi-Fi or mobile network, a protocol that does not fit the current connection, an operating system that pauses background activity, an expired or damaged subscription entry, or a server route that is temporarily unsuitable for the destination. The most useful troubleshooting method is to change one variable at a time and observe whether the connection remains stable.
This guide explains how to separate local network problems from client, protocol, subscription, and server problems. It covers Windows, macOS, Android, iOS, and Linux, along with compatible clients such as Clash Verge, sing-box, and Shadowrocket. The goal is not to keep pressing the connect button, but to identify the layer that is failing and apply the smallest effective fix.
Before changing advanced settings, record the current configuration. Note the client name, selected node, protocol, routing mode, and whether the drop happens on Wi-Fi, mobile data, or both. This makes it easier to undo an unhelpful change and compare results.
Identify the Disconnection Pattern First
Start by deciding what “disconnecting” actually means. A client may show a disconnected status because the tunnel handshake failed, because the process was closed by the operating system, or because a health check marked the node unavailable. In other cases, the client remains connected while only one website, application, or protocol stops working. These situations require different fixes.
5
Major platform groups
6
Common protocol families
110+
Countries covered
180+
Available routes
Check the following patterns before making changes:
- ✅ If the connection drops only when the device changes between Wi-Fi and mobile data, inspect network switching and background permissions first.
- ✅ If every node disconnects on one network, test the local network, DNS behavior, and protocol compatibility.
- ✅ If only one node fails while other nodes remain stable, treat it as a route or server selection problem.
- ✅ If the client says connected but applications cannot load, inspect system proxy, TUN mode, routing rules, and DNS handling.
- ❌ Do not reinstall the client immediately; reinstalling rarely fixes a blocked protocol or an operating system power restriction.
- ❌ Do not change the protocol, DNS, routing mode, and node at the same time, because you will not know which change helped.
Also check whether the drop is time-based. A connection that fails shortly after the screen locks points toward battery management or background suspension. A connection that fails when a laptop wakes from sleep may require the client to reconnect after network changes. A connection that fails only during heavy downloads may be affected by transport behavior, local congestion, or a route that does not handle sustained traffic well.
Check the Local Network and DNS Basics
A VPN client cannot maintain a connection if the underlying network is repeatedly losing access to the node address. Test the ordinary connection without the client, then test another access method if available. For example, compare home Wi-Fi with a phone hotspot, or compare mobile data with another trusted Wi-Fi network. If the connection is stable on one network and repeatedly drops on another, the local access network is an important clue.
Restart the modem or router only when the ordinary connection itself is unstable. If normal websites also fail to load, a VPN-specific change will not solve the underlying problem. Check whether the router is applying parental controls, captive-portal authentication, traffic filtering, or a custom DNS policy. Public Wi-Fi may also require a browser sign-in before long-lived connections can work correctly.
DNS problems can look like disconnections. The client may successfully establish an encrypted connection, but the application cannot resolve a domain or receives an unsuitable address. Depending on the client, DNS may be handled by the operating system, the proxy core, a TUN interface, or a remote resolver. Mixing these modes can produce intermittent results, especially when split routing is enabled.
Use a simple sequence:
- Disable the client and confirm that the local network can open ordinary websites.
- Reconnect the client and check whether its status changes to connected.
- Open more than one type of destination, such as a normal website and the service you actually need.
- Compare results with another network without changing the node or protocol.
- Inspect the client log for repeated DNS errors, timeout messages, failed handshakes, or certificate warnings.
Do not assume that changing DNS will improve every situation. DNS can help when names are not resolving correctly, but it cannot repair an unreachable node, an invalid authentication value, or a protocol blocked by the access network. Likewise, disabling all routing rules may make testing easier, but it is not necessarily the best permanent configuration.
Avoid Network Conflicts
Running two traffic-handling tools at the same time is a common cause of unstable behavior. Examples include two proxy clients, a system VPN and a TUN-based proxy, a security product with web filtering, or a browser extension that changes proxy settings. Each tool may try to install a virtual interface, modify the system proxy, or replace DNS settings.
Close other proxy clients during testing. On desktop systems, check the system proxy panel and confirm that the active client is the one intended to handle traffic. On mobile systems, inspect the VPN list and remove or disable profiles that are no longer used. If a client offers both system-proxy mode and TUN mode, enable only the mode needed for the test. When the connection is stable, add other tools back one at a time.
Change the Protocol and Transport Carefully
Protocols are not interchangeable labels. Shadowsocks, VMess, Trojan, VLESS, Hysteria2, and WireGuard use different configuration models and may behave differently on restrictive, congested, or unstable networks. A subscription link can contain several protocol types, but the client must support the relevant protocol core and all required fields.
Shadowsocks usually relies on an encrypted proxy configuration with a server address, port, method, and password. VMess and VLESS are commonly handled by clients that support their related configuration ecosystems. Trojan generally depends on TLS-related settings and correct domain verification. Hysteria2 uses QUIC and UDP characteristics, while WireGuard creates a tunnel interface with its own key and peer configuration. These differences affect compatibility, recovery behavior, and sensitivity to packet loss.
| What you observe | What to inspect | Practical action |
|---|---|---|
| Handshake repeatedly times out | Protocol support, address, port, TLS, and transport fields | Refresh the subscription and test another compatible protocol |
| Connection works on Wi-Fi but not mobile data | UDP behavior, carrier filtering, and transport compatibility | Try a TCP-based or otherwise compatible alternative if supplied |
| Connected status appears, but no applications work | TUN permission, system proxy, routing rules, and DNS mode | Test global handling temporarily, then restore rule-based routing |
| Only one imported node fails | Node expiry, server availability, and route selection | Test another node before changing the entire client setup |
| Disconnect follows sleep or screen locking | Background activity, power saving, and reconnect options | Allow background operation and enable automatic reconnection |
Change only one protocol or transport parameter at a time. If a client offers automatic selection, use it as a diagnostic aid rather than assuming it always chooses the best route. Review the log after each attempt. A clear authentication failure points in a different direction from repeated UDP timeouts or certificate verification errors.
Some networks handle TCP-based traffic more consistently, while others perform better with a protocol that can recover from packet loss or use a different transport. There is no universal “fastest” protocol independent of location and destination. Stability depends on the access network, the route between you and the server, the exit region, the client core, and the application’s traffic pattern.
Refresh the Subscription and Test Nodes
A subscription entry can become outdated even when the client itself is working normally. The provider may remove a route, change a server address, update a certificate, or publish new protocol parameters. If the client imported the link only once, it may still be using old node information. Refresh the subscription from inside the client rather than copying individual values from an unknown source.
Treat the subscription URL as sensitive configuration data. It may contain access credentials or a token that allows the client to retrieve node information. Do not publish it in a screenshot, paste it into an unfamiliar conversion website, or send it in a public support channel.
After refreshing, compare several nodes from different regions or route types. A single failed node does not prove that the whole subscription is unusable. Conversely, if every node fails after a refresh, inspect the subscription URL, account status, client compatibility, and current network. If a client reports an empty list, check whether the link was pasted completely and whether the client supports the supplied format.
- ✅ Refresh the subscription using the client’s built-in update function.
- ✅ Confirm that the updated node list contains supported protocols and complete parameters.
- ✅ Test a different region when one route repeatedly disconnects.
- ✅ Keep a known working configuration as a temporary comparison point.
- ❌ Do not edit server addresses or credentials randomly inside an imported profile.
- ❌ Do not conclude that the client is broken because one node has expired or become unreachable.
Fix Background Permissions and Reconnection
Mobile operating systems are particularly aggressive about pausing background applications. A client may connect correctly while visible, then stop maintaining the connection after the screen locks. Battery saver, background data restrictions, app sleeping, and automatic task cleanup can all interrupt a long-lived connection.
On Android, allow the client to run in the background, remove it from battery optimization where the system provides that option, and permit background data when the client needs to update or maintain its connection. The exact menu names vary by device manufacturer. Also check whether a device-management tool is force-closing applications.
On iOS, confirm that the VPN profile is installed and that the client is allowed to establish the requested network connection. Low Power Mode and changes between Wi-Fi and mobile data can alter behavior. iOS provides less freedom for arbitrary background processes, so a client may need to reconnect after a network transition or after the system suspends it. If the client has an on-demand or automatic reconnect feature, enable it only after confirming that the VPN profile is correct.
On Windows and macOS, check whether the client is allowed to launch at sign-in, whether sleep disconnects the network adapter, and whether a security product blocks the network extension or virtual adapter. macOS may request approval for a network extension or VPN configuration. Windows may display firewall or network permission prompts. Denying those prompts can leave the interface partially configured.
Linux users should inspect the service manager, network manager, permissions for the TUN device, and any competing firewall or routing service. A command-line process may end when its terminal closes unless it is started as a managed service. Desktop clients and command-line cores can also overwrite each other’s routes if both are active.
Hands-On Recovery Sequence
Use the following recovery sequence when the cause is unclear. It is designed to preserve useful evidence while returning the setup to a known state.
- Disconnect the client and verify that the underlying network works normally.
- Close every other proxy, VPN, traffic filter, and browser proxy extension.
- Restart the affected client and wait for its subscription list and local service to load.
- Refresh the subscription without changing unrelated settings.
- Select one compatible node and use the client’s simplest supported traffic mode for testing.
- Confirm that the required system permission, TUN interface, or system proxy is active.
- Test a normal website and the target application separately.
- If the connection drops, read the log and record the last event before the drop.
- Test a second node, then a second protocol only if the first node fails.
- Restore rule-based routing and background restrictions after stability has been confirmed.
Do not repeatedly uninstall and reinstall during this sequence. Reinstallation may erase useful logs while leaving the original network, permission, or subscription problem unchanged. If reinstalling is necessary, first export or note the profile settings and confirm that you can obtain the client from a trusted official source.
Platform-Specific Checklist
Windows: Check the system proxy, firewall permissions, virtual network adapter, and whether another application is controlling the same port. If the client has both service mode and portable mode, avoid launching both. After waking from sleep, reconnect if the network adapter has received a new address.
macOS: Review Network settings for the approved VPN configuration or network extension. Confirm that the client has permission to run its helper process and that macOS has not blocked it after an update. If the system proxy is enabled but the client is not running, applications may appear offline even though the ordinary network is fine.
Android: Check battery optimization, background data, automatic task cleanup, and whether another VPN profile is active. Some device vendors provide their own network acceleration or security features that can interfere with a third-party client.
iOS: Confirm the installed VPN profile, automatic reconnect settings, and behavior during Wi-Fi-to-mobile transitions. If the profile appears damaged, remove it from the client’s own settings where possible and add it again rather than creating multiple overlapping profiles.
Linux: Confirm that the selected client has permission to create a TUN interface, that the required core is installed, and that NetworkManager, systemd, firewall rules, and another proxy service are not competing for routing control. Review service logs after a reconnect attempt instead of relying only on the desktop status icon.
FAQ for Recurring Disconnections
Why does the client show connected while websites still fail?
The encrypted connection may be active while traffic is not being directed through it. Check system-proxy mode, TUN mode, routing rules, DNS handling, and whether the application bypasses the client. Test a simple destination before concluding that the node has failed.
Should I change the protocol whenever a connection drops?
Not immediately. First determine whether the drop affects every node or only one, and whether it happens on one network. If the log indicates a transport or handshake problem, test another protocol that the subscription and client both support. Make one change at a time.
Why does the connection stop when my phone screen locks?
Background restrictions, battery optimization, automatic task cleanup, or operating-system limits may suspend the client. Allow background activity where available, permit background data, review battery settings, and enable automatic reconnection if the client provides it.
When should I switch servers?
Switch servers when only one node repeatedly fails, when the route is unsuitable for the destination, or when the client log shows a server-specific timeout. If every node fails, changing servers alone is unlikely to help; inspect the local network, subscription, permissions, and protocol compatibility first.
The most reliable fix is usually a controlled diagnosis: verify the ordinary network, remove conflicts, confirm permissions, refresh the subscription, test a compatible protocol, and then compare routes. Once the connection is stable, keep a simple fallback configuration and avoid unnecessary changes. This approach restores connectivity without hiding the original cause or creating a new routing conflict.