A VPN that keeps disconnecting is rarely caused by one single setting. The failure may come from an unstable Wi-Fi link, a mobile network changing underneath the tunnel, a battery saver stopping the client, a protocol that does not match the current network, a damaged local configuration, or a server route that is temporarily unsuitable for your location. Reinstalling the app immediately can remove useful evidence, so troubleshooting works best when you first identify when and how the connection fails.
Start by separating three different symptoms. A client that shows “disconnected” has lost the tunnel itself. A client that says “connected” while websites do not load may have a DNS, routing, or local firewall problem. A connection that works for browsing but stops during downloads or video playback may be suffering from packet loss, idle timeouts, or a network transition. These cases need different fixes, and switching servers repeatedly without observing the pattern can make the diagnosis harder.
Identify the disconnection pattern before changing settings
Before making changes, use the same device and the same application for a short controlled check. Connect to one nearby server, open a normal webpage, and keep a lightweight activity running. Then observe what happens when you lock the screen, move between rooms, disable Wi-Fi, or switch to another application. You are not trying to produce a permanent performance rating. You are trying to establish whether the failure follows the network, the device state, the protocol, or the selected route.
5
Common fault areas
4
Main protocol examples
90+
Countries covered
200+
Available routes
The five practical fault areas are the local network, device power management, protocol and transport compatibility, client configuration, and server-side route selection. A route can be perfectly usable for one carrier or destination but unsuitable for another. That does not necessarily mean the entire service is unavailable. Similarly, a client can import a subscription successfully while still having an incorrect system permission, DNS mode, or rule configuration.
- ✅ Confirm whether the VPN icon disappears or remains visible when traffic stops.
- ✅ Test once on Wi-Fi and once on mobile data before changing several settings.
- ✅ Note whether the problem begins after screen lock, application switching, or network roaming.
- ✅ Try one nearby route and one alternative route, then compare stability rather than only peak speed.
- ❌ Do not run two VPN clients or two system-level tunnels at the same time.
- ❌ Do not judge every server from a single failed connection attempt.
On Windows and macOS, also check whether the operating system reports a changed network adapter or a captive portal. On Android and iOS, check whether the system VPN permission is still active. On Linux, inspect the active network manager and confirm that another WireGuard, OpenVPN, or proxy service has not taken control of the route. If you use a third-party client such as Clash Verge, sing-box, or Shadowrocket, verify that the imported profile is selected and enabled; importing a subscription does not always mean that traffic is already using it.
Fix local network, Wi-Fi, and DNS problems
A VPN depends on the connection underneath it. If the Wi-Fi access point is losing packets, the router is changing channels, or the mobile carrier is moving the device between network states, the encrypted tunnel may time out even though ordinary browsing appears to recover quickly. Restart the local connection before rebuilding the VPN profile: turn Wi-Fi off and on, reconnect to the network, or briefly switch between Wi-Fi and mobile data. This simple test tells you whether the failure belongs to one access network.
Public Wi-Fi requires an additional step. Many hotels, campuses, cafés, and transport networks use a captive portal that must be accepted before unrestricted traffic is allowed. Disconnect the VPN, open a regular browser page, complete the network sign-in, and then reconnect. If the VPN is started before the portal is completed, the client may repeatedly retry a tunnel that the access point is not yet permitting.
Router features can also interfere with certain transports. Temporarily test without aggressive firewall filtering, traffic inspection, or parental-control rules. Do not permanently weaken network security just to make a connection work; the purpose of the test is to identify whether the router is modifying or blocking the traffic. If the VPN works on mobile data but not on home Wi-Fi, review the router rather than repeatedly reinstalling the client.
DNS problems often look like a disconnection. The tunnel may remain established while domain names fail to resolve, producing blank pages or applications that report no internet access. Compare a known working domain with another destination, and check whether numeric network access behaves differently from normal domain access. In the client, test its built-in DNS mode against the system DNS mode. If your configuration uses a custom DNS server, remove that custom value temporarily and retest.
Proxy settings are another common source of confusion. A system proxy, browser proxy, VPN tunnel, and third-party proxy client can all coexist, but their routing responsibilities must be clear. On Windows and macOS, inspect the system proxy panel. In browsers, check whether an extension is forcing a separate proxy. In Clash Verge or sing-box, make sure only the intended mixed, HTTP, SOCKS, or TUN mode is active. In Shadowrocket, confirm that the selected global, configuration, or rule mode matches your purpose.
| Observation | Likely area | First action |
|---|---|---|
| Works on mobile data but drops on one Wi-Fi network | Router, captive portal, or local filtering | Complete portal login and test router settings |
| Client says connected but websites cannot resolve | DNS or proxy conflict | Test another DNS mode and disable duplicate proxies |
| Every route fails after a network change | Stale tunnel or operating system route | Disconnect fully, reconnect the network, and start one client |
| Only one application fails | Per-app rule, application policy, or app cache | Review split tunneling and application-specific settings |
Prevent battery and background disconnects
Mobile operating systems are designed to limit background activity. A VPN client that is allowed to run while visible may be suspended after the screen is locked, especially when battery saver, adaptive battery, or a manufacturer-specific sleep policy is enabled. The result can look like a random network failure: the tunnel works while you are using the phone, then disappears while a transfer or notification is waiting in the background.
On Android, open the application battery settings and select the least restrictive option available for the VPN client. The exact wording varies by manufacturer, so look for entries such as unrestricted background use, no battery optimization, autostart, background activity, or protected applications. Also review the system’s memory-cleaning feature. Some phone vendors provide a separate task manager that closes apps even after ordinary battery optimization has been disabled.
On iOS, check that the VPN profile is present and that the client has permission to establish a VPN connection. If the client offers an automatic connection or on-demand option, enable it only after confirming that the basic manual connection works. Automatic reconnection can help with network changes, but an incorrect on-demand rule can also trigger repeated connection attempts. If necessary, remove the VPN profile from the client and add it again through the application rather than creating several duplicate profiles.
Desktop systems have similar issues in a different form. Windows may change between Ethernet and Wi-Fi adapters, while macOS can reorder network services after an update or new adapter installation. Linux users may have NetworkManager, systemd-resolved, a WireGuard service, and a third-party proxy process active at the same time. Check which process owns the tunnel and stop unused services before testing. A single clean connection is easier to diagnose than several overlapping network managers.
Keep automatic reconnection enabled when the client implements it correctly, but do not treat it as a replacement for stable configuration. Reconnection may fail if the subscription contains an expired endpoint, if the selected server is overloaded, or if the operating system blocks background execution. After changing battery permissions, force-stop the client once, reopen it, and establish a fresh tunnel. Then test the exact activity that previously failed, such as screen lock, a long transfer, or switching from Wi-Fi to mobile data.
- ✅ Exempt the official client from restrictive battery optimization on Android.
- ✅ Permit background activity and autostart where the device manufacturer requires it.
- ✅ Use one active tunnel and remove obsolete profiles that are no longer needed.
- ✅ Reconnect after changing power-management settings so the new permission is applied.
- ❌ Do not assume that a visible VPN icon proves the tunnel will survive screen lock.
- ❌ Do not enable several auto-connect rules in different clients at once.
Test protocols and client compatibility methodically
Protocol choice matters because networks do not treat every type of traffic in the same way. Common options include WireGuard, OpenVPN, Shadowsocks, VMess, Trojan, and Hysteria2, but their availability and behavior depend on the subscription and the client. A protocol name shown in a configuration file is not enough: the application must correctly support the protocol, transport, authentication fields, DNS behavior, and routing rules used by that profile.
Start with the official Windows, macOS, Android, iOS, or Linux client when one is available. Official clients usually expose fewer variables and make it easier to confirm whether the account and subscription are valid. If the official client remains stable while a third-party client disconnects, investigate the third-party profile, core version, TUN permission, and rule mode instead of changing the account immediately.
For third-party clients, import the subscription link again only when you have confirmed that the link is current and the import actually succeeded. Select a single profile, save the configuration, and reconnect. In Clash Verge, confirm the active configuration and whether the system proxy or TUN mode is enabled. In sing-box, check that the selected outbound and route rules point to the intended server. In Shadowrocket, verify that the configuration is selected and that the global or rule-based mode is not sending the application into a direct route unexpectedly.
Test protocols one at a time. Connect with the default option first, record whether it remains connected during ordinary use, then disconnect fully before trying another option. Avoid changing the protocol, DNS mode, server, and routing mode simultaneously because you will not know which change helped. If one protocol works on home Wi-Fi but another works on mobile data, keep the profiles separate and choose based on the network environment rather than assuming one option is universally better.
WireGuard can provide a lightweight tunnel when the client and network support it correctly. OpenVPN may offer broader compatibility but can require more client-side parameters. Shadowsocks is commonly used as a proxy rather than a full system VPN, depending on the client mode. VMess, Trojan, and Hysteria2 profiles may include transport-specific fields that a generic importer cannot interpret perfectly. Never copy fields from one protocol into another or manually remove transport options simply because the configuration looks complicated.
Choose a better route and refresh the subscription
Once local network and client issues have been checked, test route selection. A nearby server is often a sensible starting point because it may reduce unnecessary distance, but geographic proximity alone does not guarantee the best result. The route between your carrier, the service entrance, the relay, and the destination can vary. Some subscriptions distinguish between direct routes, relay routes, IEPL routes, BGP routes, and CN2-related routes. These labels describe network paths, not a promise that one category will always be better for every user.
Change one route at a time and allow the client to establish a clean connection. Compare stability during your normal task: browsing, a work application, a video service, or a file transfer. If one destination fails while ordinary sites continue to work, the issue may be destination-specific routing rather than a total VPN outage. If every destination fails on one server but works on another, stop using that server temporarily and report the pattern to support.
Refresh the subscription when the client has an old server list, an expired endpoint, or a profile that no longer reflects the available routes. Before updating, save any custom rules you need. After updating, confirm that the new profile is selected and remove duplicate entries if the client has created several copies. A subscription update should be performed through the service’s normal account or client workflow; do not use an unknown converter simply to change the configuration format.
QhVPN lists coverage across 90+ countries and 200+ routes, but that breadth should be treated as a choice of testing options, not as proof that every route fits every network. If a connection is unstable, try an alternative country or route type, then document the device, operating system, client, protocol, network type, and approximate time of failure. This gives support information that can be acted on instead of a message that only says “the VPN is slow.”
- Disconnect the current server completely and wait for the client to show an inactive state.
- Choose one alternative route that is clearly identified in the subscription.
- Reconnect with the same protocol and DNS mode used in the previous test.
- Repeat the activity that exposed the problem, including screen lock or network switching if relevant.
- Only after the result is clear, test a different protocol or route category.
- Refresh the subscription if the server list is incomplete, outdated, or missing expected entries.
If you need a step-by-step review of installation, subscription import, and connection verification, use the user guide. For persistent failures involving several devices or networks, the troubleshooting manual can help organize the checks before contacting support.
Know when to contact support
Contact support after you have completed a controlled comparison, not after trying every setting at random. Include the operating system, official or third-party client name, protocol, selected route, network type, and the exact symptom. State whether the client reports disconnected, connected without traffic, or repeatedly reconnecting. Also mention whether another route or another network works. Avoid sending passwords, private keys, or the complete subscription URL in a public ticket.
A useful support request is concise but reproducible: “On Android over home Wi-Fi, the WireGuard profile disconnects after screen lock; mobile data remains connected; a second route shows the same behavior.” That description gives support a direction. If the issue is account-specific, they can check the subscription or service status. If it is route-specific, they can recommend a suitable alternative. If it is client-specific, they can tell you whether to use the official application or a compatible third-party client.
Also check account status and traffic limits before concluding that the service is malfunctioning. A monthly subscription includes traffic that resets monthly from the activation date, while a traffic package is used until it runs out and does not expire. If an account has reached its applicable limit or the subscription has not renewed as expected, connection attempts may not behave like a normal network failure. Keep the order information available when asking for help.
For users who want to test across several devices, QhVPN supports Windows, macOS, iOS, Android, and Linux, with no fixed limit on the number of simultaneously online devices according to the service information. That does not mean every device should run several clients at once. Install one compatible client per device, import the subscription through the supported method, and keep the test environment simple.
Frequently asked questions
Why does my VPN disconnect when I lock my phone?
The phone may be stopping the client as part of battery optimization, background limits, or a manufacturer task cleaner. Exempt the VPN client from restrictive battery controls, allow background activity and autostart where available, then reopen the client and test again. If the issue continues, check whether the VPN profile and automatic reconnection permission are still active.
The client says connected, but websites do not load. What should I check?
Start with DNS and proxy conflicts. Test the client’s built-in DNS mode, disable duplicate browser or system proxies, and verify that the selected rule mode is not sending all traffic to an unavailable direct route. Completing a captive-portal login before connecting can also resolve the problem on public Wi-Fi.
Should I change the protocol whenever the VPN drops?
Change it methodically rather than immediately. First confirm that the local network and client permissions are correct, then disconnect fully and test one alternative protocol while keeping the route and DNS mode unchanged. WireGuard, OpenVPN, Shadowsocks, VMess, Trojan, and Hysteria2 may require different client support and transport parameters, so use a compatible profile instead of manually mixing settings.
When should I stop troubleshooting and contact support?
Contact support when the same failure occurs across clean reconnects, multiple routes, or more than one network, or when the subscription cannot be refreshed correctly. Provide the device, client, protocol, route, network type, and failure pattern. This is more useful than repeatedly reinstalling the application or reporting only that the connection is unstable.
A stable VPN connection is usually the result of a compatible route, a correctly imported profile, a permitted background client, and a local network that is not blocking or rewriting the traffic. Work through those layers in order: observe the pattern, verify the local network and DNS, remove battery restrictions, test protocols carefully, refresh the subscription when necessary, and then send structured evidence to support. This process avoids unnecessary configuration changes and makes it much easier to determine whether the problem is on the device, the network, the client, or the selected route.