VPN Keeps Disconnecting? Troubleshooting Fixes That Work

A VPN that disconnects repeatedly is difficult to troubleshoot when every failure looks the same. The client may show “disconnected,” traffic may stop while the interface still says “connected,” or the connection may recover for a moment and then drop again. These symptoms can come from different layers: the local Wi-Fi or mobile network, the operating system, battery-saving rules, the VPN protocol, the selected server route, or an expired subscription profile.

The fastest approach is not to change every setting at once. First determine whether ordinary internet access is stable, then check whether the problem affects one node or every node. After that, test the client permissions, background restrictions, protocol options, and route selection in a controlled order. This guide focuses on fixes that can be repeated on Windows, macOS, Android, iOS, and Linux, as well as compatible clients such as Clash Verge, sing-box, and Shadowrocket.

Identify what is actually disconnecting

Start by separating a VPN tunnel failure from a general network failure. Open an ordinary webpage or use another internet-dependent app while the VPN is disconnected. If nothing loads without the VPN, the local connection, router, mobile signal, or upstream network is the first problem to solve. A VPN cannot maintain a tunnel when the device has already lost access to the internet.

If ordinary browsing works but the VPN drops, compare the behavior across several nodes. A single node that fails while other nodes remain connected usually points to a route, server load condition, protocol parameter, or regional path issue. If every node fails at approximately the same time, investigate the local network, client permissions, system restrictions, subscription validity, or protocol compatibility instead.

Also note the timing and context of the failure. A drop that occurs when the phone screen turns off suggests background restrictions. A drop after switching from Wi-Fi to cellular data suggests a handover or permission issue. A failure that appears only during a large download may indicate congestion, packet loss, or a transport that does not perform well on the current network. A drop immediately after importing a profile may indicate that the client cannot correctly parse one or more node parameters.

Stabilize the local network before changing VPN settings

Many apparent VPN failures begin with an unstable local link. Wi-Fi interference, a weak signal, overloaded access points, captive portals, and router band switching can interrupt the encrypted tunnel even when ordinary browsing eventually recovers. Real-time connections are more sensitive than a webpage because the tunnel must keep exchanging packets continuously. Short interruptions can therefore appear as a VPN disconnect rather than a temporary network pause.

Move closer to the access point and test the same client on another Wi-Fi network or on cellular data. This comparison is more useful than repeatedly reconnecting to the same network. If the VPN works on cellular data but not on home Wi-Fi, inspect the router, DNS settings, firewall rules, and wireless conditions. If it fails on both networks, continue with client and system checks.

Public and corporate networks may restrict UDP, uncommon ports, or long-lived encrypted sessions. Hotel, campus, office, and café networks can also require a browser sign-in before allowing full internet access. Complete the captive-portal login first, then establish the VPN. If the network blocks a particular transport, another supported protocol or route may work better, but this should be tested only where VPN use is permitted by the network owner and applicable rules.

• ✅ Confirm that normal internet access works before opening the VPN client.
• ✅ Test Wi-Fi and cellular data separately instead of treating them as one network.
• ✅ Finish any captive-portal login before connecting to a VPN node.
• ✅ Pause large downloads, cloud synchronization, and system updates while diagnosing drops.
• ❌ Do not run two VPN clients or two tunnel modes at the same time.
• ❌ Do not repeatedly reconnect without checking whether the underlying network is losing packets.

Restarting the router can help when its connection table or wireless service is stuck, but it is not a universal fix. After the restart, test a normal webpage first and then test the VPN. On a managed office or school network, avoid changing settings that you do not administer. Instead, collect the time of the failure, the network type, and the client log information that does not expose your subscription credentials.

Check device permissions, sleep rules, and client conflicts

Mobile operating systems are particularly aggressive about limiting background activity. Android may pause an application under battery optimization, background data restrictions, adaptive battery controls, or vendor-specific task managers. iOS may stop or renegotiate a connection when the app cannot maintain the required network extension state. Windows and macOS can also interrupt a client after sleep, network adapter changes, security software updates, or permission changes.

Open the system settings for the VPN client and allow the permissions required to create and maintain a VPN connection. On Android, review battery usage and set the client to an unrestricted or equivalent background mode where that option exists. Also check whether background data is blocked. On iOS, confirm that the VPN configuration has been approved and that the client remains allowed to manage its VPN profile. On desktop systems, check that the application is not being blocked by a firewall, endpoint security product, or permission prompt.

Do not confuse an operating-system VPN profile with a subscription URL. The subscription supplies node profiles; the system VPN permission allows a client to create a tunnel. Deleting one does not necessarily repair the other. If the client created a corrupted or duplicated profile, remove obsolete profiles through the client or system settings, restart the device, and import the current subscription again. Protect the subscription URL while doing so because it may contain account authentication information.

Conflicting network tools are another common cause. A second VPN, a proxy switcher, a DNS filter, a traffic monitor, or a corporate security agent may install its own virtual adapter or alter system proxy settings. Clash Verge, sing-box, Shadowrocket, and an official client should not all be active together. Select one client, disable the others, and restore the system proxy state before testing.

On desktop platforms, sleep and wake events deserve a separate test. Disconnect manually before putting the computer to sleep, then reconnect after the system has fully resumed. If this avoids the problem, update the client and network adapter driver when appropriate, and review the client’s reconnect or kill-switch behavior. A kill switch may intentionally block traffic when the tunnel drops; that can look like a broader internet failure even though the feature is working as designed.

Refresh the subscription and test protocol compatibility

A subscription import is not a permanent guarantee that every profile remains usable. Node parameters can change, a profile can expire, or a compatible client may receive a configuration it cannot fully interpret. Refresh the subscription from the service panel and check whether the updated list contains current profiles. Avoid copying the URL through messaging apps that may truncate long text, and do not paste it into unknown online conversion services.

Protocol support must be evaluated at the client level. Shadowsocks is commonly available in lightweight clients and uses a server address, port, encryption method, and password, sometimes with additional plugin settings. VMess and Trojan may include TLS, transport, WebSocket, or other parameters that must match the server configuration. Hysteria2 uses QUIC and UDP-oriented transport behavior, so a network that restricts UDP may cause repeated failures even when the profile itself is valid. WireGuard uses a different tunnel model and requires compatible key, peer, address, and routing information.

Do not select a protocol merely because it sounds faster. The best option depends on the network in use, the client implementation, and whether the required transport is allowed. If one protocol repeatedly fails on a restrictive Wi-Fi network, test another supported protocol with the same general route. If a profile imports but cannot connect, compare the client’s supported protocol list and the node’s transport parameters. If the client shows a parsing error, importing the same URL again will not fix an unsupported format.

After refreshing, remove duplicate or outdated entries so that you do not accidentally test the wrong profile. In rule-based clients, confirm that the selected mode is understood: global mode, rule mode, and direct mode can send traffic through different paths. A VPN may remain connected while the application you are testing is routed directly. That is a routing result, not necessarily a tunnel failure.

Choose a more stable server route

When the local network and client are functioning, compare routes systematically. Start with a nearby region or a route designed for stability rather than choosing the first item in a long list. If the service distinguishes direct, relay, BGP, or IEPL routes, understand the trade-off: a direct route may be efficient when the path is clear, while a relay or dedicated path can behave differently when an intermediate network is congested. The label alone cannot guarantee performance at every hour or for every destination.

Test nodes individually and keep the application workload consistent. For example, use the same webpage, meeting platform, software repository, or streaming service while comparing routes. Look for repeated symptoms: handshake timeout, DNS failure, packet loss, frequent renegotiation, or a connection that survives browsing but fails during sustained traffic. Avoid interpreting one successful reconnect as proof that the route is permanently stable.

Geographic distance is only one factor. The destination service, transit provider, peering arrangement, and local access network all influence the path. A node in a nearby country can be less reliable than a slightly farther node if the latter uses a better route to your destination. For work applications, prioritize continuity and predictable interaction. For downloads, usable throughput may matter more. For region-specific services, choose an exit location that matches the service requirement while still testing route stability.

If the VPN drops only at a particular time, record the approximate period and compare another route during the same period. This helps distinguish a route-specific congestion pattern from a device issue. Do not report unsupported precision such as an invented latency or uptime figure. A useful support report explains what was tested, on which network, with which client, protocol, and node, and what changed after reconnection.

• ✅ Compare more than one node instead of repeatedly retrying a failed profile.
• ✅ Keep the device, network, application, and test activity consistent during comparison.
• ✅ Prefer a route that remains connected during the task you actually need to perform.
• ✅ Reconnect after switching between Wi-Fi and cellular data.
• ❌ Do not assume the geographically closest node is automatically the best route.
• ❌ Do not judge stability from a single successful page load.

Repair the installation and know when to ask for help

If the problem remains after testing another network, another node, and another supported protocol, refresh the client installation. First export or note only the settings you can safely restore, then remove obsolete VPN profiles and restart the device. Install the current official client or a compatible client from a trusted source, grant the required VPN permission, and import the subscription again. For Clash Verge or sing-box, check that the configuration format matches the application and that the active mode is not sending all traffic directly.

Before reinstalling, disable only temporary troubleshooting features that may interfere, such as a third-party DNS filter or another proxy. Keep security protections enabled unless you administer the device and understand the consequences. If the VPN works with security software paused but fails when it is restored, the correct fix is an approved exclusion or policy change, not permanent removal of protection.

Contact support when the failure is reproducible and you have gathered useful context. Include the operating system, client name and version, whether the issue affects Wi-Fi or cellular data, whether every node fails, the protocol family, and the approximate time of the failure. Attach sanitized log lines if available, but remove subscription URLs, passwords, private keys, UUIDs, and personal identifiers. A short timeline is more useful than a screenshot that only shows “disconnected.”

Use the quickstart guide to verify the basic import and connection flow, and check the help center for client-specific instructions. If the issue began after a system upgrade, a router replacement, or a client update, mention that change because it narrows the investigation. If only one destination fails while other services remain reachable, describe the destination and whether the client’s routing mode is global or rule-based.

VPN disconnecting FAQ

Why does the VPN disconnect when my phone screen turns off?

The operating system may restrict background activity, background data, or battery usage after the screen locks. Review the VPN client’s battery and background permissions, allow it to maintain the VPN profile, and check whether the phone manufacturer has an additional task-killing feature. After changing the setting, lock the screen and test the same node again. If the connection still drops, compare cellular data with Wi-Fi to rule out a network handover issue.

Why does one node disconnect while other nodes work?

A node-specific failure usually points to its route, server condition, or protocol parameters rather than the entire client installation. Try another node in the same region first, then compare a different route type or supported protocol. If only that profile continues to fail after a subscription refresh, stop using it temporarily and provide support with the node name, client, network type, and relevant sanitized log message.

Why does the client say connected but apps cannot access the internet?

The tunnel may be established while DNS, routing mode, or application rules are incorrect. Check whether the client is using global, rule, or direct mode, and confirm that the intended application is not excluded. Review DNS behavior and test another profile. Also check whether a second proxy, DNS filter, firewall, or security agent is overriding the client’s routing settings.

Should I reinstall the VPN client immediately?

Reinstallation is useful when a VPN profile is corrupted, permissions are stuck, or an update left incompatible settings behind, but it should not be the first response to every disconnect. First test ordinary internet access, another network, another node, and another supported protocol. If the issue affects all profiles across networks, reinstall the client after removing obsolete VPN profiles and restart the device. Preserve sensitive credentials carefully and import a current subscription instead of an old copied configuration.