VPN Troubleshooting Guide

First check whether your local network can reach the internet

“Can't connect” can describe several different states: the client cannot start a connection, the connection repeatedly times out, or it connects and immediately drops. Note the exact message instead of assuming the route is at fault. Pause the client, keep the current configuration, and open a site you can normally access without it. If that site also fails, check whether your device is online, the Wi-Fi network requires sign-in, or another proxy setting remains active. Switching routes repeatedly won't tell you much until basic connectivity is restored.

Hotels, guest networks and public hotspots may require you to open a sign-in page first. A connected icon only means your device joined the network; it doesn't confirm that internet access has been granted. Complete the network provider's sign-in process, then reconnect in the client. If the sign-in page doesn't appear, you can temporarily quit other network tools and reconnect, but don't bypass the network's access rules. You can also compare with another network you're authorized to use and note whether the problem follows your device or the network.

Check permissions, configuration and route handshakes

If the client reports an error as soon as you tap Connect, check whether the system is asking you to authorize a network extension, virtual network adapter or VPN configuration. A previously denied permission, insufficient account privileges or a security policy blocking a component can stop the connection before it starts. Use the client from your user panel and grant the permissions requested by your system. Don't download unofficial “fix” drivers. If your managed device won't allow network components to be installed, ask your administrator which connection methods are permitted.

If the client starts connecting but stalls during the handshake or times out, make sure the subscription updated successfully and select a route currently shown in it. Note the failing route, then compare it with one in another region. If only one route fails, focus on how that route interacts with your current network. If all routes fail, check your account status, system clock and local network. An incorrect system date can interfere with secure connection checks; enable automatic time synchronization instead of disabling certificate checks.

Network tools running at the same time can compete for proxy ports, routes or virtual adapters. Temporarily quit other proxy clients and network-filtering tools you've installed, then test this client. Restore your normal security settings when you're done. If the log says an address is already in use, identify the program using it instead of changing a whole range of ports at random. After waking from sleep or switching networks, stop and restart the connection so the client can detect the current default network; don't keep importing the same subscription.

Use the comparison results to choose what to check next

Try two comparisons: the same device on a different network, and a different device on the same network. If the first works but the second still fails, the network is worth investigating. If other devices work but yours continues to fail, local permissions, leftover settings or network components are more likely. These comparisons narrow down the possibilities, but one successful attempt doesn't prove the root cause. Keep the route and test conditions similar, and avoid changing the client, network and region all at once.

Submit a support ticket if your basic network works, your subscription is valid, permissions are in place, and the same error persists across different routes. Include your platform, the version shown in the client, the time and time zone, network type, failing route name and a redacted excerpt of the error. List what you've already tried so support doesn't repeat the same tests. If this is your first setup, return to the Setup Guide and check the import steps. If the log reports an authentication failure, see the subscription section to check that your account and configuration match.

A connected status doesn't guarantee that a website is reachable

A connected status usually means that a connection has been established at one point in the path. It doesn't confirm that DNS, app routing and the destination website are all working. Compare different kinds of destinations: sites you normally visit directly, sites that need an international route, and the specific service that's failing. If only one site is affected, check the destination service, account permissions or regional requirements first. If no websites load, check whether the system proxy points to a client that's no longer running or another tool has taken over the default route.

Browser errors can help identify where things are failing. “Server IP address could not be found” often points to DNS; “connection timed out” may involve the route or the destination; and “certificate not trusted” calls for checking the system clock, site address and any security software inspecting encrypted connections. Don't try to fix every error by changing DNS. Note the full browser error and check the client log for requests at the same time. If there's no record of the request, the app may not be going through the client at all, rather than failing after traffic was routed.

Check DNS without losing sight of the lookup path

DNS translates domain names into addresses, but results can be affected by system cache, browser Secure DNS, client lookup settings and the network you're using. Start with a system diagnostic command to check whether the failing domain lookup times out and what records it returns, then compare with the client log. Different lookup paths returning different addresses isn't necessarily a problem: content delivery networks may route traffic by region. Focus on whether the lookup completes, whether the result is reachable and whether the request follows the expected path—not on making every device show the same address.

Windows：
nslookup example.com

macOS / Linux：
nslookup example.com

On systems with dig installed:
dig example.com

Replace the example domain with the one that's actually failing. You don't need to include login parameters or a full page URL. If the command fails, keep the error text. If it succeeds but the browser still fails, check whether the browser uses its own DNS settings. If you entered a DNS server manually, note the original value, then restore the system or client default for comparison. Don't stack custom system DNS, browser-specific DNS and advanced client rules all at once, or it will be hard to tell where requests are going.

Clear stale lookups and handle certificate warnings safely

After changing DNS settings, existing connections and cached results may still use the old values. Close the failing page, reconnect the client, then reopen the browser and test again. Clear the DNS cache using your system's instructions only if needed; on managed devices, ask your administrator. A private browsing window can help rule out some browser state, but it doesn't isolate system DNS or network extensions. Don't declare the route fixed just because a page opens in private browsing—verify again in your normal setup.

If you see a certificate warning, stop before entering account details. Check the domain spelling and system time, and make sure you're not on a public network that still needs sign-in. A corporate network may use managed certificates and access gateways; ask your administrator rather than deleting trusted root certificates yourself. Don't disable certificate validation just to keep browsing. If the same site works on another trusted network but the current network keeps showing a replaced certificate or redirect page, include those observations and network details when troubleshooting.

If DNS succeeds and the request reaches the client but the destination is still unavailable, try a route that meets the service's regional requirements and check whether only a particular exit is affected. A matching region doesn't guarantee the destination will accept that exit; the service may also apply account or risk policies. If the page loads but sign-in or resources fail, note whether the issue affects the main page, an API or static resources. A redacted domain, the stage where it fails and comparison results are more useful in a support ticket than “the website won't load.”

Separate slow response from slow data transfer

A long wait before a page starts loading and slow transfer after a download begins are different problems. The first may involve DNS, connection setup, authentication or the destination service. The second calls for checking your local network, the route and the destination's ability to send data. Note which stage feels slow instead of submitting only a speed-test screenshot. Video, file downloads, remote work and AI chats also use different kinds of connections, so a good result on one speed-test page doesn't guarantee that your apps will perform just as well.

Pause system updates, cloud sync and other data-heavy tasks first, and check that your device isn't sharing bandwidth in the background. A strong Wi-Fi signal can still be affected by interference on the same channel; if possible, compare with a more stable connection. Check whether the device is overheating, in power-saving mode or running other demanding tasks. If sites you normally access directly are also slow when the client is off, troubleshoot your local network first. Switching international routes won't fix a local problem; it just changes the exit.

Compare routes using the same task

Keep the destination, device, network and client mode as consistent as possible when comparing routes. Don't compare video loading in one region with download speed in another, or cached content with a first-time load. After switching routes, reconnect the app so it doesn't keep using an existing connection through the old exit. Browsers and desktop apps may keep long-lived connections open. If needed, fully quit and reopen the app, then repeat the same action and compare responsiveness and consistency.

Distance is only one factor. Performance also depends on the entry path, routing arrangements, cross-border segments and connectivity between the exit and destination service. Labels such as IEPL, relay and direct describe how a route is organized; they don't guarantee a particular speed under every network condition. First choose a route that meets the destination service's regional requirements, then compare routes for the same use. See the Routes page for route types, or read our guide to choosing a route by region, type and use instead of repeatedly guessing based on region names.

During peak hours, record when it happens instead of only switching regions

Peak-hour issues can occur at different points: your home connection, carrier interconnection or the route itself. Being fine during the day and slow at night shows a time correlation; it doesn't prove that a particular route lacks capacity. Note roughly when the problem starts and ends, your time zone, network and affected destinations. Compare routes and networks while the issue is happening. If switching networks fixes it but switching routes doesn't, your local connection deserves a closer look. If one route stays problematic while others work, keep its name for further investigation.

For choppy playback, distinguish network delays from device decoding. If audio and video fall out of sync, the device heats up, changing quality helps immediately, but other network requests work normally, check the player and device load. For slow downloads, rule out source-site throttling, disk writes and browser extensions. Don't launch lots of downloads just to get a better-looking result: it changes the test conditions and may affect other devices. For work and interactive tasks, consistent performance and recovery from failures are often more useful than a one-off peak speed.

If you need support, provide a comparison using the same task, the time of the issue, route name and destination type, and say whether another network is affected too. Avoid vague reports like “it's really slow,” and don't present an unverified guess as a conclusion. You can temporarily use a route that works and suits your needs, but keep a record of the original issue. Plan allowance and route performance are separate; upgrading isn't a general fix. Check the Plans page for data options if you need more data.

Identify which connection is dropping

A video call ending, a website asking you to sign in again and the client disconnecting may all be described as “dropping,” but they need different checks. When it happens, see whether the client's status changes, the system network icon fluctuates or other apps lose access too. If the client still shows connected but only one app session ends, check that app's sign-in policy and persistent connection before assuming the underlying route dropped. Note the order of events to tell whether a network change ended the app session or the app ended it on its own.

Look for something that happens at the same time as the disconnect: the device sleeping, closing its lid, switching Wi-Fi networks, moving from a hotspot to another connection, starting another network tool or entering power-saving mode. When the network address changes, existing connections may stop working; the client needs to rebuild the path, and the destination app may also need to reconnect. Test on a stable connection to remove variables from moving around. If the issue goes away when you stay put, check automatic reconnection and network-change handling instead of repeatedly resetting the subscription.

Check sleep and conflicts with other network tools

After a desktop wakes from sleep, its old routes, proxy state and app connections may be temporarily out of sync. Wait for the system network to recover, stop and reconnect the client, then reopen the affected app. If you can reproduce the problem after every wake, note the sleep method and error after waking rather than reporting only that it eventually recovered. Don't permanently turn off all power-saving features to keep the connection alive. Check settings for the affected network component and keep a way to restore the defaults.

Running multiple programs that change routes can let a “newer program overwrite the earlier program's settings.” Remote-work tools, security software and virtual networks can also change where traffic goes. For testing, keep essential system security enabled, temporarily quit nonessential proxy or tunnel tools, and see whether the issue stops. If you can't disable a corporate tool, ask your administrator to check route priority. Don't delete an unfamiliar virtual adapter; it may be part of a work setup you're still using.

If disconnects happen only on one route while other routes work on the same network, save the route's connection log and the time. If all routes disconnect at once and sites you normally access directly also become unreachable, check your local connection and upstream network first. A timeout, remote shutdown and local process exit in the log refer to different stages; don't group them together just because each says “error.” Capture context from before and after the issue, hiding authentication fields. That's usually more useful than a screenshot of the last line alone.

Test persistent-connection apps separately

Chat, remote terminals, meetings and AI streaming responses depend on ongoing connections. A brief network change can interrupt those sessions even if a normal webpage works again after a refresh. To verify recovery, repeat the task that actually failed, not just open a home page. The destination service may also end an idle session or refresh its sign-in state; that's not the same as a client disconnect. If only one long-running app fails, note how it maintains its connection, what action fails and whether other apps are working at the time.

If the exit region changes during a session, the destination may ask you to verify again. When practical, stay in the same region for everyday use rather than switching exits repeatedly. If you do need to switch, save your work first, then reconnect the app. Use the app's own save and recovery features for unsaved documents, uploads and remote tasks. A network service can't protect your app data; preserving your work before testing matters more than trying to keep the connection uninterrupted.

Submit a support ticket if disconnects keep recurring on a stable network, one route repeatedly shows the same error, or the client unexpectedly exits and you can reproduce it. Include what the device was doing before and after the disconnect, whether the network changed or the system slept, which apps were affected and how an alternate route behaved. For mobile disconnects after locking the screen, see the background activity section. If the client status never changed but the destination app closed, say so clearly so support can investigate the app session and routing instead of repeating basic connection checks.

Tell download, parsing and connection failures apart

A subscription link lets the client fetch routes and related configuration. It's not a webpage for everyday browsing or an ordinary address to share publicly. An “update failed” message can mean the request wasn't sent, the server rejected it or the returned content couldn't be parsed. Note the exact client message first, then check whether you can sign in to your user panel. Access to the panel doesn't guarantee that the subscription URL is reachable, but it helps distinguish account access from client retrieval issues instead of assuming every failure means the route is down.

When copying the current subscription URL from your user panel, make sure you get the whole address, without missing trailing characters or added spaces, and don't mistake display text for the URL. Don't append authentication parameters manually or keep reusing an old link of unknown origin from a chat. If you recently reset your subscription, the old URL may no longer work; update the saved source on your devices. To get the client or subscription, use the user panel download and import page. Don't use installers mirrored on static pages.

Keep the old configuration while checking the new response

Before updating, check whether your client can keep its existing configuration so you don't lose routes that still work. If the current source can't be fetched, check the network and URL before clearing all settings. A format the client doesn't expect may trigger a parsing error; the response might also be a network sign-in page or error message, not a valid configuration. You don't need to edit the configuration structure yourself. Note the error and check that the import method from your panel matches the client you're using.

Some clients can update subscriptions through the current proxy or fetch them directly. The results may differ depending on the method. If updating relies on a proxy that no longer works, you can try another method supported by the client while keeping your settings. Don't disable security checks. Public networks may require sign-in first. If the log reports a certificate or time issue, check the system clock and network before doing anything else. Ignoring certificate errors isn't a safe long-term fix and makes it impossible to verify that the response came from the expected source.

Verify subscription updates and route availability separately. A successful update means the client retrieved and accepted the configuration; it doesn't mean every destination will work through every route. After updating, check that the expected routes appear, connect to one, then test the app you actually need. If the route list is there but authentication fails, check your account status, subscription source and when the issue started. If the list differs noticeably from what's in your panel, stop overwriting settings on other devices, save a redacted screenshot and contact support to verify the configuration source.

What to do if a link is exposed or imported more than once

Treat your subscription URL like an access credential. If you posted a screenshot publicly, shared the link in a public group or pasted it into an unfamiliar site, reset it in your panel if that option is available, then update the source on your devices. Deleting the public post doesn't guarantee that the old URL can no longer be accessed. You don't need to include the full link in a support ticket; the error text, update time, client name and source type are usually enough to start. If further checks are needed, use the official process in your panel.

Importing the same subscription more than once can leave several similarly named sources in the client, and you may still be connecting through the old one. Check the currently enabled configuration and its update time before removing an old source. Before deleting anything, check whether custom rules are stored there and back them up using the client's supported method. Don't copy and paste a whole configuration without understanding how merging works. Keep one clearly identified current source and test again. If that resolves the issue, check the old source's automatic updates and overwrite behavior instead of adding more duplicates.

If you need support, say whether the failure occurs during retrieval, parsing or connection after the update, and include a redacted error and the result on another network. Check account status and data usage in your panel. Monthly subscription data resets each month on the activation date; data packs remain available until used and never expire, so the two have different expiry rules. For an overview, read the guide to getting, importing and updating subscription links. Don't switch plans repeatedly to fix an update; first confirm your account status and the cause of the error.

First check whether the request reaches the client

If a browser works but a desktop or mobile app doesn't, the proxy may not cover both. A system proxy is generally used by apps that follow system settings, but it doesn't automatically route every program. A virtual adapter or other full-device mode may cover more traffic, but still needs system permission and correct routing. Check the client's current mode, reproduce the issue in the app and look for the request in the log. If there's no request record, check how the app connects before switching remote routes.

Some apps have their own proxy settings, which may retain an old address, port or invalid authentication details. Others read the system proxy only at startup and won't rebuild their connection when you switch routes. Save your work, fully quit the app and its background processes, then restart it in the intended mode. Don't set different exits in the system proxy, app proxy and browser extension at once; requests could take the wrong path, loop or have inconsistent coverage. Note the original settings and compare one change at a time so you can restore them if needed.

Separate routing rules from destination service restrictions

If the request reaches the client, check whether it was marked direct, proxied or blocked. Routing rules may match by domain, address, process or other conditions, and an earlier rule may take precedence over later ones. An overly broad direct rule can send an app's API requests along an unsuitable path; an overly broad proxy rule can affect local services. Don't add only an app's main domain based on its brand name. Sign-in, resource loading and real-time communication may use different domains, so check the failed requests and official documentation.

If your client supports it and your situation allows, temporarily test a mode with clearer coverage to see whether a rule is responsible. When done, restore your usual routing and check that local sites and LAN access still work. If broader coverage fixes the problem, the original path or rules deserve a closer look; it doesn't prove that all traffic should always use a proxy. Keep the right direct routes for corporate intranets, LAN printers and local control services rather than breaking other connections to fix one app.

Different considerations for AI, streaming and real-time communication

If an AI tool loads but a conversation fails, check the sign-in API, request submission and streaming response separately. Access can also depend on account region, service availability and checks on the destination side; using an exit in an eligible region doesn't guarantee every account can use the service. Streaming also depends on your account, catalog and content licensing, so one unavailable title doesn't necessarily mean the whole route is broken. See the AI acceleration guide for an overview of access layers, but don't replace error diagnosis with repeated region switching.

Voice calls, games and meetings may use different transport methods from websites. A page loading successfully only confirms that the page request worked; it doesn't confirm that the current mode supports every type of communication the app needs. Check the app and client documentation, and don't copy unknown protocol settings from the web. If your workplace restricts a type of traffic, ask your administrator what is allowed. Stop if an unofficial fix tells you to disable system security features, and verify the source before taking action.

For a support ticket, include the app name, platform, page or action where it fails, whether the request appears in the client log and the routing mode in use. Record the destination service's exact error separately from route errors, and hide personal and session details. If only one account is affected while other access works in the same environment, check the destination service's account support information too. Support can help investigate the network path, but can't decide account permissions, regional eligibility or content licensing for another service.

Reproduce the conditions: works in foreground, fails in background

If your mobile connection works with the screen on but fails after locking the screen or switching apps, check background activity and network changes before resetting your subscription. Note whether the disconnect follows a screen lock, power-saving mode, background cleanup or network change. If reopening the client restores access, the system may be managing its background process or network extension. If the client still shows connected but messages are delayed, the messaging app's own background permissions or notification system may be involved. Test these separately rather than assuming one cause explains every delay.

For testing, keep your network stable, pause other tools that take over network traffic and confirm that the client can complete the task in the foreground. Then lock the screen as you normally would and check the client status and target app. Don't keep the screen awake throughout the test; that avoids the very background conditions you need to check. Notification arrival time alone doesn't prove that the network disconnected: notifications may use a separate delivery path. Compare the client status and access before and after recovery to identify which part stopped working.

Check Android and iOS separately

Battery management, background activity and auto-start settings vary across Android devices. In system app settings, check whether the client is restricted from running in the background, subject to strict battery saving or being closed by a cleanup tool. Make only the necessary changes for the affected app; don't disable all battery management or system protection. Some devices offer a background keep-alive feature, but the name and location vary, so follow the settings on your device. Restrictions on managed devices should be handled by an administrator.

On iOS, check whether the system VPN configuration belongs to the client you're using, whether another app has added a duplicate configuration, and whether the connection recovers after a network change. Switching an app to the background doesn't by itself mean the system has stopped its network extension; those are different states. If another app's network-filtering feature is enabled, follow its instructions to check for conflicts. Before deleting a configuration, confirm where it came from and how to restore it. Don't clear all system network settings if you don't have a subscription backup.

Recheck app sessions after network changes

When a device switches from Wi-Fi to another connection, its exit path and local address may change, so existing app connections need to be rebuilt. If the client reconnects automatically but the target app remains stuck in an old session, save your work, then close and reopen the app. You don't need to reimport the subscription every time the network changes; an update and session recovery solve different problems. If the issue occurs only on one hotspot, check its sign-in and access rules before assuming the background process was stopped.

Power-saving mode and device temperature can also affect background tasks and network activity. Compare results under normal working conditions and note whether the issue changes with power-saving settings. If a meeting, upload or remote task is in progress, save your work and use the app's own recovery features. Don't delete the VPN configuration during an important task. If you rely on a background connection, test the complete workflow on your own device and usual networks instead of assuming one successful webpage in the foreground proves every scenario is stable.

Submit a support ticket if the issue keeps recurring after allowing necessary background activity, the system reports a network extension error, the connection never recovers after switching networks, or the client exits even in the foreground. Include your system, the client version shown, whether power saving is enabled, the order of screen locks and network changes, and what you have to do to restore the connection. Hide account details and notification content in screenshots. If only one app's push notifications are delayed, say whether other apps work so support can distinguish background permissions, notification delivery and client connection issues.

After recovery, test everyday actions: switch apps, lock the screen, return to the foreground and change to a usual network. Use the same task for each test, and confirm it doesn't work only while a temporary settings page is open. Keep a record of the final working settings and undo temporary changes that didn't help. If the issue returns after a system update, first check whether app permissions or battery settings were reset to their defaults; you don't need to start by deleting the account configuration.

Understand unlimited devices separately from local error messages

VPNYunsu allows unlimited simultaneous devices. If the client shows “device limit exceeded” or a similar message, don't assume VPNYunsu requires fewer devices, and don't upgrade your plan just to troubleshoot. First check whether the message comes from this client, a system management screen or the service you're trying to access. Streaming, workplace platforms and other apps may have their own account sign-in rules; their device limits don't apply to your network subscription. Note where the message appears and its exact wording so a destination service account error isn't reported as a route failure.

If the error really comes from the client, check that the current configuration belongs to your own VPNYunsu account and that you haven't imported another source or kept using an old configuration. Don't send your subscription link to anyone as a test; you can get the correct source for each of your own devices from the panel. If you're still unsure, send support a redacted message and explain where the configuration came from. Account creation requires no email address; you can register with a username and password. Never enter or disclose your password in a public place while troubleshooting.

Use the right place for account, data and refund questions

Check your account status and usage in the panel first. Monthly subscription data resets each month on the activation date, not necessarily at the start of the calendar month. If you upgrade partway through, the price difference is prorated for the remaining days. Data packs stay available until used and never expire; check the remaining balance to see what's available. Don't apply monthly subscription reset rules to a data pack or repeatedly place orders before checking the account status. For a billing, order or plan discrepancy, include the relevant order details and hide payment information unrelated to the issue.

Alipay, WeChat Pay and USDT are currently supported. Check the specific order in your panel, and don't send money through unofficial channels for a supposed repair fee. See the Plans page for prices and data allowances; a connection error alone isn't a reason to choose a higher tier. The service offers a 60-day no-questions-asked refund policy. Check the Terms of Service for eligibility and instructions, then submit your request through an official support ticket. You can report a technical issue and request a refund separately to keep troubleshooting details distinct from billing information.

Submit enough to reproduce the issue—not your entire private data

A useful support ticket explains the environment, what you did, what happened and what you expected. Describe what you observe starting from a working basic network, note the client's connection status and affected destination, and include comparisons you've tried and their results. Include the time zone with the time of the issue, and use the route name shown in the client. Find your actual system and client versions in settings rather than guessing. Include your device model only when it's relevant to background management, drivers or platform compatibility.

Issue: Connected, but requests to the target website time out
Time and time zone: enter the actual details
Platform and client version: check system and client settings
Network type: home Wi-Fi, public hotspot or the actual connection used
Route name and mode: enter what the client displays
Steps to reproduce: what you did after starting the client
Comparison results: what changed after switching routes or networks
Error excerpt: remove authentication fields and personal details first
Expected result: the specific access or connection behavior you want restored

Review logs before sending them. Remove full subscription URLs, authentication parameters, session IDs, account passwords and personal browsing content. Check screenshots for browser address bars, notification previews and other open windows too. Don't cover credentials with a translucent blur; use an opaque redaction or crop that can't be reversed, and verify that exported files don't contain the original content. A short excerpt around the time of the issue is usually enough to start. Unfiltered full logs are harder to review and may include information unrelated to the problem.

Submit your request through the user panel support ticket page and keep related updates in one continuous ticket. Add new comparison results, recovery times and conditions that trigger the issue to the original ticket instead of splitting the same problem across several reports. If support asks you to run a check, first confirm its purpose and how to restore your settings. Changes requiring system administrator access or involving a corporate network should be made by someone authorized to do so. If the cause isn't clear, note any route that temporarily restored access rather than saying the root cause is fixed.

For the final check, repeat the task that originally failed: reconnect on the same network, test websites and apps, check background behavior, and confirm local services still work. Undo temporary proxy, DNS and power-saving changes that didn't help, and keep a record of the settings that did. For common issues, see the FAQ. To review the full installation and import process, return to the Setup Guide. Troubleshooting is complete when the issue is understood, the steps can reproduce it and recovery has been verified—not just when one click happens to work.