A VPN that keeps disconnecting is not always suffering from a bad server. The interruption may begin when a laptop wakes from sleep, when a phone changes from Wi-Fi to mobile data, when the local network blocks a transport method, or when the client loses permission to maintain its tunnel in the background. A subscription can also be valid while one particular node, protocol, or routing mode is unsuitable for the current network.
The fastest way to find the cause is to change one variable at a time. Confirm whether the problem affects one application or the whole device, check the local connection, test another node, review the protocol, and then inspect permissions, DNS, sleep behavior, and client logs. This order prevents a common mistake: repeatedly switching providers before establishing whether the failure is caused by the device, network, client, route, or destination service.
90+
Countries covered
200+
Available routes
Unlimited
Simultaneous devices
5
Supported platforms
Identify the disconnect pattern first
Before changing settings, record when the connection drops. A repeatable pattern is more useful than a general impression such as “the VPN is unstable.” If the VPN disconnects immediately after connecting, the problem is likely related to authentication, the selected node, the protocol handshake, or interference from another network tool. If it works for a while and then drops, inspect sleep settings, background restrictions, idle timeouts, packet loss, and route congestion.
A disconnect that occurs only when the device changes networks has a different explanation. Moving from home Wi-Fi to mobile data, joining public Wi-Fi, enabling a hotspot, or returning from airplane mode can invalidate the old interface and leave the client trying to use an address that no longer exists. Some clients reconnect automatically; others need the tunnel to be stopped and started again.
Also distinguish a real VPN disconnect from an application failure. A browser may show a timeout while the tunnel remains active. A streaming application may reject a route without the route itself being offline. Conversely, an IP check may still load from a cached browser session even though a new application request is going directly through the local network. Test in the same application that reports the problem, then confirm the public exit with the IP Check page.
- ✅ Note whether every application disconnects or only one application.
- ✅ Check whether the event follows sleep, network switching, or a change of route.
- ✅ Compare the client status with a fresh request in the affected application.
- ❌ Do not judge stability from one successful connection or one failed website request.
- ❌ Do not change the protocol, DNS, routing mode, and operating-system settings at the same time.
Common symptoms and their meaning
An immediate failure after pressing Connect often points to an invalid configuration, an unavailable endpoint, an incorrect system time, or a protocol that the current network cannot pass. A connection that drops during browsing may indicate packet loss, a route change, or a client conflict. A connection that survives normal browsing but fails during downloads, calls, or long sessions may be affected by UDP handling, idle behavior, power management, or a network device that removes long-lived connections.
Repeated login prompts can also be mistaken for disconnections. If the client remains connected but the account session expires, the visible symptom may be that websites stop responding or ask for authentication again. Record the time, selected route, protocol, device platform, and local network before attempting a fix. This gives support a useful technical description instead of an unverified claim that the entire service is offline.
Check the local network and client state
Start with the simplest comparison: stop the VPN and verify that the underlying network can open ordinary websites. If the connection is already unstable without the VPN, changing nodes will not solve the root cause. Restart the router or reconnect to the current Wi-Fi only after confirming that other devices show the same behavior. On mobile data, check whether the issue follows a change in reception, a hotspot, or a carrier network transition.
Next, close other proxy and tunnel tools. Clash Verge, sing-box, Shadowrocket, browser proxy extensions, corporate security agents, and system-wide VPN clients can compete for the same proxy port, routing table, DNS setting, or virtual network interface. Running two tools at once may produce a connection that appears to work for one application while another application is sent through a different path.
Review the client’s current state rather than assuming the displayed node is active. Confirm that the subscription was imported successfully, the profile has not expired or been overwritten, and the selected node still appears in the latest configuration. A subscription link contains access information and should be treated like a credential; do not paste it into public forums or support requests unless the service specifically provides a safe process for doing so.
For compatible clients, an official application may be the best baseline because it reduces the number of manual parameters. On Windows, macOS, Android, iOS, and Linux, update the client through a trusted source, reconnect after importing the current subscription, and avoid importing the same profile into several competing applications during the test. If you use Clash Verge, sing-box, or Shadowrocket, confirm that the imported format matches the client and that the active profile is the one being edited.
Test nodes, protocols, and routing modes
A node is a connection profile, not a guarantee of a particular experience. Two profiles with similar country names may use different entry points, route types, congestion levels, or protocol parameters. A direct route, a relayed route, an IEPL private line, or a CN2-related route can behave differently on the same local network. The label helps describe the intended path, but it does not replace a controlled comparison.
Switch to another node in the same broad region first. This helps determine whether the problem follows the original endpoint. If every node fails on one network but works elsewhere, inspect the local network or protocol. If only one node fails while other routes remain connected, keep the original profile details for support and use a different route temporarily.
Protocol choice matters because protocols differ in transport, encryption, handshake behavior, and tolerance of packet loss. Common proxy and tunnel choices include Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC, and WireGuard. A protocol that performs well on a home connection may be less reliable on restricted public Wi-Fi, while a protocol designed for a different transport may lose connectivity when the network filters or mishandles UDP.
Do not interpret a protocol name as a speed ranking. The practical question is whether the protocol can complete its handshake and maintain traffic on the current network. If a client offers several protocol types, compare them without changing the node region at the same time. When using a manually imported profile, check that the server address, port, transport, security parameters, and server name are parsed correctly. A single missing parameter can look like random instability.
Routing mode introduces another layer. Rule mode sends selected traffic through the proxy and leaves other traffic direct. Global mode sends a wider range of traffic through the selected route and is useful for isolating whether an application is bypassing the proxy. TUN mode captures traffic at a lower system level, but it may interact with firewall software, endpoint security, virtual adapters, or other network tools. System proxy mode is lighter, yet applications that ignore system proxy settings may remain outside the tunnel.
| Test result | Likely area | Next action |
|---|---|---|
| Only one node disconnects | Endpoint or route profile | Compare another node and save the original details for support |
| All nodes fail on one Wi-Fi network | Local firewall, DNS, filtering, or transport handling | Test another network and compare protocols |
| Browser works but another app fails | Proxy coverage or application compatibility | Check system proxy, TUN mode, and the application’s own proxy settings |
| Disconnect follows sleep or screen lock | Power management or background restrictions | Review battery, startup, and background permissions |
| IP changes during one session | Reconnect loop or route switching | Disable automatic switching temporarily and test one stable profile |
A controlled reconnection test
- Disconnect the VPN and close other proxy tools.
- Refresh the subscription or confirm that the current profile is valid.
- Select one node and connect with the default protocol.
- Open the affected application and confirm the public exit with an IP check.
- Keep the same node while changing only the routing mode.
- Repeat on another network if the first result is inconclusive.
The purpose of this sequence is not to create a permanent “best setting.” It narrows the fault domain. If rule mode fails but global mode works, the route may be healthy and the problem may be a missing domain rule or an application that does not use the expected proxy. If global mode also fails, return to the node, protocol, local firewall, and network checks.
Fix sleep, network switching, and background drops
Laptops and mobile devices often suspend network interfaces to save power. When the device wakes, the client may still display a connected status while its tunnel is attached to the old interface. Stop and reconnect the VPN after waking if automatic recovery is unreliable. On desktop systems, allow the client to start with the operating system when appropriate, but avoid running several clients automatically at startup.
On Android and iOS, inspect battery optimization, background activity, low-power modes, and always-on VPN settings. A battery manager may suspend the client while the screen is off. A system setting may also block background data or terminate an application that has not been opened recently. The exact names vary by manufacturer and operating-system version, so look for the client under battery, mobile data, background refresh, and VPN settings.
On Windows and macOS, check whether sleep, network adapter power management, firewall prompts, or security software coincides with the disconnect. A virtual adapter used by TUN mode may be disabled or reinitialized after a network change. Reopening the client and reconnecting is a useful short-term test; if it restores service every time, focus on power and interface recovery rather than replacing the node immediately.
When moving between Wi-Fi and mobile data, wait for the new network to obtain a working address before reconnecting. Rapidly toggling interfaces can create several partial sessions. Disable automatic node switching while diagnosing, because a client that changes profiles after a failed handshake can hide the original cause and make the public exit appear inconsistent.
- ✅ Allow the client to run in the background when stable mobile use is required.
- ✅ Reconnect after waking, changing networks, or enabling a hotspot.
- ✅ Keep one preferred profile while testing automatic switching.
- ❌ Do not grant unrelated applications broad permissions simply to keep a VPN alive.
- ❌ Do not assume a connected icon proves that every application is using the tunnel.
Check DNS, firewall rules, and application coverage
DNS problems can look like tunnel failures. The VPN may be connected, but domain lookups can time out, use an unreachable resolver, or continue through the local network when the client is expected to handle them. Compare a domain-based request with a direct IP check, and review whether the client offers remote DNS, encrypted DNS, or a DNS hijack protection option. Change one DNS setting at a time and restore the previous value if the result becomes worse.
A DNS leak is not identical to a VPN disconnect. In a leak, the request may resolve through an unexpected resolver while the encrypted tunnel remains active. This mismatch can cause regional inconsistency, slow page opening, or failures in applications that use their own resolver. Browser secure-DNS settings, operating-system DNS, router settings, and TUN mode can all affect the result.
Firewalls and endpoint security products may block a virtual adapter, a local proxy port, or a background reconnect request. Look for a recent permission prompt or security-policy change. Instead of disabling protection permanently, create a narrowly scoped allow rule according to the software’s documentation, then test again. Corporate or school networks may also impose policies that users cannot change; in that situation, ask the network administrator or use an approved connection method.
Application coverage is another frequent source of confusion. A browser may honor the system proxy while a terminal, game, updater, or desktop application connects directly. Conversely, TUN mode may capture more traffic than expected and expose a conflict with local services. Start with the client’s default mode, verify the affected application, and then add rules for specific domains or applications. The usage tutorial can help you review subscription import and basic client setup.
Know when to refresh the subscription or contact support
Refresh the subscription when route profiles disappear, a client reports parsing errors, or several previously available endpoints stop appearing after a configuration update. Import the updated link through the client’s subscription manager rather than editing every node manually. Manual edits can be useful for advanced users, but they make it harder to distinguish a service-side change from a local configuration mistake.
Contact support after collecting reproducible information. Include the platform, client name and version, selected node label, protocol, routing mode, local network type, approximate failure time, and whether another network changed the result. Describe the exact symptom: handshake failure, connected status with no traffic, application-only timeout, DNS resolution error, or disconnect after sleep. Do not include your password or an exposed subscription link.
A provider cannot diagnose “unstable” precisely without a comparison. If one node fails while another remains stable, report both profiles. If all routes fail only on one Wi-Fi network, mention that scope. If the issue began after a client update, say so. This information helps separate a route maintenance event from a client regression or a local firewall rule.
Switching providers becomes reasonable when the same reproducible issue persists across supported clients, multiple networks, refreshed profiles, and different route types, and when support cannot explain the limitation or provide a workable path. Before changing, export only safe settings, remove old virtual adapters when appropriate, and avoid leaving two VPN clients configured to start automatically.
Frequently asked questions
Why does my VPN disconnect after sleep?
Sleep can suspend the network interface and background process that maintains the tunnel. Check battery and background permissions, then reconnect after wake. If the problem repeats, compare system proxy mode with TUN mode and check whether security software resets the virtual adapter.
Why does only one application lose the connection?
The application may ignore the system proxy, use its own DNS resolver, or be excluded by a rule. Test global mode briefly, inspect the application’s proxy settings, and then create a narrow rule rather than routing every device request through the VPN permanently.
Should I change the protocol immediately?
Change it only after confirming that the subscription and selected node are valid. Then compare one alternative protocol while keeping the node, network, and routing mode unchanged. This makes the result meaningful and avoids confusing a protocol issue with an endpoint issue.
When should I consider another VPN provider?
Consider changing only after controlled tests show that the problem is not limited to one device, one network, one client, one route, or one protocol. Persistent failures accompanied by unclear plan rules or ineffective support are stronger reasons to reassess than a single temporary disconnect.