VPN Troubleshooting Guide

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

Turn “it won't connect” into a symptom you can diagnose

A connection button that does nothing, a client that won't start, a route that times out, and a connection that drops immediately are different problems. Note the last step that worked: does the client open, is the subscription list present, and does the status change after you select a route? Avoid vague reports like “it doesn't work,” and don't judge the entire network by a status icon. Start troubleshooting from the last step you reached so you don't mistake a local app issue for a route problem.

Disconnect the client and visit a website you normally access directly to check your basic internet connection. Public Wi-Fi may require you to confirm access in a browser first; a connected network icon doesn't guarantee internet access. If the basic connection also fails, check Wi-Fi, your router or network access. Switching international routes repeatedly won't help until direct internet access is working again.

Check your account, configuration and system permissions in order

Once your basic connection works, open the user dashboard to check your plan status and remaining data. Then make sure the client is using a configuration from that account. Being able to sign in to the dashboard only confirms that the account page is accessible; it doesn't mean the client has received a valid configuration. If the route list is empty, check the subscription import first. If the list is complete but every route times out, check your current network and client status.

Select the configuration you want to use in the client, then update it and connect. An old configuration may still be selected, which is a common reason an update appears to have changed nothing. Check the update time, route list and selected indicator rather than relying on a similar-looking name. If other proxy tools are installed, exit them normally while troubleshooting this client. This helps prevent conflicts over the system proxy, virtual network interfaces or local listening ports.

When your system first asks to create a network connection or allow a background service, verify the program's source before granting permission, following the client's instructions. If you previously denied access, check system settings for the relevant network extension or VPN configuration. For explicit permission or interface errors, address permissions first. Don't disable your entire security setup or install supposed repair tools from unknown sources. On a managed device, ask the administrator which connection methods are allowed.

Use controlled comparisons to choose your next step

Keep the client and configuration unchanged, switch to another available network and compare the result. Then keep the network unchanged and select a route in another region. The first comparison tests the network environment; the second checks whether only certain routes are affected. Hong Kong and Japan aren't always the best choices—see the routes page for guidance. If the issue occurs only on your current network, note the network type and error. If it persists across networks and routes, recheck the configuration, permissions and account status.

Check in this order: basic network, account status, current configuration, system permissions, then compare routes. Record the result at each step. Don't reinstall, switch networks and change modes all at once, or you won't know which action helped.

Submit a support ticket if the client won't start, permission errors persist, or a valid subscription still fails to connect across different networks. Include your operating system, the exact error, the route region and the checks you've completed. Hide account details and subscription content in screenshots. Never post a full subscription link in a public forum.

Connected but websites won't load: check proxy routing and DNS

First distinguish a single-site issue from a general failure

A connected status usually means one part of the connection is established; it doesn't guarantee browser traffic is using that route. Visit a few everyday websites and the affected site, and note whether all sites fail, only some fail, or only the sign-in page has an issue. If other sites work but the affected site shows a region notice, account verification or access restriction, keep that response for reference. These results mean something different from a connection timeout and shouldn't be handled the same way.

Next, check whether the client's system proxy or traffic-routing feature is enabled. Some clients require you to turn on the system proxy separately after connecting; some apps don't use system proxy settings at all. If the client provides connection logs, check for a matching request when you open the affected page. If there's no request, first find out whether traffic is reaching the client. If there is a request but it fails, check the rules, DNS resolution and the destination's response. This helps avoid repeatedly switching routes at the wrong troubleshooting level.

Understand DNS issues instead of changing addresses blindly

DNS translates domain names into network addresses. A page may fail to load because a domain can't be resolved, the resolved address is unreachable or the request is taking the wrong route. “Server not found” in a browser points more toward a DNS issue; certificate errors, access denials and connection resets need separate investigation. Don't label every error a DNS leak, or assume the configuration is broken just because DNS is handled in a different region. DNS resolution and the route used by web traffic are not the same thing.

Keep the client's default DNS settings initially. Check whether you've added custom DNS servers, changed the system proxy or enabled encrypted DNS in your browser. When the browser, system and client each have their own settings, requests may take different paths. For comparison, you can temporarily set the browser to use the system DNS settings, then restore the original setting after testing. Don't enter DNS addresses from unknown sources. Make sure your system clock is correct too: an incorrect time can cause secure connections to fail and look like a website access issue.

Use commands as supporting evidence only

On Windows, you can use the command below to check DNS resolution for an example domain. It shows the system's default lookup path; it may not reflect DNS handled inside the client, and it can't prove on its own that the proxy is working. To check a site you use, replace the example with its public domain. Don't paste a full URL containing login credentials or private parameters. If you've changed DNS settings, restore them first, clear the system cache, then reopen your browser and test again.

nslookup example.com
ipconfig /flushdns

If the system proxy is correctly routing traffic but ordinary websites still fail, note the exact browser error and the matching client log entry. If only one site is affected, provide its domain, the type of response and the exit region—don't share private page content. The IP lookup page can help you check for changes to your exit IP, but one lookup alone doesn't verify that a site is accessible.

Slow speeds: separate page loading, data transfer and app response

First identify which part is slow

A long wait before a page opens, images loading slowly after the page appears, and a download that starts normally but then slows down point to different stages. The first may involve DNS, connection setup or rule matching; the others may involve sustained transfer, destination-side throttling or competition on your local network. If an AI tool opens but takes a long time to respond, the delay may be on the service side—not a sign of insufficient route bandwidth. Describe what happens before deciding what to compare.

Keep the content the same as you compare everyday browsing on your regular network, access through the current route and the same task through another route. Don't compare different websites, video resolutions or file sizes. The destination server may be busy, and caching can also affect load times. Look for differences you can reproduce reliably rather than drawing a lasting conclusion about a route from one result.

Rule out local network contention before comparing routes

Check for system updates, cloud sync, other downloads or continuous uploads on your home network. Congestion on the upload side can slow web responses too; a full download isn't the only cause of lag. Weak Wi-Fi, frequent access point changes, power-saving settings and sustained high CPU load can also affect client performance. Pause background transfers you can control, move to a stable signal and repeat the same task to see whether the problem persists.

Route region is only one factor; geographic distance alone doesn't determine speed. Your ISP, exit path, destination server location and current congestion all affect performance. Compare nearby regions first, then regions relevant to the destination, while keeping your network the same. For more on choosing a region and route type, see How to Choose a VPN Route. Use the route types shown in the dashboard; don't assume a route is a dedicated line unless it's explicitly labeled that way.

Check whether the client uses per-app direct connections or split routing. If your browser uses the proxy but your download tool connects directly, the results may not share the same exit route. Conversely, sending local content over an international route may add delay. As a comparison, you can temporarily use the client's supported global proxy mode, then restore the rules that suit your everyday use. This mode is for diagnosis; it doesn't mean all traffic should use the same route permanently.

Look for results you can explain, not just a single score

A route test in the client usually checks one type of request; it isn't the same as testing a full webpage, video or large download. Results can vary depending on the test target. Don't focus on a single number in the route list. Check whether your task completes consistently, whether the connection keeps restarting and whether the same issue occurs across apps. If webpages are smooth but one download source is slow, check the source and download tool settings before considering a plan upgrade.

Data tiers describe how much data is included, not a guaranteed speed level. Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Don't assume a higher data allowance includes a bandwidth upgrade unless that's explicitly stated.

Data resets monthly on your activation date, not automatically at the start of the calendar month. See the plans page for details. If your dashboard status is normal and your basic network is stable, but multiple apps remain slow on certain routes, note the affected regions, destination services, time of day and comparison results. Distinguishing “pages load slowly” from “downloads are slow throughout” helps support identify whether to look at connection setup or data transfer.

Peak-time lag and frequent disconnects: find the common trigger

Keep time patterns and connection events separate

Slower evenings may be caused by your local network, shared Wi-Fi, cross-border routing or load on the destination service. A slowdown at a particular time doesn't prove which part is at fault. Note the network type, route region and app behavior before and after the issue starts, and check whether other everyday websites slow down too. If all access is affected, check your local network first. If only certain routes or destinations are affected, narrow down that path.

“Lag” and “disconnection” aren't the same thing. Record video buffering, pages waiting to load, the connection status dropping to zero and the client closing as separate symptoms. If the client still shows connected but content stops loading, an existing connection may have stalled or a destination request may have failed. If the client clearly shows disconnected, check network changes, system sleep, interface reconnection and app errors. Clear symptoms help you avoid repeatedly restarting the client during a transfer slowdown and interrupting sessions that still work.

Check network changes, sleep and other tools running at the same time

When you switch from Wi-Fi to another network, the existing connection may lose its route. Closing your device or locking the screen, then resuming from sleep, can also trigger a virtual interface to reconnect. First check whether the issue consistently follows these actions. If so, restore the network, disconnect and reconnect, then check that the client has established a working route. Don't treat an old status still displayed after resuming as proof of a new connection; verify by opening a page.

Multiple network tools running at once may repeatedly change proxy, routing or DNS settings. A tool may also leave settings behind after it exits, causing intermittent issues. Use the normal exit options provided by your system and clients, keeping only the tool you're troubleshooting. Then check whether the system proxy matches its status. Closing a window doesn't necessarily stop a background service. Don't delete unfamiliar network interfaces, as other work may depend on them.

If speeds drop only at peak times, keep the app and network unchanged, compare routes in other regions, then repeat the same task off-peak. If one route remains slow while others work, temporarily use a route that performs normally and report the affected region. If all routes slow down on one network but work on another, describe that difference. This is more useful than simply reporting “everything is slow at night,” and avoids blaming an unverified cause.

Restore service while preserving useful evidence

If you're in the middle of important work, save your local content before switching routes or restarting the connection. A change of exit IP may make a website reverify your session, and an upload in progress may be interrupted. Don't cycle through several regions while a task is underway just to find a better result. For apps that need continuous interaction, finishing the current task reliably is usually more important than constant adjustments. When you're done, compare routes using a repeatable test.

VPN59's no-logs policy describes the service's privacy practices; it doesn't mean your device won't create local troubleshooting logs. When preparing a support ticket, share only relevant error excerpts and check them for subscription data, authentication details, private domains or page paths.

Submit the exact error and the action that triggered it if the client repeatedly exits, reports a clear interface error or keeps disconnecting despite a stable network. If the issue depends on the time of day, include your local time zone and when it occurred. There's no need to capture all your traffic continuously. Support needs reproducible conditions and redacted excerpts—not a complete activity log from your device.

Subscription update failed: check the request, DNS and selected configuration

Distinguish a failed download from a failed configuration import

Updating a subscription involves retrieving, parsing and saving the configuration, then enabling it. A network timeout usually means the content wasn't retrieved successfully. An unsupported format or parsing error means the client couldn't turn the content it received into a usable configuration. If the update succeeds but your routes don't change, you may still have a different configuration selected. Keep the exact error and identify which step failed; don't repeatedly import over the evidence.

Check your account, plan and remaining data in the user dashboard, and make sure you're signed into the right account. No email address is required to create an account—just a username and password—so keep your username safe and don't create accounts repeatedly because you can't remember which one you used. After payment, rely on the status shown in the dashboard. If an order or entitlement looks wrong, check the order and contact support instead of paying again to fix a subscription issue.

Get subscriptions from the dashboard and protect their contents

Get your subscription from the dashboard download and subscription page. Don't use old chat messages, forwarded screenshots or configurations from unfamiliar websites. When copying, avoid extra spaces, line breaks or explanatory text. Prefer the import method provided in the dashboard for your client. Clients may support different configuration formats; content that imports into one tool may not work unchanged in another.

If importing doesn't open the client, first make sure it's installed and starts normally, then follow the dashboard instructions. Your browser may ask permission to open an app; check the app name before allowing it. After manual import, confirm that the configuration was saved and selected. “Configuration added” doesn't mean “configuration enabled.” Don't change route rules before importing is complete. If you're unsure about the initial steps, return to the Quick Start Guide and follow them in order.

The current proxy status can also affect subscription update requests. If an old configuration has stopped working and the client still forces requests through that route, fetching an update may keep failing. With your basic network working, try retrieving the subscription again using an update method supported by the client. If there are options for the update request's route, change them only if you understand what they do. Restore your usual settings after testing; don't leave a temporary troubleshooting mode enabled.

Format errors and security precautions

A parsing error doesn't necessarily mean the subscription URL is wrong. The client may have received a webpage, a network access sign-in page or other content instead of a configuration, or it may not support that format. Note the error type and client platform, then choose the matching import option in the dashboard. Don't submit your subscription to an unknown online converter, which could expose a usable configuration to a third party. Before resetting a subscription, find out whether other devices will also need their old configurations updated.

Treat subscription content like an access credential. Screenshots should show only the error and configuration status—not the full link, QR code, authentication fields or importable text. Follow the same precautions when asking for help in public.

If your dashboard shows a valid entitlement and your basic network works, but retrieving the subscription again still produces a format error, tell support your client platform, import method, exact error and whether the dashboard page opens normally. If automatic updates fail but manual updates work, include that difference too. You don't need to paste the full subscription into a ticket to prove there's a problem. Support can use your account and troubleshooting details to determine how to collect further information safely.

One app won't use the proxy: check its own network path

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

A system proxy provides an entry point for apps that respect the setting; not every program does. Some apps have their own proxy settings, some route only certain requests, and background services may use a different path from the main interface. So a desktop app can fail even when your browser reaches the site, without the route necessarily being at fault. First check whether the same service works in a browser, then determine whether the issue is specific to the app.

Open the client's connection log and repeat the action that fails in the app. If there are no matching requests, check per-app settings, the app's own proxy options and how the client takes over traffic. If requests appear, check the matching rules and exit route. Apps often connect to more than their main domain; they may also use separate domains for login, static resources and APIs. A rule for the homepage alone may let the interface load while login fails, images are missing or requests keep waiting.

Compare rules, modes and app-specific settings

If the client supports global proxy mode, you can temporarily use it to check whether the app starts working. If it does, the original rules may be missing some requests—but that doesn't mean global mode should remain enabled. Switch back to the original mode and check the matching rules for relevant domains in the connection log. Don't overwrite your configuration with an unfamiliar set of rules. Understand the specific difference first and keep a way to restore your settings. If the destination changes its domains, update your configuration before deciding whether rules need adjustment.

If the app has a proxy address field, use the local endpoint and protocol actually shown in your current client. Don't guess a port based on another tool. Some fields require a proxy protocol; others accept only an address and port. The wrong format can make the app report a connection failure. There are no universal settings here because local listener details depend on the client. Don't expose a local endpoint to an untrusted network to fix one app.

Keep the website's own decisions in mind when troubleshooting login

An app may connect to the internet but refuse a login, show that a region isn't available or request additional verification because of the service's account policies. Switching routes can't guarantee a change to these restrictions, and repeatedly changing regions may trigger different checks. Keep your exit route stable and review your account status and the service's official guidance. For AI services, use the AI Acceleration Guide to distinguish network issues from service responses. Don't mistake an account-permission issue for a proxy configuration error.

Command-line tools may inherit outdated environment variables from when the terminal started. An open terminal may not pick up changes to system settings; close and reopen it, then check the tool's documentation for separate proxy settings. Don't put credentials in public command examples or shared scripts. If only one app fails, include its name, the failed action, the exact error and whether the client logged a request—not just a screenshot showing that the browser works.

Mobile background disconnects: distinguish sleep from network changes

First reproduce the difference between foreground and background

If an app works in the foreground but fails after the screen locks or you switch tasks, that's an important clue that background restrictions may be involved. Keep the network and route the same, complete a successful request in the foreground, then lock the screen and resume. Check whether the client is still running, whether the system shows an active connection and whether reopening the client restores access. If it also fails in the foreground, troubleshoot the connection or website first rather than blaming battery-saving settings.

The system's connection indicator and an app's actual connectivity don't always match. The client may show an old status, and an existing app session may have expired. After unlocking, make a new page request instead of relying on a background task thumbnail. If reopening the client restores access, check background restrictions. If you have to reconnect, look at network changes and interface status. If only the target app needs to be reopened, check its session and app-specific network behavior.

Android: check background restrictions in system settings

Settings names vary across Android devices and system versions. In the app's info page, check battery usage, background activity and data permissions. Make sure the client isn't restricted from running in the background. Some systems also manage auto-start or background app cleanup; check the relevant settings on your device. Adjust settings only for the client that needs to stay connected. Don't disable battery management for every app or install background-keepalive tools from unknown sources.

Removing the client from the recent apps list may stop its background process; system cleanup features can have the same effect. First let the client run normally, then check whether it disconnects after you lock the screen. If the app includes guidance about background services, follow the instructions for the client provided in the dashboard. For more on Android battery saving and per-app routing, see Android Background App Settings and Battery Optimization. Your device's current settings are the final authority.

iOS and the limits of switching networks

On iOS, check that the VPN configuration in system settings belongs to your current client. An app appearing in the recent apps list doesn't prove its network extension is working. If the client offers on-demand connection settings, understand what they do before enabling them. Avoid conflicts between multiple automatic connection features. On a managed device, the organization may control the configuration; ask an administrator before removing anything.

On any mobile platform, leaving Wi-Fi coverage, a brief network interruption or switching access points can affect an existing session. Test on a stable network first, then check what happens when you switch networks. If the problem occurs only during a switch, retry the request once the connection is back and check whether the client rebuilt its route. Don't change background permissions and routes while moving around, or you won't know whether the result came from a settings change or a different network.

Find client downloads in the user dashboard. Sign in to download the client for Android, Windows, macOS or Linux. The iOS download option depends on the dashboard's eligibility check for your plan. Downloading a client and getting a usable subscription are separate steps; sign in to the dashboard to get your subscription.

If disconnects continue after you change background permissions, note the device platform, battery restriction status, action that triggered the issue, network type and whether reopening the client restores access. There's no need to list every app on your device. If only one app disconnects in the background, note whether system settings restrict it too. If the client itself is terminated, include the relevant error or system message to help support distinguish a stopped process from a route interruption.

Device-limit warnings and support tickets: check your plan and gather useful evidence

A “device limit reached” warning doesn't mean your plan limits devices

VPN59 has no limit on the number of devices that can be online at once. If a client shows a device-limit warning, don't assume you need a more expensive plan. First check whether it came from the VPN59 dashboard, your client or the destination website. An external app may limit its own signed-in sessions, and an operating system may restrict simultaneous network configurations. Those limits aren't VPN59's online-device policy. The exact error and the screen where it appeared are key to identifying its source.

Check whether you've imported an old configuration from another service or signed into different accounts on different devices. Configuration names can be changed, so a name containing VPN59 doesn't prove where it came from. Verify your account and subscription in the current dashboard, then check which configuration the client has enabled. Don't share your login details to test device limits, and don't keep signing out of other devices to work around a warning whose source hasn't been confirmed.

Check the billing details before changing plans

When sharing an account across devices, check the account's total data allowance and dashboard status. Don't assume each device gets a separate plan allowance. Monthly data resets on your activation date; mid-cycle upgrades are prorated for the remaining days. If you need more data, see the plans and data add-ons before treating a connection problem as a data-tier issue. If your plan status doesn't match the error, submit a ticket to have it checked rather than paying again.

Data add-ons don't expire and remain available until used. Options: ¥158/300GB, ¥358/1000GB and ¥658/3000GB. Pay with Alipay, WeChat Pay or USDT. Handle order issues, plan status and refunds through the official account pages, and don't send payment details to unknown contacts. VPN59 offers a 7-day no-questions-asked refund; see the refund policy for details. Troubleshooting records may help explain an issue, but don't invent refund terms that aren't listed.

A reproducible support ticket with sensitive details removed

When submitting a support ticket, describe what you expected first, then what actually happened. For example, “The browser works, but the desktop app times out at login” is clearer than “the network is broken.” Include your operating system, where you got the client, the local time and time zone when the issue occurred, the route region, and whether you could reproduce it on another network or route. If you couldn't run a comparison, say so; don't change unfamiliar system settings just to fill in the details.

Screenshots need only show the exact error, the selected configuration and enough of the interface to provide context. Before sending, hide subscription links, QR codes, authentication fields, private page content and payment details. Include only log excerpts relevant to the issue, keeping their order; don't publicly upload an entire long-term log. Avoid cropping so tightly that the context disappears. Support should be able to identify the screen showing the error without being able to extract access credentials from the image.

Symptom:
Expected behavior:
Operating system and client source:
Time of occurrence and local time zone:
Route region used:
Is the basic network working?
Results on other routes or networks:
Settings already changed:
Exact error and redacted attachments:
Temporary workaround currently available:

After submitting, add any follow-up results to the same ticket rather than creating separate, unrelated tickets for the same issue. If support recommends changing a setting, note its original value first, then make the change and report what happened. Once service is restored, undo temporary troubleshooting options and confirm that your usual rules, DNS and background permissions are set as expected. The goal isn't just to connect once by chance; it's to understand the scope of the issue, keep a restorable configuration and have a clear diagnostic path if it happens again.