Cross-Border Network Troubleshooting

FAULT / CONNECT

Can’t connect at all: identify the failing layer first

Distinguish between a client that will not start, a failed route handshake and a local network outage

“Can’t connect at all” cannot be diagnosed by checking only whether a webpage opens. The useful clue is what happens in the client before and after you click Connect. If the button does not change state, the system shows no network-permission prompt, or the client exits as soon as it starts, the issue is usually still at the client or system-permission layer. If the client enters a connecting state and then reports a timeout, handshake failure or unavailable route, focus on the route, local network restrictions and system time. If the client clearly says it is connected but no webpages are reachable, this is no longer a pure connection failure; continue to Web access & DNS.

First confirm that ordinary internet access works. Temporarily disconnect the client and open a familiar website that previously worked. If ordinary websites also fail, restore Wi-Fi, wired access or the system network settings first. Cross-border routes depend on the local network as their entry point; changing remote routes repeatedly will not help when the local connection is down. If ordinary access is fine, fully quit and reopen the client instead of repeatedly clicking Connect in the same window. On Windows and macOS, confirm that the system network extension or virtual interface has permission. On iOS and Android, confirm that the system connection-authorization prompt appeared and was not accidentally dismissed.

System time is also worth checking. Encrypted connections depend on certificate validity and time checks, so an incorrect device date, time zone or synchronization setting may appear only as a handshake failure. Restore automatic time synchronization, close the client and establish the connection again. Avoid reinstalling the client, resetting the network and changing routes at the same time: when several changes happen together, even a successful recovery will not reveal the real cause, making the next occurrence harder to diagnose.

Test routes by replacing one in the same region rather than switching randomly again and again

After confirming that the local network and permissions are working, try another route in the same region first. This keeps the destination, approximate distance and content region as consistent as possible while changing only the route. If access returns immediately, the original route may not be suitable at that moment; test it again later if needed. If all routes in that region fail, choose a nearby region for comparison. Do not click through a large number of routes in a short time: the client may still be releasing the previous connection, and the system virtual interface may not have recovered, causing errors from several connection attempts to become mixed together.

You can also test with another local network, such as switching from the current Wi-Fi to another trusted network. If the same route fails only on one local network, the scope is narrowed to the entry network, router policy or local DNS. If it fails across multiple local networks, the client’s permissions, subscription status or route choice become more likely. Check the region and route-type notes in Global Nodes and choose an alternative suited to the same use case rather than judging quality by the region name alone.

When a reset is needed, start with low-impact steps

A low-impact recovery sequence starts by disconnecting, fully quitting and reopening the client, then moving on to subscription updates and system-permission checks. Do not delete every configuration at the first timeout. Deleting configurations also removes routing settings, route choices and the old state needed for comparison, making the issue harder to reproduce. If the client says the subscription is empty, authorization has expired or the configuration cannot be parsed, go directly to the subscription update section. If only one app fails, go to the app-routing section.

Restarting the device can help when a virtual interface is occupied, a system network extension was not released correctly, or the state became inconsistent after waking from sleep. After restarting, verify ordinary internet access first, then launch one client and connect to one route. Avoid letting several similar tools take control of the system network at once. Many cases of “can’t connect at all” are caused not by the route itself but by multiple network extensions, proxy tools or security programs changing routes simultaneously. Close anything else that modifies the system proxy, DNS or virtual interface, then test with one client; this usually gives a clearer result than repeated reinstalls.

FAULT / WEB-DNS

Connected, but webpages do not open or DNS errors appear

Use different types of destinations to separate DNS resolution failures from transport failures

A connected status means only that the local virtual interface has established a relationship with the route. It does not confirm that domain resolution, routing rules and browser connections are all working. Do not diagnose the issue by refreshing one webpage repeatedly. Try a familiar webpage, another browser and an internet-enabled app that does not depend on a browser. If every domain-based destination fails while the client can still update route status, DNS resolution is a likely cause. If only one site fails, consider the destination’s regional policy, browser cache, login session or current route exit before resetting the entire network.

The browser’s own secure DNS, the system DNS and the DNS controlled by the client may all be active at once. More resolvers do not necessarily improve reliability; conflicts can produce an established connection with failed domain resolution, partially loaded pages or different behavior across browsers. During troubleshooting, temporarily disable the browser’s separately configured secure DNS so resolution returns to the system and client path, then test again. If the issue is resolved, it lies in the browser-specific resolution path. Re-enable it later if needed, but avoid letting browser settings and client rules override each other.

Clear the system DNS cache and establish the connection again

The system may retain resolution results obtained before connecting, especially after frequent route changes, waking from sleep or switching networks. Disconnect the client first, clear the system DNS cache, then reconnect and test in a new browser window. The commands below affect only the local resolution cache; they do not change your CacaVPN subscription. Save any active network tasks before running them, and execute each command in the terminal for the relevant operating system.

ipconfig /flushdns

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder

resolvectl flush-caches

After the command finishes, do not immediately open many tabs. Connect to one route, test one destination that previously failed, then test an ordinary website. If ordinary access returns but the specific destination still fails, DNS is no longer the main suspect; check the regional route, browser session and destination service status instead. Linux distributions use different resolution services. If the system cannot find the command, reconnect through the system network settings rather than copying commands from an unknown source that modify system files.

When pages load partially, check the browser state and proxy mode

When the page body appears but images, scripts or login components keep loading, different domains referenced by the page may be taking different paths. Test in a browser private window first to rule out stale cache, extensions and leftover login sessions. If the private window works, clear data for the target site step by step or disable extensions that modify requests instead of wiping all browser data. If every browser loads only some resources, check whether the client is in global mode or rule mode. Rule mode may send the main site and resource domains through the local network and route separately. Temporarily switching to global mode can help diagnose the issue, but restore an appropriate rule set for the actual use case afterward.

The system proxy may also retain an old address. If the client exits unexpectedly, the operating system can leave the proxy enabled even though no corresponding process is listening, preventing the browser from connecting. On Windows and macOS, check in system network settings whether the proxy is managed by the current client. On mobile, check whether the system connection status still shows an old network configuration. Do not manually enter a proxy address from an unknown source. To verify subscription text, use only the subscription entry supplied in the user panel. A teaching example may look like https://example.com/sub?token=YOUR_TOKEN; it only illustrates the format and cannot connect to any real service.

FAULT / THROUGHPUT

Slow speeds and peak-hour buffering: separate distance, entry network and use case

Do not judge a speed problem from a single speed test

Cross-border connection speed depends on local access, the carrier path, route type, exit region, destination service and device performance. A single speed test describes performance to one test target at one moment; it does not directly represent the experience of video, AI Tools, file transfers or web browsing. First identify where “slow” occurs: a delayed first screen, reduced video quality, consistently slow downloads, unstable uploads or slow responses from one service. Different symptoms have different bottlenecks. Treating them all as route speed problems leads to needless switching.

Disconnect the client first and confirm that the local network itself is not fluctuating. Packet loss, unstable Wi-Fi or bandwidth shared by several users cannot be fixed by a remote route. Move closer to the router or use wired access for comparison when possible. Then connect to a geographically closer route suited to the task, keeping the same device, destination and time period. If a nearby route is stable while a distant route is much slower, path length and cross-region transport are the main factors. If every region is slow, return to the local entry point, client mode and background traffic.

Compare like with like during peak hours instead of relying on impressions

Peak-hour buffering requires separating congestion on the entry network from congestion on the route. The most useful record is not “it is slow at night,” but how the same device, route and destination perform at different times, and whether switching to another route in the same region helps during peak hours. If the issue appears only during busy periods on one local network and disappears on another, the entry network is the stronger factor. If the same route remains abnormal across different entry networks while an alternative in the same region works, avoid the original route temporarily and keep the comparison record.

For video, note whether buffering occurs only when increasing the resolution. For AI Tools, distinguish an inaccessible page, failed login and a wait during generation. For downloads, check whether the source server limits each connection. “4K without buffering” depends on the route, source platform, local network and device decoding conditions, so one short playback session is not enough to draw a conclusion. Choose a region where the destination service is located or nearby, pause background synchronization and system updates, and compare different routes in the same region with the same content.

See How to Choose a VPN Route: A Complete Beginner’s Guide for ways to assess regions, route types and use cases. CacaVPN offers a choice of 90+ countries and 200+ routes, but coverage counts do not mean every route performs identically on every local network. The goal is to find a route that fits the current entry network and task, not to always choose the farthest region or a particular name.

Check background traffic, client mode and protocol overhead

Cloud-drive sync, system updates, app-store downloads, photo backups and browser tabs running in the background can consume upload or download capacity. When upload is saturated, downloads may also slow because acknowledgements cannot be sent promptly. During troubleshooting, pause identifiable background transfers, disable unnecessary device sync and test the main task again. CacaVPN supports unlimited devices, but that does not increase local broadband capacity as more devices are added; several high-traffic devices still share the same network entry.

Rule mode is usually better for everyday use, but overly complex rules, outdated sources or matching loops can also create problems. Temporarily switch to the client’s global mode for comparison. If global mode works noticeably better, inspect the rule set and app routing. If both modes are slow, continue comparing routes and local networks. Restore settings suited to normal use after testing. Company intranets, printers and local services may need to remain on a direct connection.

FAULT / SESSION

Frequent disconnects and mobile background dropouts

Determine whether the connection is actively dropping or the device is entering sleep

For frequent disconnects, record what happened just before the drop. If it occurs only when the device is idle, locked or sent to the background, check system power-saving and background-activity policies first. If it also drops during active use, compare local network stability, the route and client status. If it drops while moving from Wi-Fi to another network, the network interface has changed and the old connection needs to be rebuilt; this is different from repeated drops while the device remains idle.

After a desktop system enters sleep, the virtual network interface may be suspended. When the system wakes, the client may still show its previous state even though the connection has expired. Disconnect and reconnect manually instead of only refreshing the page. If this happens after every wake-up, check whether the system allows the client to maintain necessary background network activity and confirm that multiple network tools are not all restoring themselves at once. On Windows and macOS, also observe whether it always occurs when switching from wired access to Wi-Fi or from a company network to a home network. If it occurs only during an interface change, reconnecting is an appropriate recovery step.

On mobile, check power saving, background activity and network switching first

iOS and Android limit app activity based on battery level, background usage and system policy. You may see the connection disappear after locking the screen, return only after reopening the app, or remain stuck on the old route after switching away from Wi-Fi. In system settings, allow the client’s necessary background activity and do not place it on a strict power-saving or deep-sleep list. Manufacturers use different names for background controls, so check settings related to battery, background activity, auto-start and network access. Do not install so-called keep-alive tools to bypass system management.

Also confirm that the system is not enabling another VPN configuration at the same time. Multiple configurations can appear in the settings list, but they may replace one another when taking control of the network. During troubleshooting, leave only the connection you are using enabled and temporarily disable the others. If work data, company management policies or security software created a network configuration, confirm its purpose before changing it. Do not delete a managed configuration; compare on a non-work device or ask the device administrator whether another network extension is allowed.

Switching between mobile data and Wi-Fi changes both the exit address and network interface, so an existing session may not continue. If there is no access after switching, wait for the system to finish connecting, then reconnect in the client. If automatic switching happens frequently, keep one network active during testing and confirm whether the route itself is stable. Compare routes in the same region only if disconnects continue on a fixed network.

Narrow the scope by looking for a disconnect pattern

If disconnects have no fixed timing but always coincide with changes in the local Wi-Fi signal, address router placement, wireless interference or the entry network first. If ordinary access remains stable and only one route drops while an alternative in the same region works, switch routes temporarily. If every route drops on one device while another device works on the same network, the issue is more likely that device’s permissions, power settings or client configuration. If every device on the same network drops at once, inspect the entry network and router rather than reinstalling clients one by one.

Log messages such as “connection closed,” “network changed,” “interface unavailable” and “remote timeout” point to different areas. You do not need to interpret every log entry before submitting a ticket, but keep the continuous section before and after the disconnect instead of capturing only the final error. Screenshots should include the current route name, client connection status and system type. Before sharing account-related information, hide the username, subscription content and any fields that could be used to log in.

FAULT / SUBSCRIPTION

Subscription update failures: distinguish the URL, account status and client parsing

First confirm that the update is using the current subscription

Common subscription update symptoms include request timeouts, an empty configuration, an unrecognized format, authorization failure or no change in the route list after updating. Before troubleshooting, confirm that the subscription came from the CacaVPN user panel, not an old screenshot, note or configuration exported from another device. Subscription content may contain account authorization data and should not be pasted into public webpages, group chats or third-party checkers. If you need to obtain it again, sign in to the user panel, copy the current content from the subscription section and import it into the client.

Do not repeatedly open the subscription URL as if it were an ordinary webpage. A browser showing text, downloading a file or saying it cannot preview the content does not prove that the client cannot parse it; the client processes its own subscription format. The correct diagnostic approach is to update from the client first, record the complete error and confirm whether the current local network or an active route can reach the subscription entry. If the client has no usable route, updating usually depends on the local network. If a route is already active, test both disconnected and connected states to determine which path the update request uses.

A common format example in teaching documents is https://example.com/sub?token=YOUR_TOKEN. This is an obviously fake value used only to show that subscriptions often contain query parameters. Real subscriptions must be obtained from the panel; do not guess parameters, replace the domain or remove the query string. When copying, avoid extra spaces, line breaks and Chinese punctuation, and do not copy only part of the URL.

Keep old configurations if needed, but prevent duplicate subscriptions from overriding each other

When several similarly named subscriptions are saved in the client, you may update an old entry while using another configuration. Check the source and name of the currently enabled configuration before updating. If you need to import again, disable the old configuration instead of deleting it immediately. Confirm that the new configuration displays routes and connects successfully, then remove duplicates. This preserves a fallback and makes it easier to compare the state before and after the update.

If the update succeeds but the route list does not change, the client may still be showing cached data, the active configuration may not have switched, or sorting and filters may be hiding routes. Fully quit and reopen the client, confirm the active configuration name and inspect the route list again. If the client says the format is unsupported, use the compatible entry provided by the user panel rather than converting the subscription online. Online conversion sends sensitive authorization data through an additional service and may alter rules or fields, causing later updates to fail again.

Check account and plan status separately

Subscription updates depend on account status. Sign in to the panel and confirm that the current plan, traffic balance and subscription entry are displayed correctly. 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 the price difference for a mid-cycle upgrade is prorated over the remaining days. Traffic packages are ¥158/300GB, ¥358/1000GB and ¥658/3000GB, valid until used and never expiring. If the plan status, traffic display or order status differs from expectations, save a screenshot of the panel and verify it through a support ticket rather than placing duplicate orders.

If the panel works and other clients can update while one client keeps failing to parse, the issue is narrowed to that client’s configuration or system environment. On the same device, remove the newly imported failed entry and import it again from the panel. If it still fails, record the client name, platform, exact error and import method. If all devices fail to update at the same time, do not reinstall each one; check the panel status directly and prepare the ticket details.

Creating an account does not require an email address; a username and password are enough. If you forget the password or lose the username, there is no email address to use for recovery, so store your login details securely for everyday use. If you can still access the panel but subscription updates fail, the account-creation requirements are not the cause; continue checking the plan status, subscription entry and client parsing.

FAULT / APP-ROUTING

One app cannot use the proxy: check traffic capture and routing rules

First confirm whether the problem affects only one app

If one app cannot connect while the browser and other apps work, do not start by resetting the entire network. Confirm that the app is actually making a network request: quit and reopen it, switch to a page that clearly requires internet access and check whether the client connection log shows the related traffic. If the log contains no entry for the app or destination domain, the app may bypass the system proxy, use its own network stack or be outside the client’s current browser-proxy mode. Check whether the client supports a system-level virtual network mode and confirm that the required system permissions are enabled.

If the log shows the destination request but marks it as direct, inspect the routing rules. Rules may choose a path by domain, address, process or region, and a post-update app may use new domains not covered by older rules. Temporarily switching to global mode can help diagnose the issue: if the app works in global mode, the route itself is available and the problem is concentrated in rule matching. If it still fails in global mode, check the destination region, app cache, login session and route exit. Restore the mode suited to everyday use afterward and adjust rules for the app instead of relying on global mode permanently.

App cache, regional state and account sessions may retain old results

Streaming and AI Tools often store region settings, login sessions and API connections inside the app. Simply refreshing after changing routes may not make the app reassess the network environment immediately. Sign out of the app’s account page if appropriate, fully end the app process, connect to a route in the target region and reopen it. Decide whether to sign out based on the app’s behavior; do not clear all data when you are unsure of the credentials. If the browser version works but the native app fails, the route can reach the destination, so the difference is more likely related to app cache, system permissions or the app’s independent network behavior.

If someone searches for “VPN software” to connect an app to an overseas service, the practical troubleshooting focus is still whether the app enters the system-level network path, whether the rules match and whether the destination region is appropriate—not adding more network tools. Running several tools at once makes route ownership unclear and can send the browser and app through different paths. During testing, leave only the CacaVPN client in control of the network and close other programs that modify the proxy, DNS or virtual interface.

Keep LAN apps and company intranets on a direct connection

Printers, file sharing, router admin pages and company intranets usually depend on local addresses or internal DNS. If these apps stop working in global mode, the route is not necessarily broken; local traffic may simply be sent through a remote path. Keep LAN and internal services on a direct connection in the client rules. On managed devices, internal network rules may be supplied by an administrator and should not be deleted. Record the apps and destinations that need direct access, then use the client’s existing LAN-bypass option or rule mode.

Work apps may access public and internal services at the same time, so making the entire app direct or proxied may not be appropriate. Use the domains and addresses in the logs to distinguish them: route public destinations through the appropriate region and keep internal destinations on the local path. If you are unsure what a destination is for, ask the organization’s network administrator rather than submitting internal domains, addresses or configuration to a public channel.

For network conditions and login stability with tools such as ChatGPT and Claude, see ChatGPT VPN Guide: Login, Registration and Stable Use Tested. That article explains the use case; this chapter identifies whether the fault lies in system capture, the route region or routing rules.

FAULT / ACCOUNT

Device-limit notices, account status and plan checks

Check where the notice comes from before treating every authorization error as a device limit

CacaVPN supports unlimited devices. If the client or system shows a message such as “device limit exceeded,” first identify its source: the CacaVPN user panel, the client itself, the device system or another network tool. Third-party clients may impose their own limits on configuration count, system connections or authorization; these are not the same as the device rules of a CacaVPN plan. Screenshots should include the title and surrounding context of the page showing the notice, since a single error line can easily be misattributed.

If the notice appears while importing or starting, check whether duplicate configurations are saved in the client, whether another connection is enabled and whether the system limits available network extensions. If it appears in the user panel, sign out and back in, then confirm that the current username matches the account used for the purchase. When multiple usernames are involved, the common confusion is not device count but that one device is signed in to another account without an active plan.

Unlimited devices does not mean every device will synchronize its configuration automatically. Each device still needs the correct account to access the panel and obtain the client and subscription entry suited to its platform. CacaVPN supports Windows, macOS, iOS, Android and Linux, and each platform handles permissions, connections and background activity differently. If one platform fails while others work, investigate that platform’s environment first rather than treating the account as invalid everywhere.

Review plan, traffic and order status separately

Being able to sign in does not prove that the current subscription is usable; likewise, a client connection failure does not prove that the order is abnormal. Check plan status, traffic display, subscription entry and order history separately in the panel. Monthly-plan traffic resets each month on the activation date, and a mid-cycle upgrade is prorated over the remaining days. Traffic packages remain valid until used and never expire. If a recent upgrade is not reflected in the client, update the subscription and reload the configuration before trying the same action again.

Payment methods include Alipay, WeChat Pay and USDT. If an order has been submitted but its status does not match the actual payment result, keep the order page and payment-result page; do not make another purchase as a test. In a ticket, state the payment method, order status and steps that occurred. Hide unrelated account information in payment screenshots. The refund policy provides 60-day no-questions-asked refunds; applications are handled through the site terms and support-ticket process, and repeated purchases should not be used as a recovery step.

If the traffic display differs from expectations, first confirm whether the current product is a monthly plan or a traffic package, then check the signed-in account. Their usage rules differ: monthly-plan traffic resets each month on the activation date, while traffic packages remain valid until used and never expire. Do not calculate reset dates from calendar months or conclude that panel metering is wrong based only on one device’s local statistics; system counters may use different app, interface or reporting periods.

Keep account and network conditions comparable when testing multiple devices

Multiple devices provide an important comparison. With the same account and local network, one working device and one failing device usually indicate that the account and route are generally available; the issue is likely the failing device’s permissions, client or configuration. If the same device recovers after switching local networks, the entry network has more influence. If every device fails on one network but works after switching networks, inspect the router, DNS or entry restrictions first.

Device comparisons do not require identical platform settings, but keep the route region and test destination as consistent as possible. If Windows uses global mode while Android uses rule mode and they also use different regions, the results cannot be compared directly. Record each platform, client mode, route region and local network before interpreting the difference. Restore each device’s everyday configuration after troubleshooting.

If you need to change your plan, see Plans and Traffic Packages. The plans page compares prices, traffic and usage rules; this chapter focuses only on how account status affects connections and subscriptions. If panel data and order records cannot be reconciled, stop repeating actions, organize the screenshots and submit a support ticket.

FAULT / ESCALATION

Restore a baseline, decide when to contact support and submit a useful ticket

For complex issues, return to an explainable baseline first

When several symptoms appear together—occasional successful connections, partially inaccessible webpages, app-routing problems and failed subscription updates—adding more changes to the current setup only makes the cause harder to explain. Return to a minimal baseline: ordinary access works for familiar websites, only one network client is running, the subscription comes from the current user panel, the client uses a recognizable default configuration and one route suited to the task is selected. Verify webpages first, the target app second and personalized rules last.

Restoring a baseline does not mean immediately clearing the device’s network settings. A system-level network reset affects Wi-Fi, company networks, fixed addresses and other connection profiles, so its impact is broad. Complete low-impact steps first: fully quit the client, reconnect the local network, update the subscription, switch to another route in the same region, clear the DNS cache and restart the device. Consider the system network-reset function only after confirming that the issue is concentrated in the system network stack and saving the necessary settings.

Reinstalling the client is not the default starting point either. If the error can be reproduced consistently, save its exact text, the current configuration name and the steps that trigger it before reinstalling. Otherwise the issue may disappear temporarily while the diagnostic clues are lost. After reinstalling, obtain the client entry from the user panel rather than using an installer from an unknown source, and do not restore every problematic setting from an old backup. Import the current subscription and test the basic connection first, then add rules and personal settings gradually.

When to submit a support ticket

Submit a ticket when the panel cannot show the subscription entry, plan status and order records clearly do not match, subscription updates fail on every device and across multiple local networks, or the same error remains reproducible after basic checks. If every route in the same region still fails while ordinary access works, support can also investigate. In contrast, a temporarily inaccessible website, a single app’s cache issue or an unstable local Wi-Fi connection should first be tested in the relevant comparison section.

Write the symptom and platform in the ticket title, such as “Windows: webpages fail to resolve after connecting” or “Android: connection drops after locking the screen,” rather than only “doesn’t work” or “very slow.” Explain whether you changed networks, updated the system, adjusted rules or re-imported the subscription before the issue began, and list the actions already tried with their results. Support needs a reproducible path more than a collection of screenshots without context.

Include the system platform, client name, current mode, route region, local network type, affected app, exact error and conditions under which the issue appears. For frequent disconnects, say whether they occur during screen locking, sleep, network switching or active use. For speed issues, identify the affected apps and whether an alternative route in the same region works. For subscription problems, say whether the panel opens and what error the update returns. Do not send passwords, complete subscription content or any field that could be used to log in.

Close the loop with troubleshooting notes

After recovery, record the change that actually worked. For example, an alternative route in the same region restored access, disabling the browser’s independent DNS helped, allowing mobile background activity stopped the dropouts, or re-importing the current subscription fixed the issue. Do not treat every action taken during troubleshooting as a solution. Only a single-variable change tied to a result is useful for future reuse.

If the issue returns later, repeat the last effective step first, then check what has changed in the environment. Route problems can vary with the entry network and time of day; app problems can follow an update that adds new domains; mobile background behavior can change with system policies. A brief record lets a later ticket move directly to deeper diagnosis instead of repeating steps that have already been shown ineffective.

The goal of system troubleshooting is not to try as many actions as possible at once, but to narrow “the network does not work” to a clear layer: local entry, system permissions, client, route, DNS, subscription, app routing or account status. Once the layer is clear, the corrective action can be smaller and recovery more controlled. CacaVPN provides entry points for Windows, macOS, iOS, Android and Linux. Platform differences change where actions are performed, but the diagnostic order in this manual remains the same.