VPNUPS Troubleshooting Guide

Can't connect at all: identify where the failure occurs

Find out where the connection fails

A client showing as disconnected, a failed route test, and a system VPN icon with websites that won't load are different problems. First note whether the error appears when launching the client, fetching the subscription, selecting a route or after the connection is established. Record the full message, not just “it doesn't work.” If the client won't open, check system permissions and installation status. If it opens but the route list is empty, see the subscription update section. If a route connects but a website won't load, check DNS resolution and routing next.

Disconnect the proxy and use your browser to visit a website that normally works. This confirms whether your internet connection is available. Hotel, office and public Wi-Fi may require you to complete a sign-in page in your browser first. Being connected to Wi-Fi doesn't necessarily mean you have internet access. If the sign-in page doesn't appear, pause the proxy, disable browser proxy extensions, then open the sign-in prompt from your system's network settings. Once online, reconnect the client so you don't mistake a Wi-Fi sign-in issue for a route failure.

Keep the device fixed; test another network and route separately

Once your basic connection is working, keep the device and client settings unchanged and try a different route. If that works, the issue is more likely with the original route or the path from your network to its entry point; there's no need to reinstall the software right away. If other routes fail too, keep the route fixed and try a different available network. This order helps distinguish route issues from access network issues. A region name alone doesn't prove that all routes in that region have the same problem.

If switching networks fixes the issue, check the original network's sign-in status, outbound policies and router settings. Company and campus networks may have rules for tunnel connections; follow those rules and ask the administrator which connection methods are allowed. If every network fails, check whether the client has started its connection core and received system network permission, and whether another proxy app is using the same local listening address. Quit other clients before reconnecting to avoid multiple apps controlling the system proxy at once.

Check your account status and system clock

Check the plan status, remaining data and subscription for your current account in the account overview. Monthly subscription data resets on the activation date each month, not on the first day of the calendar month. Seeing routes in the list doesn't mean your account has data available; the client may simply be showing a saved configuration. If the status doesn't look right, refresh the dashboard before updating the subscription. Don't try to fix it by changing account fields in the configuration.

An incorrect system date or time zone can affect certificate validity checks and secure connections. Make sure your date, time and time zone are correct, then try again. If you see a certificate error, don't disable certificate checks or install an untrusted root certificate. Keep the full error and distinguish a name mismatch, a trust chain issue and an incorrect local time. These details are more useful than “the server didn't respond.”

If your internet connection works, your account is active, other proxies are closed, and changing both the route and network makes no difference, stop reinstalling the client. Save the connection log from the start of the attempt through the error, and note your operating system, client source, route name and time of failure. Then submit a support ticket as described at the end of this guide. Listing the checks you've already done helps avoid repeating them.

Connected, but websites won't load: check DNS

Tell DNS, connection and page-response issues apart

A connected indicator in the client usually means one step has completed; it doesn't confirm that the browser's entire request path is working. Loading a website also involves DNS resolution, establishing a secure connection, receiving a response and loading page resources. If the browser says it can't find a domain, check DNS first. If it keeps waiting to connect, check proxy routing and the path to the destination. If you see an access-denied or account sign-in page, the destination service has responded, so this isn't simply a DNS failure.

Try different types of websites in the same browser and keep the full error code from any failed page. If only one site fails, compare it across other routes before resetting your entire network. If all sites fail, disconnect the proxy and check your basic connection, then see whether the system proxy points to a client that's still running. If a client crashed, it may have left a local proxy setting behind, causing the browser to keep sending requests to an address that's no longer listening. Your internet can be working while pages still won't load.

Check DNS settings along the request path

Domains may be resolved by the operating system, browser Secure DNS, the client or the app itself. Different resolution paths on the same device can make browser results differ from command-line results. First check whether the client uses DNS settings from the subscription, then see whether Secure DNS is enabled separately in the browser. Don't change both system and client DNS at once. Restore the subscription defaults first, then compare one setting at a time and note which layer you changed.

The commands below help you inspect system DNS resolution and command-line access. The example domain doesn't contain account information. Run the relevant command in a Windows terminal; macOS and Linux have their own built-in tools. If a tool isn't available, there's no need to install software from an unknown source just to troubleshoot. The output only reflects that program's network path and may not match the browser's or client's built-in DNS behavior.

nslookup example.com
curl -I https://example.com

If resolution fails while your basic connection works, check whether the DNS server is reachable, whether the client is handling DNS and whether an old setting remains. If resolution succeeds but the secure connection fails, check the certificate, system time and proxy logs. Don't paste the resolved IP address into your browser instead of testing the domain: secure websites use the domain for certificate and service identification, so an error when visiting the IP doesn't prove the original site is unavailable.

Understanding cache and virtual IPs

Some clients use virtual IP mapping so the connection core can choose rules based on the domain. In this mode, the address shown by the system may not be the destination service's public IP, so its appearance alone doesn't indicate a DNS problem. After changing this mode, an old browser process may still have an existing connection or cached data. Save your work, fully quit the relevant apps and reopen them to test. Clear the system cache only if you have evidence of a cache issue; don't reset the entire network.

On Windows, run the command below in a terminal to clear the system DNS cache. This won't fix an expired subscription, an unreachable route or a restriction on the destination account, and it may not clear the browser's own cache. Reopen the app afterward and test the same domain again. If only one browser starts working, check its extensions, separate proxy settings and Secure DNS rather than assuming the route issue is fixed.

ipconfig /flushdns

When reporting this issue, include the domain, the browser's exact error, the client's proxy mode and whether system DNS results match what you see in the browser. The domain is enough; don't share a full URL containing a login token. For guidance on staying safe on public networks and protecting subscription links, see VPN Security Basics.

Slow speeds and peak-hour slowdowns

Pinpoint which part is slow

“Slow” might mean a webpage takes a long time to open, downloads have low throughput, video playback keeps buffering or interactive actions are slow to respond. These symptoms can have different causes. Describe the specific action and what happens, then check whether all apps are slow or only a particular service, file type or route. Don't judge an entire route by one download, or assume that a destination server's own throttling means your local network or subscription plan is limiting speed.

Pause cloud sync, system updates and other tasks that use the network continuously, then compare routes on the same device, network and destination. If possible, compare wired and Wi-Fi connections. A strong Wi-Fi signal doesn't rule out interference, and a busy router can cause fluctuations. Keep the destination file and video quality the same during the comparison; otherwise, the test load changes and the results won't tell you much about route performance.

Understand route types, not just regions

A nearby region doesn't necessarily offer a better end-to-end path. Your access provider, entry point, transit path and the destination service's network all affect performance. IEPL, relay and direct routes describe how a route is organized, not how it will perform at any given time. Compare different paths available in the client and keep the route that reliably handles your task, rather than choosing solely by the lowest number shown in a test list.

A node's region, entry point and exit point are different concepts. A service identifies the exit region, while the client first connects to the entry point. A route may get faster after a region change because the entry path changed or because the destination assigned a different content server. Compare the same destination under consistent conditions; don't draw conclusions from a region name alone. See the route guide for more on choosing a route.

Keep time and network conditions in your peak-hour notes

If things work during the day but slow down in the evening, record the time window and time zone, and note whether your basic connection is also slower. Compare different paths first, then check how the same route performs outside busy hours. If every route is slow on your current network but works after you switch networks, the access link may be involved. If one route behaves poorly across different networks, send its details to support for further investigation.

For video, distinguish content loading, region detection and playback buffering. A homepage loading doesn't mean video streams use the same path, and automatic quality adjustment may take time after network conditions change. Use the same video, pause background downloads and see whether buffering continues. If only one platform or title is affected, note the service and exact error; don't repeatedly change your account region. See the streaming guide for information on access limitations.

When submitting a support ticket, include the task that's slow, when it happens, the route name, your connection type and what changed after trying another route. You can include timeouts or retries from the client log, but don't include private parameters from a full download URL. For API requests, distinguish a slow connection from slow content generation by the service. See how to choose a route for AI APIs.

Frequent disconnections and mobile background disconnects

Distinguish a dropped tunnel from an interrupted app session

An app asking you to sign in again, a video pausing or a browser request timing out doesn't necessarily mean the system tunnel disconnected. Check the client's connection status, the system VPN indicator and relevant logs first. If the client is still connected but one app has stopped working, check the service session and routing. If the client log shows a connection ending, reconnecting or switching networks, then investigate tunnel stability and background management. A continuous log from before and after the disconnection is more useful than a screenshot of the last error alone.

Note what was happening when the connection dropped: did you lock the screen, switch apps, leave Wi-Fi coverage, put the device to sleep or just regain network access? Switching between Wi-Fi and mobile data changes the access path, so existing connections may need to be re-established. An app may still be waiting on an old request even after the client reconnects, so new and old requests may behave differently. Try the action again before clearing the app's data.

How to check mobile background activity

On Android, battery optimization, background data limits and manufacturer task killers can affect whether a client keeps running. In the system's app settings, check that the VPNUPS client is allowed to run in the background and use data, then see whether battery saver is restricting it. Menu names vary by system, so don't follow a path written for a different device. After changing permissions, keep the same route and repeat the same screen-lock or app-switching steps to see if the result changes.

On iOS, check that the system VPN configuration is still managed by the current client and that another VPN or network filter isn't competing for control. If the system asks for network permission when reconnecting, verify the app's source before approving it. Don't delete a work- or school-managed profile to troubleshoot; ask the administrator about network permissions on managed devices. System background scheduling and an app's own session timeout are separate issues. A webpage failing to refresh with the screen off doesn't prove that the background tunnel was stopped.

Desktop sleep, automatic switching and reconnection

After waking from sleep, network interfaces on Windows, macOS and Linux may not be ready when the client tries to reconnect. Wait for the basic connection to come back, then reconnect manually to check whether the issue is just a timing problem. If it fails every time the device wakes, record the interface status and client logs from before and after. Don't disable all power management just to keep a connection alive; identify the specific trigger before changing client startup or reconnection settings.

If automatic route selection switches exits too often, long-lived connections and service sessions may have to restart repeatedly. For troubleshooting, pin a route and avoid enabling automatic switching, browser proxy extensions and other network tools at the same time. Judge stability by how your actual task runs, not just by the client's indicator. Continuous downloads, live communications and long-running API requests tolerate connection changes differently, so note which task was interrupted.

If disconnections continue with a fixed route, necessary background permissions enabled and other proxies disabled, and you can reproduce the issue on another network, submit a support ticket with the steps that trigger it. Say whether it reliably occurs when locking the screen, waking the device or switching networks, and whether manually reconnecting helps. No single setting can guarantee that all disconnections will stop. Multiple routes offer alternatives, but they can't replace a properly working device or access network.

Subscription update failures and configuration issues

Check whether the failure is during download or parsing

A subscription update has two stages: fetching the content and parsing the configuration. Connection timeouts and DNS resolution failures usually happen while fetching; unsupported formats, unrecognized fields and import failures point more to parsing. If the client says “Update failed,” open the details and check the full error. If your existing configuration still works, don't delete it. Keep the current working state and exact error, then check the update source so a failed update doesn't leave you without your existing routes.

Go to the user dashboard to check your account, then get the subscription link for your client from the dashboard again. Don't copy purported fixes from chat history, third-party converters or unfamiliar websites. A subscription link grants access to your account, so treat it like a credential. When troubleshooting, just say where the link came from and whether you fetched it again. Never include the full link in a screenshot, public forum post or shared document.

Match the import method to the client

Different clients may accept different configuration formats. An import that works in one app may not work in another. Use the import method provided in the dashboard and check that your system hands it to the intended client. If you have several similar apps installed, an older one may handle the import, making it look as if the current client updated when the configuration actually went to another app. Check the app name and configuration source before connecting.

Copying and pasting can add spaces, line breaks or punctuation. If a manual import fails, copy the link from the dashboard again rather than trying to fill in missing parameters from memory. The example below shows the format of a subscription link; it isn't a real VPNUPS subscription and won't connect. Don't replace it with a real link and save it in a public guide or code repository. Retrieve real configurations from your private dashboard when the client needs them.

https://example.com/sub?token=YOUR_TOKEN

If the log shows a webpage instead of a configuration, the response may be a network sign-in page, a session page or an error. Don't keep importing the returned content as if it were a valid configuration. Complete network sign-in first, then get the link again from the dashboard. If your old proxy has stopped working and the subscription update depends on it, temporarily disable the proxy and retry once your basic connection is working. Change only the fetch path; don't disable secure connection checks.

Keep default settings; take care with custom rules

If an error started after you manually changed indentation, rule order or parsing settings, compare against the unmodified subscription configuration first. Whitespace, field placement and data types can all affect parsing; similar-looking text doesn't guarantee a valid format. If the default configuration works but your custom one doesn't, note the differences and revert them one at a time. Don't send the whole configuration file; it may contain a subscription link, account identifier or route credentials.

A successful update doesn't mean the current connection has switched to the new configuration. Check whether the selected profile, policy group and route still point to the old settings; disconnect and reconnect if needed. A client may also keep a session for a route that has since been removed, so the list can update while requests still fail. Save your work before switching configurations to avoid disrupting long requests or file transfers.

If the dashboard opens and your account is active, but an update still fails after you fetch the link again, and the error occurs with an unmodified configuration, submit the client name, operating system, import method, exact error and time of the issue. Say whether the old configuration still connects and whether updating works on another network. If you think your subscription link has been exposed, reset it using the dashboard if that option is available and update your devices. Don't paste the exposed link into the ticket.

One app bypasses the proxy: check routing

A working browser doesn't mean every app is using the proxy

A browser reaching a website only shows that the browser's request path worked at that moment. Desktop apps, terminals, developer tools and games may use different network interfaces: some follow the system proxy, some have their own proxy settings and others connect directly. If one app has a problem, compare its behavior with the web version on the same route, then check the client connection log for requests from that app. No request in the log calls for different checks than a request that reached the proxy but was rejected by the destination.

A system proxy usually affects apps that follow system settings. Tunnel mode may capture more traffic, but it requires system permission and depends on how the client and operating system implement it. “Global” may only change how requests already reaching the client are routed; it doesn't necessarily capture traffic from every process. Read the client's description before changing the setting. A mode name alone doesn't prove what traffic it captures. First find out where the request goes, then determine which route it should use.

Check rules, processes and app-specific proxy settings

Check the connection log to see which rule matched the destination domain: direct, blocked or a proxy policy. Apps often request multiple domains for sign-in, static files and content APIs, which may each follow different rules. Adding only the homepage domain may not cover all requests. Use the logs from the failed action to identify the actual destination rather than forcing every unfamiliar domain through the proxy. Restart the app after changing rules so existing connections don't keep using the old path.

If the app has its own network settings, check whether they still contain an old local proxy address or port. Don't copy a fixed port from an online guide; use the local listening settings shown in your current client. Developer tools may also inherit proxy variables from the process environment, so the same program can behave differently when started from a terminal or a graphical interface. After changing environment variables, restart the relevant process; running tasks won't pick up the new environment automatically.

The commands below only check common proxy environment variables. Their output may include private proxy details, so redact it before sharing. A variable being present doesn't prove the app uses it, and an empty variable doesn't mean the system proxy is off. These are just part of the evidence for locating process settings. Check the app documentation and client connection logs before drawing conclusions; don't immediately delete all system environment variables.

# macOS / Linux
printenv HTTP_PROXY HTTPS_PROXY ALL_PROXY NO_PROXY

# Windows PowerShell
Get-ChildItem Env:HTTP_PROXY,Env:HTTPS_PROXY,Env:ALL_PROXY,Env:NO_PROXY -ErrorAction SilentlyContinue

Check APIs, persistent connections and account region separately

If an AI Tools webpage opens but an API request times out, the developer tool may not have inherited the proxy, its timeout may be too short, or the service may take time to process the request. First confirm that the request reaches the client, then distinguish a connection error from an error returned by the destination service. If you already have a response about usage limits, authentication or permissions, check the destination account and API requirements instead of changing networks again. For development workflows, see the checklist for stable exit routes, concurrency and timeouts.

Streaming and other region-dependent services may also consider your account region, device settings and detected exit location. After changing routes, an app may retain its old session; sign out normally and reopen it rather than repeatedly changing account details or clearing all data. Network routing only handles the request path; it doesn't guarantee that the destination service will provide all content. Check the service's actual response and rules, not just the route's region name.

If only one app fails, include its name, the action you took, the exact error, proxy mode and matched rule in your ticket. Also say whether the web version of the same service works. Screenshots only need to show the relevant connection; don't include your full browsing history. For Windows desktop routing options, see Windows global proxy and rule-based routing. Use the current client interface for the actual steps.

Device-limit messages and system permissions

A “device limit” warning doesn't necessarily mean your plan is limiting devices

VPNUPS has no limit on the number of devices online at the same time. If you see “device limit exceeded” or a similar message, first check whether it came from the VPNUPS dashboard, the client, your operating system or a third-party service you're using. A destination app may have its own session or device policies; those aren't limits on your network subscription. Keep a screenshot of where the message appeared and the exact text instead of assuming the word “device” means you need a higher-tier plan.

If your account is active but the client rejects it, check whether you imported the subscription for the current account or accidentally used an old configuration from another service. Shared computers may store several configuration files, and similar names don't mean they belong to the same account. Get your current subscription from the dashboard and check which profile is selected. Don't test with someone else's credentials or give your subscription to a stranger to test; that could expose your configuration instead of resolving the issue.

Unlimited devices and local resources are different things

Unlimited devices describes the simultaneous-device policy; it doesn't guarantee that every device's network, system resources and app settings are suitable. Several devices downloading continuously can still saturate a home network or router, and usage will draw on the same data allowance. Monthly subscription data resets on the activation date each month. Data add-ons remain valid until used and never expire. Check your plan and data status in the dashboard rather than assuming a slowdown across devices means there's a device limit.

If only one device has an issue, keep another device as a comparison and check the affected device's time, permissions, leftover proxy settings and local security settings. If all devices are affected at once, check the shared network, account status and route first rather than reinstalling on each device. For a meaningful comparison, use the same route and destination. Different devices accessing different services won't distinguish a device issue from a destination issue.

Restore permissions precisely; don't grant unrestricted access

A client launching successfully doesn't mean the component responsible for network connections is running properly. The system may be waiting for network extension permission, or another program may have occupied the local listener. Check the client's status page and system prompts to confirm the permission request is from the client obtained through the dashboard. Don't grant an arbitrary app permanent administrator access to fix a connection, and don't routinely disable all security software. If you see a block in the security log, investigate the specific component.

After old proxy software is uninstalled, system proxy settings, virtual interfaces or network extensions may remain. First use the software's own exit and uninstall steps, then check whether the system's network settings still point to an old address. Don't delete network interfaces in bulk if you don't know what they do; work networks, virtual machines and remote connections may depend on them. Record the original settings before making changes so you can undo each one, then check how the browser and client behave.

On Linux, terminal proxy variables, desktop proxy settings and elevated-process environments may differ. Background services on Windows and macOS may not inherit the current sign-in session's settings either. A working browser doesn't prove that system background tasks use the proxy. If the issue involves router configuration, check supported configurations and client requirements first; don't apply desktop instructions directly to a router. VPNUPS supports Windows / macOS / iOS / Android / Linux. Check whether other environments can be configured before proceeding.

If the dashboard displays a message that conflicts with the unlimited-device policy, or incorrectly rejects a valid subscription, submit a support ticket with the exact message, where it appeared and a redacted screenshot of the relevant account overview. You don't need to make another payment to verify it. Check the pricing page for plans and policies, and the Terms of Service for refund information.

Support tickets and verification after recovery

When to stop troubleshooting on your own

If the issue persists after checking your basic connection, account status, alternative routes and default client settings, gather evidence instead of making broader changes. Reinstalling repeatedly, resetting all network settings or clearing all app data may delete logs or disrupt work configurations. If you see a certificate issue, inconsistent account status, a potentially exposed subscription or a permission request you don't understand, preserve the current state and ask for help through the dashboard ticket system.

The same symptom can come from different layers, so “I tried lots of routes” is less useful than describing what changed. Say whether the original route failed completely, the new one was just slower, the network stayed the same and which action failed. Support needs to understand what happened under consistent conditions, not receive a series of conflicting conclusions. If you haven't run a test, say so; don't guess just to make the report look complete.

Write a reproducible support ticket

Submit the issue through support tickets in the user dashboard. Start with a one-sentence summary, then describe the conditions, steps to reproduce, actual result, comparison results and changes you've made. Include the time zone and use the route name as shown in the client. Your system and client names identify the environment; the exact error helps pinpoint the stage. If the system doesn't show a detail, say that it isn't displayed rather than guessing.

Include the relevant process from before the action began through the error, keeping events in order. A screenshot showing only “failed” may miss an earlier DNS or permission error. You can start with the client's diagnostic export, but review the file before submitting it; an export doesn't guarantee that private fields have been removed. Don't upload your entire user folder, browser profile or environment files containing credentials for other services.

Protect credentials without losing diagnostic detail

Redact passwords, full subscription links, authentication fields and unrelated personal details, but keep the error type, route name, time and relevant configuration option names. If a URL contains query parameters, include only the domain and a path description without private identifiers. If a screenshot shows your account balance or order details, keep only what's needed to explain the issue. See how to protect your account and subscription links.

VPNUPS doesn't require an email address; you can create an account with a username and password. Keep your account details safe and follow up on tickets through the dashboard while signed in. Don't split one issue across several unrelated tickets; adding new reproduction results to the original ticket makes it easier to compare before and after. If support requests additional diagnostics, confirm the purpose and how to undo the change first. Never share credentials publicly.

Test the original task after recovery, not just the indicator

Once the issue is fixed, retry the action that first failed: reopen the original webpage, repeat the app request, lock and wake the screen, or update the subscription again. Confirm that the problem is gone, then check for side effects, such as other websites no longer connecting directly, background apps losing access or the system proxy not resetting when the client closes. The change is effective only when the original task and essential everyday tasks work; one successful route test isn't a substitute for checking real use.

Finally, record the settings that worked and how to revert them. Undo temporary changes that proved unrelated, and keep the working default configuration rather than layering on every temporary exception. For plans, payments and refunds, check the relevant details: Alipay / WeChat Pay / USDT are supported, with a 14-day money-back guarantee. See the Terms of Service for details. Troubleshooting should identify the problem and restore normal use, not mask an unresolved network issue by switching plans repeatedly.