A VPN that keeps disconnecting is frustrating, but the symptom alone does not identify the cause. The interruption may come from an unstable Wi-Fi connection, a mobile network changing state, a background permission being removed, battery optimization, an overloaded server, or a protocol that does not suit the current network. A client can also appear connected while selected applications are bypassing it through split tunneling, system proxy settings, or their own network path.
The most efficient way to troubleshoot is to change one variable at a time. First confirm whether the underlying internet connection is stable. Then check whether the operating system is allowed to keep the client running, whether the selected server works on another network, and whether switching protocol or traffic mode improves the session. This sequence applies to the official VFVPN clients for Windows, macOS, Android, iOS and Linux, as well as compatible clients such as Clash Verge, sing-box and Shadowrocket.
Identify what is really disconnecting
Begin by observing the client’s status indicator rather than relying only on the failed webpage. If the interface changes from connected to disconnected, the tunnel or proxy session has ended. If it remains connected but one application stops working, inspect the selected mode, rule set, DNS behavior, and application permissions instead. In a system VPN mode, the operating system normally routes traffic through a virtual network interface. In a system proxy or rule-based mode, only traffic matching the client’s rules may be handled.
This distinction matters because the remedy is different. A tunnel that repeatedly closes usually points to transport interruptions, background restrictions, authentication failure, or a server-side session problem. A browser that cannot open a page while the client remains active may be using a different proxy setting, resolving DNS outside the intended path, or matching a rule that sends the request directly. On Linux and desktop systems, a local firewall, another proxy service, or a network manager can also alter the route after the VPN client has connected.
110+
Countries covered
160+
Available routes
5
Official platforms
Unlimited
Online devices
Use the following observations to classify the problem:
- ✅ If every device on the same Wi-Fi loses access, inspect the router or internet connection first.
- ✅ If only one device disconnects, inspect that device’s permissions, battery policy, and competing network tools.
- ✅ If one route fails but another route remains stable, treat it as a route or protocol issue.
- ✅ If the client says connected but only selected apps fail, inspect rules, DNS, and application proxy settings.
- ❌ Do not repeatedly reconnect without recording which network, route, protocol, and mode were active.
Check the network, route, and server selection
The local connection is the foundation of every VPN session. A VPN cannot remain stable when the device is moving between weak Wi-Fi access points, losing cellular signal, or passing through a captive portal. Public Wi-Fi may require a browser sign-in before any tunnel can work. Some office, school, hotel, or carrier networks restrict unfamiliar ports or long-lived connections. In those situations, the VPN may connect briefly and then stop when the network rejects or expires the session.
Test the ordinary connection without the VPN enabled. Open more than one unrelated website and, if possible, move from Wi-Fi to cellular data or from cellular data to a trusted Wi-Fi network. The purpose is not to measure a particular speed, but to determine whether the disconnection follows the network. If the problem disappears after changing networks, keep the VPN settings unchanged and investigate the original access point, router DNS, captive portal, or network firewall.
Next, change the selected route. A route that is geographically close is not automatically the best route for every network. Congestion, maintenance, peering, and the route’s transport parameters can all affect reliability. A server list may contain entries using different protocols or route types, so compare like with like where possible. Do not conclude that the entire subscription is invalid because one entry fails; a subscription can contain multiple independent configurations.
| Observation | Likely area | Practical action |
|---|---|---|
| VPN and ordinary internet both stop | Wi-Fi, cellular signal, router, or captive portal | Reconnect the local network, complete any sign-in page, and test another access method |
| Only one route disconnects | Route load, transport, or route-specific parameters | Switch to another route and compare protocol or transport settings |
| Several routes fail on one network | Network filtering, DNS behavior, or incompatible ports | Try another protocol supported by the subscription and test a different network |
| Client remains connected but an app fails | Rules, split tunneling, DNS, or app-level proxy settings | Review the matching rule and temporarily use a broader test mode |
When a subscription has not been updated for a long time, refresh it through the client’s subscription management screen. Importing a subscription again is useful when the provider has changed route parameters, but it should not be the first response to every brief interruption. Preserve a working configuration before removing it, and avoid importing the same subscription repeatedly if the client already contains duplicate entries.
For clients such as Clash Verge and sing-box, confirm that the selected profile is active and that the client is actually running its local mixed or proxy port. For Shadowrocket, check whether the selected global, rule, or direct mode matches your test. Incompatible configuration formats, expired credentials, or missing transport fields can cause a connection to appear briefly and then fail during the handshake.
Check permissions and background settings
Mobile operating systems are designed to stop applications that consume network, CPU, or battery resources in the background. A VPN client may therefore work while its screen is open and disconnect after the phone is locked. This is especially common when battery saving, adaptive battery, background refresh, or restricted data access is enabled. The exact menu names vary by operating system version and device manufacturer, but the principle is consistent: the VPN client must be allowed to maintain its tunnel or proxy process when it is not visible.
On Android, open the application information page and review battery usage, background activity, unrestricted data access, and automatic startup. If the phone manufacturer provides a separate task manager or memory cleaner, exclude the VPN client from aggressive cleanup. Also review whether a system-wide data saver is preventing background traffic. Some Android devices have both a general battery policy and a manufacturer-specific optimization layer, so changing only one may not be sufficient.
On iPhone, check the VPN profile and allow the client to add or manage the VPN configuration when requested. Review Background App Refresh where relevant, and be careful with Low Power Mode during long sessions. iOS may also change behavior when the device moves between Wi-Fi and cellular data. If the VPN disconnects immediately after a network transition, reconnect once after the new network is fully available and observe whether the behavior repeats.
On Windows, confirm that the official client is permitted through the operating system firewall and that no security product is terminating its service. If the client installs a virtual adapter, check whether the adapter remains enabled after the failure. Fast startup, sleep, network adapter power management, and third-party “network protection” features can all affect reconnection. Windows users should also check whether another VPN, proxy manager, or corporate security agent is applying a competing policy.
On macOS, review VPN permissions, login items, network extensions, and security software approvals. A client that uses a system extension may require explicit permission in Privacy & Security settings. If the connection works only while the client window is open, inspect background or login-item settings instead of repeatedly changing servers. On Linux, check whether NetworkManager, systemd-resolved, a desktop proxy setting, or a firewall rule is replacing the route after the client starts.
Run a controlled troubleshooting sequence
After checking the basic network and permissions, perform a controlled sequence. The goal is to avoid changing several settings at once, because that makes the result impossible to interpret. Record the current client, mode, route, protocol, and whether the device is on Wi-Fi or cellular data. Then reconnect and test the same application after each change.
- Close other VPN, proxy, DNS, traffic-filtering, and network-acceleration applications. Two clients may compete for the same virtual adapter, local port, DNS service, or routing table.
- Disconnect the VPN and confirm that ordinary internet access works. Complete any captive-portal sign-in before reconnecting.
- Refresh the subscription only if the client reports an update issue or the route list appears outdated. Keep a known configuration available before deleting older entries.
- Select another route in the same region or a different region. Test a normal webpage and the affected application after the connection becomes active.
- Switch between the protocols available in the imported configuration. Do not manually invent missing fields; protocol parameters must match the server-side configuration.
- Compare rule mode, global mode, direct mode, or system VPN mode according to the client. Use a broader test mode temporarily to determine whether rules are bypassing the affected traffic.
- Lock the device or let the desktop enter its normal idle state, then check whether the client remains active. If it fails only during idle, return to battery and background permissions.
- Test another network. A result that changes with the network points toward local filtering, DNS, ports, Wi-Fi roaming, or carrier behavior rather than the device alone.
Protocol selection should be treated as a compatibility decision, not a universal ranking. WireGuard often provides a simple, efficient tunnel when the client and network support it. Shadowsocks is commonly used as a proxy protocol and may be suitable for clients that support rule-based traffic handling. VMess and Trojan depend on their complete transport and security parameters, while Hysteria2 uses a different transport model and may behave differently on networks that handle UDP traffic poorly. These protocols are not interchangeable: importing a profile with the wrong client type or omitting transport, TLS, server-name, path, or authentication fields can produce repeated handshake failures.
For a desktop client, start with the official application when it is available because it normally manages system permissions, virtual adapters, and subscription updates in one workflow. Use Clash Verge or sing-box when you specifically need detailed rules and understand how the local proxy mode is configured. Shadowrocket is convenient on iPhone, but its behavior depends on whether traffic is set to global, rule, or direct mode. A compatible client is not automatically equivalent to the official client; format support and platform permissions still matter.
Apply platform-specific fixes
Windows and macOS
Desktop disconnections often occur after sleep, waking from a locked screen, changing Wi-Fi networks, or resuming from a network adapter reset. First restart the client normally and verify that its service or network extension has loaded. If the client displays a system proxy switch, confirm that it matches the intended mode. A stale system proxy can make the client look disconnected even when its local process is still running; the opposite can also happen, where the proxy remains enabled after the client has stopped.
Check for software conflicts in a controlled way. Temporarily stop another VPN, local proxy, DNS filter, firewall module, or traffic monitor, then reconnect. Do not permanently disable security protection without understanding the consequences. If the VPN becomes stable only after a security product is stopped, create a narrowly scoped and documented exception according to that product’s instructions rather than leaving the entire device unprotected.
When sleep is the trigger, inspect power management for the Wi-Fi or Ethernet adapter and test whether the operating system is dropping the adapter during idle. On macOS, inspect network extensions and login items; on Windows, inspect the virtual adapter and firewall permissions. If the problem began after a client or operating system update, reinstalling over the existing installation may not reset every permission. Remove only the affected configuration when necessary, then import the subscription again through the supported workflow.
Android and iPhone
On mobile devices, start with battery and background access rather than protocol changes. Set the VPN application to an unrestricted or allowed background policy where the system provides that option. Exclude it from memory cleaning, permit background data, and check whether a device-level data saver is active. If the client disconnects when the screen turns off, this evidence strongly favors an operating-system restriction over a route failure.
When moving between Wi-Fi and cellular data, allow the new connection to become usable before reconnecting. Some devices retain an old network state for a short period, while the VPN still tries to use the previous interface. If the issue happens only in one location, compare another Wi-Fi network or cellular data. If it follows the phone regardless of network, review permissions, installed profiles, and other network-management applications.
On iPhone, verify that the VPN configuration belongs to the intended client and remove obsolete profiles only when you know they are no longer needed. On Android, check whether another always-on VPN or work profile is enforcing a separate connection. Multiple management layers can cause a client to reconnect continuously because the system is applying a different VPN policy in the background.
Know when to reset or escalate
A reset is reasonable after ordinary checks have isolated a local configuration problem. Before resetting, note the current route, protocol, mode, DNS choice, and any custom rules you need to preserve. Export supported configuration data if the client offers that function, or keep the original subscription available. Resetting network settings may remove saved Wi-Fi networks, custom DNS settings, proxy entries, and VPN profiles, so it should not be the first step for a single failed route.
Escalate the issue when the same route and protocol fail across multiple devices and networks, when the client reports authentication or subscription errors, or when every imported configuration fails during the handshake. Include useful evidence: platform, client name, operating-system version, connection type, selected route, protocol, approximate time of failure, and whether another route works. Avoid sending passwords, private keys, complete access links, or other credentials in a support request.
Also separate account or traffic-limit questions from connection stability. A monthly plan includes a defined traffic allowance that resets each month from the activation date, while a traffic package remains available until used and does not expire. If a session stops after an allowance is exhausted, reconnecting repeatedly will not solve the underlying account state. Review the account panel and subscription status before changing local settings.
- ✅ Keep one known-good route and protocol as a comparison point.
- ✅ Test the same application after each configuration change.
- ✅ Preserve custom rules before reinstalling or resetting a client.
- ✅ Share diagnostic context without exposing subscription credentials.
- ❌ Do not run multiple VPN clients at the same time while diagnosing a drop.
Frequently asked questions
Why does the VPN disconnect when my phone screen turns off?
The most common cause is battery optimization or restricted background activity. Allow the VPN client to run in the background, permit background data, and exclude it from the phone’s memory-cleaning feature. If the problem continues, compare Wi-Fi and cellular data to determine whether the network transition is also involved.
Should I change the protocol immediately?
No. First confirm that ordinary internet access is stable, the client has background permission, and another route behaves differently. Once those checks are complete, try a protocol already provided by the subscription. Do not manually combine parameters from WireGuard, Shadowsocks, VMess, Trojan, or Hysteria2 profiles, because each requires compatible server-side settings.
Why does the client say connected while one app has no access?
The app may be bypassing the client through split tunneling, a direct rule, its own proxy setting, or a separate DNS path. Compare rule mode with a broader test mode, inspect the matching policy, and confirm that the application is not using an independent network configuration.
When should I switch to another route?
Switch routes when only one entry disconnects, when the route fails on more than one network, or when another entry using compatible settings works normally. Keep the original configuration for comparison, and refresh the subscription only when the client or provider indicates that its route information needs updating.