VPN Troubleshooting Guide

Diagnostic baseline

Cannot connect at all: first identify where the failure stops

“Cannot connect at all” can describe several different situations: the client will not start, a subscription has been imported but shows no routes, clicking Connect immediately returns to a disconnected state, the connection remains stuck for a long time, or the system says it is connected while no traffic passes. They look similar but require different fixes. First check whether the client can open its configuration page, whether subscription routes are visible, and whether the failure occurs before or after clicking Connect. If the client will not open or a permission request is incomplete, handle installation and system permissions first. If the route list is empty, skip to the subscription section. Only when routes are present and the connection action fails should you inspect the network and route.

Create a minimal test environment

First close other tools that can change routing, including leftover system proxy settings, browser-specific proxies, enterprise network clients, and virtual adapters that were previously enabled. Do not run two programs that provide system proxy or tunneling at the same time: the later one may overwrite the default route while the earlier one continues handling DNS, leaving every interface looking normal but traffic without a clear exit. After closing these programs, fully quit the 46VPN client and reopen it instead of repeatedly clicking Connect in the window.

Next, keep one network entry point fixed for testing. If you are on Wi-Fi, stay on that network and do not switch access methods repeatedly during the test. Open an ordinary webpage that was already known to work to confirm the base network is available. If no webpages open without 46VPN, the problem is at the local network entry point, and changing routes will not produce a useful conclusion. Once the base network is confirmed, reconnect using another available route. Do not try every route with similar names; switch first to a different region or route type to determine whether one route is faulty or the connection mechanism is failing as a whole. See the full route range on the Global Locations page.

Check system permissions and virtual adapters

Desktop clients usually need to create or use a virtual network interface. If a system permission prompt is canceled on first launch, the client may open and show routes while the tunnel still cannot be established. On Windows, check the network adapter list to confirm that the relevant virtual interface exists and is enabled. On macOS, confirm in Network settings and privacy and security prompts that the network extension is allowed. On Linux, verify that the current account has the network permissions required by the client. Do not delete unfamiliar system interfaces; fully quit the client first, then use its built-in repair or reauthorization flow.

Mobile systems also require approval for a VPN configuration. If it was previously denied, deleted, or reset, start a new connection from the client so the system can show the configuration prompt again. When the Connect button immediately returns to its previous state, common causes include a denied system configuration, a damaged existing configuration, or an operating-system network policy blocking a new tunnel. Delete only an expired configuration created by the current client, then generate it again from the client. Do not remove configurations managed by an administrator in an enterprise or work environment.

Narrow the result with cross-checks

Cross-check across three dimensions: device, network, and route. Keep the device and network unchanged while switching routes to identify a single-route problem. Keep the device and route unchanged while switching networks to identify an entry-network problem. Keep the network and subscription unchanged while testing another supported platform to identify a local-device issue. 46VPN supports Windows, macOS, iOS, Android, and Linux, with unlimited devices online at once, so existing devices can be used for comparison without first removing other devices.

If every route fails on one network but works after switching networks, record the failed network type, whether web authentication is required, and whether enterprise or campus policies are present. If only one route fails, switch temporarily to another route and provide support with the route name and failure time. If every device, network, and route fails, confirm that the account and subscription still load normally in the user panel, then continue with subscription checks. Do not reinstall the client as the first troubleshooting step. Reinstallation clears logs, configuration, and reproducible state, so use it only when there is evidence of damaged permissions or configuration, not as a substitute for diagnosis.

Reachability and DNS

Connected but webpages will not open: separate routing, resolution, and browser state

A client showing “connected” only proves that the tunnel or system proxy is running; it does not by itself prove that DNS resolution, the default route, and browser requests are correctly using the route. First distinguish between “no webpages open,” “domains fail but a direct request to a known service responds,” “one website fails,” and “the browser fails while other apps work.” These boundaries determine whether to inspect the system network, DNS, the site itself, or browser extensions. Do not attribute a single site’s maintenance, account-region restriction, or login state directly to the route.

Verify a basic request before checking DNS

After connecting, open several websites with different purposes. If all fail, quit and reopen the browser so an old session from before the connection is not reused. If the problem continues, check whether the client shows traffic, whether the system proxy is enabled correctly, and whether the connection mode proxies only selected rules. Then use a terminal to check whether domains resolve. The example uses a public test domain and contains no real subscription information:

nslookup example.com

ping example.com

nslookup If it returns a result, the system can at least obtain a DNS record. If it reports that the server cannot be found, the request timed out, or no result was returned, the problem is more likely in the DNS path. ping may not receive replies because the target service may not respond to this type of probe, so it is not sufficient as the sole measure of website availability. What matters more is whether the command can translate the domain into an address. If the domain resolves but the browser still fails, check proxy routing, browser secure DNS, extensions, and cache instead of repeatedly changing DNS.

Clear caches and handle DNS problems

The operating system, browser, and client may all cache domain results. After switching routes, an old result may still point to the previous access path, making the page fail even though the connection has changed. Fully quit the browser, then clear the system cache for your platform. On Windows, use:

ipconfig /flushdns

On macOS, run the system cache refresh command in Terminal:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

On Linux environments using systemd-resolved, use:

sudo resolvectl flush-caches

After running the command, reopen the browser and test again. If the browser has its own secure DNS enabled, it may bypass the system resolution path, making system tests pass while the browser fails. Temporarily disable the option for comparison, then decide whether to use system resolution or the browser’s specified resolver. “Temporarily disable” is only a diagnostic variable, not a long-term configuration recommendation. Restore settings that meet your security requirements when testing is complete.

When only some websites are affected, do not broaden the scope

When one website will not open, test it in a private window to rule out old cookies, site storage, and extensions. Then switch to another route in the same region and see whether the result changes with the exit. If the homepage opens but login, video, or API requests fail, record the exact page and action instead of writing only “the website is unavailable.” Different subresources may use different domains, so a successfully loaded page framework does not mean later requests use the same path. Developers can inspect failed request domains, status codes, and long waits in the browser’s Network panel, but remove account information, authorization fields, and private content before submitting a ticket.

If every domain fails but access returns immediately after quitting 46VPN, check whether the client’s current mode fully handles system traffic and whether a manual proxy remains configured. On Windows and macOS, use the system network proxy page to confirm that the address and port are maintained by the current client. If the proxy remains after quitting the client, disable the leftover setting before running the client again. On mobile, disconnect, briefly disable and re-enable the network interface, then reconnect so the system can rebuild the default route. If the symptoms began after switching networks, perform a full disconnect and reconnect to prevent the old network’s DNS and the new tunnel from coexisting.

Once the route is working, use the exit IP and DNS check to verify that requests actually use the expected exit. Check the exit, DNS, and specific app together rather than relying only on the client button color. If the exit has changed and DNS resolves but a particular service still refuses access, the cause is more likely the service’s account, regional policy, or site status and should be handled separately.

Performance isolation

Slow speeds and peak-hour slowdowns: test the entry point, route, and app separately

Speed problems are often summarized as “the route is slow,” but the actual path includes local access, the carrier exit, the route entry, the international segment, the target service, and device performance. Congestion anywhere can appear as slow loading. Establish a local-network baseline while disconnected, then compare different routes, times, and apps instead of relying on one speed-test result. Speed-test tools choose their own target servers, whose paths may differ completely from the sites you actually use. A fast test page does not guarantee fast Streaming, AI Tools, or code repositories, and the reverse is also true.

First rule out local Wi-Fi and background traffic

Before and after connecting, check whether ordinary webpages remain stable, and pause cloud sync, system updates, large downloads, and local backups. When Wi-Fi fluctuates, the VPN tunnel turns existing packet loss into retransmissions and pauses. Move closer to the access point, avoid roaming between multiple access points, or compare with a more stable local connection when possible. If video quality already drops, webpages occasionally time out, or remote sessions pause while disconnected, fix the entry network first. Switching through more routes on an unstable baseline will not produce reliable conclusions.

Device performance also affects encryption and forwarding. If only one device is slow while others on the same network work normally, check power-saving mode, low storage, busy background tasks, and security software scanning all network traffic. A browser with many tabs, developer tools continuously capturing requests, containers, or virtual machines using the network can also change the experience. Close unrelated tasks and retest the same target page so device load is not mistaken for a route problem.

Choose routes by use case, not just by place name

Physical distance usually affects round-trip time, but it is not the only factor. The target service’s location, entry carrier, route type, and current congestion matter as well. For services in Japan, compare routes in Japan and nearby regions first. For US-facing development services, a geographically closer region is not necessarily better than an entry point with a more stable route. Judge by the actual use case: web browsing depends on time to first byte and sequential requests, video on sustained transfer, terminal sessions and AI coding tools on long-connection stability, and file transfers on sustained throughput.

Evidence of peak-hour slowdowns

If the same device, network, and target service are stable at other times but repeatedly slow during peak hours, record the time window, route, target service, and symptom type. “Slow to start,” “pauses during playback,” and “terminal session disconnected” are more useful than simply “slow.” Then compare routes in different regions or route types. If one group of routes is broadly affected while another works, use the latter temporarily. If all routes slow at once, also check the local carrier, shared household traffic, and the target service for high load.

46VPN covers 90+ countries and 200+ routes, giving you options when local congestion affects one path, but no region suits every target. Keep several candidate routes that perform reliably on your network instead of depending on one exit indefinitely. After a route recovers, switch back and retest to see whether the issue is time-dependent. If one route repeatedly shows the same failure, providing support with its name, time window, entry network, and target service is more useful than an isolated speed-test screenshot.

Your traffic balance also needs checking. Monthly plans include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; traffic resets monthly on the activation date. Traffic packs are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they last until used and never expire. If the account shows an unexpected traffic status, open the user panel and verify the plan instead of assuming that stopped transfers mean route congestion. When upgrading mid-cycle, the price difference is converted based on the remaining days. See plans and traffic packs for details.

Session continuity

Frequent disconnects and mobile background drops: check the session lifecycle

First determine whether the tunnel actually disconnected, an app rebuilt its long connection, or the device switched network entry points. If the client still says connected but a chat, terminal, or video app reloads, only that app’s session may have expired. If the client also returns to disconnected, the tunnel was more likely interrupted. Note whether drops consistently occur after locking the screen, entering sleep, switching Wi-Fi, leaving an access point, or entering power-saving mode. Problems with a clear trigger can often be fixed in system settings; random drops need logs and comparisons across routes.

On desktop, check sleep and network changes first

When a desktop wakes from sleep, its network interface may have obtained a new address while the client retains the pre-sleep tunnel state. The interface can briefly show connected even though requests are no longer routed correctly. If webpages fail after wake, disconnect and reconnect before restarting the system. If it happens after every sleep cycle, check whether the client runs after system startup, whether it reconnects after network recovery, and whether the operating system disables the network adapter to save power.

Roaming between access points also changes the underlying connection. Even with the same network name, the device may move to another link and the existing tunnel may need to be rebuilt. For testing, stay in one place and disable automatic connections to other networks to see whether drops stop. On devices connected by both wired and wireless links, prevent the operating system from automatically changing their priority. If drops occur only at one entry point, investigate the entry network or router. If they occur at every entry point, check the client, system permissions, and route.

Mobile background policies are the main variable

Mobile operating systems restrict background activity to save power. After the screen turns off, the system may freeze the client, delay network tasks, or reclaim the session, causing brief unavailability when the screen turns back on. On Android, check the app’s battery policy, background permissions, data-saver mode, and built-in app-sleep features, and allow the client the background operation it needs. Menu names vary by manufacturer, so search around “battery,” “background,” “auto-start,” and “data usage” rather than following one fixed path. Lock the screen, wait, then reopen the app used in practice to verify the change.

On iOS, confirm that the VPN configuration still exists in system settings, and check Low Power Mode, network switching, and on-demand connection behavior. If the problem appears only when moving between Wi-Fi and a mobile network, fully disconnect, wait until the new network is stable, and reconnect. Do not repeatedly tap Connect while the signal is switching; the system may be cleaning up the old session while creating the new one, making the displayed state temporarily differ from the actual route. If only one app fails after background recovery, force-close and reopen it. If every app fails, reconnect the tunnel.

Separate route interruptions from app reconnections

Watch one ordinary webpage and one long-connection app at the same time. If the webpage stays available while the long-connection app drops, the issue is more likely the app session, heartbeat, or target service. If both fail and the client reconnects, route or entry-network instability is more likely. Repeat the same test on another route. If the symptom disappears, record the original route. If all routes drop on one network but work on another, record the entry network. This result is far more actionable than “it disconnects often.”

If disconnects are unrelated to the number of devices online on the account, there is no need to delete devices as a test. 46VPN supports unlimited devices online at once, so normal connections from your own devices do not exceed a device limit. Check instead whether multiple devices are transferring heavily, the household entry network is congested, or one device is repeatedly reconnecting and causing local interference. Use the device dimension to compare failures, not as a limit that must be cleared.

Subscription state

Subscription update failures and unexpected device notices: verify from source to local cache

Subscription updates usually fail at one of four stages: the user panel generates subscription information, the client accesses it, the client parses it, or the new configuration is saved locally. First confirm that the account can sign in normally and that plan and traffic details load in the panel. 46VPN registration requires no email address; a username and password are enough, so use the actual username when checking the account. If credentials are forgotten or the sign-in state is abnormal, follow the account flow in the panel instead of repeatedly creating accounts, which can scatter plans and subscriptions across different accounts.

Confirm the subscription source and access path

Get both the client and subscription from the user panel. Do not use a forwarded address, text copied from a screenshot, or an old third-party record. Marketing pages do not provide static installer links or public subscription URLs; the panel provides the client and subscription associated with the account. If a subscription used to update but suddenly fails, return to the panel and copy the current entry again instead of using old content that may be expired, truncated, or padded with spaces.

When copying, make sure the text is complete from beginning to end. Do not edit query parameters manually or mistake preview text automatically generated by a chat tool for the address. The example below uses only obvious dummy values to illustrate the format and cannot be used for a real connection:

https://example.com/sub?token=YOUR_TOKEN

If a browser can access the subscription entry but the client cannot update, the issue is more likely the import method, format compatibility, or local cache. If neither browser nor client can access it, check account status, the current network, and whether the entry is valid. Never paste real subscription content into a public forum or a publicly visible ticket screenshot. A subscription entry is part of the account credentials; if it is exposed, update it through the available process in the user panel instead of continuing to share it for troubleshooting.

Handle cache, duplicate configurations, and parse failures

Record currently working routes before updating so you have a fallback if cleanup is needed. First run the subscription update inside the client rather than deleting the configuration. For a format error, check whether you imported a webpage address, quoted text, or incomplete content. For a network error, switch to an environment with a working base connection and try again. For a write error, check whether the client has the system permissions needed to save configuration. Delete the old subscription and re-import it only after confirming that the local configuration is damaged.

When a client contains multiple subscriptions with the same name, you may update an old entry while connecting to routes from another. Compare update times, route names, and sources. Keep the current valid entry and remove only clearly duplicated, expired copies. Before doing so, export configuration notes without account credentials or record route names for recovery. If routes remain empty after re-importing, keep the exact client error and subscription update time, then ask support to check whether the server response matches the client parser.

How to assess an over-limit device notice

46VPN allows unlimited devices online at once, so normal use of your own devices should not be treated as a plan-based device limit. If the client, system, or another app shows a similar notice, first identify its source: the 46VPN user panel, the current client, the operating system, or another network tool running at the same time. Screenshots should include the window title and the complete notice area; a single sentence is not enough to identify the source. If the notice is not from 46VPN, handle it in the corresponding software or system environment.

If the user panel actually shows a state inconsistent with the unlimited-device rule, stop deleting devices or repeatedly purchasing plans and submit a support ticket directly. Include the account username, plan name, affected platform, action path, and a complete screenshot, but never include a password or subscription entry. Support needs to verify the account-side state, not have you hide the issue by reinstalling the client. If the notice appears on multiple platforms, specify which of Windows, macOS, iOS, Android, and Linux are affected. If it appears on only one platform, also check that client’s local cache and signed-in account.

For payment verification, rely on the order record in the user panel. 46VPN supports Alipay, WeChat Pay, and USDT. For a payment-related ticket, provide the order status, payment method, and order identifier visible in the panel; never submit a payment password, complete account credentials, or unrelated private information. If you are unsure which plan to choose, read the pricing and plan details first. This service offers 60-day no-questions-asked refunds; handle refund requests through panel tickets under the site terms instead of creating duplicate orders as a test.

Application routing

One app does not use the proxy: check mode, processes, and independent network stacks

When the browser works and the exit has changed but one app still uses the original network or cannot connect at all, the problem is usually application routing rather than the entire route. The app may ignore the system proxy, use independent DNS, create a particular connection type directly, start helper processes, or establish a session before the connection is ready. First prove that only this app is affected by comparing the browser and another app on the same device. Confirm the system works overall before investigating the app’s network behavior. If all apps fail, return to the Web and DNS section.

Rebuild the app session first

Many apps read the system proxy at startup and continue reusing existing connections. If the app was opened before connecting to 46VPN, it may not migrate automatically to the new path. Fully quit the app, including tray processes, menu-bar processes, and background helper services, then connect 46VPN and start it again. Closing the window often leaves background processes running. Development tools, game platforms, messaging apps, and sync software are especially persistent, so confirm in the system task manager that their processes have ended.

After restarting, use the app’s own account refresh, content loading, or network diagnostic function to test again. If it works, the issue came from the old session and global settings do not need to change. If it still fails, check whether the app offers “Use system proxy,” “Auto-detect proxy,” “Direct connection,” or custom network settings. The app should usually follow system settings first. Clear any saved old proxy address. Do not configure both system and app proxies without understanding them; this can create duplicate forwarding or send requests to a closed local port.

Compare rule mode with full mode

In rule mode, only requests matching the relevant rules use the route. If an app’s domain, address, or protocol is not covered, it uses the original network. For diagnosis, temporarily switch to a more comprehensive connection mode. If the app immediately works, the issue is rule matching; if it still fails, continue checking the app’s network stack and system permissions. Restore the original mode after comparison, then adjust rules for the app’s domains or processes instead of permanently changing other apps’ paths.

If the client supports per-app selection, confirm that both the target app and its helper processes are included. A browser may have one main process, while a development tool may issue requests through a launcher, background service, and runtime. Selecting only the visible main program can leave downloads, login, or update modules connecting directly. Use the system task manager to observe related processes added after launch, then configure them through the client’s per-app features. Do not copy complete rule sets from unknown sources; keep rules focused on the actual app and domains so they remain maintainable.

Special cases for development tools and command-line apps

Terminal programs usually do not automatically read the browser proxy settings from a graphical interface. Some commands read environment variables, other tools use their own configuration files, and some follow system routing directly. When the browser works but the command line fails, first confirm whether the client provides a system proxy or takes over through a virtual adapter. If environment variables are required, use only the local address and port explicitly shown by the client; do not copy fixed values from another guide. The example shows only the variable form and provides no invented port:

export HTTP_PROXY="http://LOCAL_PROXY"
export HTTPS_PROXY="http://LOCAL_PROXY"

unset HTTP_PROXY
unset HTTPS_PROXY

After diagnosis, use unset to clear temporary variables so the terminal does not keep pointing to an invalid address after the client exits. Git, package managers, container environments, and integrated development tools may also store their own proxy settings, so check each layer. A container’s network environment differs from the host’s; host access does not guarantee that the container inherits it. In remote development, also determine whether the request originates locally or on the remote host. Identify where the request executes before choosing which side to configure, rather than repeatedly changing the local machine without effect.

AI coding tools are sensitive to long connections, terminal sessions, and helper processes. Read the guide to choosing a VPN for AI coding tools and maintaining stability for more. If the app opens a browser login and then returns to the client, check the browser callback, client main process, and background service together to ensure they use the same network path. If only one account fails while others work, separate account region, service policy, and network failure instead of broadening proxy coverage.

Escalation and recovery

When to contact support: turn one failure into a reproducible ticket

Troubleshooting should not become an endless loop. After confirming the base network, changing one variable at a time, and running cross-checks, stop making random changes if the issue reproduces consistently. Submit a ticket when multiple routes fail in the same way across multiple networks; one route remains abnormal while others work; the user panel conflicts with unlimited-device access, traffic, or order status; the subscription entry is reachable but the client continually fails to parse it; system permissions are confirmed but the client still cannot create a connection; or the same app continues to fail in full routing mode.

What context a support ticket must include

A useful ticket should describe the symptom before offering a conclusion. Write something specific such as “clicking Connect returns the client to a disconnected state,” “all domains fail to resolve after connecting,” “all apps lose network access after waking from a locked screen,” or “only one app’s login request fails.” Then name the affected platform using the actual item among Windows, macOS, iOS, Android, and Linux. Include the current network type, route name, time window, whether the issue reproduces every time, and what changed between the last normal session and the failure.

Then list the comparisons already completed: whether you changed routes or networks, whether other devices work, whether other apps work, whether quitting and reopening helped, and whether clearing the DNS cache changed the result. Include only actions you actually performed; do not add unverified conclusions just to make the ticket look complete. For website or app issues, provide the service name, failed action, and exact error text. For subscription issues, provide the client’s error type and update time, but never paste the real subscription entry.

Issue:
Affected platforms:
Current network:
Selected route:
Affected app or website:
Reproduces consistently:
Comparisons completed:
Exact error text:
Available redacted screenshots or logs:

Screenshots, logs, and privacy boundaries

Screenshots should show the client status, route name, error message, and enough system-time context, while masking sensitive account information beyond the username. Passwords, subscription entries, payment credentials, cookies, authorization tokens, and private messages must not appear in attachments. Before submitting logs, search for complete request URLs or account fields. If the client offers a redacted export, use it first. If you cannot verify the log contents, say in the ticket that logs are available and ask support what scope is needed.

Network diagnostic screenshots should show the test conditions. For a failed website screenshot, also state whether other sites work, whether the client is connected, and which route is in use. A single error page cannot distinguish a target-service failure from DNS, route, or browser state. For speed issues, do not attach only a speed-test page; describe the real app behavior, whether the disconnected baseline works, and how the result changed after switching routes. For frequent disconnects, state whether they correlate with screen locking, sleep, or network changes.

Keep a fallback state while waiting for support

After submitting a ticket, use a verified working backup route instead of deleting every configuration. Keep the route name and action path that reproduce the issue, while switching daily work to a stable candidate. If only one app is affected, temporarily restore the original rules and use another available method instead of changing the whole system. If subscription updates are failing while old routes still work, keep the old configuration until the new subscription is confirmed imported successfully.

Record the current state before major changes, including the client connection mode, whether the system proxy is enabled, whether DNS is managed by the system, the subscription name, and available routes. This lets you return to a known state even if a test has no effect. Network resets, clearing client data, and reinstalling have broad impact and should come after permissions, cache, and configuration issues have clear supporting evidence. Confirm that account credentials work before proceeding, and check the user panel for how to retrieve the client and subscription again.

Complete one final verification after recovery

When the issue appears fixed, repeat the original failing action instead of checking only the client’s connected status. For connection issues, confirm that ordinary webpages and the target app work. For DNS issues, confirm domain resolution and the exit path. For speed issues, observe sustained performance in the real use case. For mobile issues, repeat the original screen-lock and network-switch triggers. For subscription issues, confirm that the route list updated and can connect. For app-routing issues, verify that both the main process and helper functions work.

Finally, record the changes that actually worked and undo temporary diagnostic settings that did not, such as proxy environment variables, browser test switches, or full routing mode. Keep a short result covering the symptom, failure boundary, effective fix, and rollback method. If a similar issue appears later, verify the same boundary first instead of testing every setting from scratch. If a local route issue caused the problem, check Global Locations and prepare an alternative exit. For subscription and budget questions, return to the plans page to verify traffic and billing periods.

46VPN offers 60-day no-questions-asked refunds. If the service still does not meet your practical needs after the support process, follow the service terms. Troubleshooting and refunds are separate processes: technical tickets verify connection, routes, clients, and account status, while refund requests depend on the terms and order status. Keep the two requests separate so technical and order details do not get mixed into one description.