VPN Keeps Disconnecting? Troubleshooting Fixes That Work

A VPN that keeps disconnecting is frustrating, but reinstalling the client is rarely the best first move. Repeated drops can come from an unstable Wi-Fi or mobile connection, a captive portal, battery optimization, background restrictions, DNS changes, an incompatible protocol, or a route that is difficult for the current network to maintain. The most efficient approach is to identify when the drop occurs and then test one layer at a time.

This guide follows a practical order: check the local network, confirm that ordinary internet access works, review system restrictions, refresh the subscription or configuration, change the protocol, and finally compare another route. The same principles apply to Windows, macOS, Android, iOS, and Linux, although the names of the settings differ. A client using a system VPN interface, a local proxy, or a TUN virtual network adapter may also behave differently when the connection is interrupted.

Identify the disconnect pattern before changing settings

Start by recording what “disconnecting” actually means. The client may show a disconnected status, but the underlying problem could be different. In one case, the tunnel closes completely. In another, the client remains connected while DNS requests fail. A third situation occurs when the tunnel is active but a browser, streaming app, or work application cannot reach its destination. These cases require different fixes.

Ask when the failure happens. Does it occur immediately after connecting, only after the screen is locked, whenever the device changes from Wi-Fi to mobile data, or after a long period of inactivity? Does every route fail, or only one node? Do ordinary websites work when the VPN is turned off? Does the problem affect one application or the entire device? The answers help separate a local network issue from a client, protocol, or route issue.

Separate a tunnel failure from an application failure

When the client reports a drop, first open a normal website with the VPN disconnected. If the website cannot load, repair the local connection before changing VPN settings. If ordinary access works but the tunnel fails, continue with the client and route checks.

Next, reconnect and test more than one destination. A single website may be unavailable, rate-limited, or resolving to a problematic address. If the client status is connected and several unrelated websites load, the VPN may be functioning while a particular service has its own regional, account, or security restrictions. Do not treat an application-specific error as proof that the entire connection has failed.

• ✅ Test ordinary internet access with the client disconnected
• ✅ Check whether the drop affects every route or only one route
• ✅ Test a browser and the application that originally showed the problem
• ❌ Do not change several settings at once, because the cause becomes harder to identify

Check the local network and system state

A VPN cannot maintain a tunnel if the device is repeatedly losing its underlying connection. Wi-Fi may appear connected while the access point is renegotiating, the network requires a sign-in page, or the local carrier is changing between network types. On mobile devices, signal strength can also change quickly when moving between rooms, elevators, vehicles, or outdoor areas.

Reconnect to the Wi-Fi network and wait until the captive portal is complete. Hotels, airports, cafés, schools, and offices may require a browser confirmation before normal internet access is allowed. If the VPN starts before that process is finished, the portal may not open or may not complete correctly. Disconnect the VPN, complete the local network login, open an ordinary website, and then reconnect.

For a quick comparison, test another trusted network. On a laptop, a phone hotspot can help determine whether the original Wi-Fi is interfering with long-lived connections. On a phone, compare Wi-Fi and mobile data if your plan and local conditions allow it. This is not a permanent solution; it is a diagnostic step. If the VPN is stable on one network and repeatedly drops on another, investigate the network, router, firewall, or access policy rather than reinstalling the client.

Restart the network path in the right order

Disconnect the VPN, turn the device network connection off and on, and reconnect to the access point. If you control the router, restart it only after confirming that other users will not be interrupted. Check whether the system clock is correct, because significant time errors can affect certificate validation and authentication. Also disable any second VPN, proxy utility, traffic filter, or security application temporarily for testing. Two tools attempting to control the same traffic path can produce resets, loops, or misleading status messages.

On Windows and macOS, check whether the operating system has more than one active network interface, such as Wi-Fi, Ethernet, a virtual adapter, or a corporate security client. On Linux, inspect the active connection and the virtual interface created by the client. The exact commands and interface names vary by distribution, so use the documentation for your operating system instead of deleting adapters at random. A virtual adapter may be required for TUN mode and should not be removed merely because it appeared after installation.

Review battery, background, and permission settings

Mobile operating systems are designed to limit background activity. When the screen is locked or another application is in the foreground, the system may suspend a client, restrict background network access, or apply aggressive battery optimization. Some phones also provide separate controls for background data, unrestricted battery use, auto-start, and the ability to display a persistent notification. A VPN that depends on a background process can disconnect when one of these controls is too restrictive.

On Android, open the client’s app settings and review battery usage, background activity, mobile data, Wi-Fi data, and auto-start permissions where available. The wording differs between manufacturers. Set the client to an option that allows background operation when you need an always-on connection. If the phone has a manufacturer-specific memory cleaner, add the client to its protected list. Do not assume that closing the app from the recent-apps screen is harmless; on some devices, that action stops the background service.

On iOS, check whether the VPN profile is present and whether the client is allowed to establish the connection. Review Low Power Mode and network permissions when the issue began after a system update or a change in battery settings. iOS controls background behavior more tightly than desktop systems, so reconnecting after a network transition may be normal for some clients. If an application requires the VPN continuously, check whether the client offers an approved always-on or on-demand option rather than repeatedly tapping connect.

On Windows, review battery saver, sleep behavior, and whether the client is allowed to run at sign-in or in the background. A laptop that enters sleep mode will normally interrupt active network sessions. On macOS, check Login Items, background extensions, and any permission prompt that was dismissed during installation. On Linux, confirm that the desktop environment, NetworkManager integration, system service, and user session are not stopping the client when the screen locks.

Check for conflicts instead of adding more tools

Firewall software, endpoint security products, DNS filters, ad blockers, parental controls, and other proxy applications may inspect or redirect the same traffic. A conflict can look like a protocol failure even when the route is healthy. Temporarily pause one suspected tool for a controlled test, then restore it after the test. If the VPN becomes stable, create a documented exception according to the security product’s instructions instead of leaving protection disabled.

If you use TUN mode, confirm that the client has the required operating-system permission. TUN captures traffic at the network-interface level, while a system proxy affects applications that honor proxy settings. A browser may work through a local proxy while another application ignores it. Conversely, a TUN configuration may capture more traffic and expose conflicts with another virtual adapter. Choose the mode according to the applications you need to route, not merely because it is available.

Refresh the subscription and test the configuration

An imported subscription is a collection of connection configurations, not a guarantee that every entry will remain suitable. A client may store node names, server addresses, ports, protocol parameters, and authentication information locally. If the subscription has changed, the local list may contain outdated entries. A stale node can remain visible and selectable even though an updated configuration would use a different address or parameter.

Before refreshing, copy or note any custom settings that you intentionally changed. Open the subscription manager, update the subscription, and wait for the client to finish parsing the returned content. If the update fails, check whether the link is complete and whether the current network can open it. Do not publish the full link in a support request: it may contain account-related information and can expose usable configuration details.

After the update, test one ordinary route and one alternative route. Avoid judging the result from the route name alone. Two entries marked with the same region may use different servers, protocols, transport settings, or network paths. If one route disconnects while several others remain stable, the problem is more likely route-specific. If every route fails after the update, return to the local network, permissions, and protocol checks.

Use routing mode deliberately

Global mode sends most supported traffic through the selected proxy or tunnel. Rule-based mode sends traffic according to domain, address, application, or policy rules. Direct mode bypasses the connection. A mistaken rule can make it appear that the VPN is dropping when only the target application is being sent directly or when DNS is resolved through an unexpected path.

For troubleshooting, simplify the configuration temporarily. Use a basic mode, a single selected route, and the client’s standard DNS behavior if those options are available. Once the connection remains stable, restore rule groups gradually. If only one application fails, check whether it honors the system proxy, requires TUN mode, uses its own DNS, or blocks connections from the selected region. This distinction is especially important for games, desktop software, command-line tools, and corporate applications.

1. Disconnect the client and verify that the local network works.
2. Refresh the subscription or import the configuration again without exposing the full link.
3. Select one route and use the simplest supported connection mode.
4. Connect and test several ordinary websites plus the affected application.
5. Change only one variable, such as route or protocol, and compare the result.
6. Restore custom rules and security tools after identifying the stable combination.

Change the protocol and route methodically

Protocols are not interchangeable labels for the same connection. Shadowsocks is commonly used as an encrypted proxy protocol. VMess and Trojan define different proxy connection approaches, while Hysteria2 is designed around QUIC and UDP-based transport behavior. WireGuard is a VPN protocol that uses a virtual interface and cryptographic keys. A compatible client must support the selected protocol and its associated parameters; copying a configuration into an incompatible client may result in parsing errors or repeated connection failures.

Network conditions also matter. Some networks handle long-lived TCP connections more reliably, while others treat UDP traffic differently. Hysteria2 and WireGuard may depend on UDP behavior that is restricted or unstable on a particular access network. A TCP-based option may be worth testing in that situation, provided the configuration and client support it. This does not mean one protocol is universally faster or more secure. It means the transport must match the current network and the service configuration.

Change one protocol or one route at a time. If you switch the route, protocol, DNS mode, routing mode, and TUN setting together, a successful connection provides little information about which change helped. Keep a short record of the previous state. If a new protocol connects but still drops when the screen locks, the remaining cause is probably a system restriction rather than protocol compatibility.

When a route keeps dropping

A route can become unsuitable because of congestion, maintenance, changes in upstream routing, or a network policy between your device and the remote endpoint. The visible region is not the whole path. Your local carrier, the transit network, the entry server, and the destination service can all influence stability. Try a different route near the target service or a different route family offered by the same subscription.

Do not repeatedly reconnect to one failing entry for a long time. If several alternatives work, leave the failing entry out of your routine selection and report its name, protocol, platform, and approximate failure pattern to support. Share the minimum necessary diagnostic information and never include credentials or the full subscription address.

Platform-specific recovery steps

On Windows, close duplicate client windows, confirm that the correct virtual adapter is enabled, and review the Windows Firewall prompt associated with the client. If the issue began after changing networks, reconnect the Wi-Fi or Ethernet interface before reopening the VPN. Check sleep and battery settings on a laptop, and make sure another VPN or corporate tunnel is not active at the same time.

On macOS, inspect the VPN configuration under the relevant network settings and check whether a background extension or security application is blocking the client. If the client uses a system extension, approve only the request you recognize from the installed application. A browser proxy setting and a system VPN are not the same thing, so verify which one the client actually uses.

On Android, review battery optimization, unrestricted background use, auto-start, and data permissions. Turn off any manufacturer memory-cleaning rule for the client during testing. If the connection drops only when changing between Wi-Fi and mobile data, test each network separately and enable any reconnect or network-switch option that the client officially supports.

On iOS, remove and re-add a damaged VPN profile only after recording the current configuration and confirming that you can import it again. Check the client’s permission prompts, Low Power Mode, and on-demand settings. When a system update changes connection behavior, install the current official client version rather than importing an unknown profile from an untrusted source.

On Linux, confirm that the client process remains running after the desktop session changes and that NetworkManager or the relevant system service is not replacing the route. Check the TUN device and local firewall rules only if you understand how your distribution manages them. For command-line clients, review logs for authentication, DNS, handshake, timeout, and interface errors instead of treating every message as a generic disconnect.

For official client installation and subscription import, use the quick start guide. The important principle is to use a client that supports the configuration format you received. Clash Verge, sing-box, and Shadowrocket can be useful compatible clients, but their routing, DNS, TUN, and background behavior is not identical. A configuration that works in one client may need a different import method or permission in another.

Know when to reset or contact support

A reset can help when local profiles, cached rules, or damaged permissions have become inconsistent, but it should not be the first response to every drop. First record the working and failing conditions: platform, client version, network type, route, protocol, routing mode, whether the screen was locked, and whether ordinary internet access continued. Then export only safe settings if the client supports it, remove the problematic profile, and import a fresh configuration.

Contact support when the subscription update fails on several networks, every compatible client shows the same authentication error, or multiple routes disconnect while ordinary internet access remains stable. Include the exact error text and a redacted screenshot. Do not send your password, payment information, full subscription link, private key, or QR code. If the problem affects only one application, provide that application’s name and whether it uses the system proxy or requires TUN mode.

• ✅ Confirm the local network before changing VPN settings
• ✅ Allow the client to run in the background when continuous access is required
• ✅ Refresh subscriptions through the client’s normal import or update function
• ✅ Compare one route or protocol at a time
• ❌ Do not run two VPN clients simultaneously during diagnosis
• ❌ Do not share credentials, private keys, or complete subscription links

FAQ: VPN connection drops

Why does the VPN disconnect when I lock my phone?

Battery optimization, background restrictions, or a manufacturer memory cleaner may be stopping the client. Review the client’s battery and background permissions, allow background operation where appropriate, and check whether the client provides an official reconnect or on-demand option. If the issue continues only on one phone model, compare its system power-management settings with another device.

Should I reinstall the VPN client immediately?

No. Reinstalling can remove useful logs and does not fix an unstable Wi-Fi connection, an incomplete captive-portal login, a blocked protocol, or a route problem. Reinstall only after checking the local network, permissions, subscription, and client compatibility. Use the official download source and import a known-good configuration afterward.

Which protocol should I choose when connections keep dropping?

There is no universal best choice. Test a protocol supported by both the client and the configuration. If UDP-based transport is unreliable on the current network, a supported TCP-based option may be more stable. Change one setting at a time and compare stability, DNS behavior, and the applications you actually use.

Does changing routes really help?

Yes, when the problem is specific to an entry server, transit path, or destination route. A different region name does not automatically mean a better connection, so test routes methodically and consider the location of the service you need to reach. If every route fails in the same way, return to the local network, permissions, DNS, and protocol checks.