VPN Troubleshooting Guide

Can't connect at all: narrow down the cause

“Can't connect” could mean the client won't start, the configuration won't load, the connect button does nothing, or traffic doesn't flow after connecting. Each points to a different place to start. Note the exact status and error message shown on screen—not just “it doesn't work.” Then disconnect the proxy temporarily and open a website you can usually access directly. If your regular internet connection is also down, check network access, any sign-in page, and your router first. Switching international routes is unlikely to fix an issue with the underlying network.

Set up a fair comparison

Once your regular connection is working, keep the device, client and target website the same, and test on another network. If Wi-Fi fails but another network works, the issue may be related to the current network, but that alone doesn't prove the router is at fault. Campus, workplace and public networks may require sign-in or have usage policies; follow the rules for that network. If a sign-in page appears, complete it before connecting. Don't disable system security features as a substitute for normal network authentication.

If the problem persists across networks, check that the client has a valid configuration selected, the route list isn't empty, and you've selected a specific route rather than an unresolved automatic group. Open the user panel's Account Overview and check your subscription status and available data. Account status, an imported subscription and a working route are separate things; one doesn't confirm the others. Seeing route names in the list isn't a reason to skip checking when the configuration was last updated or which option is selected.

Troubleshoot at the layer where the error occurs

For a configuration format, unsupported field or parsing error, return to the client download page and make sure you're using the import method intended for your client. For an authentication error, confirm the subscription belongs to the current account and that you're not using an outdated configuration. For a network timeout, keep everything else unchanged and select another route in the panel. If only one route fails, note its full label and when you tested it. Don't delete the entire subscription or describe an issue with one route as an outage across every region.

Check whether another VPN, proxy app or network security tool is running at the same time. Multiple programs can compete for the system proxy or virtual network interface, so the client may appear to connect even though traffic isn't routed. Quit other proxy apps using their normal exit options, then reconnect with the current client. Don't uninstall network adapters, remove drivers or reset all network settings: those steps can make the problem worse and may disrupt a work network that was functioning normally.

When to stop troubleshooting locally

If the system clock is noticeably wrong, correct the date, time and time zone before trying again. Encrypted connections validate credential timing, and a clock that's out of sync can cause certificate or handshake errors. If you see a certificate warning, don't bypass the check or install a root certificate from an unknown source. Managed work devices may have centrally controlled certificate and network policies; ask your device administrator whether this connection method is allowed.

If your regular connection and account are working, the subscription loads, and the same error occurs across different networks and routes, it's time to submit a support ticket. Include your operating system, client name, route label, exact error message and a comparison such as “works with the proxy disconnected, fails when connected.” If the client won't start at all, say whether the system blocked it or showed a permissions prompt. This is more useful than repeatedly clicking Connect. For setup steps, see the Guides to make sure you haven't missed a system permission.

Connected but websites won't load: check DNS and the request path

A client showing “Connected” usually means a connection component is running; it doesn't confirm that browser requests are taking the intended route. First establish whether all websites fail, only international sites fail, only one domain fails, or apps fail while the browser works. Choose a target you can reliably test and note the exact browser error: DNS lookup failed, connection timed out, connection reset or certificate error. These point to different stages of the request, and treating them as the same problem can break settings that were working.

First check whether the request reaches the client

Open the client's connection history or request log, then reload the target page. If the domain doesn't appear, check the system proxy, browser proxy and routing rules before changing DNS. Browser extensions can override system settings, and apps may use their own proxy address. If the request appears in the log, check the matched rule, outbound group and reason for failure. A log can show which processing stage a request reached, but one successful entry doesn't prove that every page resource loaded correctly.

DNS translates domain names into network addresses; a proxy carries requests. They work together but aren't interchangeable. System DNS, a browser's secure DNS and the client's DNS module may all be involved. If they use different paths, a domain may resolve successfully while the connection that follows doesn't behave as expected. First find out which component handles resolution, then adjust it according to the client's official documentation. Avoid adding a public DNS server you found online to every setting.

Check DNS results with system tools

On Windows, run the following query in Command Prompt. You can also run it on macOS or Linux if the same tool is available. The example domain only illustrates the command; replace it with the domain you're troubleshooting. A successful query means the tool got a result, not that your browser, proxy and target app all use the same DNS path. Different results don't automatically mean something is wrong: content delivery networks and regional routing can return different addresses.

nslookup example.com

If the result says the domain can't be found or the query timed out, note your network, the error and the client's status, then compare results with the proxy disconnected and connected. If the system query works but the browser still reports a DNS error, check whether secure DNS is enabled separately in the browser or an extension is changing the connection path. After saving your current settings, you can temporarily test the system's default DNS and then restore your original settings. Don't clear the cache, change DNS servers and switch routes all at once, or you won't know which change made a difference.

Tell DNS, connection and certificate errors apart

If the domain resolves but the connection times out, check the outbound route and routing rules. For a certificate error, check the system clock, the target domain and whether the network requires sign-in. Don't use “ignore certificate errors” as a permanent fix, and don't paste a resolved IP address into a browser to test a website. Many sites rely on the domain name for encrypted handshakes and site selection, so a failed direct-IP visit doesn't prove the route is down.

If text loads but images, video or sign-in components fail, inspect the resource domains. A website may load scripts and media from different domains; routing the main page through the proxy doesn't mean every resource uses the same rule. The browser's developer tools Network panel can help identify failed requests, but an exported log may contain sign-in details and sensitive parameters. When contacting support, share the error type, resource domain and matched rule rather than uploading an unchecked network log.

After making a change, close the old page connection and reopen the target to confirm the result is repeatable. If only a specific app is affected, see Split tunneling. To test the route, DNS and app separately, see How to Check Whether Your VPN Is Working. If the same DNS error occurs across networks, share a redacted query result with support instead of layering conflicting DNS settings on top of one another.

Slow speeds and peak-hour slowdowns: separate throughput from responsiveness

First turn “slow” into something you can observe: pages take a long time to start loading, downloads stay slow, video keeps buffering, or interactive apps are slow to respond. These can be affected by DNS, connection setup, sustained throughput or the remote service. A route's displayed latency doesn't capture the whole experience, and a shorter distance doesn't guarantee faster loading on every site. Identify what you're doing, then compare the same activity under different conditions rather than repeatedly switching routes based on one displayed number.

Rule out competing traffic on your network

Check whether your device is syncing cloud files, installing updates, downloading games or uploading files. Other devices on the same network may also use bandwidth; sustained uploads in particular can delay interactive requests. Pause background transfers where possible and test the same target again. A weak Wi-Fi signal, being far from the router or frequent access-point changes can also make performance inconsistent. If possible, compare with a more stable local connection, but don't credit a one-time improvement to a particular region's route.

Next, keep the target, client and proxy mode the same, and switch only the route. Compare available routes with different labels in the panel and record the results. See Global Servers for route types and region details. YuyuVPN covers 90+ countries / 170+ routes; that describes the range of available options, not a guarantee that a route in any particular country will suit your needs. The target service's server location, your network path and current congestion can all affect performance.

Look for peak-hour patterns

If performance drops only at certain times, note the time, network, route label and target service, then retest under the same conditions at another time. If multiple routes slow down on the same network but another network works better, focus on the local connection and network path. If the same route has the same issue across multiple networks, include that comparison in your support request. Peak-hour reliability depends on the actual path; no route label on this page guarantees stable performance at all times.

Don't run a large number of speed tests at once. Concurrent downloads compete for bandwidth, and browser caching can make a later visit appear faster. Use the same target, similar conditions and the same test steps to compare results. If only one site is slow while other sites and apps work, check that site's account, regional availability and service status. Streaming services may adjust picture quality automatically; note brief blur at startup separately from ongoing buffering.

Don't treat a plan upgrade as a universal fix

Check your available data and subscription status in the panel first. If you run out of data, follow the instructions for your account; not every slowdown means your plan tier is too low. Monthly plan data resets each month on the activation date; mid-cycle upgrades are prorated for the remaining days. See Plans & Pricing for available options. Data add-ons remain valid until used and never expire. Choosing a billing option addresses usage and billing periods; it doesn't replace checks of your local network, target website or route.

If you mainly use Cursor, Copilot or command-line tools, check whether a long-lived connection is dropping rather than downloads being slow. If a request starts but frequently stops mid-response, check disconnects and app proxy settings. See Long Connections and Reliability for AI Coding Tools. When contacting support, describe the type of activity and steps to reproduce the issue; that's more useful than simply saying “the internet is slow.”

Frequent disconnects and mobile background dropouts

First work out whether the client connection dropped, an app session ended, or the network itself changed. If the client still shows as running and other sites work while a chat or coding app disconnects, check the app's long-lived connection and server session. If the VPN indicator disappears from the system status bar, the client may have been stopped or another program may have taken over the connection. Note whether the drop happens when you lock the screen, switch networks, open another app or keep the device in the foreground. The trigger is more useful than the number of disconnects alone.

Compare foreground and background behavior

Keep the client in the foreground on your current network and check whether the target works. Then switch to the background or lock the screen as usual. If it fails only in the background, check how the system manages background activity, battery use and network permissions. On Android, settings vary by device manufacturer; check whether background activity or network access is restricted, or whether a battery-saving policy pauses the app. Change only the permissions this client needs; don't disable system security controls across the board.

On iOS, check the system VPN status, the network permissions granted to the client and whether another configuration is taking over the connection. On-demand connection options vary by client, so don't assume another app's menu names apply. If the system asks you to authorize the client again, make sure the prompt comes from the app you're using. Check the user panel for download eligibility and client access. Don't install an unknown configuration profile or certificate to fix a background issue.

Switching networks doesn't guarantee an existing connection will survive

When a device moves from Wi-Fi to another network, its public IP address and network path may change, so an existing session may not continue. Check whether the client reconnects and whether the target app recovers on its own. If only the app fails to resume, stop the current task and start it again. Don't assume an unfinished response means the route is completely unavailable. Save your work before switching routes or reconnecting during an upload, remote session or editing task, so troubleshooting doesn't cause additional loss.

On Windows, macOS and Linux, sleep, wake, closing the lid and switching network interfaces can cause similar issues. After waking the device, confirm the regular connection is back, then check the client and system proxy. Some apps keep using a connection established before sleep, so you may need to reopen the page or restart the app. If you have to restart the whole device every time it wakes, save the client logs from before and after waking and report the issue rather than treating a full restart as a normal step.

Check for conflicts between connection managers

Another VPN, work remote-access tool or network manager may replace the current interface or system proxy when it starts. Check whether the disconnect always happens when a particular program launches. Follow your organization's requirements for work connections; don't change managed policies to force two connections to run together. To switch between uses, disconnect and quit the current tool normally, wait for the system network to recover, then enable the next one. This helps avoid proxy addresses and routes overwriting one another.

If the client still disconnects with the app in the foreground, the same network, and other proxies closed, compare different routes. If only one route fails, note its label and the disconnection reason in the logs. If all routes fail, compare different networks. A timeout in the logs may be a symptom rather than the root cause, so also say whether the device was asleep, the network changed and other apps still worked. Don't share only the final error line; keep the context that shows what triggered it.

When contacting support, include the device type, operating system, client name, foreground/background behavior, trigger and how you restored the connection. If removing a battery restriction helped, specify the setting you changed so support can tell whether system management was involved. Redact subscription URLs, authentication details and other account information from logs. Background disconnects often require looking at system behavior; don't share your complete configuration publicly to seek a fix.

Subscription update failed: separate fetching, parsing and activation

A subscription update involves several steps: the client requests the configuration, parses the response, then loads it as the active configuration. A failed request, incompatible content or a configuration that loads without becoming active may all be called an “update failure,” but each needs a different fix. Keep the exact client error, current configuration name and last update time. Don't delete the old configuration straight away; it may still work and can help you compare the old and new content and route lists.

Check the subscription source and account status first

Get the current account's subscription link again from this site's user panel instead of copying it from an old chat, a screenshot or your clipboard history. A subscription URL may contain account credentials, so protect it like a password. Make sure you haven't copied extra spaces, line breaks, Chinese punctuation or explanatory text. Never paste a real subscription link into a public link checker or an online conversion tool you don't trust. For configuration compatibility, start with the import method provided in the panel.

Then check the current account's subscription status and data balance. Being able to sign in doesn't mean a usable route configuration is available, and route names left in the client don't confirm that your account status is unchanged. If the panel shows something unexpected, first make sure you're signed in to the right account, then check your order and subscription status. No email address is required to create an account—just a username and password—so keep your credentials safe and check the original account rather than creating another one to work around the issue.

Handle fetch errors and parsing errors separately

If the error occurs while fetching the subscription, check that the user panel opens on your regular network and whether the client uses a separate proxy path for “Update subscription.” If updates are set to go through the current proxy, a failed connection can create a dependency loop. Only if the client supports it and explains the option clearly, temporarily test another suitable update path. Save the original setting first, and don't change the system proxy and configuration content at the same time. Update behavior varies by client; follow the labels in the app you're using.

If the configuration downloads but the client reports an unsupported syntax, field or format, check that the import target selected in the panel matches your client. Some configurations are designed for a specific configuration engine; changing the file extension won't make them compatible. Don't delete fields you don't understand, especially when rules, outbound groups and DNS settings refer to one another. Try the matching import option in the panel first. If it still fails, give support the client name, selected import type and full error message.

After a successful update, check which configuration is active

When the client says the update succeeded, check that the active configuration is actually the one you just updated. Some clients let you save multiple configurations, and updating one doesn't automatically replace another that's in use. Check whether the selected group still points to a route that was removed or renamed, and select a valid one if needed. Finally, open the target website and check the request log to confirm the new configuration is handling traffic. Don't stop troubleshooting just because the last-updated time changed.

If you're concerned that importing may affect custom rules, back up your settings using a method supported by the client. Keep in mind that backup files may contain sensitive information. Don't upload them publicly or let an unknown configuration overwrite your system proxy. Give test configurations clear names, and tidy up old entries only after confirming the new one works. Too many duplicate configurations make it easier to select the wrong one, but don't delete everything before you know what's wrong and have a backup.

Submit a support ticket if the panel opens normally but the client still can't fetch the configuration, the matching import option keeps reporting a parsing error, or the route list after an update clearly differs from what the panel shows. Say which update stage failed, whether you tested another network, whether you kept the old configuration and what changed after the update. Redact subscription URLs and authentication fields in screenshots. For basic setup, see the Guides; for account and billing questions, visit the Help Center.

An app won't use the proxy: check rules and app-specific settings

If the browser works but one app doesn't, the basic connection may be established, but that doesn't prove the app uses the same route. It may use the system proxy, its own proxy settings, built-in networking or a connection method that bypasses the system proxy. Pin down what fails: the sign-in page won't open, account verification fails, images don't load, requests keep waiting or a response stops partway through. Note the app name, where the action starts and the exact error, then compare it with the client log. This helps distinguish a rejection by the service from traffic that never reached the proxy.

Start by checking whether the request appears

Open the client's connection history and repeat the failed action. If the request doesn't appear, check whether the app uses the system proxy, has its own proxy switch, or is covered by the current client mode. A working desktop browser doesn't mean terminal tools, developer apps and background services inherit the same settings. Command-line programs in particular may read only environment variables—or read them once at startup—so you may need to restart the process after changing them.

If the request appears in the log, check the matched rule and outbound group. An app may connect to separate domains for sign-in, APIs, static resources and downloads; if only some domains use the proxy, sign-in may work while the app itself fails. Don't simply add every failing domain to an exception or force it to connect directly. First understand what the rule is for, then use the client's supported rule editor and save the original rule so you can roll back if needed.

Test terminal tools separately

On macOS and Linux, run the following command in a terminal to check whether the current process environment contains common proxy variables. It only reads the settings; it doesn't configure a proxy or prove that an app actually uses those variables. If the output includes authentication details, don't paste it into a support ticket or public discussion. On Windows, check system environment variables and app settings instead; you don't need to copy commands written for a different terminal.

printenv HTTP_PROXY
printenv HTTPS_PROXY
printenv ALL_PROXY
printenv NO_PROXY

If you find an outdated address, first work out whether it comes from the current terminal session, a startup script or the app configuration, then update it using the relevant tool's documentation. Don't assume someone else's local proxy port is yours; check the listening address and port in your own client. Apps differ in their support for proxy variables, and they may handle capitalization differently. Save the original values, restart the target program after making a change, and use the client log to verify where requests go—not just that the variable was set.

System-wide traffic capture isn't a universal fix

Some clients offer a virtual network interface or a broader traffic-capture mode. It may work for apps that ignore the system proxy, but it can change permissions, routing and DNS behavior. Before enabling it, check the current client's documentation and confirm whether work networks, remote desktops or enterprise access might be affected. Don't switch network-capture modes on a remotely managed device without a recovery plan. If something goes wrong, restore the original mode and save the logs before investigating; don't add more proxy tools on top.

If the logs show that a request reached its destination through the route but the service returned an account, region, quota or access-policy error, check the target service's account and usage rules. A network connection can't satisfy a service's eligibility requirements or guarantee the same streaming catalog or AI features at all times. For streaming availability, see Streaming Availability. For long-lived connections in developer tools, see Access Tips for AI Coding Tools to tell handshake failures, slow responses and interrupted sessions apart.

In your support ticket, include the app name, failed action, whether the request appeared in the client, the matched rule and how other apps behaved. For developer-tool logs, remove access keys, private details in project paths and request bodies. You don't need to submit source code to show that there's a network issue. If only one app fails, describing its network path accurately is more useful than replacing the entire subscription or repeatedly reinstalling the system. Once it works, return to your usual routing mode and make sure new rules haven't affected apps that worked before.

Device-limit alerts and configuration differences across devices

YuyuVPN has no limit on the number of devices connected at the same time. If a client or page says “device limit exceeded,” don't assume there's a device cap. First identify where the message came from: the YuyuVPN user panel, the current client, system network settings or the target app's account page. Different services may use similar wording; a website's limit on signed-in devices isn't a YuyuVPN device limit. When taking a screenshot, include the name and context of the screen so the source is clear.

Device limits and connection resources aren't the same thing

No device limit describes how many devices can be online at once. It doesn't mean network tools on the same device can't conflict or that a local router can handle any amount of simultaneous traffic. Multiple proxy apps competing for an interface, an app limiting sign-in sessions or a heavily loaded router can all look like a device-limit issue. Don't force every device to disconnect just to test. Keep a working device as a reference and see whether the problem occurs only on a newly added device.

If one device works and another doesn't, compare the network, configuration name, last update time, proxy mode and selected route. If any of these differ, you can't attribute the issue solely to the operating system. Bring the problem device as close as possible to the working device's test conditions, then compare results. Import configurations using each device's own panel entry; don't share files containing account details through public links. On shared devices, sign out when finished and protect saved credentials.

Check system integration settings for each platform

On Windows and macOS, the system proxy often depends on the current network; work-managed settings may also be reapplied at sign-in or when you switch networks. On Linux, desktop apps and terminal programs may use different settings, and services running as another user don't necessarily inherit the current user's proxy environment. On mobile, check system permissions, app scope and background policies. These are areas to check, not a promise that every client has the same buttons and menus.

Don't assume one configuration file will work on every platform. Clients may differ in their support for fields, rules and system-wide traffic handling. Check the panel download page for compatible clients, then use the matching import method. Supported platforms: Windows / macOS / iOS / Android / Linux. iOS download eligibility is shown in the panel. Marketing pages don't provide public installer links, and you don't need a third-party conversion site to use a real subscription.

Confirm your account status and where the message came from

If the message appears in the YuyuVPN panel and conflicts with the no-device-limit policy, keep the full error and steps that triggered it, then submit a support ticket. If it comes from a client permissions screen, distinguish the client's own license rules from the route subscription. If it's from a target website, check that site's account information. Don't assume you need to pay for additional device slots, and don't give your username, password or subscription details to an unknown page claiming it can remove a limit.

This service accepts Alipay / WeChat Pay / USDT. Check Plans & Pricing and the panel for plan and data rules. You don't need to upgrade to diagnose a device issue. If you also see messages about low data or an invalid configuration, record them separately rather than treating several symptoms as a device limit. If account information conflicts, ask support to check the specific status instead of repeatedly creating accounts or making another payment.

After comparing devices, restore any normal settings you paused and confirm each device uses the intended route. Support needs to know how the working and problem devices differ, what happened under the same test conditions and where the alert appeared—not what private files are stored on your device. If you're on a shared network, get the administrator's permission before changing the router or gateway. Troubleshooting one person's device shouldn't disrupt access for others.

Contact support: organize evidence and verify recovery

Once your regular network is working, you've checked your account, confirmed the subscription source and can reproduce the same issue under controlled conditions, stop experimenting and submit a report through the user panel support ticket. You don't need to finish every check on this page before asking for help. For persistent authentication errors, configuration parsing failures, connection problems across networks or a mismatch between the panel and your subscription, share the checks you've already completed. Don't risk changing system settings just to work through every step.

Give support enough detail to reproduce the issue

Describe the symptom and environment in the title—for example, “Connection drops when the screen locks; works again in the foreground”—rather than “Help” or “It doesn't work.” In the message, explain the last known working state, when you first noticed the problem and which settings you've changed since. Use your local time and include your time zone so support doesn't confuse times from different regions. If the issue is intermittent, describe the triggers you've actually observed; don't invent a pattern to sound certain.

Include your operating system, client name, network type, proxy mode, full route label and target app. Don't share your account password or complete subscription. If the client displays a version number, copy it as shown; this guide doesn't assume that any particular version is trouble-free. For a managed work device, mention any work VPN or network policies, but don't upload internal network diagrams, work files or anything else that isn't needed to diagnose the issue.

Describe your comparisons, not just your conclusions

Record each test as “what changed, what happened and whether restoring the original setting fixed it.” For example, keeping the route the same, switching networks and recovering—then failing again on the original network—is a useful comparison. “I changed a lot of things and it still doesn't work” doesn't identify the cause. Say if you've restored a setting. If you make major changes while waiting for a reply, update the ticket; support's earlier steps may no longer apply to your current setup.

Share only log excerpts related to the trigger, not an unchecked copy of the entire folder. Remove usernames, passwords, subscription URLs, authentication headers, access keys and unrelated private information. Browser network exports may contain session credentials, and terminal output may include proxy authentication details. If you're unsure whether a field is sensitive, describe the error type first and share only confirmed, relevant excerpts as requested in the support ticket. Don't post raw files publicly and ask strangers to inspect them.

Test recommendations one at a time

Apply each suggested change separately and record what happens. Before changing the system proxy, routes or an existing work connection, make sure you know how to roll back. Once access is restored, test the original target that failed and verify sign-in, resource loading and continued use. Opening one ordinary website successfully doesn't prove the app that failed is fixed; likewise, getting the app working doesn't prove a new rule hasn't affected local access that worked before.

For mobile issues, retest after locking the screen, returning to the foreground and switching networks. For subscription issues, confirm that the update succeeded, the configuration is active and the correct route is selected. For speed issues, repeat the same activity under similar conditions. If the fix is only temporary, add the trigger details to the original ticket rather than starting a new one without context. Specifying exactly which step still fails is more useful than saying “it still doesn't work.”

Keep a record of settings that work for you: client, configuration source, usual mode and any system permissions to keep in mind. Never put a real subscription URL in public notes. Restore or clean up temporary proxy variables, rules and DNS settings so they don't combine into a new problem later. For getting started, revisit the Guides; for common account questions, see the Help Center. This guide helps narrow down the issue; check your account status in the panel or through a support ticket.

If the service still doesn't meet your needs after troubleshooting, review the 14-day no-questions-asked refund policy and Terms of Service, then explain your situation through the panel. Refund requests and technical troubleshooting are separate matters; don't keep repeating tests instead of submitting an account request, and don't pay again before checking your status. Document the issue clearly, protect your credentials and make changes you can roll back.