Connection Issues: Troubleshooting Guide

Describe what you can observe instead of saying “it doesn’t work”

Different problems call for different checks: the client won’t start a connection, it says connected but websites return errors, or websites work but a particular app doesn’t. Copy the exact error, then note what you were doing when it appeared: updating the subscription, selecting a route, connecting, or accessing a service. Don’t capture only the final red warning; what you did just before and after it often points to the cause. If the client is still loading, wait for a clear result rather than clicking Connect repeatedly and mixing multiple attempts in the logs.

It also helps to note how widespread the issue is. Does it affect only this device or other devices on the same network too? Are all websites affected, or just one domain? Does it happen all the time, or did it start after waking from sleep, switching networks or changing a setting? No complex tests are needed; describe what you can reproduce. One page that consistently fails is more useful for diagnosis than a series of screenshots without timestamps or context. For a page that requires login, first check whether a public page loads.

Compare your local network with the proxied connection

Pause the proxy and try a website that normally opens directly to confirm that your basic network connection works. If it still fails, check Wi-Fi, Ethernet, the network sign-in page or the router before repeatedly updating the subscription. Hotel, campus and office networks may require authentication first. A browser displaying a sign-in page doesn’t mean internet access is available yet; complete authentication before opening the client. If another network tunnel or workplace remote-access tool is running, first check its purpose and management requirements, then decide whether it can be temporarily disconnected for comparison.

Once your basic connection works, restore the current configuration and try the same page again. Change only the route or the network—not the client, DNS method and routing rules all at once. That way, you can tell which variable changed the result. If Wi-Fi fails but another network works, focus on the local network. If other devices on the same network work, focus on this device. If the same route fails across different devices and networks, then investigate a route-side issue. Base each conclusion on an actual comparison; one timeout alone doesn’t prove the service is at fault.

Keep a rollback point and limit the impact of troubleshooting

Before changing settings, note the client name, configuration name, selected route and proxy mode. Redact account details and subscription links from screenshots. If the client offers configuration backups, save one somewhere you control. Backups may contain sensitive information, so don’t upload them to public forums. Don’t start by resetting all network settings: that can also remove workplace proxies, Wi-Fi configurations and remote-access settings, causing more disruption than the original problem.

On a device managed by an organization, use this page to help document symptoms—not as a guide to removing management policies. Ask your administrator to verify system permissions, certificates and security software settings. On a personal device, make small changes you can undo, and restore any settings that don’t help after testing. This gives you a clear starting point next time. If you’ve lost track of what you changed, stop adding settings. Document the current state, then check the configuration source and import results against the setup guide.

Tell startup failures apart from route connection failures

If the client switches straight back to disconnected after you click Connect, first check system permissions, configuration validity and conflicts with local listeners. If it times out only after trying for a while, compare your network and route next. Check the client status and logs for the error tied to this attempt. A permissions denial, a configuration parsing error and a connection timeout are different problems and shouldn’t be handled the same way. If the interface won’t open at all, first verify the installation source and system compatibility before troubleshooting the network.

When the system first asks to create a network connection or enable a network extension, review the prompt and grant permission if you understand its purpose. Closing the permission prompt or leaving approval pending in system settings can make the button appear to work without establishing a connection. On Windows and macOS, check the system proxy or network extension status. On mobile, check whether the VPN configuration in system settings was created by the current client. Don’t disable all security features just to connect, and don’t install certificates or configuration profiles from unknown sources.

If the logs say a local address is already in use, check whether another proxy client is still running in the background. Disconnect and quit it normally before starting the current client. Closing its window may not be enough; some programs stay active in the system tray or menu bar. Don’t copy a fixed port number from online advice or terminate system processes you don’t recognize. Use the listening settings shown in the current client. Ask an administrator to investigate conflicts on a managed device.

Check your subscription status, then compare routes

Open the account dashboard and confirm that the account and subscription match the ones used by the client. Check your plan status and remaining data. Route names still shown in the client don’t prove that the subscription is active; they may be left over from an earlier update. If there’s no active service on the account, resolve the account status before changing system DNS. If the status is normal but the configuration timestamp looks wrong, check the subscription update results in the relevant section of this guide.

Keep the client and proxy mode unchanged, then compare routes in different regions or of different types. If one route fails and another works, the local client can at least establish a connection, so focus on the specific path. If all routes fail, don’t immediately conclude that every exit point is down; check the basic network and system permissions too. See the route list for route names, types and selection details. The dashboard shows which routes are currently available to you.

Keep the selected route unchanged and test on another network you can control. If switching networks fixes the problem, note the original network type, when the failure occurred and the error. There’s no need to keep reinstalling the client. If only this device consistently fails while other devices work under the same conditions, check the configuration import, local proxy conflicts and system time. A significantly incorrect date or time zone can cause secure connection checks to fail. Correct it through system settings rather than skipping verification.

Address the error without resorting to a destructive reset

For an authentication error, check the account and subscription configuration. For a configuration parsing error, check the imported content. For a timeout, compare the network and route. For a permissions error, revisit system authorization. If the logs show a certificate error, first check the system time, client source and network sign-in page; don’t simply disable certificate verification. Deleting and reinstalling the client may temporarily clear the symptom, but it can also erase useful logs and configuration details. Consider reimporting or reinstalling only after saving what you need and confirming how to restore it.

If one route keeps failing but an alternative works, use the verified alternative for now and report the failed route name and comparison results in a support ticket. If connections fail across different networks and devices while the dashboard shows a normal status, contact support to check the service side. Say whether the failure happens before or after connecting, and include the exact error with sensitive details removed. Don’t share your password, full subscription link or an unchecked configuration file; none is needed to diagnose a connection timeout.

Check the browser error before switching DNS resolvers

A browser message saying the domain can’t be found, the connection was reset, a certificate is invalid or access was denied can point to different issues. Copy the exact error and note the domain, then test another public website. If other pages work, consider a problem with the target site, its access policy or your account. If no domains work, check the system proxy and DNS resolution path. Login restrictions, regional notices and network failures are also distinct; don’t treat every message returned by a website as evidence that the route is unavailable.

Check whether the client has enabled the system proxy or is using a tunnel mode that handles the traffic you need. Some clients start a local proxy endpoint in the background, but the browser may still access the internet through its usual path. The browser may also have a manual proxy setting that points to a local endpoint that has stopped. Check the current client settings and confirm that the proxy host, listener status and browser configuration match. Unless you have a clear reason to do so, don’t layer the system proxy, a browser proxy extension and another network tunnel together.

Try a private browsing window or a clean temporary browser profile to help distinguish cache, extensions and account issues. This won’t change the system network path. If the temporary profile works but the original one doesn’t, check extensions and site data first. If neither works, continue with network checks. Before clearing site data, make sure you can log in again so you don’t lose an essential session. Don’t clear all browser data to fix a problem with just one site.

Use DNS results as clues, not as a definitive diagnosis

DNS translates domain names into addresses used for subsequent connections. A resolution failure can occur in the system, client, browser or current network’s DNS path. A browser using its own secure DNS may return different results from a system command. A client using internal DNS may not use the system’s response at all. A command-line lookup tells you only about the path used for that query; it doesn’t prove that your browser uses the same path.

The query below can help check system DNS resolution. On Windows, you can usually run it in a terminal. On macOS and Linux, the required tool may not be installed. The example domain is only for illustrating the command format; it isn’t a VPNZW subscription address. An address in the result means only that this particular lookup returned one. If there’s no result, note the error and the network you were using. Don’t paste a resolved address directly into the address bar for a site that requires secure verification; doing so can cause certificate and site-matching problems.

nslookup example.com

If the client uses custom DNS, check whether the setting comes from the current configuration or was overridden by an older one. Try a default option explicitly supported by the client, note the result and then decide whether to keep it. Don’t combine conflicting settings from multiple guides or enter a resolver from an unknown source. If network authentication isn’t complete, or your workplace domain relies on a dedicated resolver, changing system DNS without approval can also break internal services that were working.

Check cache, protocol differences and results

After changing DNS or routing rules, cached results and existing connections may continue using the old settings. Close the page, reconnect the client and reopen it. If needed, clear the DNS cache using the official instructions for your operating system. Don’t run a bundle of network reset commands if you don’t know what they do. If a page’s text loads but images, sign-in or attachments fail, related domains may be following different rules. Note the domain of the failed resource instead of reporting only the home page address.

Also check whether different network protocol paths on the device behave consistently. An app may choose a different address or transport from the browser, making it look as though “the browser works, but the app doesn’t.” Use app logs and routing rules to investigate; don’t disable system networking across the board. After making a change, test a public page, the target sign-in page and the actual task separately. If DNS resolves consistently but connections still fail, return to comparing routes rather than repeatedly changing DNS settings.

First identify when the slowdown occurs

A long wait before a page starts loading, a drop in download speed, repeated video buffering and intermittent audio in a call can have different causes. Note what happened from the moment you started the task until the slowdown began. Is the connection slow to establish, or does it become unstable after data starts flowing? A single large download doesn’t represent every app. The target service’s server location, account limits and workload also affect performance. Don’t attribute all the time an app takes to generate content to network transfer.

Before testing, pause large syncs, system updates and other ongoing downloads on this device and the same network. Weak Wi-Fi, a busy router or local upload traffic can all make remote connections feel slow. Compare results near the Wi-Fi access point or over a reliable wired connection to help isolate local issues. Keep the target content, device and client mode the same and change only one condition. Changing video quality, route and network at once might seem to help temporarily, but it won’t reveal the cause.

A route probe usually checks whether a particular request gets a response in time; it doesn’t measure real-world performance for your apps. A probe may respond even if the target site behaves differently because of the route, routing rules or server status. A failed probe doesn’t necessarily mean all services will fail. Choose a route based on the task you actually need to perform, not just one indicator in the list. This guide doesn’t provide fixed speed test figures; check the route page and dashboard for current status and availability.

Keep peak-time comparisons consistent

If everything works during the day but slows down in the evening, check the local network and target service during the slowdown, then compare another route. Testing different content on different days won’t show whether the time of day is a factor. Note how the same device, network and task perform at different times, along with the selected route. If every route is slow on the current network but works on another, focus on the local network’s upstream connection. If only one route changes noticeably, report that route and the time range.

Route types can help guide your selection, but they don’t guarantee the same results on every network. The real-world performance of IEPL dedicated lines, relay routes and direct connections depends on your local carrier network and the target service. Don’t assume a route is trouble-free just because it’s labelled “dedicated,” or dismiss other types without testing them. If you encounter congestion, use a verified alternative route and keep its exit region suitable for the target service. Frequent region changes to chase speed may trigger additional verification.

Test the task itself and separate network time from service processing time

For video, keep the content and quality fixed and see whether buffering improves. For calls, check audio continuity and video freezes, not just download performance. For collaborative documents, distinguish slow initial loading from slow input syncing. For AI tools, check page loading, request submission, service processing and response delivery separately. For a closer look at API requests, read our guide to consistent exit IPs, concurrency and timeouts for AI APIs. For workplace use, see our guide to choosing routes for calls and collaboration tools.

If the same target is slow on different routes while other services work, check the target service status and account notices. If switching routes fixes it, keep using the working route and note the original route; there’s no need to keep changing DNS or system settings. If you need help, share what you did and the conditions you compared, not just “it’s slow.” Data allowance and network speed are different things. Upgrading a data plan won’t necessarily fix route congestion, so identify the cause before changing plans.

First determine whether the connection or the app session dropped

When an app asks you to reconnect, first check the client and system connection status. If the client is still running and other websites work, the app session may have expired or the target service may be down. If the system connection indicator has disappeared or the client process has exited, check background operation and permissions first. A video call reconnecting or a chat app briefly going offline doesn’t necessarily mean the tunnel stopped. Note whether the device was locked, changed networks, had its lid closed or entered power-saving mode before the drop; those details are more useful than a general description.

Switching between Wi-Fi and mobile data can change the local address and network path, so existing connections may not survive the switch. A client coming back online doesn’t mean an interrupted app session will resume automatically. Wait for the network to stabilize, reconnect the client and start the task again. For important uploads, remote operations or long-running requests, check whether the app supports resuming. Don’t submit repeatedly until you’ve confirmed the result, or you may create duplicate tasks or content.

If the connection is stable while the device is stationary but drops when you move or change access points, check local Wi-Fi coverage and network handoffs. If it drops periodically without any network change, check the client logs for system termination, network unreachable or remote closure messages. Don’t guess at account limits based on the time between drops, and don’t add keepalive settings from unknown sources. Reconnection behavior varies between clients; use the setting names shown in your current client.

Check background operation by platform

On Android, check the current client’s battery use, background activity and data permissions. Settings may be in different places on different devices, so use the app info page or system search instead of relying on screenshots from another device. If the system offers options such as restricted, optimized or unrestricted background activity, understand their effects and adjust only this client as needed. Don’t set every app to unrestricted or install an extra background-management tool; these changes can increase battery use and create new issues.

On iOS, check whether the VPN configuration still exists in system settings, whether the client is available and whether another network configuration is enabled. Force-quitting the app, switching configurations or changes to the system network can alter the connection state. Keep the network stable while comparing behavior in the foreground and after locking the screen. If only one app stops refreshing after the screen locks, check that app’s own background behavior too; don’t attribute every background refresh issue to the network client.

How to restore service and assess recurring issues

After a desktop device wakes from sleep, first confirm that the basic network connection is back. Then check that the client is still running and the system proxy points to a working endpoint. On Linux, if the client runs through a service manager, check the relevant service status and logs. Don’t run a restart command using an unfamiliar service name. Desktop proxy settings and terminal proxy environment variables may differ; a working browser doesn’t prove command-line tasks have recovered. Test them separately before deciding whether to restart a specific app.

If an alternative route is stable but the original one repeatedly disconnects on the same network, in the foreground and with the same target, report the results to support. If disconnections occur only after locking the screen or switching networks, focus on the system behavior and background settings. After changing a setting, repeat the action that originally triggered the problem instead of checking only whether a page opens right after connecting. If you still can’t find the cause, keep log excerpts from just before and after the drop. Avoid repeated restarts that overwrite the logs, and don’t assume an app session will remain uninterrupted on every network.

Did the update fail while retrieving or parsing the subscription?

A subscription update usually involves retrieving content, recognizing its format and saving a local configuration. A request timeout means retrieval didn’t finish. A parsing error means the retrieved content wasn’t in a format the client expected. A write failure may be due to local permissions or storage. Check the update log for the specific stage; don’t delete the current configuration as soon as an update fails. If the old configuration still works, keep it as a rollback point. Clearing everything without a usable backup can turn a partial issue into a complete loss of connectivity.

Open the account dashboard to check your account, then use the subscription link provided there. No email address is required; you can get started with a username and password. Keep your login details secure. When copying the link, avoid extra spaces, line breaks or explanatory text. Import it using a method supported by your client; don’t mistake a webpage address for subscription content. A subscription link works like a credential: add it only to clients you trust, never to a public conversion site or online checker.

If the retrieved content is actually a login page, network sign-in page or error page, the client may report an invalid format. Go back and check the retrieval path, account status and basic network instead of editing the configuration syntax by hand. If the dashboard offers import options for different clients, choose the one that matches your client. Don’t guess at the format by changing link parameters or combine templates from other services with the VPNZW configuration; doing so can overwrite route, DNS and routing settings.

Use account details to understand data and device status

Monthly subscription data resets each month on the date you activated the plan, not on a fixed calendar date. If your remaining data changes, check the billing cycle and actual usage in the dashboard rather than assuming a reset failed based on the calendar. When you upgrade mid-cycle, the price difference is prorated for the remaining days. Don’t calculate that as extra fixed data or a new discount. See the Plans page for full plan and billing details. This page is for diagnosing account status, not for treating a plan change as the default fix for every issue.

Data bundles don’t expire; they remain valid until used. “No expiration” refers to the validity period, not to unlimited data. If you’ve used all your data, check your actual account status before deciding how to continue. If you use the same account on multiple devices, check whether a client you no longer use is still syncing or transferring data. Investigate unexpected usage using your own devices and activity records; a change in the displayed amount after one page refresh doesn’t prove someone else used your account or that the usage counter is wrong.

VPNZW has no limit on the number of devices connected at the same time. If the client reports “device limit exceeded” or a similar message, don’t assume it refers to a paid device limit or buy additional device slots. First check whether the message came from the VPNZW dashboard, the client, the operating system or the target app. Some apps, client import features and organizational policies have their own limits, which are separate from this service’s simultaneous connection policy. Keep the full notice and note where it appeared so support can determine whether it relates to account status or a client misreading.

Remove old configurations and protect subscription links

If an update succeeds but the route list doesn’t change, check whether the client still has an old configuration selected or several subscription groups with similar names. Updating one group while selecting a route from another can make the update seem ineffective. Identify the active configuration, then remove only copies you’ve confirmed you no longer need. Don’t enable configurations that overwrite each other, or assume that a changed route order means content is missing. Check the exact names and import results.

If you think your subscription link has been exposed, use the management options actually available in the dashboard, and check for old links saved on your devices. Follow the dashboard’s results to determine whether you need to import it again; don’t assume a particular account feature exists. To contact support, provide the update time, client name and error message, but redact the full link. For more on protecting account passwords and subscription links, read our beginner’s guide to account and subscription link security.

The system proxy doesn’t necessarily handle all traffic

Some apps use the system proxy; others have their own network settings, and some support only specific proxy types. A working browser doesn’t mean your terminal, meeting app or background service uses the same path. First look in the app’s settings for network, connection or proxy options and check the documentation. If there’s no relevant setting, see whether the client supports a mode that can handle the app’s traffic. Don’t assume a setting called “Global” necessarily covers every program and protocol.

For an in-app proxy, use the proxy address and port from the current client’s local listener settings, not values copied from someone else’s device. Check that the proxy type matches what the app requires. If the settings look correct but it still fails, disable the in-app proxy to restore the original state, then compare with the system-level mode. Combining both can produce an unexpected path or send a request through the local proxy twice. Test one clearly defined method at a time.

Terminal programs often read proxy environment variables that desktop browsers may ignore. An old terminal session may retain an obsolete setting, while a new one uses different values, causing inconsistent results on the same device. Check the program’s official network documentation and current environment. Don’t paste environment variables containing credentials into a support ticket. For a test request, start with a public target that contains no account information, then retry the actual task. This helps keep keys out of debugging logs.

Check both the main domain and related requests in routing rules

Routing rules may choose a path based on the domain, address, app or other conditions. A single page may request sign-in services, images, attachments and APIs. Routing the main page through the proxy doesn’t mean all related resources will use the same path. If a page loads but you can’t sign in, or its text appears but attachments fail, note the specific action that failed. If the client has connection logs, check the rule and exit point used by the failed request. Don’t guess which domains are involved based only on a website’s brand name.

When changing rules, use a method supported by the client and save the original rules first. Don’t delete all routing rules to get one app working, or force all local and internal services through an external exit. Workplace internal domains, file shares and administrative services may need their existing paths. Ask an administrator before changing policies on a managed device. After changing a rule, close the app and reconnect so new requests can use the updated match.

Temporarily switching the traffic-handling mode can help with comparisons, but it isn’t automatically the right permanent setting. If the app works after expanding the traffic covered, the original path may not have included the required requests. Find the missing rule rather than keeping a change that affects other apps. If the mode change makes no difference, check the app’s own settings, account status and target service requirements. After testing, undo changes that didn’t help and keep only the smallest adjustment you’ve verified.

A correct exit point doesn’t rule out service-side restrictions

Seeing the expected region in an exit IP lookup confirms only the path used for that check, not the path used by every app. Verify sign-in, content loading and the task itself in the target app. AI tools may be affected by account eligibility, regional policies and request frequency. Streaming services may have content, account and regional restrictions. A working network connection doesn’t mean the target service has authorized access. Don’t present a business error from a website as a promise about VPNZW routes.

Troubleshoot APIs separately from web apps. If a website works but an API call fails, note the request stage, error type and whether a connection was established, then check the SDK or program’s proxy support. A request that reaches the server and gets a service error needs different troubleshooting from a network timeout before sending. Don’t put real credentials in public command examples to test a proxy, and don’t repeatedly retry a request without checking the result. See our ChatGPT guide for more on this use case.

When reporting an app issue to support, include the app name, platform, proxy method, action that failed and browser comparison results. If you have connection logs, share only relevant excerpts with sensitive details removed. Hide request contents, account identifiers and authorization information. If the problem started after an app update, describe what worked before and what changed afterward; there’s no need to speculate about the app’s implementation. This helps assess compatibility without treating unverified app behavior as a service capability or a route failure.

Retest the original scenario after making a fix

A page suddenly loading doesn’t necessarily mean the original issue is fixed. Restore the initial conditions and repeat the task that failed. For a background disconnect, check what happens after locking the screen. For an attachment failure, retrieve a similar attachment again. For a subscription update failure, check the update result and the active configuration. Don’t use an unrelated page loading as proof that the actual task now works. Also confirm that changes to the proxy haven’t affected local or workplace services.

Keep the final settings that worked and revert temporary changes that didn’t help. Extra rules, manual DNS settings and duplicate subscriptions make the next round of troubleshooting harder. Write down the original symptom, the change that helped and the verification result. If the issue only goes away on an alternative route, describe it as a temporary workaround—not proof that the original route is fixed. A temporary solution and a confirmed cause are different outcomes.

If the issue comes and goes, observe it under the conditions that originally triggered it rather than repeatedly refreshing one page. Note when you switch networks, wake from sleep or change routes, and whether the problem occurs after any of these actions. Don’t run repeated high-load tests to prove the issue is gone or repeatedly trigger account verification on the target service. If you can’t reproduce it reliably, provide the full context of the latest occurrence. Support can still use it to narrow things down, but label guesses as guesses.

When to contact support

If your basic network and account status are normal and the issue persists after comparing networks or routes, report it through a support ticket in the account dashboard. Support can also investigate if the same issue occurs across multiple devices and networks, a subscription consistently fails to parse or the dashboard status clearly differs from what you see in use. For permissions or workplace network policies on a managed device, ask your administrator as well. Support can’t grant organizational permissions or ask you to remove management controls.

Describe the symptom and scope in the ticket title; that’s more useful than “Urgent” or “Everything is broken.” In the message, include the platform, client name, network type, selected route, time of the issue, exact error and comparisons you’ve already made. Distinguish between a test you haven’t run and one that failed. Don’t make up results just to fill in details. Screenshots should show where the message appeared and enough context to understand it, but hide usernames, subscription links, payment details and unrelated content. If the logs are long, include the excerpt around the relevant action.

Protect your credentials and understand what support can do

Before sending, check your logs for full subscription links, authorization fields, access tokens or private request content. If you’re unsure whether something is sensitive, describe the error and the module where it appeared, then ask what needs to be shared. Don’t upload a complete configuration file or send account details through public article comments. If support needs more information, add relevant excerpts to the same dashboard ticket so the conversation stays in context and important details aren’t lost.

VPNZW covers 90+ countries and 150+ routes, with no limit on simultaneous devices. These facts don’t mean every target website will be accessible under all conditions. App policies, local networks and device status can all affect the result. For purchases and billing, refer to the Plans page and your dashboard status. See the Terms of Service for details on the 30-day money-back guarantee. A refund policy isn’t a troubleshooting step, and a single connection issue doesn’t determine your billing outcome.

After support replies, follow the suggestions one at a time and report what changed. Say which steps you completed and which you couldn’t test because of permissions or your environment. If the results differ from expectations, keep both the old and new error messages instead of replying only “still not working.” Once service is restored, you can add the final working method to the same ticket for future reference. To review the full setup process, use the Quick Start Guide. For common policies, see the FAQ; there’s no need to change settings that are already working reliably.