A VPN that suddenly stops working is not always a client failure. The cause may be a temporary network restriction, an expired plan, a stale subscription configuration, a blocked protocol, an overloaded route, or a permission change on the device. Reinstalling the application immediately often removes useful settings without addressing the real problem.
The fastest approach is to test one layer at a time. First confirm that the device has ordinary internet access. Then check the account and subscription, refresh the configuration, try another protocol or server, and finally inspect permissions, DNS behavior, and local software conflicts. Each result narrows the cause and prevents random changes from producing a second problem.
Check the network and account first
Before opening the VPN client, test the underlying connection. Disable the VPN temporarily and open several ordinary websites or services that you normally use. If nothing loads, the VPN is not the first problem to solve. Restart the local router only if other devices on the same network show the same failure, and compare Wi-Fi with mobile data when possible. A connection that works on one access network but not another points toward a local firewall, captive portal, DNS issue, or network policy rather than a damaged client installation.
Public Wi-Fi often requires a sign-in page before encrypted tunnels can work correctly. Open a normal browser page while disconnected and complete the network’s access procedure. Hotel, school, office, and airport networks may also restrict unfamiliar ports or long-lived connections. Do not conclude that every failed VPN attempt means the account is invalid until ordinary internet access and any captive-portal step have been verified.
Confirm the service account separately
Next, sign in to the user panel through the official website or application. The account password authenticates the panel; it is not normally a node password and should not be pasted into a third-party client as if it were a server configuration. If login fails, check for an accidental space in the username, an old saved password, or a password-manager entry from another service. If the panel itself cannot be reached, changing a proxy protocol will not fix that login problem.
Review the plan status and traffic allowance in the panel. A monthly plan resets its traffic on the activation day each month, while a traffic pack remains available until it is used and does not expire. If a payment was completed but the panel still shows the previous status, record the transaction information and contact support rather than repeatedly purchasing another plan. The panel is the authoritative place to confirm entitlement; the client may continue showing an old configuration until its subscription is refreshed.
90+
Countries covered
200+
Available routes
Unlimited
Simultaneous devices
30 days
Refund window
- ✅ Test ordinary internet access with the VPN disconnected
- ✅ Complete a captive-portal login before reconnecting
- ✅ Sign in to the panel separately from the VPN client
- ❌ Do not treat a panel password as a node or subscription password
- ❌ Do not buy another plan before checking the current account status
Refresh the subscription and client configuration
If the account is valid but the client shows no usable routes, the subscription may be missing, expired inside the client, or stored with an outdated URL. Open the client’s subscription management screen and update the subscription manually. A subscription link is configuration data: it allows a compatible client to retrieve route entries and related settings. It is not the same as a website login and is not intended to be displayed publicly.
After updating, check whether the client reports a successful refresh and whether the route list has changed. If the update fails, copy the subscription link again from the authenticated panel instead of relying on a very old local copy. Confirm that no extra spaces or line breaks were added. Some clients treat a copied newline as part of the address, which can make an otherwise valid link appear broken.
Use the right client for the configuration format
Official clients for Windows, macOS, Android, iOS, and Linux are usually the simplest starting point because the download, account, and subscription flow is presented in one environment. Compatible clients require more attention to the format they accept. Clash Verge commonly works with Clash-style profiles, sing-box uses its own JSON-based configuration model, and Shadowrocket is designed for mobile proxy profiles and subscription imports. A link that works in one client is not automatically suitable for every other client.
Do not paste a raw configuration into a field intended for a subscription URL, and do not import a Clash profile into a client that only accepts sing-box JSON. Likewise, an individual node link and a subscription link have different purposes: the former may describe one server entry, while the latter can provide a larger managed list. When importing into a third-party client, follow that client’s documented import method and confirm that the profile is enabled after the update.
If a subscription update succeeds but every route is still unavailable, inspect the profile’s expiration, selected group, and rule mode. A profile can be present without being the active profile. Some clients also separate proxy groups from individual nodes, so selecting a group without a usable member can look like a connection failure even though the subscription imported correctly.
Test the protocol and route methodically
When the client is updated and the account is active, test connection choices one at a time. Common configurations may use Shadowsocks, VMess, Trojan, Hysteria2, or WireGuard, depending on the service and compatible client. These are not interchangeable labels. A client must support the protocol, the profile must contain the required parameters, and the selected transport must be allowed by the current network.
Start with the default or recommended protocol in the official client. If it fails, try another available protocol rather than editing advanced fields without a clear reason. In a third-party client, verify that the profile has not been converted incorrectly and that fields such as server address, port, UUID, password, encryption method, TLS setting, or transport type remain consistent with the imported configuration. Manual edits can silently invalidate a working profile.
Change one route variable at a time
Choose another route in the same broad region first. A single route may be temporarily congested, under maintenance, or incompatible with the network where you are currently connected. If a nearby route fails, compare a different region or route type. Depending on the provider’s inventory, routes may use direct connectivity, BGP transit, CN2, or IEPL-style private connectivity. These labels describe network paths and are not a guarantee that one option will work best on every access network.
For general browsing, choose a route based on the destination region and stability rather than selecting a name that merely looks fast. For video or other bandwidth-sensitive services, confirm that the route is available in the required region and that the client is not forcing the traffic through an unsuitable rule group. For work systems, databases, or authentication pages, consistency may matter more than choosing the route with the shortest displayed label.
| Observed result | Likely area to inspect | Next practical test |
|---|---|---|
| No routes appear after import | Subscription URL, profile format, or active profile | Copy the link again and import it using the client’s supported format |
| One route fails but others connect | Individual route availability or temporary congestion | Switch to another route without changing the account |
| Every route fails on one Wi-Fi network | Captive portal, firewall, DNS, or network policy | Test mobile data or another trusted network |
| The tunnel connects but websites do not load | DNS, rule mode, system proxy, or application routing | Check DNS behavior and switch temporarily to a simple global mode |
| The client disconnects after sleep | Battery management, background permission, or network handoff | Reopen the client and review background and battery settings |
Inspect permissions, DNS, and local conflicts
A VPN client needs operating-system permission to create a VPN profile or tunnel. On mobile devices, accept the system VPN permission prompt and check whether the profile remains installed in network settings. If the system lists an old profile from another client, remove only the profile you recognize as obsolete and then allow the current client to create its own profile. Two applications may not be able to control the same system VPN interface at the same time.
On Windows and macOS, security software, endpoint management tools, or a manually configured proxy can interfere with the client. Check whether a corporate firewall, antivirus web filter, or system proxy was enabled recently. On Linux, inspect the desktop network manager and any service that may be applying a separate proxy or tunnel. The goal is not to disable security controls permanently; it is to identify whether a local control is blocking the connection, then create an approved exception or restore the correct setting.
Understand a connected tunnel versus working traffic
A client can report “connected” while a particular application still fails. Rule-based clients may send only selected domains through the proxy, while local services, private addresses, or an application with its own proxy settings may bypass it. Temporarily switch to a simple global mode for diagnosis, then test a normal website and the target application separately. If global mode works but rule mode does not, the route is probably usable and the problem is more likely to be a rule, domain match, DNS request, or application-specific setting.
DNS deserves special attention. If domain names fail but a service behaves differently when opened through another resolver, the tunnel may be established while DNS requests are being sent through an unsuitable path. Review the client’s DNS mode and the operating system’s DNS configuration. Avoid stacking several DNS-changing applications, browser extensions, and security filters during testing because each can make the result harder to interpret.
- ✅ Allow the operating system to create the VPN profile
- ✅ Close or pause another VPN and proxy client during the test
- ✅ Compare global mode with rule-based mode
- ✅ Check whether a browser or application has its own proxy setting
- ❌ Do not permanently disable antivirus or firewall protection as a first fix
- ❌ Do not run several tunnel clients at the same time
Recover safely and know when to ask for help
Once the basic checks are complete, restart the client and reconnect. If the operating system recently changed networks, waking the device or switching between Wi-Fi and mobile data can leave a stale tunnel state. Sign out and sign in again only after confirming that your username and password are saved securely. Then refresh the subscription, select a known route, and test with one ordinary website before opening several applications.
Reinstalling should be a later step, not the default response. Before removing the client, record the operating system version, client name and version, profile type, protocol, selected route, and the exact error message. Export a configuration only when the client provides a safe, supported export function, and treat subscription links as sensitive account material. After reinstalling, install the client from the official source, grant the requested system permission, import the correct subscription format, and test the default configuration before adding advanced rules.
When contacting support, provide useful diagnostic context without exposing passwords, private keys, or a complete subscription link in a public channel. State whether ordinary internet access works, whether panel login succeeds, whether the subscription refresh completes, whether all routes fail or only one, whether another network changes the result, and which device and client are involved. A short timeline is more useful than saying only “VPN not working.” If the issue began after a system update, network change, or plan change, include that fact as well.
Use this final sequence as a compact recovery checklist:
- Disconnect the VPN and verify ordinary internet access.
- Complete any captive-portal or network sign-in page.
- Confirm that the service panel accepts the account credentials.
- Check the current plan and traffic status.
- Refresh the subscription from the authenticated panel.
- Confirm that the imported profile is active and compatible with the client.
- Try the default protocol and then another supported protocol if available.
- Switch to another route, changing only one selection at a time.
- Check system permissions, DNS, rule mode, and competing proxy software.
- Collect the error details before reinstalling or contacting support.