Start with the basics: identify where the problem occurs
Describe the symptoms before reinstalling the client
“It doesn't work” could mean the client won't start, the subscription list is empty, a route handshake fails, or the client says it's connected but pages won't load in your browser. These symptoms point to different areas: the software on your device, subscription retrieval, network transport, or traffic routing. Note the client's current status, the affected websites or apps, the route you're using, and whether the issue happens all the time or only at certain times. Don't clear settings, switch routes, and change system network settings all at once. Changing several things together makes it impossible to tell what actually fixed the issue.
First, disconnect from VPNUL and try opening a website you can normally access. If it still won't load, check your current network: does your browser show a network sign-in page? Can other apps load content? Does switching to another available network fix the issue? Reimporting your subscription repeatedly won't usually help if basic access is already broken. Once your local network is working again, test the client. If everything works normally without VPNUL but fails when you connect, keep the network unchanged and check the route, proxy mode, and DNS.
Narrow down the cause with side-by-side tests
On the same device and network, switch to a route in a different region and visit the same destination. Then, on the same route, try a different website. The first comparison helps show whether the issue is limited to one route; the second checks whether it affects only a particular service. If several destinations fail, check the client's connection status and whether it is routing system traffic. If only one app fails, go straight to the app routing section. You don't need speed test scores or complicated logs for these checks—the key is to keep everything else the same.
Distinguish between “it used to work but stopped” and “it has never connected successfully.” For the first, think about whether you recently updated the client, changed proxy mode, switched networks, or enabled another network tool. For the second, check whether the subscription imported correctly and whether the selected client profile belongs to your current account. If the same issue occurs on multiple devices, check the subscription and route first; if only one device is affected, check its permissions, system proxy, and background restrictions. These are troubleshooting priorities, not assumptions about the cause.
When checking your account, rely on the plan status and data allowance shown in the dashboard. VPNUL monthly plan data resets each month on your activation date. Data packs don't expire and remain available until used. VPNUL covers 110+ countries with 220+ routes, but those numbers don't replace testing individual routes on your current network. For route types and regions, see the servers page. To review the import steps, see the subscription link beginner's guide. Start with the section below that matches your issue; it's usually faster than changing settings at random.
Can't connect at all: check your local network, then the route handshake
Find where the connection fails
After you tap Connect, check whether the client gives a clear message. “No configuration found” and “Connection timed out” are different issues: the first may mean there are no subscription entries available in the client; the second means it tried to reach a route but couldn't connect. If the list is empty, don't keep switching regions—go to the subscription update section. If routes are listed but the client stays on “Connecting,” first confirm that your device can access regular websites. Then check whether the client reports missing permissions, a network conflict, or a connection component that isn't running. Copy the exact error message; don't guess at the cause based on its color or appearance.
Once you've confirmed your basic network is working, disconnect and try another route in the client. Choose one in a different region and, if possible, a different type from the original. This avoids repeatedly picking entries with similar names that may use the same path. If one route connects and another doesn't, you can use the working route for now and note the failed route's name for support. If every route fails at the same stage, check whether the client has the network permissions it needs and whether another tool is managing the system proxy or virtual network interface. When multiple tools compete to route traffic, switching routes alone may not make a difference.
Check that the settings are actually taking effect
Some clients separate selecting a route from starting the connection. A selection indicator in the list doesn't mean system traffic is already using that route. Check the main screen for a clear status such as Connecting, Connected, or an error. In your system network settings, confirm that the required connection permissions haven't been revoked. If your system asks for permission to create a network connection the first time you use the client, grant it after confirming the request came from the client you're using. Testing websites before confirming the permission was granted can make a permissions issue look like a route problem.
If you still can't connect, test on another network that you know can access websites normally. If the same device and subscription work on one network but not another, note the network type and the stage where the connection fails. Check whether the affected network requires you to sign in through a web page first. Don't assume that connecting on another network means your account has been restored—it only shows that the issue is related to the original network. If the same error occurs on different networks, check whether the subscription is up to date and the plan status in your dashboard is normal.
To narrow things down further, note the current configuration name in the client, refresh the subscription, and try a route you haven't used before. Don't treat example addresses as real subscription links, and never post your full subscription link publicly. Get your actual subscription details from the user dashboard. If you still can't connect, use the support checklist at the end of this page to share the error, route name, and comparison test results. This helps support distinguish between a configuration import issue, a connection failure, and local traffic routing problems without asking you to repeat every step.
Connected, but websites won't load: check traffic routing and DNS
Test DNS resolution and page loading separately
A Connected status means the client believes it has established a connection; it doesn't confirm that your browser traffic is reaching the website. First open a website you can normally access, then try the site that's having trouble. If both fail, check whether the client is routing your browser traffic in global or rule mode, and whether the system proxy status matches what the client shows. If regular websites load but one destination doesn't, check that the address is correct and try another route. If the browser says it can't resolve the name, focus on DNS. If it times out, check the route and whether the destination is responding.
DNS translates domain names into addresses your device can connect to. The client, operating system, and browser may each have their own DNS settings, so a connected route and working domain resolution don't always go together. First turn off any custom DNS options in your browser. Then check the client instructions to see whether the current proxy mode handles DNS. If you set a custom system DNS before, note its current value, restore the system default, and test again. Change one setting at a time, then reload the affected page and check whether the error changes. Don't copy generic DNS settings from an unknown source; they could introduce another problem.
Use repeatable checks instead of guessing
On a device with command-line tools, you can look up a domain used specifically for this example and check whether your system returns a result. The command below doesn't test VPNUL route performance; it only checks whether your current environment can perform a standard DNS lookup. If the command isn't available, use the browser error and client logs instead.
nslookup example.comA successful DNS lookup doesn't rule out every DNS-related issue: your browser may use a different resolution path from the system, or have cached an earlier failure. Try another site in the same browser, then compare with a different browser. Don't clear all network settings before recording your current setup. If only one browser fails, check its proxy extensions, custom DNS settings, and cache. If all browsers fail when the connection is on but work as soon as you disconnect, go back to the client and check its traffic routing mode and route status.
If a page frame or images load but the content or video doesn't, the issue may be with the destination site's sign-in state, regional policies, or resource requests—not a complete route failure. Try different destinations on the same route, then try the original destination on another route. This helps show whether the failure follows the destination or the route. Don't change your account details or reinstall the client based on a single error on one page. For specific video services, see the streaming access guide and follow the notes for the route you're using.
Finally, check that your device date and time are set correctly. Incorrect device time can cause encrypted connections to fail, even when the error looks like a general network problem. If your browser explicitly warns about a certificate, don't bypass the warning to open the page; first check the device time and destination address. If you're unsure what's causing the issue, record whether you saw a DNS error, a timeout, or a certificate warning. A specific error type is more useful than “connected but nothing loads.”
Slow speeds and peak-hour lag: distinguish route congestion from app load
First, identify what's slow
A slow first page load, slow file transfer, and frequent video buffering can all feel like “slow internet,” but they can have different causes. First check whether your basic connection is already slow with VPNUL off. Then, on the same network and device, compare different routes against the same destination. Avoid running large downloads or sync tasks during the test, as background traffic can hide differences between routes. Record what you observe: which route reliably loads the destination, or whether only a particular app slows down. Don't treat one speed test as a measure of performance throughout the day.
Peak-hour lag needs a closer look at whether the issue is tied to the time or the destination. If things work well during the day but slow down at a regular busy time—and switching routes helps—try using the route that performs more consistently. If the same service is slow on different routes but other destinations work, check whether the service itself is responding slowly. If regular local websites are slow too, check for congestion on your network and background tasks on your device. VPNUL covers 110+ countries with 220+ routes, giving you options to compare; that doesn't mean every route will have the same speed at every time or for every destination.
Choose a route based on distance and destination region
Routes in a closer region are often worth trying first, but physical distance isn't the only factor. Your experience also depends on your local connection, the route path, where the destination is hosted, and whether it serves different content by region. For interactive websites or calls, check whether pages open and respond consistently. For streaming, see whether buffering keeps happening. Don't judge a route only by the region in its name. Use the routes page to compare regions and route types, then test them one by one on your current network.
| What you're seeing | Compare first | Next step |
|---|---|---|
| All websites are slow | Basic access with and without the connection | Check your network and background tasks |
| Only one destination is slow | The same destination on different routes | Check the destination region and service status |
| Lag only during busy hours | Route performance on the same device at different times | Keep the stable route and note when the issue occurs |
| Only video playback buffers | Compare page loads with continuous playback | Check app settings and route notes |
If your client has an automatic route selection feature, keep a manually tested route for comparison. Automatic selection may optimize for one metric without being the best choice for your current destination. If automatic and manual modes behave differently, note the route name for each—not just that “automatic is slower.” Repeatedly switching routes while testing the same destination may also cause the website to start a new session. After each switch, wait for the page to reload before comparing the results.
Check your plan's data status too. Monthly plan data resets each month on your activation date, and the price difference for a mid-cycle upgrade is converted into the remaining days. Data packs don't expire and remain available until used. If your dashboard shows a different allowance than expected, check the billing details on the plans page, then verify your account status in the dashboard. Don't assume every data limit notice is a route issue, and don't try to calculate a reset date that isn't shown in your dashboard. If you're unsure, submit a screenshot of the notice and the plan name.
Frequent disconnects and mobile background drops: note when the connection drops
Find out whether the connection ended on its own or the system interrupted it
For frequent disconnects, start by noting when they happen: while browsing, when switching networks, or only after the screen turns off or the app goes into the background. Each points to a different set of checks. If the connection drops while you're actively using the device, see whether your basic network connection also drops and compare another route. If it happens only when switching networks, check whether the client reconnects once the network is back. Don't mistake a brief reconnection for a failed subscription. If it happens only in the background, check how the system manages background activity and battery use for the client.
Mobile operating systems may restrict background activity when an app isn't in the foreground, or rebuild connections when the network changes. In system settings, find the client's battery management, background activity, and network permissions. Make sure they haven't been restricted manually. Menu names vary by device, so use the actual options provided by your system; don't follow screenshots from another device to look for settings that may not exist. After changing a setting, leave the client in the background and repeat a scenario that used to trigger the drop. Check whether the client shows Connected, Reconnecting, or Disconnected when you return to it.
Track auto-reconnect separately from connection stability
A successful reconnect means the service is available again; it doesn't mean there was no interruption. If you're on a call, uploading, or streaming, check whether the app also showed a retry message. First note how the client status changed around the time of the drop, then test whether another route fails in the same scenario. If every route drops only in the background on one device, focus on system restrictions. If the same route drops in the foreground on multiple devices, note the route name and time and send them to support. Keep your network unchanged during troubleshooting so you can distinguish route instability from network switching.
On Windows, macOS, and Linux, check whether the network stays connected while the device sleeps. A page reloading after wake may simply mean the system is restoring its network connection. If the device hasn't slept but the connection keeps dropping, check whether the client log shows an interface closing or a connection being rebuilt. If your client uses a virtual network interface, don't run multiple tools that try to manage the same interface. Temporarily closing other network management tools is easier to reverse and test than changing system routes at random.
| Platform and scenario | Check first | How to verify |
|---|---|---|
| iOS / Android in the background | Background activity, battery management, network permissions | Retest the scenario that usually causes a drop |
| Windows / macOS after sleep | Device wake and network recovery status | Compare client status before and after sleep |
| Linux after a network switch | Network interface and client reconnection status | Check whether the client reconnects once the network is back |
Some apps maintain their own long-lived connections. After the VPNUL client reconnects, those apps may not restore the previous session automatically. Reopen the app or refresh the page to tell the difference between “VPNUL is still disconnected” and “the app hasn't recovered yet.” If the app asks you to sign in again, first confirm the connection is stable, then restore the app session. Never post your password or full connection configuration in a public forum when asking for help—especially your subscription link.
If the connection keeps dropping after checking background permissions and testing other routes and networks, contact support through a ticket in the user dashboard. Before submitting, confirm the issue occurs with your current active plan and subscription, and say whether it affects only one device. VPNUL has no limit on the number of devices connected at the same time. Don't assume that multiple devices are restricted by the service—first check the actual message you're seeing.
Subscription update failed: check the link, retrieval, and parsing
First, make sure the subscription belongs to your current account
Updating a subscription makes the client fetch the route list again; it doesn't mean you need to buy another plan. First check your account status and subscription link in the user dashboard. Then confirm that the client has the matching subscription saved, not an example address from a tutorial. Copy real subscription links using the dashboard's copy button. If you have to paste one manually, check for leading or trailing spaces, unexpected line breaks, or a cut-off ending. Your subscription link contains information needed to access your configuration. Treat it like account information—don't post it in a public chat or show the full address in a screenshot.
Errors can happen at several different stages. If the client can't retrieve the subscription, check whether regular websites and the dashboard load on the same network. If it says the subscription address is invalid, copy it again from the dashboard and check where you're importing it. If parsing fails, confirm you're importing a subscription format supported by the client, rather than pasting a web page address into a route configuration field. Some clients have separate options for adding a subscription and importing a single configuration. Using the wrong option can make it look like the service has no routes. See What is a subscription link? for more on getting and importing a subscription.
Keep your existing configuration before trying a fresh import
When an update fails, don't immediately delete the only configuration that still works. First note the working route name, the subscription name in the client, and the exact error. Then try updating it in the client. If your client supports multiple subscriptions, check the source and add the subscription currently shown in the dashboard, then compare the old and new route lists. Remove outdated or duplicate entries only after confirming the new configuration works. That way, an unstable connection during an update won't make you lose the routes you could still use.
A completed subscription update doesn't necessarily switch your active connection to a new entry. Once the list has routes, select one and test the connection. If the client is still using an old route that has disappeared, select another manually. If routes are listed but none connect, go back to Can't connect at all instead of repeatedly updating the subscription. If only some regions appear, check whether the client has a filter, search, or collapsed groups enabled. An entry missing from the screen doesn't necessarily mean the service didn't return it.
If you've posted your subscription link somewhere public, check the user dashboard for an option to reset or replace it. If you can't find one, contact support and explain that the link may have been exposed—don't paste the full link into the ticket. Support needs account-related details, the client error, and steps to reproduce the issue, not credentials that could be used to access your configuration. There's no need to refresh the subscription repeatedly based on guesswork. Update it using the client's built-in feature when the route list looks wrong, the configuration appears out of date, or the dashboard says to import it again. Then check the resulting list.
Client menus may be in different places on Windows, macOS, iOS, Android, and Linux, but the checks are the same: dashboard status, link source, import option, retrieval result, list contents, and actual connection. Recording each step makes it clear where the process fails. If importing the same account subscription fails in the same way on multiple devices, include the error messages from each platform. If only one device fails, say which steps work on another device to help narrow the issue down to the local client.
One app isn't using the proxy: check rules, processes, and the destination service
Confirm the issue affects only this app
First, open the destination service in a browser using the same route, then try the app that's having trouble. If the website also fails, go back to the web and DNS section. If the website works but the app doesn't, check whether the app's traffic is going through the current client. Some clients route traffic by domain; others use app processes or a system network interface. In rule mode, the app may be assigned a direct connection. If it still fails in global mode, check the app's own network settings and sign-in status, along with any message from the service.
Before switching modes, note the current mode and a destination that worked before. Temporarily test the app in the client's global mode, then restore your usual mode or continue checking the rules. If global mode works but rule mode doesn't, check whether the app name, domain, or destination region in the rule matches the actual request. Don't rely on the app's displayed name alone: a single app may use different domains for sign-in, images, or media. A rule for one domain that misses related requests can make the app interface load while its content stays blank.
Rule out proxy settings in the app itself
Some desktop apps have their own proxy settings, and browsers may use separate proxy extensions. These can override the system proxy or send requests along a different path from the VPNUL client. Note the app's current settings, check its network mode in the app's documentation, and run a comparison test. Don't change the system proxy, client rules, and in-app proxy all at once just to get one app working. Even if it starts working, you won't know which path the request took. Keep the exact error code if the app shows one, but don't use it to guess your VPNUL account status.
Connecting to a region doesn't automatically give you access to content or account permissions restricted by the destination service. Using the same account and route, compare the website with the app and check the service's own regional availability, sign-in status, and content permissions. For a regional notice on a video service, see the route selection tips on the streaming page. If an AI tool won't load, check its website and app separately instead of treating every error as a failed route. VPNUL provides cross-border route subscriptions; it doesn't manage accounts or content policies for other services.
On mobile, if only background notifications or content refreshes are delayed while the app works normally in the foreground, also check the background disconnects section. Background activity depends on system and app settings, so switching routes may not help. On desktop, an app may only read proxy settings when it starts. Once the client is connected, restart the app and test again. This is particularly useful if websites work but a standalone app doesn't. Keep the same account and route during the test so you don't mistake a sign-in change for a proxy rule fix.
When contacting support, include the app name, client mode, browser comparison results, route name, and the exact error shown in the app. If the issue involves content that appears only after signing in, describe which page or step fails instead of uploading a full screenshot with personal information. The goal is to find out whether the request is going through the proxy and where it fails—not to collect your app account details.
Account alerts, data status, and support tickets: make the issue clear
If you see a “device limit exceeded” alert, check where it came from
VPNUL doesn't limit the number of devices you can have connected at the same time. If you see a “device limit exceeded” message, don't assume it's a VPNUL plan limit. First check whether it appears in your VPNUL dashboard, the client you're using, or an account page for another app. Each source can have different limits. Note the exact message and what you were doing when it appeared, check that you're signed into the expected account in the client, and review your plan status in the dashboard. If the alert comes from another service, follow that service's account rules—a different VPNUL route won't change how it manages devices.
Check your data allowance based on the type of plan. VPNUL monthly plans include ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on your activation date, and the price difference for a mid-cycle upgrade is converted into the remaining days. Data packs are ¥158 for 300GB, ¥358 for 1000GB, and ¥658 for 3000GB. They don't expire and remain available until used. First check whether your dashboard shows a monthly plan or a data pack, then compare the allowance and status shown there. If something doesn't look right, share the plan name and dashboard message. Don't assume a reset date based on the calendar month or calculate remaining upgrade days yourself.
When to submit a support ticket
A support ticket is appropriate if you've tested your basic network, other routes, subscription, and client mode but still can't connect; the same error occurs on multiple devices; the plan or data status in your dashboard doesn't match your purchase history; your subscription link may have been exposed; or the issue reliably occurs under the same conditions. Submit it through the support ticket section in the user dashboard. If only one website is temporarily unavailable, first narrow it down using the web and app sections. You don't need to diagnose the root cause before submitting a ticket—just provide clear observations that can be reproduced.
Describe the issue in this order: what happened, when it happened, how to reproduce it, and what you've already ruled out. Include your platform, the exact client error, route name, network type, and whether it also happens on another route or device. For website issues, include the affected domain and browser error type. For subscription problems, say whether the failure occurs during retrieval, parsing, or connection. For billing questions, give the plan name shown in the dashboard and the order status shown there. Crop screenshots to the relevant error and hide account credentials, your full subscription link, and other private information.
Example support ticket
“The Android client shows Connected, and regular websites load, but the destination app won't load content. The issue occurs in rule mode; switching to global mode on the same route lets it load. I reproduced the issue on another route. I've attached the app error and a screenshot of the client mode, with account details hidden.”
After submitting, keep your test conditions unchanged if possible until support gives you a clear next step. If the issue resolved on its own, update the ticket with the last change you made before it recovered. This can help distinguish a temporary network issue from a configuration fix. If support asks you to change a setting, note its current value, test only that change, and share the result. Changing several settings on multiple devices makes the original issue harder to verify and the previous configuration harder to restore.
You can also check quick answers in the Help Center or review the basics in the Quick Start Guide. To compare data allowances and payment methods, visit the plans page. VPNUL accepts Alipay, WeChat Pay, and USDT, and offers a 60-day no-questions-asked refund. Create an account with a username and password—no email address required. Use these details to check your account and the scope of the service; they don't replace troubleshooting the actual issue. Whether the connection works depends on where the error occurs and what your comparison tests show.