Cross-Border Connection Troubleshooting Guide

Identify the Symptom and Create Comparisons

Separate Basic Network Access from the Accelerated Connection

After disconnecting the client, open a website that normally works without a special connection. If ordinary pages also fail to load, the immediate issue is your local network, not the route. Check the router, Wi-Fi status, wired connection, airplane mode, and whether the current network requires browser-based authentication. Public networks often show a login or usage-confirmation page in the browser. Until that page is completed, the client may appear to be connecting without establishing a stable data channel. Further route checks only make sense once the basic network can open web pages normally.

Once the basic network is working, start the client and watch how its status changes. Do not rely only on the connection icon in the system tray; check whether the client interface says connected, identifies the current route, and shows any error. A system icon only indicates that a network interface was created—it does not necessarily mean the target route is usable. If the client remains on “connecting” for a long time, classify it as “cannot connect at all.” If it quickly says connected but no pages open, use “connected but no web access.” If only specific sites or apps fail, move to app routing and DNS.

Use a Minimal Test Set to Define the Scope

A useful comparison should cover a browser, another independent app, and different routes. If the browser works but one app does not, the overall network path is usually available and the issue is more likely the app’s proxy support, routing rules, or cache. If no apps can connect, look more closely at the system proxy, DNS, or route. If one route fails while others work, your local configuration is broadly valid. Continue using a working route and record the faulty one for follow-up instead of repeatedly reinstalling the client.

Compare different access networks as well. If the same device fails on a home network but recovers after switching to another available network, the scope narrows to the original network, router, or its DNS environment. If the behavior is identical on every network, check the client, subscription, and system settings. A comparison network helps define the boundary; it is not necessarily a permanent fix. After recovery, retest in the original environment to confirm that the problem is consistently gone.

Keep a baseline and protect working settings

If one route or one app still works, treat it as your baseline. Note the route name, client mode, and system proxy status before testing other options. Do not delete every subscription, clear all rules, or reset the entire system network configuration without a backup. A broad reset removes the comparison conditions that could help locate the fault and may turn a localized issue into a complete outage.

Also note whether the problem is continuous or appears only briefly after switching. Browsers reuse existing connections, and systems may retain old DNS results. Immediately refreshing an existing tab after changing routes may still show the result from the old path. A more reliable test is to close and reopen the target app or use a new browser private window. If the new window works while the old one does not, the network service has usually recovered; the remaining issue is likely cache, an old session, or the site’s login state.

By the end of this chapter, you should be able to place the issue in one main branch. If you still cannot classify it, start with the broadest symptom: first handle being unable to connect at all, then no web access after connection, and finally a specific app. This avoids changing app or browser settings before the basic channel is established.

The Client Cannot Establish a Connection

Confirm Client Status and System Permissions

When the client cannot connect, read the status on screen instead of clicking Connect repeatedly. Staying on connecting, disconnecting immediately, requesting permission, and reporting an invalid configuration point to different causes. After a system update or client reinstallation, you may need to reconfirm permission for the network extension, virtual network interface, or firewall. Return to the client’s main interface, complete the authorization requested by the system, and try again. If an authorization window is hidden behind another window, the client may wait indefinitely and look like it has timed out.

On desktop systems, check whether the client is still running in the background. Multiple instances can conflict over ports or system proxy state; fully exit the old process before reopening it. On mobile, confirm that the client still has permission to create a network connection. If old connection profiles remain in system settings while you are using a newly installed version, disconnect normally inside the client first, then let the current client create its configuration again. Do not delete unfamiliar system network entries, as this may affect other working software.

Use Route Switching to Identify a Single-Route Failure

This service covers 90+ countries and 200+ routes. When you cannot connect at all, compare different regions or route types instead of retrying the same route repeatedly. If another route connects, the account, subscription, and basic client path are working; the problem is concentrated on the original route or the path from your current access network to it. Use a working route temporarily and include the faulty route name in your support ticket. See the Routes page for the full range and route types.

If no route can connect, check local security software, system time, access-network restrictions, and subscription status. Security software may block the client from creating a network interface or ask for network permission again after an update. Do not permanently disable protection while troubleshooting. First review its blocked-activity log, allow the current client to access the network, and test again. If connection works only when protection is fully disabled, keep the block record and ask that software’s support channel about compatible settings.

Compare Access Networks and Complete Web Authentication

When using hotel, campus, office, or public Wi-Fi, disconnect the client first and open an ordinary web page in a browser to see whether a network usage or sign-in page appears. These networks often require accepting terms or completing local authentication. Encrypted connections may not work until that step is complete. After authenticating, close the sign-in page, confirm that ordinary pages load, and start the client. If the page does not appear, you can temporarily disable the browser’s forced secure-connection option and visit a regular site to trigger it, then restore the original setting afterward.

If every route recovers immediately after the same device switches to another available access network, the client and subscription are probably working. Check whether the original router has special filtering, parental controls, enterprise policies, or custom DNS enabled. If the network is centrally managed, do not change its device configuration yourself; give the administrator the comparison result that another access network works. If no network can connect, continue with subscription and client logs.

Check That the Subscription Loaded Correctly

A client showing route names does not mean the subscription is current. Open subscription management, confirm that the selected subscription came from the user panel, and update it. If the update fails, do not delete the original subscription first; its contents may still be useful for comparison. Copy the error text and check the system date, basic network, and whether a browser can sign in to the user panel. The complete subscription retrieval and import flow is in the Guides; later sections cover update failures in more detail.

If the subscription updates successfully but the route list is empty afterward, confirm that the client recognizes the subscription format and that you have not selected an empty local profile by mistake. Return to the download and subscription area through the user panel and follow the entry point for your platform. Do not copy an address from a chat or old device if it may have been truncated, and do not edit characters in the subscription manually. When showing an address in documentation or screenshots, use an obvious placeholder such as:

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

If the client error mentions a certificate, system time, or network interface, preserve the original wording. Do not capture only the dialog title, which is usually too general. If connection still fails after confirming permissions, comparing routes and networks, and updating the subscription, you have the core information needed for a useful support ticket. There is no need to perform a broad system reset.

Connected, but Web Pages Will Not Open

First Determine Whether All Targets or Only One Site Is Affected

After the client reports connected, test a commonly used site, a second site, and an independent app separately. If only one site fails, do not immediately conclude that the route is unavailable. The site may require a new login, restrict the current region, be under maintenance, or retain an old session. Open the same address in a private browser window to rule out extensions, cache, and login state. If several sites and apps all fail, focus on the system proxy, DNS, and exit route.

Also check whether ordinary direct-access sites are affected. Some client modes take over only traffic matching their rules; if the target domain is not covered, the browser uses the original network. Other modes handle all traffic, so a route or DNS issue affects every page. Do not switch modes back and forth without understanding them. Record the current mode first, test the client’s recommended default mode, and adjust individual settings only after recovery.

Rebuild the Browser and System Connection State

Browsers reuse established connections. After switching routes, an existing tab may continue using an old session, appearing to load endlessly, show a blank page, or reset the connection. Fully close and reopen the browser instead of only refreshing the page. If a separate proxy extension is configured, it may override the system proxy. Temporarily disable the extension and test with the system’s default network settings. Once access returns, decide whether the client or browser extension should handle proxying; avoid having two rule sets take over at once.

Desktop systems may also retain a proxy address left behind by an abnormal exit. Disconnect and exit normally inside the client, then check whether the system proxy has been restored. If ordinary pages still fail after the client exits, open system network settings and look for a local proxy address that is no longer active. Remove only entries you can confirm belong to the current client. Do not change settings managed by an organization or used by other software. Restart the client and let it write the required state again.

Separate Domain Resolution from Data Transfer

Web access usually starts by resolving a domain to an address and then establishing a data connection. If resolution fails, the browser may say that the server cannot be found or the domain could not be resolved. If an address is returned but data transfer fails, timeouts, connection resets, or secure-connection errors are more common. Use a built-in system tool to query a public test domain and see whether a result is returned. The following command is only for checking the resolution path and contains no service credentials:

nslookup example.com

If the query returns no valid result and direct access to a known working site also fails, continue with the DNS section. If the query works but the browser still cannot open pages, focus on browser extensions, the system proxy, the exit route, and the target site’s status. A command-line result cannot prove that every network function is working; it only helps distinguish a failure before resolution from one after it.

Check Client Mode and Local Loopback

Some clients receive app traffic through a local listening address and then forward it to the route. If security software blocks local communication, the client may still show connected while the browser cannot hand requests to it. Check the security log for blocks involving the current client or local network communication. Limit the allow rule to the trusted client program instead of opening access for unrelated apps. Restart the browser afterward so it reads the system proxy state again.

If the browser works but the system store, command-line tools, or other apps fail, the system proxy is not being used by every app. Some apps read proxy settings only when they start; fully close and reopen them after the connection is established. Others use their own network settings and require you to enable the system proxy or disable a custom proxy inside the app. If an app does not support the system proxy, use a client mode that can handle its traffic, but record the original mode first so working programs are not disrupted.

If a new browser window, different routes, and different apps all fail while the basic network works after disconnecting the client, record the client mode, faulty route, and the browser’s complete error text. If only a specific service is affected, see the Streaming access guide or check that service’s regional requirements. If multiple targets fail at once, state clearly in the ticket: “The client shows connected, but none of the test targets respond.” This distinguishes the issue from a handshake failure.

Speed Drops and Peak-Hour Buffering

Establish a Network Baseline Without the Client

Start by confirming the local network baseline. Disconnect the client and check whether ordinary pages, file transfers, or video are already slow. If the local network is congested, no international route can remove the bottleneck at the entry point. Weak Wi-Fi, a heavily loaded router, background synchronization, and shared access can all cause fluctuations. Move closer to the access point, pause large sync and update tasks, and retest on the same device and access method.

Do not compare results from different times, devices, and targets directly. A work device tested over Ethernet and a mobile device tested on weak Wi-Fi are not a valid comparison; the difference may not come from the route. Keep the device, access network, and target the same, changing only the route. If switching routes clearly restores performance, keep the working route. If every route is slow, continue checking the entry network and target service.

Choose Routes by Use Case, Not Distance Alone

A shorter geographic distance often helps interactive response, but it is not necessarily best at every time of day. Routes may use different entry points and transit paths, and actual performance changes with the access provider environment and target site location. Web browsing, remote work, and messaging prioritize stable response; large downloads and high-bitrate video depend more on sustained throughput. Choose a route based on your main use case, and review regions and route types on the Routes page instead of judging quality by the region name alone.

When accessing region-sensitive streaming services or AI Tools, also consider whether the exit region meets the target service’s requirements. Choosing a mismatched region for lower latency can produce pages that open but content that remains unavailable, which may then be mistaken for a speed problem. Identify the required region first, then compare routes within it. If no fixed region is required, start with a relatively nearby, stable route and try another path if performance fluctuates.

Identify Peak-Hour and Persistent Problems

Peak-hour buffering requires comparisons across different times. If access is stable during the day but repeatedly buffers at night, and ordinary access also slows on the same network, entry-network congestion is more likely. If ordinary access remains normal but one route drops noticeably at night and recovers after switching, avoid that route temporarily and record the time. If every route is slow for the same target, check whether the target site itself is busy instead of attributing everything to the acceleration service.

Focus on sustained behavior rather than a momentary peak. Speed-test tools may choose different servers, so results are easily influenced by the test endpoint. A more useful comparison uses the real scenario: whether the same video keeps buffering, the same page resources repeatedly time out, or the same file transfer remains stalled. Do not draw a long-term conclusion from one unusually fast or slow result. A ticket describing “persistent slowness” should include the exact scenario and time range.

Rule Out Device Resources and Background Tasks

The client handles traffic forwarding and encryption. Performance may drop when the device is in power-saving mode, under storage pressure, or running many tasks. Close unrelated apps, pause cloud sync, system updates, and large downloads, then observe the real use case. A browser with many media tabs also consumes network and memory resources, making page switching sluggish in a way that can resemble reduced route throughput.

For household sharing, this service supports unlimited devices connected at once, but “unlimited devices” does not mean the local broadband or Wi-Fi network has unlimited capacity. Multiple devices downloading, backing up, or playing high-bitrate content share the same entry connection. Temporarily pause high-traffic tasks on other devices and compare the main device again. If it recovers, the bottleneck is in the shared local path; schedule tasks, improve router placement, or use a more stable access method instead of repeatedly changing the subscription.

If several access networks, targets, and routes remain slow, confirm that the client is the version provided through the current user panel and submit the diagnostic details in a ticket. If the issue is simply insufficient traffic in the current plan, review the Plans and Pricing page for monthly subscription and traffic-pack rules. Monthly subscription traffic resets each month on the activation date, and mid-cycle upgrades are prorated by the remaining days. Traffic packs remain available until used and never expire. Do not reinstall the client repeatedly to address a traffic-balance issue.

Frequent Disconnects and Mobile Background Dropouts

Check Whether Disconnects Coincide with Network Changes

When disconnects happen frequently, first check whether the device is switching between Wi-Fi and another access method. Leaving Wi-Fi coverage, roaming between access points, or a router reallocating network state can interrupt an existing connection. The client may then reconnect, but an old session in the target app may not recover automatically. Wait until the network is stable after the switch, then reopen the target app.

If disconnects occur only in one location, check the Wi-Fi signal and access-point roaming before changing routes. If the device is stationary and the local network remains normal but the client repeatedly changes from connected to reconnecting, compare another route. If the problem follows one route, use another temporarily and record the original. If it follows the access network, check the router and network environment.

Handle Stale Sessions After Sleep and Wake

When a device enters sleep, the system may pause the network interface. After waking, the connection icon can remain visible even though the original session has expired. Open the client to confirm its actual state, disconnect and reconnect if necessary, then fully reopen the target app. Refreshing the old page alone may continue using the pre-sleep connection. If the same issue occurs after every wake-up, check whether the system allows the client to restore networking and whether power-saving policies suspend network activity too aggressively.

Closing a laptop lid, switching users, or locking a desktop for a long time can trigger similar behavior. Record whether the disconnect always follows one of these actions. If the connection is stable during use and fails only after waking, it is usually not a long-term route-stability issue. “Worked before sleep; required reconnection after wake” is a useful ticket condition and is easier to reproduce than a vague report of frequent disconnects.

Mobile Background-Restriction Checklist

Mobile systems may pause background apps as part of power-saving policies. If the connection disappears after switching to another app for a while and returns immediately when you reopen the client, check battery optimization, background activity permissions, and low-power mode. Allow the client the background network activity it needs and keep it out of automatic cleanup lists. Settings names vary by system, so use the device’s app battery and background-management pages. Do not install third-party so-called keep-alive tools.

Also distinguish a paused client from a paused target app. If the connection icon remains but the target app cannot refresh when brought back to the foreground, the app’s background session may have expired. Restart the target app separately; if it recovers without reconnecting the client, the route is still working. Continue checking client background permissions only if the connection icon disappears and the client says disconnected.

Avoid Conflicts Between Automatic and Manual Switching

Some systems or clients reconnect automatically after a network change. Repeatedly clicking Connect at the same time can interrupt that process and create a connect-disconnect-reconnect loop. When the client is reconnecting, wait for its current action to finish before intervening. If it cannot recover after a reasonable wait, disconnect normally and choose another route instead of clicking rapidly again and again.

Router optimization, automatic dual-band switching, and access-point roaming can also change the underlying connection. If one device disconnects frequently while others on the same network remain stable, temporarily pin it to a stable wireless access method for comparison. This tests whether roaming is involved; it does not mean optimization must remain disabled. Once the cause is clear, choose a suitable configuration that balances router capabilities with mobility needs.

If the disconnect can be reproduced across multiple access networks and routes, and is unrelated to sleep, background restrictions, or network switching, check that the client came from the user panel and submit the complete logs. Windows, macOS, iOS, Android, and Linux handle background activity differently, so the ticket must specify the platform. Do not list only the device brand; system policies can differ on the same brand.

Subscription Updates, Specific Apps, and Device Checks

Keep the Existing Configuration When an Update Fails

When a subscription update fails, do not delete the existing subscription immediately. If the old configuration still connects, it is an important baseline for checking account status, client compatibility, and the update path. First confirm that the basic network works with the client disconnected, then sign in to the user panel in a browser and check whether the download and subscription area opens. If the panel works but the client update fails, record the client’s exact error and check that the subscription address was copied in full.

A subscription address contains information used to identify the subscription and should not appear in public screenshots, forums, or shared documents. You do not need to paste the complete address into a support ticket; state the retrieval entry point, client platform, and error, and support can check the account status. If the address was exposed, review the user panel for available security measures and explain the situation in a ticket. Documentation examples must use a fake value such as https://example.com/sub?token=YOUR_TOKEN.

Distinguish Update Failures from Parsing Failures

An update usually involves downloading the subscription and having the client parse it. A network error, timeout, or download failure points more toward the basic network, DNS, or update channel. A format error, empty configuration, or parsing failure points more toward incomplete copying, the wrong client entry point, or incompatibility. These cases require different information; do not reduce both to “the subscription is broken.”

If the browser can open the user panel but the client cannot update, fully exit and reopen the client and confirm that the system date is correct. When migrating from an old device, retrieve the subscription again from the current user panel instead of copying an exported cache from the old client. Both the client and subscription are obtained through the user panel; the marketing pages do not provide static installers or real subscription addresses.

A Specific App Does Not Use the Proxy

If the browser works but one app cannot connect, the network channel is usually established. Fully exit the app first, then reopen it after the client connects so it rereads the system network state. Check whether the app has a custom proxy, direct-connection mode, or independent DNS. In-app settings can override the system proxy and send the app along a different path. If unsure, restore the app’s default network settings instead of entering proxy parameters from an unknown source.

Some apps do not read the system proxy, or read it only for certain connection types. Check whether the current client mode handles only common browser traffic. Record the current option before switching modes, using the working browser as a comparison. If the app recovers but the browser fails after the switch, the rule scope has changed. Choose a configuration that supports the main apps instead of continually layering rules. For complex routing scenarios, see Subscription, Route, and Routing Terms Explained.

Unlimited Simultaneous Devices and Fault Diagnosis

VncVPN supports unlimited devices connected at once, so a normal multi-device connection should not be treated as an exceeded-device limit. If one device fails while others work, first check that device’s client, subscription update time, access network, and system permissions. If every device fails at once, check the shared router, the same route, or subscription status. This comparison quickly shows whether the issue is device-specific or shared.

Unlimited simultaneous devices does not mean local network conditions are identical across devices. One device may have a weaker Wi-Fi signal, another may retain an old subscription, and mobile systems may pause background connections. Compare devices using the same route and access network where possible, and record each platform separately. For further guidance on household sharing and device limits, read Multi-Device VPN Comparison: Real-World Testing.

If only one app remains affected after the subscription update is restored, classify the issue as app compatibility or traffic routing rather than continuing to troubleshoot the subscription. In the ticket, state “browser works, target app does not,” along with the app name, platform, client mode, and whether the app was restarted. This directs the investigation to the app path instead of repeating basic connectivity questions.

DNS Issues and the Resolution Path

Recognize Common Resolution Problems

DNS issues often appear as a browser message that the server cannot be found, different results for the same site across apps, an old region still appearing after switching routes, or intermittent pages while the direct network connection remains up. Start by querying a public test domain with the system tool, then compare results before and after connecting. No response points more toward an unreachable resolution server; an address returned with pages still failing points more toward data transfer, the system proxy, or the target site.

Do not diagnose DNS from the browser error page alone. The browser may use its own secure DNS, creating a different path from the system and client. If the command-line query works but the browser fails, check the browser’s DNS settings and extensions. If the browser works but another app fails, check whether that app uses custom resolution. During troubleshooting, reduce the number of resolution sources: first use system defaults in the browser and app, then decide whether to enable advanced options after recovery.

Clear Stale Cache Instead of Repeatedly Changing Servers

After switching routes, the system and browser may retain old resolution results. Close the target app first, then use the cache-clearing function provided by the system. On Windows, run the following in Command Prompt:

ipconfig /flushdns

Cache mechanisms vary across macOS, Linux, and mobile systems, so do not copy high-privilege commands from unknown sources. A safer general approach is to close the target app, disconnect the client normally, reconnect, and reopen the app. If the system is managed by an organization, follow the administrator’s network-maintenance procedure instead of changing managed DNS settings.

Browsers may also keep their own host cache or reuse old connections. A private window reduces the influence of cache and extensions, but it may not bypass every browser-level DNS setting. If the private window works, check extensions, cache, and login sessions in the regular window one by one. Do not clear all browsing data at once, especially if login states must be preserved; clearing data for the target site first makes the result easier to confirm.

Resolve Conflicts Between Multiple DNS Settings

The system, browser, router, client, and security software may all provide DNS functions. When several layers are enabled at once, requests may bypass the intended path or return different results in different apps. Map the actual path first: what settings the device receives from the router, whether the system specifies DNS manually, whether the browser uses independent resolution, and whether the client handles domain requests. If uncertain, temporarily return to automatic system settings and the client’s default mode.

Manually specifying a public DNS server does not always solve the issue. If the current network blocks a particular resolution method, repeatedly changing addresses only adds variables. First compare queries with the client disconnected and connected, then determine whether the issue occurs in only one state. If disconnected queries work but connected queries fail across all routes, record the client mode and query error. If only one route fails, use another route and report the original.

Prevent False Results from Being Mistaken for Route Failures

A target site may change addresses, adjust regional distribution, or return different results because local caches expire at different times. This does not necessarily indicate a DNS leak or an unavailable route. Consider whether the target site opens, whether the exit region matches expectations, and how different routes behave. An IP-check page can show the current exit environment, but one test result cannot replace a complete path diagnosis.

If a target site is abnormal only while logged in, sign out first or test in a private window. Some services determine content availability from the account region, cache, and exit environment together. Changing DNS cannot change account attributes, and not every regional-content issue is a DNS problem. For streaming scenarios, see the Streaming access page for the difference between route and account region.

If different apps return conflicting resolution results, list the system query, browser, and target-app behavior separately in the ticket. If resolution fails across all routes, different access networks, and default DNS settings, attach the query output. If clearing the cache fixes it, continue monitoring instead of repeatedly changing DNS; simple configuration is usually more stable than layering multiple resolution tools.

When to Contact Support and How to Prepare a Ticket

When a Support Ticket Is Appropriate

Submit a ticket if the issue still reproduces consistently across multiple access networks or routes after checking the basic network, comparing routes, and restarting the client. Identical handshake errors on every route, a subscription that continually fails to update, all targets being inaccessible after connection, and repeated foreground disconnects are all appropriate cases for support review. You can also report a single faulty route with its name and time of occurrence so the service team can check it, while continuing to use other available routes.

If the issue was resolved by clearing browser cache, reopening the app, or completing public-network authentication, you can usually continue monitoring. If it keeps returning, submit a record and note whether the same action triggers it each time. For target-site maintenance, account-region restrictions, or weak local Wi-Fi, support may not be able to change the target service or access network, but a complete comparison can still clarify the boundary of responsibility.

What to Include in a Support Ticket

An effective ticket should include the platform, client source, fault type, selected route, access-network type, time of occurrence, complete error text, and comparisons already completed. Specify Windows, macOS, iOS, Android, or Linux rather than only “computer” or “mobile.” State whether the client came from the user panel. Use the complete route name shown in the client, not just a regional abbreviation.

Describe the fault in observable terms, such as “the client remains on connecting,” “the client shows connected but neither the browser nor an independent app can access the network,” “only one app cannot load,” or “the device must reconnect after waking.” Describe the access network as home Wi-Fi, wired, office, or public network; no private address is needed. The time helps locate matching logs, so record when the issue began rather than when the ticket was submitted.

Platform:
Client source: User panel
Symptom:
Selected route:
Access network:
Time of occurrence:
Complete error:
Comparisons completed:
Can the issue be reproduced consistently:
Attachment notes:

Screenshots, Logs, and Privacy

Screenshots should include the full error area and client status, while covering usernames, subscription contents, access tokens, private bookmarks, and unrelated file paths. Do not crop away the context in which the error occurred. A screenshot containing only the word “failed” has little diagnostic value; the status heading, error body, and current route are usually much more useful. If the error can be copied, paste the text as well so image compression does not make it unreadable.

Export logs as soon as possible after the failure and submit them only through a user-panel ticket. Do not publish logs publicly; they may contain device details, accessed domains, or local paths. Review the file before submitting and remove unrelated private information, but do not rewrite error lines. If you are unsure what is needed, submit the error text and comparison results first and wait for support to specify the required log range.

How to Describe Billing, Traffic, and Refund Issues

Billing tickets should include the plan name, payment method, and order status shown in the user panel; complete payment credentials are not needed. VncVPN supports Alipay, WeChat Pay, and USDT. 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 are prorated by the remaining days. Traffic packs are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain available until used and never expire.

If the displayed traffic differs from what you expected, state whether you are using a monthly plan or traffic pack, when you noticed the change, the plan name shown in the user panel, and whether you recently upgraded. Do not calculate remaining days yourself or assume a rollover rule; use the order and plan rules shown in the user panel. See the Plans and Pricing page for details. This service offers 60-day no-questions-asked refunds; refund requests and applicable rules are covered by the Refund Policy.

How to Retest After Support Replies

After receiving troubleshooting advice, still perform one action at a time. Record the current state before each action and retest in the original fault environment afterward. If the problem occurs on a home network at night, a successful test on another network during the day does not prove that it is fixed. Return to the same route, app, and a similar scenario whenever possible. Once restored, reply to the ticket with the action that worked so the conclusion can be retained.

If the advice involves updating the client, obtain it through the user panel instead of downloading an installer from search results or a third-party page. Before updating, preserve the current subscription retrieval method and necessary logs; afterward, import the subscription provided by the user panel again. If the issue remains, reply to the original ticket instead of opening multiple tickets on the same topic, keeping the diagnostic record continuous.

The end point of troubleshooting is not having “tried many things,” but defining the fault boundary: whether it follows the device, access network, route, app, or time. Once the boundary is clear, you can avoid repeated changes even if the issue has not yet recovered, and support can inspect the most likely layer directly. To review the complete connection flow, return to the Guides. To understand plans, device sharing, and route selection, continue with the Complete VPN Beginner’s Guide.