Complete VPN Troubleshooting Guide

Connection failures: find where the process stops

Turn “can't connect” into something you can check

“Can't connect” can mean the client never starts connecting, or that it starts but can't establish a route. Note the exact message shown in the client: waiting for configuration, authentication failed, connection timed out, or the system refused to create a network interface. Don't lump every state under “network problem.” If the connection button switches off right away, check permissions and configuration first. If it waits and then reports an error, check your local network, subscription status and selected route. “Connected” in the client usually means the client is running; it doesn't confirm that the website you want is reachable.

Check your internet connection, then check service status

Disconnect the client temporarily and try a website you normally access directly to confirm your internet connection is working. If it isn't, complete any network sign-in, check your router or switch to another available network first. Repeatedly importing your subscription while the underlying connection is down will only add variables. Public Wi-Fi may require browser authentication, and existing proxy settings can interfere with the sign-in page. Temporarily quit other networking tools, then reopen your browser to sign in. For workplace or campus networks, follow the stated usage rules; don't try to get around them by changing managed policies.

Once your internet connection is working, open the user dashboard and check your plan status, remaining data and subscription validity. Data on monthly subscriptions resets each month on the activation date, so don't assume it has reset just because a new calendar month has started. A route name saved in the client doesn't mean your account currently has active service; cached settings can remain visible after plan status changes. If the dashboard itself won't load, distinguish a browser access problem from a sign-in problem. Keep the error message, and don't share your login details with anyone offering to test them.

Narrow it down with cross-checks

Once your account status is confirmed, switch to another route in the same client on the same network, leaving other settings unchanged. If only the original route fails, note its name and continue using an available route. If all routes behave the same way, test on another available network. If switching networks fixes the problem, the access network or connection path is more likely to be at fault. If other devices work on the same network, check permissions, leftover proxy settings and security software on the affected device. These comparisons help locate the problem far better than a single “connection failed” screenshot.

Check whether the system allows VPN configuration or network extension access. A previously denied permission, authorization lost after a system update, or device management restrictions can prevent the client from starting. Permission screens vary by system version, so follow the current system prompt and the guides on this site. After granting permission, return to the client and try connecting again. If the system says the device is managed by an organization, ask its administrator. Don't leave system protections disabled for testing, or remove certificates or management settings used for work.

Before reinstalling, save your current configuration name, proxy mode and error screenshots; redact any subscription address. Reinstalling may erase useful comparison logs and leave the old system proxy setting behind, so it shouldn't be your default first step. If this is a new setup that has never connected, return to the Getting Started Guide and check the setup steps from beginning to end. If it worked before and stopped suddenly, note whether you changed networks, updated the system or client, or changed security settings beforehand. Include when those changes happened relative to the error so the sequence can be reconstructed.

Connected but can't open websites? Check routing and DNS

First check whether all websites fail or just one

When the client shows Connected, try both a familiar local website and one that needs an international route. If every site fails, check proxy handling, DNS and the device's network. If only one destination fails, consider the platform's status, regional requirements and account restrictions. “Server not found” points more toward a name resolution issue; a connection timeout is more consistent with a path or destination response issue. A certificate error also calls for checking the system clock. Error messages are useful clues, not conclusive diagnoses; compare results across apps and networks.

Test in a regular browser window before changing extensions, cache or sign-in state. Some extensions set their own proxy, while privacy tools can change DNS behavior. Running these alongside the client may create inconsistent access paths. Check what an extension does, temporarily disable only the relevant feature, and retest the same destination. Restore it afterward. If only one browser has the problem while other browsers and apps work, don't change the entire system network right away. Check that browser's proxy, encrypted DNS and extension settings first.

Check whether traffic reaches the client

Open the client's connection log, then try to visit a website and check whether its domain appears. If there's no entry, the system proxy may not be active, the browser may have its own proxy settings, or the app may not use the system proxy. If an entry appears but is marked Direct, check which rule matched. If the request uses the selected route but the destination still fails, then check the route's exit or the destination service. Some logs reuse cached connections and won't add an entry on every refresh. Close the destination tab and open it again rather than judging by whether the log list scrolls.

Check DNS layer by layer

DNS translates domain names into addresses. The system, browser, client and app may all take part in resolution; a bad cache or inconsistent path at any layer can make the same domain work sometimes and fail other times. Save your current settings first, then prefer the default DNS configuration provided by your subscription. Don't cobble together unfamiliar resolver addresses from random online guides. Corporate intranet domains may rely on internal DNS, so replacing system DNS outright could disrupt work access. Before making changes, identify which domains need the internal network and which should use an international route.

These commands can help check whether system DNS resolution returns a result. They query public domains only; they don't test whether a route works through the client. A successful command also doesn't prove your browser uses the same DNS path. Run them in Command Prompt on Windows, or in Terminal on macOS and Linux. If the required tool isn't installed, skip this step rather than changing your system to install it. Keep the error type in the output, but redact internal DNS servers, private domain names and local network identifiers before sharing.

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

If a lookup fails but your internet connection works, check whether the client handles DNS, whether a manual DNS setting remains on the system, and whether the browser uses its own resolver. If the lookup succeeds but the browser still fails, return to proxy handling and browser settings. Command-line tools don't necessarily use the proxy settings in the system's graphical interface, so different results in a terminal and browser don't by themselves prove the route is faulty. If you see a certificate warning, check the clock and destination address. Don't bypass certificate checks to sign in or install certificates from unknown sources to make the warning disappear.

Slow speeds and peak-hour lag: compare each link separately

Turn “slow” into a repeatable test

Slow performance could mean a page takes a long time to open, images load slowly, transfers are unreliable, video keeps buffering or an AI conversation takes too long to respond. Pick one destination and one action, then compare routes. Don't compare image loading on one site with a file download on another, and don't choose a route based only on the client's route test. Test requests can differ from real requests in destination, connection method and processing. A result shown in the client can't replace your actual experience.

If only an AI tool responds slowly, distinguish page connectivity from server-side generation. If the page loads and the prompt is submitted but the response takes a while, the platform may be handling a queue or processing the task. If page resources don't finish loading or submissions repeatedly fail, check the network path. Streaming can also be affected by content regions, platform policies, playback quality and device decoding. Compare the same content on the same device before switching routes; don't assume every issue comes from the VPN when the platform itself may be responsible.

Compare your connection, route and device load

Pause unnecessary downloads, cloud sync and background updates first, and check that nothing on your device is using the network continuously. On Wi-Fi, also check signal strength, router placement and traffic from other devices. If your underlying connection is already slow, switching routes won't solve everything; compare a different type of network when convenient. Keep the destination, device and proxy mode the same, changing only the network or route for each test. If you change the device, network and region all at once, you won't know what made the difference.

Geographic distance isn't the only factor when choosing a route. The path from your access network to the relay, the path from its exit to the destination service, and current network conditions all affect performance. Start with a commonly used region, compare using the same task, and keep the route that works best for what you're doing. VPNYZ covers 110+ countries and 240+ routes, but coverage doesn't mean every route will perform the same for every destination. When reading the locations and routes guide, treat route types as information about the path, not a guarantee of speed or access to a particular platform.

Swipe horizontally to view the full comparison on narrow screens.

Keep time-based comparisons for peak-hour slowdowns

When performance drops at a regular time, note the local time, access network, route name and task, then repeat the same test at other times. If local and international sites both slow down, congestion on the access network is more likely. If the underlying connection is fine but one route changes significantly, compare it with another route. A single peak-hour test reflects only that moment; it doesn't show that one region is always faster. In a support ticket, describe which task changed on which route rather than just saying “it's really slow at night.”

Avoid changing connection pools, transport buffers or a large number of advanced network settings before you know where the problem is. Changes may temporarily alter the symptoms but introduce new compatibility issues. Start with the client's default settings, rule out background traffic and rule conflicts, then check for guidance specific to the issue. If another route reliably completes the task, keep using it and report the problematic route. If all routes are slow but a different network works, include that comparison in your ticket instead of upgrading your plan in the hope of a speed boost.

Frequent disconnects and mobile background drops

Tell a dropped tunnel from an expired app session

A chat interruption, stopped video or sign-in prompt doesn't necessarily mean the VPN disconnected. Check the system's connection status and the client log first. If the tunnel is still active and other sites work, the issue may be limited to the target app's session. If the client logged a reconnection, check for network changes, system background restrictions and route status. Note what you were doing when it dropped, such as locking the screen, switching Wi-Fi, waking from sleep or opening another networking tool. These details can be more useful than a screenshot taken after the error.

When switching from Wi-Fi to another type of connection, the existing connection may need to be re-established. Downloads, live conversations and remote sessions may not resume seamlessly. Even after the client shows Connected again, an app may still be using a stale connection. Wait for the underlying network to come back, confirm the client has reconnected, then start the task again. If only the original app still fails, close its current task and retry; there's no need to delete the subscription right away. Changing the exit region can also affect a session, so keep the route stable during sensitive sign-in tasks whenever possible.

Android: check background limits and battery settings

Battery management and background policies vary across Android device makers. If the client works in the foreground but disconnects when the screen is locked, open its app info and check settings related to battery use and background activity. Allow the background activity the client needs using the options available on your system, and check whether battery saver changes network behavior. After making changes, lock the screen and wake the device, then test the destination app. Seeing “Allowed” in a settings screen doesn't prove background access is working. Don't grant broad permissions to every app or add unrelated apps to background exceptions.

Some devices stop the client when clearing recent apps, managing memory or running system optimization. While testing, avoid force-stopping the client and watch whether the system VPN indicator and client log change at the same time. If the indicator remains but the destination app stops receiving content, the app itself may be restricted from using the network in the background; check it separately. If the device is managed by an organization, its background policies may not be changeable, so ask the administrator. Keeping the system and client in a supported state is more reliable than repeatedly installing unknown “keep-alive” tools.

iOS and desktop systems: check wake-up and network changes

On iOS, first confirm the system allows the current VPN configuration and check whether another networking configuration is also active. An app pausing tasks when the screen locks doesn't necessarily mean the system shut down the tunnel. After waking the screen, check whether the client reconnects and whether other apps are affected too. If the issue occurs only on one Wi-Fi network, compare with another. For first-time setup or unclear system permissions, see the iPhone VPN setup guide, focusing on allowing the configuration and verifying the connection.

After waking from sleep, Windows, macOS and Linux may have a network interface that hasn't recovered yet or a proxy process still holding its previous state. Confirm the underlying network is back, disconnect and reconnect in the client, then restart the app task. If the issue happens after every wake, note the network type before and after sleep, system proxy state and client logs. Don't disable every power-saving feature. Test relevant network settings one at a time where you can roll them back, then decide whether anything else needs changing.

If the logs repeatedly show connections being re-established, keep entries from around the first error, not just the latest successful connection. Note whether it recovered automatically, required a manual tap or happened only on one route. If the target account asks for extra verification after repeated region changes, stop switching regions and follow the platform's account rules. VPNYZ provides network connectivity; it can't restore a session or remove security checks imposed by another platform. Troubleshoot the network and account separately.

Subscription update failures and import issues

First distinguish a download failure from a parsing failure

A subscription update usually involves getting the configuration from the dashboard, downloading it in the client, parsing it and saving it as the active configuration. If the client can't reach the address, check the download path. If it says the format isn't supported, check the returned content and client compatibility. If the update succeeds but the routes look unchanged, confirm that the updated configuration is active. A longer route list doesn't necessarily mean the update worked: server-side rules or route details may change without visible name changes. Check the update time and active configuration name first.

Open the user dashboard, confirm your service status and get a fresh subscription link from the current dashboard. Don't reuse an old link from a chat or let someone else keep your subscription link. It may contain access credentials and should be treated as sensitive account information. When copying it, make sure no spaces, line breaks, quotation marks or explanatory text were added. You could also select the wrong import method when switching between QR codes, the clipboard and manual import. If the dashboard offers an import method for your client, follow the matching instructions there or in the guide.

Check which route the update request uses

Some clients let you choose whether subscription updates use a direct connection or the current proxy. If the active configuration is already unusable and the update request depends on it, you can get stuck in a recovery loop. First confirm your underlying connection can reach the dashboard, then try an appropriate update path offered by the client. Change only the update method at a time; don't also change DNS and rules. A failed update doesn't mean you have to delete the old configuration, which may still have usable routes. Keep it, then create a clearly named configuration for comparison so you can roll back easily.

If the log shows a webpage instead of a configuration, you may have copied the dashboard page URL, been redirected to a sign-in page or need to authenticate on the current network first. Don't paste the entire returned page into a public forum or submit your subscription link to an unknown online converter. Check the correct entry point and try again; if it still fails, send the error type to support. For format problems, provide the client name, installed version and relevant error excerpt. Redact credentials, internal addresses and personal information, keeping only enough context to show where parsing failed.

After a successful update, check which configuration is active

Some clients store multiple configurations, and updating one doesn't always switch to it. Check the active configuration, proxy mode and selected route to make sure an older configuration isn't still running. After importing, confirm the configuration is valid and check for rule parsing warnings. Manual overrides in an older configuration may still affect results, including custom DNS, proxy group selections or app rules. Before returning to the defaults, note these overrides and use the client's supported restore method. Don't delete configuration entries you don't understand.

A failed subscription update and running out of data are different issues. Data on monthly subscriptions resets each month on the activation date; the price difference for a mid-cycle upgrade is converted into remaining days. Data packs don't expire and remain available until used. To compare plans, see the pricing page. Repeatedly updating your subscription won't change your account's billing status. If an order is complete but the dashboard shows the wrong status, open a billing support ticket and include the order's current status. A successful client update doesn't confirm that an order has taken effect.

Don't make “clear all configurations” your default fix. Consider clearing them only when you've confirmed the old setup can't be recovered, saved the details you need and know how to import it again. If the problem remains after clearing and the original logs are gone, support will have a harder time identifying the cause. You can use the complete beginner's guide to review the setup from dashboard to client, but keep your troubleshooting notes separate. Record whether each import succeeded, when it was activated and what changed afterward.

One app isn't using the proxy? Check its routing path

A system proxy doesn't mean all traffic is being routed through it

If a browser opens the destination but a desktop app doesn't, first check whether the app uses the system proxy. Apps handle networking differently: some read system settings, some have their own proxy options, and others need a client-supported tunnel mode to capture their traffic. Turning on the system proxy only writes the relevant setting; it doesn't guarantee every process will follow it. Check the client's connection log for the app or destination domain before deciding whether to investigate rules or traffic handling. Don't switch regions based only on an app's “network error” message.

If the request doesn't appear in the log at all, check whether the app needs to restart before it reads new proxy settings. Closing a window may leave the app running in the background; use its normal Quit command, then reopen it and test again. Browser extensions, terminal environment variables and an app's own proxy settings can also differ. Don't paste a subscription URL into an app's proxy server field: a subscription retrieves a configuration, while the proxy server field expects local proxy details provided by the client. Check the instructions for your client rather than copying port settings from an unknown source.

Distinguish proxy mode from rule matching

If the request reaches the client, check whether the matching rule sent it direct, through the proxy or rejected it. Smart routing assigns paths according to rules. A missing destination domain, extra resource domains called by the app or an outdated rule can make part of a page work while another part fails. For diagnosis, briefly try the client's global proxy mode. If the same task then works, a rule may not cover the destination. If it still fails, check the destination service, exit region and app settings. Restore the mode you prefer for everyday use after testing.

Global proxy mode and tunnel-based traffic capture aren't the same thing. The former usually decides how requests that have reached the client are routed; the latter determines which traffic the system sends to the client. Switching rules to global mode won't necessarily capture an app that bypasses the system proxy. Before enabling tunnel mode, check system permissions, device management requirements and the impact on intranet access. After enabling it, check work platforms and local network resources, and make sure it doesn't conflict with other VPNs. If something breaks, roll back. Don't stack multiple traffic-capture tools without understanding how they route traffic.

For AI tools, check the page, sign-in and task separately

Tools such as ChatGPT, Claude and Gemini may use different page resources, sign-in flows and task APIs. Opening the home page doesn't prove that sign-in or a real task will work. Check in order: open the page, sign in, then submit a simple task. Note the exact error at each stage. If the platform says your region or account isn't supported, follow its rules; a network route can't replace platform eligibility. See the AI tools access guide for more scenarios. Constantly switching regions isn't a general fix for account restrictions.

For Midjourney and Discord, distinguish connection status, resource loading and task responses. The chat list may appear while images fail to load because resource domains use a different path. A submitted task that remains pending may also be waiting on the platform. See the Midjourney and Discord connection guide to identify the affected stage. If a browser works through the same exit but the app doesn't, compare the app's network settings rather than clearing account data. Before clearing the cache, make sure your sign-in details and local content are safely stored.

If global mode improves the result, tell support which app and action failed, which rule matched and how normal mode behaved. There's no need to submit your entire browsing history. If only one app fails and the client shows no request, state clearly that the request never reached the client. If the log shows the request used the selected route and the destination returned a service error, include the exact error message. This helps separate traffic capture, routing rules and platform issues so you don't keep changing settings at the wrong layer.

Platform differences and “device limit reached” messages

First check where the message came from

VPNYZ has no device limit. If you see a “device limit reached” message, first check whether it came from the VPNYZ dashboard, client, operating system or destination website. A platform may manage account sessions separately, and another networking tool may retain an old warning; don't assume either is a VPNYZ plan restriction. Keep the app name and surrounding context in screenshots, but redact account and subscription details. Don't upgrade your plan or remove a working configuration on another device just to clear the message. Check which service you're using and which subscription is active first.

No device limit doesn't mean a destination website allows account sharing, nor does it mean every device must have identical settings. VPNYZ supports Windows / macOS / iOS / Android / Linux. Each platform still needs its own system permissions, configuration import and connection check, even when using the same subscription. If one device fails while others work, that's a useful comparison. Leave the working devices unchanged. Note their client status, proxy mode and network type, then compare them with the affected device one item at a time instead of resetting everything.

Swipe horizontally to view platform checks on narrow screens.

On desktop systems, check for leftover settings and permissions

If Windows still can't access the internet after you quit the client, check whether the system proxy still points to a local address. If the local proxy process has exited but the system continues sending requests to it, browsers may keep returning errors. Note the original setting, use the client's normal option to turn off the system proxy, then check the system settings. Don't delete all network adapters as a routine fix. For the difference between global proxy and smart routing, see the Windows proxy modes guide and check startup, traffic capture and routing separately.

On macOS, check whether the network extension is allowed to run and whether the current network service has its own leftover proxy settings. Different network locations can keep different settings, which is especially worth checking if it works at the office but not at home. When the system asks for permission, confirm the request comes from the client you're using; don't authorize an unfamiliar extension. For background on Apple services and network extensions, read the macOS network extensions and compatibility guide. Keep your original settings so you don't confuse a system service issue with a route problem.

On Linux, proxy settings in the graphical desktop may not apply to terminal programs, and terminal environment variables may not affect graphical apps. Check for proxy-related environment variables, but don't publish full output that includes internal addresses or credentials. If the terminal and browser behave differently, identify where each gets its proxy settings before making changes. The system resolver, network manager and client may all manage DNS; confirm which one is in control first. On a managed workstation, follow administrator settings rather than overriding the organization's network configuration.

Mobile devices and configuration migration

After switching devices or restoring a system backup, the client may still show an old configuration name, but you should recheck system permissions and subscription status. Confirm the current link in the dashboard, then import it using the Getting Started Guide rather than copying settings from someone else's screenshot. Get the client through the client download section in the dashboard; sign in and use an available option shown there. If only the new device fails after migration, keep the old one as a comparison. There's no need to erase working data on the old device to “sync” them.

If the message is confirmed to come from VPNYZ and conflicts with the no-device-limit policy, open a support ticket with the message location, steps that triggered it and a redacted screenshot. Support needs the context, not login details for your other devices. If the message comes from the destination service, follow that platform's account management rules. Identifying the source first helps avoid unnecessary plan changes, signing out of every session or deleting local data, and directs your request to the right team.

Recovery checks, rollbacks and support ticket details

Restoring access once doesn't mean troubleshooting is finished

After changing a setting, repeat the action that originally failed, then verify the other things you normally need to access. Depending on the original symptoms, check app sign-in, task submission, intranet resources and recovery after locking the screen or waking from sleep. If changing routes was the only fix, note which route worked rather than saying “everything is fixed.” If you have to keep using a temporary global mode, state that the rule issue is still unresolved. Clear recovery conditions make it easier to tell whether a later problem has the same cause.

Keep a brief record while troubleshooting: what happened at first, what you changed, the result and whether you rolled it back. Don't change proxy mode, DNS, route and system permissions all at once; even if the problem clears, you won't know what helped. Revert changes that didn't help so settings don't build up. For changes that worked, note when they apply. This is especially useful on shared or work devices, so others know what settings are in use. Screenshots aren't a substitute for a written summary: state clearly which actions worked and which still failed.

When to stop troubleshooting and open a support ticket

Open a support ticket if your internet connection and account status are normal but the issue persists across networks or devices. A route that consistently fails, a subscription parsing error, or a mismatch between the plan status in the dashboard and your order are also worth having support check. If the system says the device is managed by an organization, contact its administrator first. If a platform has restricted your account, contact that platform. Different issues require different permissions: a VPNYZ support ticket can't grant system administrator access or change another platform's account decisions.

Open the support tickets page in the user dashboard. No email address is required; you can create an account with a username and password. If you already have an account, sign in and submit your ticket. Start with the symptoms and scope, then list the comparisons you've tried and attach only the necessary logs. Don't combine unrelated issues in a long screenshot or open multiple tickets for the same problem. Add results to the original ticket to keep the context together. If the error has gone away, note what restored access so support can tell whether any follow-up is needed.

Prepare a diagnostic summary support can use

Include your operating system, client name and installed version, access network type, current proxy mode and route name. Give the local time and time zone so support can match events to the logs. For results, include the destination domain, the action that triggered the error, the exact error message, whether other routes or networks worked, and whether it happened only in the background or at a particular time. Check the version on your own device instead of guessing from an online article. There's no need to list every app you have installed; include only details relevant to network behavior.

Symptom: The client shows Connected, but the destination page won't load.
Scope: The browser fails on this device, while other apps can still connect.
Environment: Enter the actual system, client and access network.
Time: Enter the local time and time zone.
Current settings: Enter the proxy mode, route name and configuration name.
Comparison: Describe what happened after changing the route, network or device.
Changes made: List settings you changed and note whether you rolled them back.
Attachments: Redacted error screenshots and relevant log excerpts.

Logs should cover the steps leading up to the failure and include relevant entries from before and after it. Before submitting, check for subscription links, access credentials, QR codes, private domains, internal network addresses and personal file paths. When redacting, keep the error type and enough surrounding context to understand what happened; don't obscure the entire screenshot. Account passwords aren't diagnostic information. Share only the payment details needed to check an order. If support needs more information, confirm why it's needed first, then add it through the dashboard rather than sharing a complete diagnostic bundle publicly.

Keep technical issues separate from billing issues

For plan details, see the pricing and billing information; upgrading isn't a fix for every connection problem. VPNYZ offers a 14-day no-questions-asked refund policy. See the Terms of Service for details, or contact support through the dashboard. Technical tickets should describe the error and environment; billing requests should explain the order status and what needs checking. Keeping the two kinds of information separate helps prevent billing questions from getting lost in connection details, and avoids trying to resolve account status by repeatedly importing configurations.