Cross-Border Network Troubleshooting Guide

A consistent troubleshooting method

Describe the symptoms before guessing the cause

The easiest way to misdiagnose a network problem is to treat what it looks like as proof of what it is. A page that keeps loading may indicate a DNS failure, a destination rejecting the current exit route, or a browser reusing an old connection. A client showing “Connected” only means that the local proxy process and selected route completed one stage of the handshake; it does not mean every app is using that route as expected. Start by recording observable facts: which apps are affected, all websites or just one, whether changing the local network changes anything, and whether other devices using the same subscription work normally. This description can quickly narrow the scope.

Think of the connection as a series of layers. The local access network lets the device reach ordinary websites; system time and certificates establish encrypted connections; the client reads the subscription and starts the local proxy; the system proxy or virtual network interface takes over traffic; routing rules decide whether requests use the local network or a remote route; DNS converts domain names into addresses; and the remote route communicates with the destination service. If any layer fails, the layer above may simply appear to be “unreachable.” Start diagnosis close to the device instead of repeatedly changing remote routes.

Establish a repeatable baseline

Before testing, pause downloads, cloud sync, system updates, and other tasks that continuously use the network. Record the client, operating system, connection mode, route name, and local network type. Then test an ordinary webpage, an affected destination service, and a method that does not rely on browser cache. Change only one condition at a time—for example, switch routes without changing the protocol or routing mode, or disable browser extensions without resetting every system setting. Repeat the same tests after each change so you can identify what caused the difference.

VPNVB supports Windows, macOS, iOS, Android, and Linux. Permission models differ by platform. Desktop systems commonly involve the interaction between the system proxy, virtual network interfaces, and the firewall; mobile systems also require attention to battery optimization, background activity permissions, and network changes. The troubleshooting principles are the same, but button labels and permission locations may differ. If you cannot find an exact label in your client, look for an equivalent function—for example, “rule mode,” “route by rules,” and “automatic routing” usually describe similar behavior.

Keep troubleshooting records

You do not need complex tools to keep useful records. Use four columns: “time—environment—change—result.” For example: home network, rule mode, Route A; webpages open but one app times out; the app recovers in global mode; switching back to rule mode causes the issue again. That result points to routing rules rather than the route itself. If changing the local network restores service immediately, check the original network’s DNS, routing, or access policy first. Records also preserve the initial settings and prevent you from forgetting what changed, so you know which adjustment actually restored the connection.

If you have not completed your first subscription import, return to the Quick Start guide. If you can connect but are unsure what “nodes, protocols, and rule mode” mean, read the Beginner’s terminology guide. Separating basic concepts from fault symptoms is usually faster than testing settings at random.

How to troubleshoot when you cannot connect at all

First separate a client problem from a route problem

“Cannot connect at all” can describe several different states: the client will not open; the client opens but the subscription is empty; a route can be selected but fails immediately; the connection stays in progress; or it shows success and then disconnects. The first usually occurs on the device, the second is often related to subscription retrieval, and the later cases require comparing routes, system time, the local network, and protocol compatibility. Treating these states as one problem leads to repeated subscription updates without addressing startup permissions or process conflicts.

Quit the client and confirm that no similar process remains in the background, then start it again. Desktop proxy clients often need to create a local listening port or virtual network interface. If another network tool is using the same resource, the new client may appear to start while being unable to take over connections. Do not run multiple tools responsible for the system proxy, virtual networking, or traffic filtering at the same time. Security software, firewalls, and enterprise device policies may also restrict network extensions. Check system notices or event logs instead of assuming the remote route is unavailable.

Check system time and the basic network

Encrypted connections rely on the device clock to determine certificate validity. If the date, time zone, or time synchronization is seriously wrong, cached pages may still appear while new secure connections fail. Restore automatic date, time, and time-zone management, then restart the client. Next, turn the proxy off completely and check whether ordinary websites open over the current local network. If the device has no connection without the proxy, repair the router, Wi-Fi, cable, access authentication, or local network service first; a remote route cannot replace that basic connection.

If the home network fails while another type of connection works, the problem is narrowed to the original local network. Restart the router, obtain a new network address, and check for manually configured DNS, a fixed gateway, or special filtering rules. If every local network fails but the same subscription works on another device, the current device’s client state, permissions, or configuration is more likely at fault. Conversely, if every device on the same network fails to connect, checking subscription status and route selection is the more sensible next step.

Verify with a minimal configuration

During troubleshooting, remove large collections of custom rules, scripts, and layered proxies from the equation. Back up the current configuration, import the current subscription from the panel, choose a standard route, and use the client’s recommended connection mode. If the minimal setup works, the service and basic network are available; the issue lies in the original rules, ports, chained proxy, or manual overrides. Restore custom items one at a time and test after each one instead of bringing everything back at once.

# Basic connectivity check example
# First turn off the proxy and confirm that the local network can resolve and reach an ordinary domain
nslookup example.com

# Then check whether the system can reach a public test domain
ping example.com

Command results must be interpreted in context. Some networks or destinations ignore ping, so no ping response alone does not prove an outage. However, failed domain resolution, an unreachable default gateway, and failed HTTPS requests to every destination usually indicate that the basic network is not established. Command-line checks are supporting evidence, not a replacement for client logs or comparisons across networks.

How to switch routes correctly

After confirming that the local network, system time, client, and subscription are working, choose another route with a different region or type. VPNVB offers 100+ countries / 210+ routes; see the route list for regions and route types. Disconnect the old session deliberately, wait for the client to clear its state, and then connect to the new route. Rapidly clicking through multiple routes can mix old sessions, DNS cache, and new route state, making the result harder to interpret.

If only one route fails while others work, continue with an available route and record the failed route name, failure stage, and time. If every route fails on one device but works elsewhere, return to device permissions and client configuration. If every device and local network fails after the subscription has been updated, submit a support ticket. Do not write only “cannot connect”; state whether the client starts, whether the subscription updates, where the connection stops, which networks and routes you tried, and whether the error text can be reproduced.

Connected but websites will not open

“Connected” only means that part of the path is complete

When a client shows “Connected,” it usually means the local client has established a session with the remote route. Whether traffic actually enters that session still depends on the system proxy, virtual network interface, app-specific proxy settings, and routing rules. First distinguish between “all requests fail” and “only domain requests fail.” Visit an ordinary site you have never opened before, then compare the browser with other apps. If the browser works but other apps fail, check app routing first. If every domain-based request fails, focus on DNS. If nothing works, check whether the client has taken over system traffic.

The system proxy mode common in desktop clients affects only apps that follow system proxy settings. Some command-line tools, games, store clients, and programs with their own network stack do not use it automatically. Virtual network mode can capture more traffic, but requires additional system permissions and may conflict with other network extensions. Identify the current mode first; do not assume that every app uses the route just because “system proxy” is enabled.

Check proxy takeover and leftover settings

After disconnecting the client, check whether the system proxy has been restored automatically. If the client exits unexpectedly, the system may retain a proxy address pointing to a local port whose process has already stopped. Every app that follows the system proxy will then fail to open webpages. Restarting the client and disconnecting normally often fixes this. You can also check whether the automatic proxy script, HTTP proxy, and secure proxy still point to a nonexistent local listener in the system network settings. Do not paste unfamiliar proxy addresses into system settings; under normal circumstances, the client manages them.

If the connection test inside the client succeeds but the browser fails, quit the browser completely and reopen it. Browsers may reuse existing connections or enable their own secure DNS, network extensions, or proxy plugins. Temporarily disable extensions that change the network path, and compare with the browser’s DNS set to follow the system. If a private window works while a normal window fails, check extensions, cache, and site data. If every browser fails, return to the system proxy and DNS layers instead of clearing each browser individually.

Determine whether DNS is the problem

Typical DNS symptoms include a client that appears normal while newly opened domains remain unresponsive; a domain behaving differently across apps; brief recovery after changing networks; or an error explicitly mentioning name resolution. DNS converts domain names into network addresses, and requests may be handled by the system, local router, client, or remote route. When several layers are configured at once, results can diverge. During troubleshooting, remove overrides and use one clear path through the client and system.

# Windows
nslookup example.com
ipconfig /flushdns

# macOS
dscacheutil -flushcache

# Linux (systems using systemd-resolved)
resolvectl query example.com
resolvectl flush-caches

Run a query before deciding whether to clear the cache. A timeout means the resolution path did not respond in time; an address returned with webpages still inaccessible points instead to routing, certificates, the destination service, or the browser. Clearing the cache removes old results but does not repair an incorrect upstream DNS configuration, so do not treat repeated cache clearing as a universal fix. If DNS was set manually, record the original value and restore automatic assignment for comparison. If the client offers “resolve through route” or an equivalent option, test it after confirming that system permissions are working.

Check IPv4, IPv6, and routing results

A domain may return addresses from more than one address family, while the current route and local network handle those paths differently. Some sites may open immediately while others wait and then fail. Do not permanently disable an address family as a first step. Check whether the client can take over both paths consistently, whether DNS results match the connection mode, and whether rules send different domains for the same service through different exits. If a temporary change helps, record the resolution results before and after it before choosing a long-term configuration.

In rule mode, a webpage often loads scripts, images, APIs, and login resources from multiple domains. Sending the main page domain through a remote route does not mean every related domain follows the same path. If a page shows only text, buttons do nothing, or login loops, inspect the client’s connection log and see which rule matched the failed resource. Temporarily switch to global mode for comparison: if global mode works while rule mode fails, the evidence points to rule coverage rather than route speed. Return to rule mode after testing and update or extend the rules.

If the issue is limited to streaming quality or resources from a specific site, see the bitrate and bandwidth testing guide. If every domain fails to resolve with the same result across different networks and devices, submit the query output, client logs, and affected domains. If only an enterprise or campus network is affected, also state whether it requires login authentication or a dedicated DNS service.

Slow speeds and peak-hour slowdowns

Break “slow” into observable metrics first

Slow performance is not one single fault. A delayed first screen often relates to latency, DNS, or connection reuse; a low sustained download rate points more toward bandwidth or congestion; repeatedly changing video quality can also reflect bitrate negotiation and short-term fluctuations; delayed or jumpy game controls require attention to latency, jitter, and packet loss. Different symptoms need different tests. One speed test cannot explain why webpages are slow while downloads are fine, nor prove that a route remains stable over time.

When establishing a baseline, turn off the proxy and test ordinary access on the same device and local network. Then connect to a geographically sensible route and repeat the same task. Do not run a wireless repeater, remote desktop, cloud sync, or system update at the same time. Keep the test target fixed: the same download source, video segment, and webpage. If the local network is already fluctuating, basic noise will mask every comparison with a remote route.

Route distance, type, and congestion

Physical distance adds to the round-trip path, but it is not the only factor. Detours, inter-network links, wireless interference, and congestion at the local network exit can make a clearer route perform better than a closer one. Narrow your choices by use case and region, then compare route types instead of judging by country name alone. VPNVB covers 100+ countries / 210+ routes; see the route list for all regions and types.

Peak-hour slowdowns often come from congestion on one segment of a shared link. Focus on timing: stable during the day, noticeably slower at a consistent busy period, and significantly different after switching to another local network or route. If only home Wi-Fi is affected, check signal strength, band interference, and router load first. If performance drops just as much with the proxy off, the bottleneck is local. If ordinary access is fine but one route slows down, compare other routes in the same region.

Rule out device and app-side limits

A device’s battery-saving mode may restrict background networking and processing performance. Many browser tabs, encrypted scanning, real-time sync, and disk usage can also affect downloading and extraction. If the proxy runs on a router, consider whether the router has enough processing capacity for the current encrypted traffic. A simple check is to connect another device to the same route on the same network: if the other device works normally, inspect the original device; if every device behaves the same, check the router, local network, and route.

An app server may also limit single connections, account regions, or specific content sources. If only one download site is slow, do not attribute it to the entire route. Cross-check with different sources and compare browser, desktop app, and command-line requests. For AI Tools, long-connection stability can matter more than peak throughput; see AI image generation and long-connection requirements. For games, read the difference between latency, jitter, and packet loss instead of treating bandwidth as the only metric.

Order of checks for peak-hour slowdowns

First confirm that the local network works with the proxy off. Then switch between routes in the same region, test nearby-region routes, and only afterward consider changing the connection mode. Keep the test conditions identical after each switch and allow enough time for the connection to re-establish. Repeated speed tests consume capacity and may trigger limits at the test server. For video, sustained playback is more meaningful than chasing a single peak result.

If the speed issue appears only when usage approaches the plan allowance, sign in to the panel and check the current cycle usage. Monthly subscription traffic resets each month on the activation date; an upgrade mid-cycle is prorated by the remaining days. Data packages remain available until used and never expire. To compare options, see the plan details. Repeatedly updating the subscription will not fix an allowance issue because updates only sync configuration and account status; they do not change traffic already used.

Frequent disconnects and mobile background drops

First determine whether the session ended or the network changed

A disconnect may appear as a client status change, an app connection reset, a brief webpage interruption followed by recovery, or a route reconnecting after the device switches from Wi-Fi to another connection. First note whether the local network icon changes at the same time. If ordinary access also drops, check Wi-Fi signal, the router, cable, or access authentication. If the local network remains stable and only the client session reconnects, check the route, system sleep, background permissions, and network-extension conflicts.

Do not treat one app’s expired login as proof that the entire route disconnected. Some services require a new login after an exit change, session expiry, or the app’s own reconnection policy. Observe a persistent request and the client status together. If other websites and apps remain normal, the issue is limited to that service. If every proxied connection stops while ordinary access remains available, the client session or route is more likely responsible.

Desktop sleep and network changes

After closing a laptop lid, sleeping, switching Wi-Fi, plugging or unplugging a cable, or starting or stopping a hotspot, the local address and default route used by existing connections may have changed. Some clients reconnect automatically; others require a manual disconnect first. If the device shows “Connected” but cannot access anything after every wake, disconnect deliberately, wait for the system to finish reconnecting, and then connect again. Do not keep clicking Connect while the system has not obtained a working network.

Frequent disconnects can also occur when multiple network tools compete for the system proxy or virtual interface. Check for enterprise network clients, traffic filters, packet-capture tools, parental controls, or other proxy programs running at the same time. During troubleshooting, keep only one client responsible for taking over traffic. If disabling one tool restores service, determine whether the two can coexist rather than permanently turning off every protection feature.

Mobile background permissions

Mobile operating systems restrict apps that remain out of the foreground to save power. A network acceleration client depends on a continuously running system network extension, so battery-saving mode, background activity limits, automatic cleanup, and manufacturer battery policies may terminate or freeze related processes. Check that the client has the system permissions needed to establish the connection and allow necessary background activity. Remove it from the system’s restricted list, lock the screen for a while, and then wake the device to test; do not test only while the app remains in the foreground.

Also distinguish between the app interface being cleaned up and the system network extension stopping. Sometimes the client interface reloads while the network connection remains in the status bar; sometimes the interface shows an old state even though the session has ended. Trust actual access and system network indicators. If the system offers always-on or on-demand connection features, confirm that the configuration is stable before enabling them, because an incorrect setup can repeatedly trigger reconnections and affect ordinary networking.

Compare routes and transport methods

If disconnects are unrelated to screen lock, sleep, or network changes and occur only on one route, compare another route in the same region. If every route is unstable on one local network but works after switching networks, the original network may be affecting long connections, a specific transport method, or idle sessions. Keep records from both networks instead of reporting only that it “disconnects occasionally.”

Do not set the reconnection frequency too aggressively. During a brief network fluctuation, immediately creating multiple sessions may slow recovery. Prefer the client’s default strategy unless you understand the roles of keepalive, timeouts, and on-demand connections. Temporarily remove timeout overrides, chained proxies, and complex scripts from manual configurations during minimal-configuration testing.

If a mobile app disconnects only after it moves to the background while other apps remain normal, check that app’s background networking permission. If every app using the route stops at once, inspect the acceleration client and system network extension. If the device is hot, low on storage, or continuously cleaning up background processes, restore basic device operation first. If the issue remains reproducible, provide the device OS, client, route, foreground/background actions, and reproduction path so support can follow the same steps.

Subscription update failures and configuration problems

The subscription link, subscription content, and route connection are three separate things

The subscription link is the client’s entry point for retrieving configuration. Subscription content is the route and rule information saved after download. A route connection is the session established by selecting one item from that configuration. An update failure does not mean every saved route has immediately stopped working, and a failed route does not mean the subscription link itself is wrong. First determine whether the client reports an error while downloading the subscription or whether the update succeeds but routes cannot be used.

If subscription mechanics are new to you, start with the guide to obtaining, importing, and updating a subscription link. VPNVB registration requires no email address; a username and password are enough. After signing in to the panel, retrieve the current subscription. Do not use an old address from chat history, OCR from a screenshot, or manual edits. The subscription link is an account configuration entry point and should be stored carefully. If you suspect it has been exposed, update it through the panel where available instead of continuing to share the old link.

Verify the retrieval path first

When updating a subscription, the client must reach the subscription address. If the system proxy points to a dead local port, or the client requires an unconnected route before it can retrieve the subscription, a loop can occur: a new configuration is needed to connect, but connecting is required to download the new configuration. Turn off the invalid proxy or use the client’s direct-update option. If the client supports choosing an update path, try it after confirming that the local network can reach the panel.

If signing in to the panel fails, first verify the username and password, then check whether the browser can open other pages normally. Do not paste the subscription address into public testing websites. If the panel works but the client cannot download the subscription, delete that subscription entry in the client and import the current address again. Before doing so, record custom rules and local overrides because deleting a subscription may also remove associated manual settings.

Identify format and parsing errors

Clients support different subscription formats and field sets. One client being able to read a subscription does not mean a completely different client can interpret the same content. Common parsing errors include treating webpage content as configuration, characters missing during copying, an unsupported response format, incorrect text encoding, or conflicting fields in the local configuration. Prefer the retrieval method provided by the panel for the relevant platform. Client download links point to the user panel rather than static installer URLs.

# A safe example from the documentation, for identifying link structure only
https://example.com/sub?token=YOUR_TOKEN

# Do not put a real subscription address in screenshots, public logs, or shared configurations
# When an update fails, record the error type without submitting the full token

If the error response is a webpage title, login page, or ordinary HTML, the client did not receive the expected subscription content. The link may be expired, incomplete, or redirected. If the content downloads but the configuration is empty, check the parsing message in the client log. Do not use an online converter on a real subscription just to remove the error; a third-party conversion process can access the complete link. Return to the panel to retrieve it again or use a support ticket to confirm the correct import method for the client.

Routes disappear or are duplicated after an update

A route may disappear because the subscription was overwritten, a filter hides it, a group is collapsed, or the client kept the old subscription while creating another entry. Check whether the subscription list contains multiple sources with similar names, then confirm which configuration is active. Duplicate routes usually result from importing the same subscription more than once, not from the service actually providing duplicates. Keep one valid subscription entry, update it, and select the group again.

If custom rules refer to an old route name, a name or group change after an update may leave the rule without a target. The client may fall back to a default route or report an error. Check that the rule target still exists, and prefer stable groups over binding many rules to one route. Export local custom content before updating, then restore items one at a time afterward to keep the configuration manageable.

Account status and traffic cycles

Subscription updates are also affected by account status. Sign in to the panel to confirm that the plan is active and review usage. 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 upgrade differences are prorated by the remaining days. Data packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain available until used and never expire. Visit the pricing page to compare plans. Do not infer account pricing or billing cycles from a client error.

If the panel shows a normal status but the current subscription still cannot be parsed after re-importing, submit the client name, platform, update method, exact error text, and time. If logs contain the full subscription address, hide the token first. Support needs the error type and response behavior, not account credentials. If only one of several clients fails, explain the difference between the failing and working clients; this often quickly distinguishes format compatibility from an account-side issue.

One app ignores the proxy and routing behaves unexpectedly

Why the browser works while an app still fails

Apps do not all use the network in the same way. Browsers usually follow the system proxy, but may enable their own secure DNS. Command-line programs may read environment variables. Games and some desktop apps use network interfaces that bypass the system proxy. Mobile apps are generally handled by the system network extension but may still be affected by per-app rules. “The browser works” proves only that the browser path is valid; it does not prove that every process uses the same exit route.

First determine whether the client is using system proxy mode or virtual network mode. In system proxy mode, check whether the affected app supports the system proxy or needs an in-app setting. In virtual network mode, check system permissions, conflicts with other network extensions, and whether the client excludes that app. Do not enter the client’s local port in an app unless its documentation explicitly specifies the matching protocol and address.

Use global mode for a brief comparison

When rule mode fails, switch briefly to global mode for comparison. If the app immediately recovers in global mode but continues to fail in rule mode, the route and the app’s basic connection are probably working; the issue is likely a rule match, domain set, or address range. Restore rule mode after testing and inspect the connection log. Do not use global mode long-term to hide incorrect rules, because it also changes the path for requests that should remain local.

If the app still fails in global mode, switch to another route and restart the app. An app may keep an old connection even after the client changes routes, continuing along the previous path or remaining in a failed state. Quit the app completely, confirm that its background process has ended, and reopen it. On mobile, remove the app from the task switcher before testing again. If only account login fails while other functions work, check the service region, account security checks, and cached session instead of changing the entire routing table.

Locate the rule from connection records

Modern apps usually contact more than one domain. Login, images, APIs, push notifications, WebSocket connections, and content delivery may come from different hosts. If rules cover only the main domain, the homepage may open while login buttons do nothing, messages fail to refresh, or images are missing. Open the client connection log and reproduce the issue while watching new requests. Check the domain or address, matched rule, selected group, and final route. Focus on failed requests rather than adding every listed domain to one rule.

When editing rules, work from narrow to broad: add an exact domain first, then consider the subdomain range for the same service. Prefer rule sets already provided by the client, and avoid broad wildcards that alter unrelated websites. Clear the app’s old session and retest after each change. If the rules come from a subscription, update the subscription first. For local overrides, record their order because priority can differ between clients.

Check command-line settings and environment variables

Developer tools often retain proxy environment variables from earlier sessions. After the client changes ports or exits, the command line may keep trying the old address, leaving the browser working while a package manager fails. You can inspect the current environment in the terminal, but do not publicly share complete output containing credentials. The examples below show structure only; use the port displayed by the client rather than copying a fixed value.

# Check whether proxy variables are set in the current terminal
env | grep -i proxy

# Temporarily clear common proxy variables from the current terminal session
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
unset http_proxy https_proxy all_proxy

Run the affected command again after clearing them to determine whether an old environment variable caused the issue. If the command line really needs a proxy, use the local address and matching protocol supplied by the client, and place the configuration where you understand its scope. Do not set conflicting HTTP and SOCKS paths at the same time. Enterprise development environments may also store proxies in the tool’s own configuration file, so check those separately instead of looking only at system settings.

AI Tools, Streaming, and long-lived connections

AI Tools and real-time collaboration apps often use WebSocket or persistent requests. A page may open while generation stalls because a related domain is not covered by the same rule or a long-lived connection was not rebuilt after a network change. Restart the app, compare global and rule modes, and inspect failed connections. For specific Midjourney and Discord requirements, see the tested comparison of connection requirements.

Streaming also depends on exit region, account region, cache, and content licensing. An accessible homepage does not guarantee that content will play, and changing quality cannot be attributed to routing alone. Review the streaming access guide and related route support information, then choose a route for the target use case. If an app fails in the same way across multiple devices, networks, and suitable routes, submit its name, failed steps, matched rule from the connection log, and error message instead of writing only “an app does not work.”

Device usage, account status, and support tickets

Check the exact message before assuming a device limit

VPNVB supports unlimited device usage. If a client or app displays “device limit exceeded,” do not assume that it is a plan restriction from this service. First identify the source: the operating system account, app store, destination-service account, enterprise device management, or the acceleration client itself. “Device” means different things in each context. When capturing the message, include the window title or app name, but hide usernames, subscription addresses, and other sensitive information.

When importing the configuration on multiple devices under one account, retrieve the subscription from the current panel and avoid forwarding the configuration publicly. Unlimited device usage does not mean the account configuration should be shared with unrelated people. Many old configurations from unknown sources make troubleshooting harder because devices may use different update times, local rules, and route groups. Keep a clear client name and update record for each device, and confirm that it still uses the current subscription when a problem occurs.

Account, plan, and payment status

When a connection issue is related to account status, the client can usually show only a simplified error. Sign in to the panel to verify that the plan is active, traffic is available, and the order is complete. VPNVB supports Alipay / WeChat Pay / USDT. Payment processing, a cancelled order, and an activated plan are different states; do not judge solely from the payment page result. If the order page and actual payment result differ, save the order identifier and payment-channel record and check through a panel ticket instead of creating duplicate orders.

Monthly plans include ¥9.9/month with 60GB, ¥18/month with 250GB, and ¥28/month with 500GB; traffic resets monthly on the activation date, and mid-cycle upgrade differences are prorated by the remaining days. Data packages include ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain available until used and never expire. All plans include a 30-day hassle-free refund policy. See the pricing page and refund policy for the applicable choices and terms. During troubleshooting, verify the current account status instead of deleting the client or reinstalling the operating system to address an order issue.

Complete a minimal reproduction before submitting a ticket

Support can address reproducible service, account, route, and configuration issues. Before submitting, reduce the problem to one device, one client, one local network, one route, and one clear target. State whether access works with the proxy off, whether another route changes the result, and whether the subscription updates successfully. If only one app is affected, compare global and rule modes. If the issue occurs only in the mobile background, describe the exact screen-lock, network-switch, or foreground-return action.

Do not submit passwords, complete subscription addresses, or payment credentials in a ticket. When logs are needed, inspect and hide tokens, usernames, and personal information in local file paths first. Copy error text as written rather than summarizing it. Screenshots should include context without exposing unrelated account information. If a log is long, identify roughly where the issue occurred and what action preceded it; support does not need the entire unrelated startup history.

When to contact support directly

Submit a ticket when the account page and order status clearly disagree, the current subscription cannot be retrieved from the panel, multiple devices and networks show the same route error, the issue is reliably reproducible but client logs point to a server response, or the issue remains unclear after following this page. Open user-panel tickets and organize the details using the checklist above. The more specific the report, the more likely the first reply will be actionable.

If you only need to confirm a concept or common setting, start with the Help Center. If initial configuration is incomplete, return to the Guides. To choose a suitable region and route type, see the route list. Handling account, client, route, and target-app issues separately avoids repeating the same explanation across support channels.

What to do after service is restored

After resolving the issue, restore temporary global mode, manual DNS, disabled security settings, and test rules to sensible values. Remove duplicate subscriptions and keep the current valid configuration. Record the change that actually helped and undo unrelated adjustments. If switching routes solved the issue, keep the original route name and time period for faster comparison if it happens again. Do not leave every temporary setting in place permanently just because one problem has cleared.

Update subscriptions regularly from the panel and give each device a clear, traceable configuration source. When a new problem appears, follow the same order: ordinary network, client startup, proxy takeover, DNS, routing rules, route, account. The value of this sequence is not that it covers every special case, but that each step produces clear evidence and narrows the next step.