VPN Troubleshooting Guide

What to check when you cannot connect at all

Define “cannot connect at all” precisely first: does the client fail to open, show no nodes after a subscription import, report an error immediately after you click Connect, or remain stuck processing? These symptoms belong to different layers. Switching routes repeatedly at the start can mix together local network, system permission and account issues. First verify that the basic network can open ordinary websites directly, then check whether the client can read the subscription, and only then test individual routes. Record the result after each layer and change only one setting at a time; otherwise, even if the connection returns, you will not know which action helped.

Classify the problem at the right layer first

Disconnect the client, then use a browser to open websites you normally use. If they also fail, the issue is with the local network, router or current access environment; a client cannot replace a broken underlying connection. Switch to another known-working network and test again, watching for a system prompt requiring confirmation on a network sign-in page. If ordinary websites work, open the client and inspect the node list. An empty list usually points to an unimported subscription, a failed subscription update or an overwritten configuration. If nodes are present but every route fails, continue by checking the system proxy, virtual network permissions, security software blocks and system time.

A client starting successfully does not mean its core network components have permission. After first launch, a system update or reinstallation, the system may again ask to allow a VPN configuration, network extension or virtual adapter. After one rejection, clicking Connect may show only a generic error. Open the system network or privacy permissions page and confirm that the relevant authorization is still enabled. If necessary, remove the old network configuration, then obtain the 93VPN client from the user panel and import the subscription again. Always download the client through the user panel download entry; do not mix in configuration files from unknown sources.

Immediate connection failures versus prolonged waiting

An immediate failure after clicking Connect often means the request never reached the route endpoint. Common causes include missing configuration fields, unapplied system permissions, a client core that did not start, a large device-time discrepancy or a network that blocks the required connection. Fully quit the client process and reopen it rather than merely closing the window. Then check the system date, time zone and automatic time synchronization. Certificate validation depends on accurate time; a significant discrepancy can make every route fail while ordinary web browsing still works.

If the connection stays processing for a long time, the request was more likely sent but did not receive a complete response. Test nodes from different regions and route types for comparison. Do not keep clicking adjacent routes in the same region, as they may share part of the upstream path. 93VPN covers 110+ countries / 240+ routes. Check the region and type on the route list, then choose routes with more distinct paths. If another underlying network connects while the original one consistently fails, focus on the original network’s routing, local network policy or access environment rather than changing the account.

Restore the basics without damaging existing settings

When a reset is necessary, first save the current error message and selected route name in the client, then update the subscription. If it still fails, remove the 93VPN subscription and import it again. Do not immediately clear the client’s entire configuration, because it may contain rules you maintain yourself. After reimporting, test in the client’s default mode without custom scripts, port changes or additional network tools. If the default state connects, restore personal settings one at a time. If it still cannot connect, compile the exact error, system platform, network type, route name and reproduction steps for a support ticket.

Do not judge recovery only by whether the switch says Connected. After connecting, open an ordinary webpage, check the network test page to confirm that the exit address has changed, and test the service that previously failed. If the connection appears normal but websites remain inaccessible, the issue has moved from “cannot connect at all” to proxy takeover or DNS. Continue with the next chapter instead of repeatedly clicking Connect.

Connected but websites do not load: check proxy takeover and DNS

If the client shows Connected while websites still fail to open, the tunnel state and the actual traffic path do not match. Common causes include the system proxy not being taken over correctly, a browser reusing an old connection, routing rules sending the target domain direct, DNS returning a result unsuitable for the current route, or the website using a protocol not covered by the current proxy mode. Do not treat “Connected” as the end of troubleshooting. Verify DNS resolution, the exit address and the traffic path used by the specific application separately.

Separate a domain issue from an end-to-end issue

Test several websites of different types first. If every site fails, check system proxy and virtual-network takeover. If only a few domains fail, check rules and DNS. Pages already open in a browser may reuse sessions created before the connection changed, so close the relevant tabs and open them again; fully quit the browser if necessary. Then use a built-in system command to query a public domain and see whether local resolution works. The example is only for testing local resolution and contains no 93VPN credentials:

nslookup example.com

ping example.com

A result from nslookup only shows that the resolver returned an address; it does not prove that the address is reachable through the current route. A silent ping also does not by itself prove that a website is unavailable, because some servers do not respond to these requests. A more reliable approach is to check the browser error at the same time: “server not found” points to DNS; a connection timeout points to routing or the route; certificate or time errors call for a system-time check; if the page opens but some resources are missing, some domains may not be following the same routing policy.

Handle DNS caches and resolution paths

After changing routes, the system and browser may continue using resolution results cached before the connection changed. Fully quit the browser, use the system’s DNS refresh function, or disconnect and reconnect to the current network. Do not enter several public resolvers at once without understanding their roles. Remote DNS in the client, system DNS and browser secure DNS can create three separate paths, causing the main domain to use the proxy while resource domains connect directly using local results. During diagnosis, keep one path: use the client’s default DNS setting and temporarily disable browser options that override system resolution.

If only one website is affected, check the client log to see which rule matched its domain. If it matched Direct, switch the client to global takeover mode for comparison. If global mode works while rule mode fails, fix the rule rather than changing plans. If global mode also fails, try a node with a different region and route type. If several nodes return the same error for one domain while other sites work, the cause may be the target service’s regional policy, account region or server status, not a client failure.

Check for leftover and conflicting system proxies

After an abnormal client exit, the system proxy may still point to a stopped local port, leaving web browsing broken even after the client is closed. On the system network proxy page, confirm that automatic proxy, manual proxy and VPN settings match the current client state. If several applications modify the system proxy, quit all of them and test with only one client running. Once browsing works again, relaunch the other tools one at a time and note when the issue returns. This separates a 93VPN route issue from local software competing for the proxy port.

Also check browser extensions, system security software and managed network settings. Some extensions proxy only browser traffic and can override system settings; some security policies block new virtual network interfaces. For comparison, use a browser profile without extensions, but do not leave all security protections disabled. If the device is managed by an organization, confirm whether network extensions may be added or proxy settings changed. Final verification should cover the exit IP, DNS resolution and target webpage. See How to confirm that a VPN is really working for related methods.

Layered checks for slow speeds and peak-hour lag

Speed issues need a baseline; otherwise “slow” is only a subjective impression. Compare direct access with the connected state on the same device, underlying network and target service, distinguishing slow initial page loads, slow sustained downloads, video buffering, voice jitter and upload problems. These point to different bottlenecks: initial page loads depend more on DNS and connection setup, sustained transfers on path capacity and packet loss, voice and remote work on jitter, and upload problems may reflect poor local upstream quality.

Rule out the underlying network and background usage first

Disconnect the client and test the underlying network. If direct access is unstable too, address wireless signal, router load, access-network congestion or the carrier path first. Pause cloud sync, system updates, livestreaming and large downloads during testing so other tasks do not consume all upstream or downstream capacity. Many cases where a download “does not reach full speed” are actually caused by background sync using the upstream, delaying acknowledgements and reducing overall throughput. On mobile networks, also observe whether moving around causes frequent network changes instead of relying only on the signal icon.

Do not judge a route from a single speed test. The test site may select a server at a different distance and may use a completely different path from the service you actually need. A better method is to repeat the real task: open the same group of pages, play the same content, fetch the same development resource or access the same work system. Keep the target unchanged and switch routes one by one. This measures real-world experience rather than an isolated number.

Choose routes by distance, type and purpose

Start with a geographically nearby region to reduce uncertainty across the international path, but the closest route is not always the fastest; the local carrier’s path to the entry point also matters. If a nearby direct route fluctuates during peak hours, compare it with a relay or IEPL route. Direct routes have a simpler path and suit networks with good routing to the target region; relays optimize some inter-network paths through an additional entry point; IEPL focuses more on path stability. Check route names and types on the global routes page.

How to capture useful evidence for peak-hour issues

If peak-hour lag occurs only on a particular network, record the access method, full route name, target service and exact symptoms. Do not write only “very slow”; support cannot tell whether the issue is slow resolution, slow connection setup, reduced throughput or adaptive bitrate from the video platform. Be specific: “page text appears first but images keep loading,” “video buffers but downloads are normal,” or “the remote terminal pauses frequently while websites work.” The more precise the symptom, the easier it is to match to the route, protocol or routing layer.

Cross-testing routes with clearly different paths during the same period is also important. If every route is slow and direct access is equally slow, return to the underlying network. If one route type is stable while another fluctuates, use the stable type temporarily and submit route feedback. If only one target service is slow, check its region selection, account region, app rules and server status. For Streaming, see the route notes on this site, but do not confuse “the page opens” with “all content is available in the same region.”

If the panel shows normal available traffic, the underlying network is stable, and several target services remain unavailable on the same route, submit the comparison results in a ticket. If the issue disappears after switching routes, continue using the new route and note the original route name and context. The goal is not to prove that a route is simply “fast” or “slow”, but to find the more stable path for the current network, region and use case.

Frequent disconnects and mobile background dropouts

For frequent disconnects, first identify which layer is breaking: the underlying network, a transition between networks, a client process paused by the system, a rebuilt tunnel, or the target app’s own session timeout. The visible symptom may be a spinning page or messages that stop updating, but the remedy differs. The most useful record covers network changes, client state and app state immediately before and after the disconnect, not just a screenshot of the normal page after recovery.

Reproduce the issue on a fixed network

Test first in a stable location with a stable signal, and temporarily disable features that automatically switch networks. If disconnects stop on a fixed network, the likely cause is an access-network transition. The tunnel must be rebuilt after the underlying address changes, and some apps do not automatically restore long-lived connections. If it still disconnects on a fixed network, check whether the client switch also changes to Disconnected: a switch change points to a tunnel or client interruption; if it stays connected while one app stops responding, check the app session, routing rules and DNS first.

Sleep and wake cycles are another key boundary. After closing the lid, locking the screen or entering power-saving mode, the system may pause network extensions or restrict background activity. If websites work after wake but messaging still shows no new content, an old connection probably was not rebuilt; reopen the app or briefly disconnect and reconnect. If sleep makes the client quit completely every time, check background permissions, battery optimization and autostart settings instead of continually changing routes.

Why mobile apps drop connections more easily in the background

Mobile operating systems pause apps according to battery, memory and background-activity policies. Whether the tunnel continues running after the client moves to the background depends on the VPN configuration permission and background policy granted by the system, not on whether the app window remains open. Confirm that the client is not under strict battery restrictions, check whether the system VPN indicator remains after locking the screen, and test whether the connection can recover automatically when switching from Wi-Fi to mobile data. Settings vary by system, so use the labels shown on the system network and battery-management pages.

If the disconnect occurs only after the app has been in the background for a while but remains stable with the screen active, focus on background restrictions. If it happens whenever the network changes, focus on tunnel reconnection. If only the target app stops receiving content in the background while the browser remains usable, check that app’s notifications, background refresh and long-connection recovery. Do not attribute every background issue to the route; a route cannot stop the operating system from pausing an app process.

Desktop sleep, virtual adapters and software conflicts

On Windows, macOS and Linux, a virtual network interface may be renumbered or slow to become ready after waking from sleep. If the client shows Connected but traffic does not work, disconnect and reconnect first; if that fails, fully quit and reopen the client. Virtual machines, containers, remote-work security software and other VPNs may each add routes and DNS settings. During diagnosis, pause other tools that modify the network path and keep only the 93VPN client. Re-enable them one at a time after stability returns to locate the conflict.

Security-software blocking often appears suddenly after a client upgrade, system update or network-interface change. Check the security software’s event log to see whether it blocked the client process or virtual network component. You may create an allow rule for the 93VPN client that complies with local security policy, but do not leave all protection disabled. On managed devices, a policy refresh may revoke network permissions; an administrator must confirm this, and support cannot bypass local management policies.

The boundary between route switching and automatic recovery

Frequent automatic route switching does not necessarily improve stability. With a long-lived app connection, changing the exit can invalidate existing sessions, causing message interruptions, meeting reconnects or failed downloads. For ongoing tasks, choose one stable route and keep the exit unchanged; switch manually only after confirming that the route itself is unusable. For services that require a fixed session region, avoid changing regions repeatedly during a task.

If several routes disconnect in a similar pattern on a fixed network, check the error category at the time of disconnection in the client log and submit a ticket. If only one route is affected, record its full name and switch routes temporarily. If the issue occurs only after a network change or sleep, adjust system policies first. Identifying the trigger is faster than repeated reinstalls and prevents reproducible system behavior from being mistaken for a random failure.

Subscription update failures and abnormal node lists

A subscription update delivers the routes currently available to the account to the client. A failed update does not mean every route is broken or that buying another plan will restore access. First distinguish an unreadable subscription URL, client parsing failure, an old configuration that was not replaced, an account-status issue and a local cache problem. An empty node list, unchanged route names and a format error during update point to different stages and need different remedies.

Check the account and plan in the user panel first

Log in to the user panel overview and confirm the current plan and traffic status. Monthly plans are ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; traffic resets monthly on the activation date, and mid-cycle upgrades prorate the difference into remaining days. There are also permanent, never-expiring traffic packages valid until used: ¥158/300GB, ¥358/1000GB and ¥658/3000GB. If the panel does not match expectations, resolve the order or account issue first. If the panel is normal but the client update fails, continue by checking the subscription import.

Registration requires no email address: a username and password are enough. When recovering or verifying an account, first confirm that you are signing in with the original username. Similar usernames or a browser saving another account can make it seem that the panel has a plan while the client does not. Never paste the subscription link into public chats, screenshots or documents; treat it as a credential. For related security principles, read the VPN Safety Guide for Beginners.

Identify download, parsing and replacement failures

A network-request error during an update means the client could not retrieve the subscription content. Confirm that ordinary websites are accessible, then try updating while disconnected. If the current network cannot retrieve it, switch to another underlying network. A format or parsing error may mean the client received a login page, error page or incompatible content. Do not edit the subscription text manually. Copy it again from the user panel or use the panel’s import entry, and confirm that you selected a client method supported by 93VPN.

If the update reports success but the node list does not change, the client may still be showing an old configuration, may have updated a different subscription with the same name, or may not have switched configuration groups. Check the subscription name, update time and currently active group. Before deleting duplicates, confirm which one came from 93VPN. To avoid removing personal rules, remove only the old 93VPN subscription and import it again rather than clearing all client data. After reimporting, test connectivity with the default rules before merging personal settings.

Handle cache, system-time and certificate errors

Subscription requests rely on HTTPS validation. If the system date, time zone or certificate environment is wrong, the client may refuse to read the subscription. Enable automatic time synchronization and restart the client, then check whether certificate-related errors remain. Enterprise networks, public-network sign-in pages and local security software may also rewrite requests, causing the client to receive something other than subscription content. Compare with another trusted network. If the other network updates successfully while the original does not, the issue lies in the original access environment.

When the cache is abnormal, use the client’s built-in update or reimport function first; do not directly edit internal client files. Manually replacing cached files can desynchronize the configuration index from the actual content and cause later updates to fail. If the client offers separate “Update subscription” and “Update configuration” entries, choose the one for the 93VPN subscription. Do not confuse core software updates, rule updates and node subscription updates.

When to submit a subscription support ticket

Submit a ticket when the panel shows a normal plan, updates fail on multiple networks and reimporting the same subscription still fails. Include the system platform, client name, exact error, action that triggered it, whether the user panel opens, and whether the subscription list is empty. Hide the subscription link and any login information in screenshots. If the issue occurs only in one client, say whether other platforms work; this helps distinguish account content, network requests and client parsing differences.

Do not paste the complete subscription URL into a ticket. Support generally needs only the error text, platform, network environment and reproduction steps. If account verification is necessary, open the ticket through the logged-in panel. After the update works again, connect to a route and check the exit address rather than ending verification when the node list reappears.

An app does not use the proxy: check routing and takeover mode

If a browser works but one app does not, the entire route is usually not down. The app’s traffic may not be entering the client, may have matched a Direct rule, may use a protocol not covered by the current mode, or may retain a session created before the connection. Shift the focus from trying more routes to confirming the path this app actually uses. Establish a comparison with another app on the same device, then inspect the client log and takeover mode.

First determine whether it is one app or one domain

One app may access multiple domains for its main interface, login, images, voice and updates. If it can log in but some content fails to load, the whole app is not necessarily outside the proxy; a resource domain may have matched a different rule. If the app cannot connect at all while the browser works, check whether it has its own proxy setting, bypasses the system proxy or trusts only a specific network interface. Opening the app’s official website in a browser does not prove that its internal requests use the same path.

Quit the app completely rather than merely sending its window to the background. Connect the route, then restart the app so it creates a new network session. Some apps choose their network interface at startup and keep using an old connection if they are not restarted. If a restart fixes it, the issue was session rebuilding. If it still fails, temporarily switch the client from rule mode to global takeover mode for comparison. If global mode works but rule mode fails, inspect the matched rule. If both fail, check the route region, the app account region and the service status.

System proxy, virtual networking and in-app proxy differences

A system proxy mainly affects apps that follow system proxy settings, while some apps connect directly and ignore them. Virtual-network takeover usually covers more traffic, but it can still be affected by per-app settings, exclusion lists and system permissions. An in-app proxy is a separate configuration; if it contains a dead local address, it may bypass the client’s normal path. During troubleshooting, restore the app’s network settings to default temporarily and avoid chaining the system proxy with an in-app proxy.

Use logs to confirm the actual match instead of guessing

Client logs usually show the target domain, connection result and selected path. Open the app, perform one reproducible action and search the log for the relevant domain. If it matched Direct, create a targeted rule. If it matched Proxy but timed out, test a route in a different region. If the log contains no related request, the app may be outside the current takeover scope or the request may come from another process. Check the app’s helper processes and system network permissions.

Development tools, command-line sessions and containers are especially likely to be separate from the desktop system proxy. A terminal process may read environment variables only at startup, a container may have its own network namespace, and a virtual machine may use another gateway. After changing the system proxy, reopen the terminal or restart the relevant environment before making the request. Do not put real subscription URLs, account passwords or access tokens in command history; teaching configurations should always use obvious placeholders.

export HTTPS_PROXY=http://127.0.0.1:YOUR_PORT
export HTTP_PROXY=http://127.0.0.1:YOUR_PORT

curl -I https://example.com

The ports above are placeholders. Replace them with the local port shown in the client interface. If you use virtual-network takeover rather than a local proxy port, do not copy the environment variables. A command returning a web response proves only that the current terminal path works; it does not validate the app itself. For development involving OpenAI or Claude APIs, also distinguish web access from API-call connection behavior. See route selection advice for developers.

After recovery, switch the client back to the mode needed for everyday use and complete the app’s login, content-loading and sustained-connection flows. Verifying only the startup screen is not enough. If you add a rule, document its purpose and avoid overly broad matching, which could send local services through the proxy and create new access problems.

Device-limit warnings and account-status checks

93VPN plans support unlimited devices, so a “device limit exceeded” message or similar warning should not be read as proof that the plan has a device cap. More likely causes include being signed in to another service or account, an old subscription left in the client, confusion between similarly named configurations, a limit imposed by the app itself, or a message actually referring to a session or connection configuration rather than the 93VPN plan. Identify where the message comes from before deciding whether the account needs attention.

Confirm the source and exact wording of the warning

The message may come from the operating system, client, app-store account, another subscription service or the target website. Keep the window title and surrounding context in screenshots; do not capture only the middle line saying “limit exceeded”. If it appears in the user panel, record the page and triggering action. If it appears in the client, record the current subscription name. If it appears only in the target app, it is more likely a restriction from that service itself and unrelated to the device count in the 93VPN plan.

Checking the subscription source in the client is equally important. Users may save several subscriptions in one client under similar names. If the selected configuration is not 93VPN, the error is not governed by 93VPN’s plan rules. Rename the 93VPN subscription clearly to match the user panel if needed. Before removing an old configuration, save any personal rules you need. Genuine 93VPN subscriptions come only from the user panel; search results or someone else’s shared link cannot establish the source.

Check account, plan and traffic status separately

Confirm that the username matches when signing in to the panel. 93VPN requires no email address; a username and password are enough. If the browser autofills another username, the page may open normally while showing different orders and plans. Check the plan, orders and traffic status in the account overview. Monthly plan traffic resets on the activation date; traffic packages remain valid until used and never expire. When available traffic is exhausted, the usual result is an unavailable route or account-status message, not a device-limit issue.

Plan pricing and capacity are listed on the plans page: ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; traffic packages are ¥158/300GB, ¥358/1000GB and ¥658/3000GB. Supported payment methods are Alipay, WeChat and USDT. Do not determine account benefits from third-party screenshots, old caches or word of mouth. For a mid-cycle upgrade, the price difference is prorated into remaining days; the client does not calculate this status, so use the order result in the panel.

Clear old sessions and duplicate configurations

When a client contains several configurations with the same name, updating one may not update the currently active one. Record the route and rules in use, disconnect, remove confirmed-unused duplicate subscriptions, and import the subscription again from the panel. Afterwards, check the configuration source, node list and update time rather than only the subscription name. If the system network settings still contain multiple old VPN configurations, confirm that the active one was created by the 93VPN client.

Some systems retain old network configurations after an app is reinstalled, causing conflicts when the new client requests a connection. Identify and remove confirmed-unused entries from the system VPN list, then let the current client request permission again. Only remove configurations whose source is clear; do not casually delete entries managed by an organization or created by work software. If you cannot identify one, take a screenshot and ask the device administrator.

Cross-platform comparisons and fault boundaries

93VPN supports Windows, macOS, iOS, Android and Linux. If the same account works on one platform but shows an error on another, the plan is usually not the first suspect. Compare the subscription source, client permissions and configuration update time on both platforms. If every platform shows the same panel status, then check the account and order. Cross-platform comparison quickly separates server-side account status from a single-device configuration issue.

When submitting a ticket, state whether the message came from the panel or client, whether other platforms work, whether the current username matches the one used to activate the plan, and whether duplicate subscriptions exist. Support does not need your password or complete subscription URL. For an order issue, provide the order details visible in the panel and the payment method; the available methods are Alipay, WeChat and USDT. Once the issue is resolved, delete duplicate configurations created for testing and keep the one with a clear source.

When to contact support and what to include in a support ticket

The purpose of local troubleshooting is not to make you try indefinitely, but to identify the fault layer within a reasonable scope. Submit a ticket when the underlying network is normal, system permissions are complete, the subscription status is normal, and the issue still reproduces consistently across different routes or networks. This is especially appropriate when several routes show the same server-side error, the panel plan does not match the order, the subscription cannot be read on multiple platforms, or one route remains abnormal with clear comparison results. Reinstalling again usually adds no useful information.

When to submit a ticket directly

For errors involving account orders, plan status, traffic display or payment results, contact support through the user panel ticket entry; do not paste order information on a public page. 93VPN supports Alipay, WeChat and USDT. For a payment issue, state the method used, the order status shown in the panel and the action that occurred. For a refund request, the applicable service commitment is a 60-day no-questions-asked refund; see the refund policy for application and processing details.

Connection issues are also suitable for a ticket when ordinary websites work directly, client permissions are confirmed and reimporting the subscription still shows no nodes; when routes with clearly different paths all report the same connection-stage error; when the same route reproduces the issue on different networks; or when another route works and clearly isolates the abnormal route. If only one website is temporarily unavailable, first check its service status, regional policy and DNS so that a target-service outage is not reported as a route-wide failure.

What a diagnostic ticket should include

Describe the symptom and platform directly in the title, for example “Websites fail to resolve after connecting on macOS” or “Android did not recover automatically after switching networks in the background”, rather than simply “It does not work”. In the body, describe the context first, then list the troubleshooting steps already completed and the result of each. Include the system platform, client name, access-network type, full route name, target app or website, exact error, whether it reproduces on another route or network, and whether a system update, client reinstall or network change occurred beforehand.

Screenshots should include the complete error window and necessary context, but must hide the username, subscription URL, sensitive order details and other credentials. Include only log excerpts around the failure; do not publicly share an entire file containing personal directories, access tokens or other service configurations. If the log is long, identify the triggering action and error keywords. Never put a password in a ticket; support does not need it to diagnose a network issue.

Symptom:
System platform:
Client:
Current network:
Route name:
Target service:
Exact error:
Results on other routes:
Results on other networks:
Troubleshooting completed:
Reproducible action:

How to record a reproducible test

Keep the reproduction sequence short and use the same conditions each time. Quit other tools that may interfere with networking and confirm that the underlying network works. Open the client, update the subscription and select a specified route. Perform one clear action, such as opening the target webpage or refreshing app content, and record the error. Then change only one variable, such as the route or underlying network, and repeat the same action. This comparison shows whether the issue follows the route, network, device or app and is more useful than trying many random steps.

If the issue is time-dependent, record the time period; do not invent availability rates or user counts. If it is region-dependent, state the country, region and city shown for the route. If it occurs only in a development tool, include the proxy mode and a redacted request error, never a real API key. If it occurs only in a specific app, say whether the browser and other apps work so the routing scope can be assessed.

Review after recovery

Do not delete all records immediately after recovery. First confirm that the connection switch, exit IP, DNS, target webpage and target app all work again, then document the effective action in the ticket. If switching routes fixed it, retain the original route name. If changing a rule fixed it, record the matched domain and reason for the change. If background permission fixed it, record the system setting changed. If reimporting the subscription fixed it, confirm that the old configuration has been cleared. Next time, you can start from the verified boundary.

Restore temporary changes to a sustainable everyday setup. Switch global mode back to the required rule mode, re-enable security software paused during testing, remove test environment variables from terminal configuration, and clear duplicate subscriptions and old VPN configurations after confirming their sources. Do not keep overly broad rules or duplicate proxies after a one-time incident; they may create new conflicts later.

If these steps do not locate the problem, submit a ticket with the complete comparison results. 93VPN provides 110+ countries / 240+ routes, supports Windows, macOS, iOS, Android and Linux, and allows unlimited devices. Service facts define the account and route boundaries, but each fault still needs to be assessed layer by layer across the local network, system permissions, client state and target service. Recording each layer and changing one variable at a time is the most important principle in this guide.