VPN Troubleshooting Guide

DIAGNOSTIC METHOD

Build a Reproducible Diagnostic Method

Network problems are easiest to misdiagnose when several variables change at once. When a connection fails, users often reinstall the client, switch routes, adjust the system proxy, refresh the subscription, and restart the device all at once. The issue may disappear temporarily, but there is no way to know which step helped; when it returns, the entire sequence has to be repeated. A more reliable approach is to record the current state first, then change only one variable at a time. After each change, retest with the same website, app, or command so the results remain comparable.

Before troubleshooting, determine the scope of the problem. If it occurs in only one app, first check the app’s proxy support, routing rules, and cache. If every app on the same device is affected, check the client, system network, and DNS. If several devices on the same network are affected at once, the issue is more likely related to the current access network, routing environment, or a shared route. Scope does not provide an immediate diagnosis; it tells you which layer to examine first and prevents time being wasted elsewhere.

Keep a Stable Comparison Environment

A comparison environment can be another working network, another device with a known-good setup, or another regional route in the same client. Its purpose is not to replace the current environment, but to distinguish local problems from route problems. For example, if no route connects on the current network but connections work after switching networks, first inspect restrictions, DNS, or gateway status on the original network. If only one route fails while others work, do not immediately reinstall the client; switch routes first and record the affected route name.

Keep the destination consistent during testing. Do not compare routes by loading different websites, because each site has its own server location, cache, and resource size. Start with a stable, ordinary webpage, then test the AI Tools, Streaming service, or work app you actually need. If the ordinary page works but a specific service does not, the scope has narrowed from “the entire connection” to “the target service, regional exit, or app rules.” This is more useful than simply saying that the network is bad.

Separate “Connected” from “Usable”

When the client shows Connected, it only means that the local client and selected route completed some form of connection process. It does not mean domain resolution, the system proxy, app routing, and the target service are all working normally. Conversely, a failed client status alone cannot tell you whether the cause is the account, route, or current network. Break the path into subscription retrieval, route selection, connection establishment, DNS resolution, system forwarding, app access, and target response, then use the symptoms to locate the interruption.

Command-line tools can provide supporting evidence, but should not determine the diagnosis on their own. The examples below access a public example domain and contain no real subscription URL or credentials. If a command resolves the domain and receives a response while the browser still fails, check browser extensions, cache, system proxy handling, and security software. If domain resolution itself fails, go to the DNS section instead of repeatedly switching browsers.

Basic Connectivity and DNS Resolution Examples

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

Finally, troubleshooting records should use copyable details rather than simply saying “it doesn’t work” or “it’s very slow.” A useful report states the platform, access network, selected route, affected apps, exact error text, and what changed after switching conditions. With this information, even an unresolved issue can go straight to technical review instead of starting with basic questions again.

CONNECTION

Cannot Connect at All and Connection Establishment Failures

First clarify what “cannot connect at all” means: can the client not start, is the subscription list empty, does clicking Connect produce an immediate error, does it remain stuck on Connecting, or does it disconnect immediately after appearing connected? Each symptom points to a different layer. A client that will not start indicates local software or system permissions; no selectable routes usually points to subscription retrieval; failures during connection establishment on every route require comparison of the current network, system time, client permissions, and local security policies.

Check the plan and subscription status before troubleshooting the client. Open the user panel to confirm that the plan is still active, then retrieve the subscription again. Do not treat an old page saved in the browser address bar, outdated text from a chat, or a configuration exported from another device as the current subscription. VPNBi registration requires no email address; a username and password are enough. When checking the account, verify the username currently signed in and avoid using another account’s subscription in a different browser environment.

No Route Can Establish a Connection

If the route list appears normally but every route fails, quit and reopen the client, then confirm that the system maintains the date and time zone automatically. Certificate checks, encrypted handshakes, and subscription requests all depend on a reasonable system clock. A significantly incorrect time can cause connection failures, subscription retrieval errors, or certificate warnings in the browser. Next, check whether the client has the system permissions needed to create network connections. Windows and macOS may ask you to approve a network extension or system permission; mobile platforms also show a system prompt to create a VPN configuration. If permission is denied, the client usually cannot take over traffic properly.

Next, switch the access network for comparison. Move from the current wired or wireless network to another network you can use, but do not change the client and route at the same time. If the same device, client, and route connect on another network, the account and subscription are probably fine; focus on DNS, the gateway, access controls, or router settings on the original network. If every route still fails on different networks, import the current subscription for the same account on another device to determine whether the problem is device-specific.

Local security software or the system firewall may also prevent the client from creating a tunnel, but disabling protection for an extended period is not recommended. A safer approach is to review blocked-event logs, check for entries involving the client process, network extension, or virtual network adapter, and allow trusted programs using the security product’s supported method. Keep only the necessary rule after testing. On centrally managed devices, network extensions, proxies, and certificate settings may be controlled by policy. Contact the device administrator instead of forcing changes to managed settings.

Only Some Routes Fail to Connect

When other routes work and only one region or route fails, the client and account are usually not the first suspects. Record the affected route’s full name, then switch among nearby regions or other routes in the same region. VPNBi covers 120+ countries / 240+ routes; visit the Locations page to review regions and route types, then choose an alternative route based on the target service’s region. When the problem is limited to one route, repeatedly uninstalling the client only removes useful logs and comparison conditions.

If the issue changes with the access network—for example, one route fails on a home network but works elsewhere—include the network details in the ticket. If it is independent of the network and the same route fails on different devices, it is more consistent with a route-side problem. Changing local DNS or resetting the browser cannot repair a route-side connection failure; further attempts only add variables. Preserving the route name, time of occurrence, and exact error is more valuable than repeating the same steps.

Subscription List Empty or No Routes After Import

When the route list is empty, do not immediately classify it as a network dropout. First confirm that you imported the complete subscription content, not a plan page URL, login page URL, or truncated text copied from a browser. Get the subscription URL from the user panel; marketing pages do not provide static subscription URLs. If documentation or a ticket needs to show the format, use an unmistakable placeholder value like the example below and never submit real credentials.

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

Before importing again, remove clearly invalid duplicate configurations from the client so multiple entries with the same name do not overwrite one another. Then copy the current subscription from the panel and use the client’s “Import from URL” entry or equivalent. If the client reports a failed subscription request, save the original message. If there is no message but the list remains empty, import the same subscription on another platform for comparison. Failure on multiple platforms points more strongly to subscription status or the request path; failure on one platform points first to that client’s import method and system permissions.

After completing this chapter, you should be able to classify the issue as a local client problem, access-network problem, subscription retrieval problem, single-route problem, or account-status problem. If you still cannot classify it, do not change several settings at once. Restore the simplest default configuration, select an identifiable route, use an ordinary webpage as the test target, and document the complete path from starting the client to the error. Technical support needs a reproducible process, not a speculative conclusion.

WEB AND DNS

Connected but Websites Won’t Open and DNS Issues

If the client shows Connected but websites will not open, the failure usually occurs after the connection is established. The key question is whether the domain cannot resolve, all requests fail, only the browser is affected, or only one site is affected. Do not switch through many routes in succession. Keep the current route unchanged and test an ordinary webpage, the target service, and the command line separately to see whether the problem is limited to domain access, a particular app, or content from a particular region.

Open the operating system’s network settings and check for a leftover manual proxy that conflicts with the current client. Some browser extensions also configure proxies or intercept requests, causing system and browser traffic to take different paths. If other apps work but the browser does not, temporarily disable extensions related to networking, privacy filtering, or proxies and test in a new browser session. The purpose is not to disable extensions permanently, but to determine whether the conflict is at the browser layer.

Determine Whether DNS Resolution Is Failing

DNS converts domain names into addresses that the network can use. When the connection is established but resolution requests still go to an unavailable or conflicting resolver, webpages may wait indefinitely, report that the server cannot be found, or work for some domains but not others. Running nslookup example.com shows whether the system can obtain a resolution result. If the command reports a resolution failure while the client status is normal, check DNS handling, the system cache, and the network adapter before simply clearing browser cache.

Start with the client’s default DNS policy. Many problems come from configuring different resolution methods in the system, router, browser, and client at the same time, making the request path difficult to determine. During troubleshooting, reduce customization as much as possible: restore the client defaults, disable experimental browser-level resolution options, reconnect, and test again. If the default settings work, add back only necessary custom settings one at a time to identify the source of the conflict.

The system DNS cache may retain old results. On Windows, use the DNS cache flush command provided by the system; on macOS, Linux, and mobile platforms, disconnecting and reconnecting the network or restarting the network service can rebuild the resolution state. Because commands and permission requirements vary across system versions and distributions, this page does not present a single privileged command as a universal solution. Before running any administrator command, verify its source and purpose; on managed devices, follow administrator policy.

Domain Resolves but the Website Still Won’t Load

If the resolution command returns a result and curl -I https://example.com/ also receives a response while the browser still fails, focus on browser cache, extensions, certificate checks, and system proxy conflicts. Test in a new browser session, but do not immediately delete all browsing data and lose your working state. If the new session works, return to the original environment and isolate extensions and site cache one at a time. If both the command line and browser fail, continue checking the route and routing rather than stopping at browser settings.

If ordinary websites work but one site does not, check whether the target service requires an exit region, restricts accounts by region, or is experiencing an issue of its own. Switch to a route in the target content’s region and test again, making sure the app or browser is actually using the current connection. For Streaming scenarios, see the unblocking support page for regional selection; for Japan-region content, read the Japan route selection and testing guide. These checks help identify regional and app differences; they do not mean every target service will show the same content on every route.

Still No Internet After Disconnecting

If ordinary network access does not return after quitting the client, the system proxy, virtual network adapter, or routing state may not have been restored correctly. Fully quit the client instead of merely closing its window, then check whether the system proxy still points to the local client and whether the network adapter retains manual settings. Disconnect and reconnect the current network so the system can obtain the gateway and DNS again. Do not delete system network components without understanding their purpose, as this may affect other work software.

If restarting the device restores access, the issue may be related to an abnormal client exit or leftover system network state. Record whether it followed a normal exit, system sleep, force-quit, or sudden network switch. If it happens often, update the subscription and retest with the client’s default network mode. If the problem remains reproducible, include the exit method, platform, and recovery steps in the ticket. Support needs to know whether “no internet after disconnecting” is occasional or follows a fixed, repeatable sequence; the two cases require different approaches.

After fixing DNS issues, test an ordinary webpage and the actual work app again, and confirm that local network access returns normally after quitting the client. Do not use a cached page opening as the only sign of success, because cached content may not create a new network request. Open an ordinary page that has not been loaded before, or request response headers from the command line, to confirm that resolution and connection have genuinely recovered.

PERFORMANCE

Slow Speeds, Peak-Hour Lag, and Route Selection

First distinguish between consistently slow performance and slowdowns limited to certain times. Persistent slowness may come from the local network, wireless signal, device load, route distance, or target service. If it occurs only during peak hours, compare different times, routes, and access networks. Do not summarize the entire experience from one speed test, and do not equate a slow download from one website with a slow route. The target server, cross-region content delivery, and app-level throttling can all affect the final speed.

Establish a local baseline before troubleshooting. Disconnect the client and test, on the same device and in the same location, whether ordinary network access to everyday websites is stable. Check for wireless fluctuations, router load, or other devices consuming substantial bandwidth. If the underlying network is unstable, every cross-border route will inherit the problem. Fix the local network first, then compare routes; only then will the results be meaningful.

Choose Routes by Distance and Target Region

A route is not better simply because it is farther away, and a popular region is not always the right choice. For ordinary browsing, start with a geographically nearby region and a more direct route; for region-specific content, choose an exit that matches the target service. VPNBi offers 120+ countries / 240+ routes; see the Locations page for regions and route types. Fix the target app first, then compare a small number of candidate routes. Randomly switching through many nodes makes it difficult to tell whether differences come from the route or the target service’s changing state.

If a distant route loads ordinary webpages quickly but video buffers noticeably, the issue is not necessarily a failed basic connection. Streaming services typically use segmented requests, adaptive quality, and regional checks, so their requirements for sustained throughput and exit region differ from those of an initial webpage load. Check whether quality remains stable in the app and compare with other routes in the same region. If only one platform buffers while other Streaming services and ordinary downloads work, first assess the target platform or exit compatibility rather than labeling the entire network a speed failure.

How to Compare Peak-Hour Slowdowns

Peak-hour troubleshooting requires recording the time window. When lag occurs, note the access network, route name, target app, and exact symptom, such as page loading delays, reduced video quality, voice latency, or stalled file transfers. Then switch only to another route in the same region and test again. If all routes in that region are slow, try a nearby region; if every cross-border route is slow and the local network is also unstable, inspect the access network first. This gradually separates single-route congestion, regional paths, and local-exit issues.

Do not record only a low speed-test number. The test server’s location affects the result, and different targets cannot be compared directly. A more useful method is to perform a fixed action in the real service—open the same document, load the same public video, or sync the same type of file—and record whether it completes reliably. To avoid cache effects, use content that has not been preloaded or the app’s own network-status indicator. The goal is a repeatable difference, not an attractive momentary number.

Wireless environments also require checking signal quality and frequent roaming. When a device switches between access points, the underlying network path changes briefly and the client may need to establish the connection again, appearing as video buffering or voice interruption. Keep the device in a stable position during testing and disable power-saving or smart-connect features that actively switch networks for comparison. If wired access is stable but wireless access is not, focus on the local wireless network rather than the remote route.

Differences Caused by Client Mode and Routing

If the client offers Global, Rule, or System Proxy modes, each may cover a different range of traffic. Global mode helps determine whether all supported traffic can use the route, but it may not be necessary for everyday use. Rule mode depends on matching rules, so new domains or app connections may not behave as expected. With only the system proxy enabled, apps that ignore system proxy settings may connect directly. When troubleshooting speed, identify the current mode first so that “the app is not using the route” is not mistaken for an unusually fast or slow route.

Too many custom rules also make diagnosis harder. Temporarily use the client’s default configuration and retest the actual target. If the default works, restore custom rules one at a time. After each change, check that the target domain, app process, and DNS handling still behave as expected. Rule problems usually reproduce consistently: the same app and target remain abnormal in the same mode, then change immediately after switching modes. Route congestion is more likely to vary by time and node.

When a speed problem is reproducible and tied to one route, submit the route name, target service, access-network type, time window, and performance on alternative routes. If only one app is affected, also state whether its web version or another device works normally. This comparison helps support determine whether the cause is the route, exit compatibility, app rules, or local environment without starting again with “Have you restarted the device?”

STABILITY

Frequent Disconnects and Mobile Background Dropouts

First distinguish between an intentional disconnect, an underlying network switch, and the client process being suspended by the system. An intentional disconnect usually comes with a clear client error or route-status change. An underlying network switch often occurs when moving between wireless and another access method. Background suspension is common after a mobile device locks, enters power-saving mode, or reclaims memory. All three may look like “it suddenly stopped working,” but they require entirely different fixes.

Observe what triggers the disconnect. Does it happen after locking the screen, moving the device, switching access points, launching a particular app, or without any action? If it occurs after every screen lock, first check background operation and power-saving policies. If it occurs when moving between rooms or coverage areas, focus on network roaming. If only one route disconnects while others remain stable, record the route name and compare it with another route.

Why Mobile Apps Drop in the Background

Both iOS and Android manage background activity to control battery use and resource consumption. After the client moves to the background, the system may limit its execution, pause network activity, or terminate the process when memory is low. Confirm that the client is allowed to run in the background, and check whether the system has placed it on a strict power-saving, auto-sleep, or background-restriction list. Settings vary by manufacturer, so use the Battery, App Management, Background Activity, and VPN configuration pages in system settings as the source of truth.

Do not disable every power-saving feature permanently. A better approach is to allow background activity only for the client that needs a persistent connection, then lock the screen and test again. If the issue disappears, the disconnect is related to background management. If it continues, check whether the underlying network switches or sleeps when the screen is locked. Some devices reduce wireless activity while the screen is off and recover only when it turns on; unlike a route failure, this can usually be observed as delayed network recovery even without using the service.

Mobile platforms may also retain an old session after a network switch. When a device moves from wireless to another access method, the local address and route used by the original connection change, so the client must rebuild the link. If it does not recover automatically, bring it to the foreground and manually disconnect and reconnect. If every network switch prevents recovery, record the direction of the switch, whether the client was in the foreground or background, and the recovery action. This is more useful in a ticket than simply saying that mobile access is unstable.

Desktop Sleep, Wake, and Virtual Network State

Windows, macOS, and Linux may reinitialize network adapters after sleep. The client interface may still show the Connected state from before sleep even though the underlying route has changed. If webpages do not work after waking, first check whether ordinary network access has returned, then explicitly disconnect and reconnect in the client. If ordinary network access has not returned either, fix the system network before changing the subscription.

If the problem occurs after every wake-up, disable the client’s auto-connect feature for comparison: let the system finish restoring the network, then connect manually. If this is stable, auto-connect is probably occurring too early, before the system network is ready, creating an invalid session. If manual connection also fails, inspect the virtual network adapter, leftover system proxy, and security-software records. Do not reset every network component at once, as that removes evidence needed to evaluate the timing of auto-connect.

Large synchronization, backup, or development tools on desktop systems can also change network state. Some install their own network filters, virtual adapters, or proxies. If disconnects always begin after launching one of these tools, quit it and test again, then check whether its traffic handling conflicts with the client’s. Filters on managed devices are usually installed by policy and should not be removed independently; provide the conflict details to the administrator or technical support.

Distinguish a Route Disconnect from an App Session Disconnect

Voice, gaming, remote desktop, and long-lived connections may drop after a brief network fluctuation even if the client route recovers automatically afterward. The app session may not reconnect on its own. Observe both the client status and the app’s message. If the client remains Connected, ordinary webpages work, and only the service session drops, focus on the app’s reconnection behavior, network switching, and target service instead of assuming the route was interrupted.

Conversely, if the client clearly changes from Connected to Disconnected and every app loses access at the same time, record the network environment and route before and after the event. You can use another route in the same region for a longer real-use comparison, but do not switch repeatedly in a short period. If all routes disconnect on the same device under the same trigger, inspect device power and network management first. If only one route is affected, report it as a route issue.

The final judgment on stability depends on repeated comparisons, not one successful recovery. After changing a setting, use the device again in the scenario that normally triggers the issue, such as locking, waking, or switching networks. Apparent recovery in a different test scenario does not prove the original problem is fixed. Keep the same route and app during retesting so the trigger remains the only variable.

APPLICATION ROUTING

An App Bypasses the Proxy and Routing Diagnosis

If websites work on the same device but one app cannot connect, the entire connection usually has not failed. The app’s traffic may not be entering the current route, it may use different domains or protocols, it may have cached old regional data, or the target service may apply a separate account-region check. First verify that other apps and the browser work, then narrow the scope to that app. Do not reset the entire system network because of one app’s problem.

First confirm the mode currently used by the client. In Rule mode, the domain or process used by the app may not match the expected rule. With only the system proxy enabled, some apps may connect directly. If the client offers Global mode, switch to it briefly for comparison. If the app recovers in Global mode, the issue is more likely related to rules or app interception. If it still fails, continue checking the target region, app cache, and service status.

Compare the Web Version with Another Device

Many services offer both a website and an app. Open the service in a browser on the same device and check whether the web version works. If the web version works but the app fails, focus on the app cache, login state, system network permissions, and routing rules. If both fail, the issue is more likely related to the exit region, target service, or route. If the same app works on another device, compare the client modes and system settings on both devices rather than comparing only route names.

An app may cache regional data, DNS results, or a login session. Fully quit the app and reopen it; if necessary, clear its cache or sign in again through the app’s own settings. Do not delete all app data without consideration, especially in apps containing offline content or work materials. If signing in again changes the regional state, record the order of route switching and reauthentication, since some services check the region only at login or launch.

For AI Tools, the browser session, account region, and exit route may all affect access. See the AI Tools access guide; first confirm that ordinary web access is stable, then test the target tool. If someone searches for “VPN software” because a particular AI service will not open, troubleshooting should still focus on the target region, browser session, and app routing rather than treating the search term as a technical diagnosis.

Check Whether the App Bypasses the System Proxy

Some apps use their own network stack and ignore system proxy settings; others establish separate direct, real-time communication, or background connections. A working browser therefore does not prove that the app uses the route. If the client offers per-app routing, virtual networking, or global forwarding, compare them using the recommended default configuration. Save the current settings before switching, then decide whether to keep the change after testing; do not turn a temporary diagnostic mode into a permanent configuration without review.

On desktop platforms, check the client log before and after launching the app for requests related to the target domain. Logs may contain local paths, account identifiers, or destinations, so redact them as needed before submitting a ticket. Do not publish a real subscription URL, access token, or complete identity information. Support generally needs the error, target-domain type, and rule-match status—not credentials that could be used directly.

If client rules allow custom domains, do not add a large number of rules from unknown sources at once. Identify the official domains actually used by the app, then make the smallest possible adjustment. Overly broad rules can reroute unrelated traffic and create new speed or regional problems. After confirming that the rule works, also test app login, content loading, and background updates rather than stopping after the home page opens.

Special Cases for Streaming and Regional Content

Streaming apps often use separate login domains, content APIs, image resources, and media-delivery domains. An open home page does not prove that the playback path is complete, and playback failure does not mean every request bypassed the route. Record separately whether login, catalog browsing, playback start, or continuous playback fails. Then choose a route matching the content region and fully quit and relaunch the app so it creates a fresh session.

If the browser version plays content but the app version fails, check whether the app retains old cache or uses device location or store-region information. VPNBi provides network routes and does not modify an app-store account or target-service account on the user’s behalf. Separate the network exit from account status during troubleshooting instead of repeatedly switching routes while overlooking the app’s regional rules. For Japanese animation scenarios, continue with Japan route selection and common limitations.

Enterprise Apps and Managed Devices

Enterprise office apps may connect through a company gateway, device-management policy, or dedicated certificate, competing with a personal network client for routing. If the problem occurs only on a managed device or in a company app, do not remove management settings. Confirm whether the organization allows simultaneous use of another network connection, then give the administrator the app name, error message, and difference observed with the client off and on. For internal systems, do not submit internal domains, files, or logs through ordinary channels.

If an app works with the client off but fails with it on while other internet apps work, traffic may be routed incorrectly or an internal address may overlap with the client route. Describe the issue minimally: state whether the resource is internal or public, whether it affects only managed devices, and which client mode is active. Support does not need to know the contents of the internal service to determine whether the traffic scope requires a rule change.

After troubleshooting, restore a client mode suitable for everyday use and verify the other apps again. Temporary global interception may fix the target app while sending local services or work software through an unnecessary route. The final configuration should make the target app usable, keep local networking normal, and allow network access to recover after the client exits. If the app works only in a temporary mode, record the mode difference in a ticket so support can assess rule coverage.

SUBSCRIPTION AND ACCOUNT

Subscription Update Failures, Data Status, and Device Connections

A failed subscription update and a failed route connection are different problems. The former occurs while the client retrieves configuration and may appear as an update error, a route list that never changes, an empty list after import, or an old configuration being loaded. The latter occurs when an existing route tries to connect. Check whether the client can display the current route list, then choose the subscription or connection section accordingly. Confusing the two leads to repeated route switching without actually updating the configuration.

Get the subscription from the user panel only; do not use a marketing-page URL, plan-page URL, or configuration forwarded by someone else. VPNBi requires no email address; a username and password are enough to register. Keep the username safe and confirm that the browser is signed in to the correct account. If multiple accounts or browser profiles exist, sign out of the panel, sign in again, verify the plan and subscription status, and copy the current link.

Order of Checks When a Subscription Cannot Be Updated

First confirm that an ordinary webpage can open the user panel. If the panel itself is inaccessible, fix the current network or DNS issue first. If the panel opens but the client update fails, check that the copied content is complete, the import method is correct, and the system allows the client to connect. When copying manually, avoid leading or trailing spaces, line breaks, or formatting characters added by chat software. The safest approach is the client’s URL-import entry, not rewriting the address into a configuration template from an unknown source.

If the client retains multiple subscriptions with the same name, an update may apply to an old entry. Identify each entry’s source and update time, remove clearly invalid duplicates, and import again. Before deleting anything, confirm that other work configurations will not be affected. After reimporting, check whether route names or the list changed rather than relying only on a brief “Update successful” message. If the message says it succeeded but the content is unchanged, close and reopen the client to rule out interface cache.

If the same subscription fails to update on one device but works on another, the account and subscription are probably usable. Focus on the client, system time, DNS, and network permissions on the affected device. If it fails across different devices and networks, record whether the panel is accessible, the exact client error, and the time of the subscription request, then submit a ticket. Never paste the real subscription URL into a public screenshot or article; if a ticket requires it, redact the token portion.

How to Assess Monthly Plans and Data Resets

VPNBi monthly plans include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB. Data resets monthly on the activation date, and an upgrade price difference is converted into remaining days. If the client suddenly cannot connect, open the panel to check whether the plan is active, whether the current period’s data has been used up, and whether an upgrade was just completed. Do not use the first day of the calendar month as a universal reset date; the stated basis is the activation date.

For usage that does not reset monthly, data packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. They remain available until used and never expire. Check the panel for the status of monthly plans and data packages. Do not convert prices, remaining data, or periods into another format, and do not infer account status from client cache. The client shows local configuration and statistics; verify the final plan status in the panel.

If the status is out of sync after an upgrade, quit the client, refresh the panel, and retrieve the subscription again. Because the upgrade price difference is converted into remaining days, use the panel result rather than calculating the new period from the original plan. If the panel and client show a clear mismatch, save screenshots of both interfaces while covering the username, subscription token, and payment identifiers, then describe the before-and-after status in the ticket.

Unlimited Devices Does Not Mean Every Connection Always Has the Same Status

VPNBi supports unlimited devices, but each device remains affected by its local network, system background management, client configuration, and route status. One working device does not prove another is configured correctly, and simultaneous issues on several devices do not necessarily mean a device limit was reached. If you see a device-limit message, first determine whether it comes from the VPNBi panel, the client, or the target app. Websites and apps may have their own device-management rules, which are separate from this service’s device policy.

If every device fails at the same time, first check the account plan and data, then compare different networks. If only a new device fails, focus on whether the subscription was imported completely, system permissions were approved, and the client supports the platform. VPNBi supports Windows / macOS / iOS / Android / Linux. The client and subscription access points are in the user panel; static marketing pages do not provide direct installer links. To retrieve the client again, go to the user panel download page.

For payment status issues, VPNBi supports Alipay / WeChat / USDT. If payment is complete but the panel has not updated, do not repeat the same action or publish payment credentials. Open a ticket and state the payment method, time of the action, and current panel status, then provide only the necessary redacted proof requested. VPNBi provides a 14-day no-questions-asked refund; handling is subject to the on-site terms and ticket process.

SUPPORT HANDOFF

When to Contact Support and Organize Ticket Details

The goal of self-troubleshooting is not to solve every issue, but to narrow the fault to a point support can handle directly. Stop repeated reinstalls and submit a ticket when one route fails across different networks and devices, a subscription cannot update on multiple platforms, the panel and client remain out of sync, or disconnects recur under the same trigger. Changing many settings can overwrite logs and destroy the conditions needed for reproduction, making diagnosis take longer.

The ticket entry is in the user panel. Before submitting, state the platform, access network, selected route, and whether the target is an ordinary webpage, Streaming, AI Tools, or another app. Also say whether the issue is constant, limited to certain times, or triggered by screen lock, wake-up, network switching, or launching a particular app. This lets support choose the right conditions for retesting.

Required Basic Information

State the platform as Windows, macOS, iOS, Android, or Linux, and say whether the issue reproduces on one device or several. Copy the client name and exact error shown in the interface as completely as possible instead of rewriting it as “connection failed.” For route issues, include the full route name. For subscription issues, say whether the route list is empty, whether the panel is accessible, and what happened after reimporting. For website issues, state whether ordinary websites and the target site are both affected.

For the access network, provide only the network type and comparison result; do not submit a home address, organization name, or unrelated private information. For example: “The current wireless network fails; switching to another available network restores access.” That is enough to show a network difference. If a company device is managed, state that a device-management policy is present; do not export internal certificates, domains, or management files.

Time details should include the time window and whether the problem continues; do not invent false precision from memory. Route status can vary with network paths and time, so “only during peak hours” or “reproduces at any time” is more useful than a speed-test screenshot without context. If the issue has recovered, state which action restored it so support can distinguish a temporary route change from a local-state reset.

Screenshots, Logs, and Privacy

Screenshots should show the error area, route name, and client status, but redact the username, subscription URL, token, payment identifiers, private messages, and unrelated file paths before submission. A subscription URL is an access credential and should not appear in public images, community posts, or blog comments. If a ticket needs additional logs, provide the smallest necessary range requested by support instead of uploading the entire system log directory.

Client logs may contain accessed domains, network interfaces, configuration names, and local paths. Capture the relevant sections before and after the issue, remove unrelated content, and confirm that no real credentials remain. Do not edit the error text, and do not submit only a compressed image that cannot be read. Include copyable text as well so support can search for error keywords.

Handle payment issues only through a user-panel ticket. VPNBi supports Alipay / WeChat / USDT, but tickets generally do not require complete payment credentials. State the payment method, panel status, and time of the action first, then add only the necessary proof requested in the reply. Do not paste sensitive transaction information into ordinary web forms or public pages.

Copyable Ticket Template

The template below uses descriptive fields and contains no real account information. Delete items that do not apply and replace the instructions with the actual symptoms. Do not submit the sample placeholder text unchanged, and do not attach a real subscription link.

Issue type: connection / website / speed / disconnect / subscription / app routing
Platform: enter the actual platform
Affected route: enter the full route name shown in the client
Access network: enter the network type and comparison result
Scope: one app / one device / multiple devices
Original error: copy the client or system message
Reproduction conditions: state when it occurs and what action precedes it
Already tried: list in the actual order, changing one variable at a time
Comparison result: what changed after switching the route, network, or device
Attachments: screenshots or necessary log excerpts with credentials redacted

When to Prioritize the Local Environment

If the same account works on other devices but only one device is affected, troubleshoot that device’s client, system permissions, leftover proxy settings, and DNS first. If the same device works on another network, prioritize the original access network. If ordinary websites and other apps work but one app fails, first check app routing, cache, and regional status. These comparisons already point to the local or app layer, so changing the account is unlikely to help.

Conversely, if multiple devices and networks fail on the same route while other routes work, give the information to support. If the subscription cannot be retrieved on multiple platforms while the panel shows the plan as active, submit a ticket as well. The key question is not whether the problem looks serious, but whether it reproduces consistently across device and network boundaries. The clearer the cross-environment reproduction, the more likely the cause is on the route or account side.

Final Checks After the Issue Is Resolved

After access is restored, do not immediately delete all records. First confirm that ordinary websites, the actual target app, and local network access after quitting the client all work normally, then keep the final working configuration. If Global mode was enabled, an extension disabled, or a power-saving policy adjusted during troubleshooting, restore each unnecessary change and retest after every step. This avoids fixing one issue while leaving another hidden problem.

Keep a brief personal environment record with your usual platforms, effective client mode, commonly used regional routes, mobile background settings, and software known to have caused conflicts. Do not include the subscription URL or password. The next time a similar symptom appears, start from the known stable state instead of repeating every experiment. For users who need to maintain privacy settings over time, read the no-logs VPN verification checklist for terms, registration information, and public-network usage practices.