VPN Troubleshooting Guide

Can't Connect: Check Your Network, Account and Client

“Can't connect” can mean the client won't start, the route list is empty, the connection button keeps spinning, or a website simply won't load. These are different problems and need different fixes. Describe exactly what you see—for example, “The route list updates, but connecting to Tokyo times out.” Note when it happened, which network you were using and the exact error message. Then choose what to check next. Don't delete your configuration first; that could erase both your settings and useful troubleshooting evidence.

Establish a baseline for your local network

Disconnect the client, then try opening a website that normally works without a proxy. If it still won't load, check your network first: does the Wi-Fi require browser-based sign-in, is the gateway working, and is an old system proxy still enabled? Public networks sometimes require you to accept their terms in a browser before connecting through a proxy. Switching routes repeatedly won't help if the request hasn't reached the route's entry point. On a work network, make sure your intended use complies with its policies.

If possible, test on a different network while keeping the device, client and route the same. If the connection works on the new network, the original network environment is the more likely cause. If it still fails, check your account and client. Don't change networks, reinstall the client and switch routes all in one test. Change one thing at a time so you can identify what made a difference and restore your original setup if needed.

Check your account and configuration source

Open the user panel to check that your plan is active, you have data available and the client is using a subscription from your current account. Monthly plan data resets each month on the activation date, so don't assume it resets on the first of the month. If the panel doesn't show what you expected, check your order and data records before troubleshooting the connection. An old route list in the client doesn't confirm that your account is currently eligible to connect.

If the route list is empty, troubleshoot the subscription import before assuming all routes are down. If routes appear, compare routes in different regions and see whether they return the same error. If only one route fails, note its exact name and temporarily try another. If every route reports the same authentication or configuration error, check the subscription and local core first. Don't replace your existing subscription with configuration copied from an unknown source or chat.

Check permissions and identify the error

Desktop clients may need permission to set a system proxy, run a background service or use a virtual network adapter. Mobile clients need permission to add a VPN configuration. If system authorization was revoked, the button may appear to connect even though traffic isn't being routed. Check the client log for errors that coincide with startup. Look for permission issues, port conflicts, authentication failures or connection timeouts. Fix permission issues in system settings, and check for other networking tools if a port is in use. Repeatedly clicking Connect won't resolve either problem.

If your network and account are working and tests across different networks and routes still can't connect, submit a support ticket. Include the stage where it fails, the exact error, where you got the client and the comparisons you've already made. “Nothing works” isn't enough detail. Redact subscription URLs, authentication fields and account details from logs before sharing them. Support needs the context around the problem, not your password or full subscription link.

Connected but Websites Won't Load: Check Routing and DNS

When the client says it's connected, that usually means the connection process completed or the local service started. It doesn't prove that your browser request reached the website. Check separately whether traffic is entering the client, the domain is resolving and a remote connection is being established. Try more than one website, and note whether the page hangs, DNS lookup fails, a certificate error appears or the service rejects the request. Each points to a different part of the connection; a blank page alone can't tell you whether the route is working.

Confirm that requests reach the client

Check the client's connection history or request log for the domain you're trying to visit. If no corresponding request appears, check the system proxy, browser-specific proxy settings, virtual network adapter mode and app bypass rules. If a request does appear, check which rule matched and which route was selected. A rule set to direct connection can send a site outside the selected route even while the client is connected. You can temporarily change the traffic-routing mode to test, but restore your usual settings afterward so unrelated apps aren't routed differently.

Browser extensions, developer tools, remote desktop software and other proxy clients may all have their own proxy settings. Temporarily disable nonessential traffic-routing features one at a time, leave your current client running and retry the same request. If the site works after you quit a tool, the tools were competing for control; the website itself probably hasn't changed. Don't run multiple system-wide tunnels to “boost” your connection. They may compete over routes or send traffic into a loop.

Separate DNS lookup from remote access

DNS translates domain names into addresses. If a lookup fails, the browser hasn't begun connecting to the site. A successful lookup only means an address was returned; the connection can still fail afterward. Run the query below in a system terminal to see whether your local resolver returns a result. The example domain is for demonstrating the check, not a guarantee that any particular service is available. If the command isn't available, use a network diagnostic tool already on your system rather than installing unknown software just to run the example.

nslookup example.com

Record DNS timeouts, returned addresses and whether the page loads as separate results. When a client uses virtual DNS or handles DNS traffic, a system query may return an address used for internal mapping; the address alone doesn't prove something is wrong. Also check whether the client log recognizes the original domain and whether the website request completes. Browser Secure DNS, encrypted system DNS and client DNS may use different paths. Follow your client's guidance to coordinate these settings instead of stacking them at random.

Check caches, certificates and site-specific issues

After changing routes or DNS settings, your system or apps may continue using cached data. Close and reopen the affected page, then clear the relevant cache using the method for your platform. Restart the app normally if needed. Before running a command to clear the system cache, make sure it applies to your platform. Don't enter random public DNS addresses into every field or disable certificate checks. DNS resolution and certificate validation are separate issues; bypassing validation can hide errors and expose your data.

If only one website shows a certificate error, check your device's date, time and time zone, then verify the domain spelling so you don't mistake a lookalike address for the real site. If the same error appears on every website, check for a network sign-in page, connection inspection by security software and workplace network policies. On a managed device, ask your administrator to check the policy. Don't delete certificates or turn off essential protections yourself.

To decide whether you need support, check whether the problem happens across browsers, networks and routes. If only one browser is affected and other apps work, gather details about its settings first. If several apps fail to resolve domains, include the DNS results and corresponding client logs in your ticket. Don't upload your entire browsing history; include only relevant domains and error excerpts. If the target service displays a region or account message, check the app troubleshooting section. Working DNS won't override the service's own access requirements.

Slow Speeds and Peak-Hour Lag: Compare Routes Fairly

Start by describing what you're trying to do. A slow-loading webpage, buffering video, slow download and choppy remote meeting don't necessarily have the same cause. Websites depend on DNS resolution and connection setup; video depends on sustained throughput; interactive apps are more sensitive to latency and jitter. Don't treat a speed-test result as a substitute for real-world performance, or assume that lower latency makes every service faster. Fix the task you're measuring, then compare routes to get useful results.

Rule out local bandwidth use and Wi-Fi interference

Check whether your device is syncing files, updating its system or downloading large files. Then see whether other devices on your home network are using bandwidth. Pause background tasks where possible and retry the same activity. A strong Wi-Fi signal doesn't rule out interference. If you can, test using a more stable connection or closer to the access point. If websites are also slow without the proxy, troubleshoot your local network first; not every slowdown is caused by an international route.

Keep the device and content the same during each test. Record the network type, selected route, time and what happened. For video, check whether playback stays smooth, not just whether it starts. For downloads, consider whether the server is limiting speed. With AI Tools, distinguish page loading from the time it takes the service to generate a response. If the platform is processing a task, the wait may be on its end; switching routes may not help. The task details are more useful than an isolated speed figure.

Understand route types and choose an exit

IEPL, relay and direct routes describe different network paths; they aren't a performance ranking that holds at all times. Your experience also depends on your local network provider, cross-border routing, exit region and the destination service. Choose a region that suits the service you're using, then compare routes in that region. The closest exit isn't always on the best path, and an intercontinental exit isn't necessarily broken just because its latency is higher. See the global routes page for the available groups.

Include time of day when testing peak-hour slowdowns

If the same route works during the day but slows down in the evening, repeat the same task under similar conditions. Don't compare different times, videos and devices as if they were the same test. Try another route in the same region, then compare with a route in another region to see whether the slowdown follows a particular path. If every route slows down only on one network, congestion or routing on that network is more likely. If only the target platform is slow, check its content delivery and service status.

For streaming, distinguish access to the catalog from uninterrupted playback. Being able to access a catalog doesn't guarantee smooth playback at your chosen quality; higher resolutions need more sustained throughput. Let the player choose a quality automatically first and see whether buffering continues, then restore your preferred settings gradually. See Netflix catalogs and streaming bandwidth for more on regions and playback. A successful playback test doesn't guarantee permanent access.

When submitting a support ticket, describe a task that's easy to reproduce, when the issue occurred, the route name and the results of your comparisons. Explain whether all requests are slow, the first response takes a long time or data transfer is interrupted. If you include a speed-test screenshot, describe the test environment so the result isn't misinterpreted. VPNUrban covers 110+ countries / 170+ routes, but that doesn't mean every route performs the same on every network. Troubleshooting should reflect your current connection.

Frequent Disconnects and Mobile Background Drops

First distinguish a disconnected tunnel from an interrupted app session. If the client shows disconnected or the system VPN status disappears, it's a connection-level issue. If the client stays connected but a meeting ends or a webpage asks you to sign in again, the app session may have expired. Note what changed in the client and what the logs show when the issue occurs, especially whether it follows a locked screen, network switch, sleep or battery-mode change. The sequence of events is often more useful than the final error message.

Separate network switching from route issues

When a device switches between Wi-Fi and mobile data, its address, gateway and routes may change, and an existing connection may not survive. Test on a single network with the client in the foreground, and see whether it can complete the same task reliably. If it works in the foreground on a fixed network but fails after switching networks, check how the client reconnects and whether the app needs to restart its session. Don't rely only on the system status-bar icon; it may update after the connection has already changed.

If your network hasn't changed but the connection drops periodically, check for system sleep, a stopped background service, DNS failures or remote timeouts just before the disconnect. Try another route on the same device, then test the original route on another device. If the problem follows the device, check its local setup. If it happens on one route, note the route name and save the logs. If all devices also lose direct internet access, check the network itself. Keep other conditions as consistent as possible when comparing results.

On mobile, check background restrictions

On Android, background activity, battery optimization, auto-start and data-use restrictions can affect whether the client keeps running. The settings vary by device and system version. In the app info page, check whether background activity is restricted and whether battery saver pauses network tasks when the screen is locked. Change only the permissions the client actually needs; don't disable system-wide power-saving features across the board. Afterward, lock the screen and resume the same task to check whether it helped. Avoid enabling unrelated permissions.

On iOS, check that the VPN configuration is still allowed and whether another VPN or managed configuration is also active. Note whether the issue occurs only when a particular app is in the background. A lack of new entries in the client log doesn't necessarily mean the system tunnel has stopped; check the system connection status and whether access works when you return to the app. If your device is managed by your organization, don't remove its profile yourself. Ask your administrator to check the connection policy and configuration compatibility.

Desktop sleep and session recovery

After waking from sleep, Windows, macOS and Linux may reinitialize the network adapter while the proxy process retains its old connection. Wait for your local network to recover, then disconnect and reconnect the client normally and reopen the affected app. If that fixes the issue, report it as “stops working after wake; reconnecting restores access” rather than simply calling the route unstable. Don't treat launching at startup or automatic reconnection as a fix; these may just repeat the same failure.

Frequently changing exits may also prompt a destination platform to reverify your account because it detects a change in your network environment. Choose a route before starting a meeting, remote editing session or upload, and keep the exit consistent if possible. If you need to switch, save your work or pause the transfer first, then reconnect your session. If the app doesn't resume automatically, the new route may be working; the app might simply need to retry or reconnect.

If disconnects continue on a fixed network, with the app in the foreground and across different routes, submit logs from before and after the drop. Include the system's battery mode and whether the screen was locked. A screenshot of the final “Disconnected” message is rarely enough to identify the cause. If the issue occurs only in the background, say whether the client works in the foreground. Note if the system network connection also disappears. Don't leave verbose logging enabled indefinitely just to gather more data; restore your usual log level after reproducing the issue.

Subscription Update Failed: Check the Source, Format and Plan

A subscription provides the client with routes and rules. It's a configuration source, not a regular webpage or your account password. An update can fail while downloading the configuration, parsing its format or applying it. Start with the exact error: an unreachable URL, certificate error, parsing failure and apply failure each need a different approach. Keep your existing configuration, confirm that the panel loads, then get the subscription for your current account. Don't send your full subscription URL to a public checker just to test it.

Check the source and how you copied it

Get the current subscription from the user panel and choose the import method supported by your client. When copying, don't include explanatory text, line breaks, quotation marks or an ellipsis. Messaging apps may collapse long links, and screenshots can't preserve a complete URL, so neither is suitable for transferring a configuration. If your client can import directly from the panel, check the configuration name afterward to make sure you're not still using an older entry alongside the new one.

If the panel provides the subscription but the client reports a format error, check the import type and client compatibility. The client may mistake an error page returned by the website for a configuration, leading to a confusing parse error. That doesn't mean you need to edit the entire configuration by hand. First confirm that the request succeeded, then check the format. For help getting, importing and protecting your subscription, read the complete guide to subscription links.

Separate the update path from the connection path

When an old configuration stops working, the client may still try to download the new subscription through the old proxy. This can create a dependency: “I have to connect to update, but the old connection no longer works.” If your client lets you choose a network for updates, test direct access and updating through the existing proxy separately, and record the results. Don't change global routing or system DNS without evidence; first confirm that the failure occurs during the subscription request. On public networks, complete sign-in first.

If the system clock is significantly wrong, certificate validation may prevent the subscription request. Correct the time and try again; don't disable certificate checks. If the update succeeds but applying the configuration fails, check whether the core supports its features and whether local custom rules conflict with the new configuration. Back up your custom settings, then compare them with the original configuration from the panel. Restore custom settings one at a time to identify any conflicts without permanently giving up the routing you need.

Check your data, billing cycle and account status

Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated based on the remaining days. If you've used all your data, waiting for the calendar month to start may not restore it. Check the billing cycle shown in the panel. A successful subscription download doesn't mean the route is usable; don't treat a successful update as proof that your plan is active. Compare options on the pricing page.

Data add-ons cost ¥158 for 300GB, ¥358 for 1000GB and ¥658 for 3000GB. They remain available until used and never expire. “Never expire” describes the data add-on's validity, not continued access after the data is used up. If the panel and client show different information, save screenshots of the relevant pages and your order status, then ask support to check. Don't pay again before confirming. After payment, rely on the panel's confirmation instead of assuming the subscription updated based only on the payment app's return page.

If you think your subscription has been exposed, use the reset option in the panel if available. If you can't find it, submit a support ticket; changing the local configuration name won't help. Update old subscription URLs saved on your other devices, too. Attach only redacted errors and the configuration type to a troubleshooting ticket—not the full URL, query parameters or QR code. A QR code can contain subscription credentials; fully obscure it in screenshots rather than blurring just a small section.

An App Isn't Using the Proxy: Check Rules and App Settings

If a browser works but an app doesn't, the basic connection probably isn't completely down, but that doesn't automatically mean the app is at fault. Apps may use different proxy settings, DNS methods and transport protocols. They may also decide whether to offer a feature based on account region, payment details or service policies. First check whether the client receives requests from the app. Then determine whether traffic routing is missing, a rule selected the wrong route, or the service received the request and rejected it.

Use connection logs to confirm the actual route

Close and reopen the app while watching the client's connection log. If no related requests appear, check whether the app follows the system proxy, has its own proxy setting or is covered by the current traffic-routing mode. A system proxy doesn't necessarily cover every process. Virtual network adapter mode can route more traffic, but it also needs the right permissions and routes. Don't change the app's account just because your browser works; first confirm that its requests are reaching the expected path.

If requests appear in the log, check the matched domain and process rules and the selected policy group. Some apps connect to multiple domains for sign-in, content and file transfers; these requests may not use the same address. Adding a rule for the homepage alone may let you sign in but prevent content from loading. Adjust rules based on the failed requests, not a rule set copied from an unknown source. Save the original values first and note whether each rule is in the subscription or a local override, so an update doesn't overwrite it unexpectedly.

Expand traffic routing temporarily for diagnosis only

If the client lets you temporarily route more traffic through the proxy, use that to check whether routing rules are the cause. Run only the app you're testing and see if it starts working, then restore your original mode. If broader routing solves the problem, find the missing rule rather than routing all traffic the same way permanently. Work intranets, printers, local file sharing and other services may need direct access; don't disrupt them to fix a single app.

If the issue continues with broader routing but the client is receiving requests, check whether DNS resolution fails, the connection times out or the service returns a specific message. Voice calls and meetings may use different transport methods from ordinary websites, so a working webpage doesn't prove every type of traffic works. Check the client and app documentation for supported settings. Don't change the MTU, disable system protections or open extra ports without knowing why. For workplace apps, ask your administrator which network methods are allowed.

Distinguish network issues from service eligibility

Tools such as ChatGPT and Cursor may run different checks when you load a page, sign in and send a request. Loading the homepage doesn't mean your account is eligible for a particular feature. If the service reports a usage limit, account issue or region restriction, read the message instead of switching routes repeatedly. Note exactly where the process stops, and distinguish the service's response from a client network error. Network acceleration can improve the route; it can't change a third-party service's account eligibility or usage rules.

Streaming access may also depend on account region, catalog licensing, app cache and device settings. After changing exits, the app may keep an old session or cached catalog. Close and reopen it normally before checking again; don't repeatedly clear all app data. Clearing app data can affect downloads and sign-in state, so check what will be lost first. If the platform explicitly rejects the current exit, compare other suitable routes and tell support which service and message you saw. Access depends on the result you actually get.

For this kind of support ticket, include the app name, the feature that failed, the client's traffic-routing mode, the matched rule and whether only this app is affected. Instead of saying “AI doesn't work,” describe what happened: “I can sign in on the website, but sending a request returns this message.” Redact session content, work materials and account identifiers from screenshots. If logs contain unrelated domains, include only the relevant excerpts from the time you reproduced the issue. Don't expose access records for other services used in your work environment.

Platform Differences and “Device Limit Reached” Messages

VPNUrban supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices. If you see “device limit reached” or a similar message, don't assume your plan limits the number of devices or choose another plan just to add one. First find out whether the message came from the VPNUrban panel, the local client or the destination platform. Similar wording can refer to app sessions, client authorization or a third-party account—not this service's device policy.

Identify where the message actually came from

Keep the message visible with its surrounding context, and note whether it appeared before connecting, during import or after opening a website. If it came from the client, check that you got the client from the panel and didn't import a configuration for another service by mistake. If it came from the destination platform, follow that platform's device and session rules. If the VPNUrban panel clearly shows a message that conflicts with its unlimited-device policy, submit a support ticket to check your account. Don't delete configurations on other devices and keep retrying.

If several devices have the same issue, check whether they share a network and subscription. Devices on the same network failing together may point to a change in that network. If devices on different networks also fail, check the account, subscription and routes. If only one device is affected, check its permissions and routing settings first. Unlimited devices doesn't mean local settings sync automatically: after updating a subscription or changing a configuration, check what's actually selected on each device.

Check traffic routing by platform

On Windows, if direct internet access still doesn't work after you exit the client normally, check whether a system proxy is still set and whether other software keeps changing proxy settings. On macOS, closing a window may leave the background service running; use the client's exit option when checking for conflicts. On both systems, deleting a virtual network adapter or network extension should not be your first step. It could affect other apps and make recovery harder. Identify the component first, then remove it using the official uninstall process.

On Linux, a desktop proxy, terminal environment variables and system routes are separate settings. A browser may use the desktop settings while a command-line tool uses its own configuration, so they can behave differently. Check whether the terminal inherited an old proxy variable, whether the current session loaded a different configuration and whether the background service is actually running. Don't paste environment variables containing authentication details into a support ticket or run an administrator script from an unknown source to “fix your network.”

Get the client and restore your configuration

Find the client in the download section of the user panel. After signing in, you can get clients for Windows, macOS, Android and Linux; the iOS download option requires an active plan. Sign in to access your subscription. If an option isn't visible, check your account and plan rather than searching for an installer with a similar name. For the initial setup and import steps on iPhone, see the iOS setup guide. This page covers troubleshooting.

Before reinstalling, back up any necessary local rules and non-sensitive settings, and note which configuration is selected. Disconnect normally, then uninstall the client using the steps for your platform. After reinstalling, test the basic configuration from the panel before restoring old settings; otherwise, you may bring back the original problem. If the basic setup works, restore your custom settings one at a time. Backups may contain subscription information, so keep them somewhere trusted and remove temporary copies securely when you're done.

When to Contact Support: Evidence, Recovery and Refunds

Troubleshooting isn't about trying every setting; it's about narrowing the issue down to a specific, explainable point. If you've confirmed that direct internet access works, your account is active and you've compared relevant networks and routes, random changes are unlikely to help. Summarize what you found and ask for help through a support ticket in the panel. Submit a ticket promptly for payment issues, a suspected subscription leak or a mismatch between the panel and what you see. You don't have to complete every technical check first.

Describe steps that someone else can repeat

Start your ticket with the scope: can't connect at all, one website is affected, one device is affected, or the issue happens only on a particular network or at certain times. Then list the steps to reproduce it and what you expected to happen—for example, which route you connected to, what feature you opened and what error appeared. Say when it began and whether you recently updated the client, switched networks or changed rules. Skip a long account of normal use; help support see the key difference first.

Next, list the comparisons you've made and what happened. Useful detail: “It works on another network but still fails on the original one.” “I tried everything” isn't. Include your platform, the client name shown in its interface, the current traffic-routing mode and where the configuration came from. If you don't know the name of a setting, attach a redacted screenshot instead of guessing. Clearly mark checks you haven't performed so support doesn't draw conclusions from assumptions.

Issue: After connecting, the target website keeps loading
Impact: Browser affected; other apps not tested yet
Network: Home Wi-Fi
Current route: Enter the route name shown in the client
Steps to reproduce: Connect to a route, then open the target website
Exact error: Enter the message shown
Comparison results: Enter what actually happened after switching networks and routes
Recent changes: Enter any updates or changes to rules or system settings
Attachments: Redacted screenshots and logs from the relevant time

Include only the necessary log details

Logs should cover the time before and after the issue and preserve exact errors and their sequence. A DNS, permission or authentication message before a failed connection is often more useful than the final timeout. Include only the relevant time range, not a complete long-term log. Redact usernames, order IDs, subscription URLs, QR codes, authentication fields and personal content from screenshots. Support doesn't need your password. Pasting a full subscription into a public page is never a routine troubleshooting step.

You can still submit a ticket if the problem is hard to reproduce, but describe when it happens and what you don't know yet. For intermittent issues, note the device state, network and task the next time it occurs rather than filling in details from memory. After support suggests a change, try one key step at a time and report the result. This keeps the troubleshooting history clear, avoids repeated requests for the same information and reduces the risk of deleting the wrong configuration.

Keep a way back, then check the service policies

Before troubleshooting, record your original settings and note the scope of each change. If a change doesn't help, restore the original value before trying the next one. After temporarily broadening traffic routing, pausing an extension or changing background permissions, decide whether to keep the change only after testing. Before actions that need administrator access, remove network components or change workplace device policies, confirm their impact and that you're authorized. Don't disrupt other work connections just to get one webpage working again.

Use panel records and the pricing page for account and billing questions. Payment methods: Alipay / WeChat Pay / USDT. No email address is required; create an account with a username and password. If you've forgotten your account details, use the available panel process or explain the issue in a support ticket. Don't post payment records publicly. Plan upgrades, data resets and data add-ons each have different rules. Specify which one applies so an exhausted data allowance isn't mistaken for a technical issue.

VPNUrban offers refunds within 7 days, no questions asked. For eligibility and instructions, see the Refund Policy and Terms of Service. To request a refund, submit a support ticket through the panel with the necessary order details; you don't have to troubleshoot indefinitely. After the issue is resolved, retest the original task and check that temporary settings have been reverted. Save your working configuration and troubleshooting notes so you can start from a known baseline if the same symptoms return.