Connection Troubleshooting Guide

Separate network access, configuration loading and connection setup

“Can't connect” could mean the client won't start, no routes are available, or the connection remains stuck after you select a route. These failures happen at different stages. Disconnect first, then check whether your device can reach websites you normally access directly and whether the current network requires you to confirm access in a browser. If basic access is also failing, check your Wi-Fi, cable or network sign-in status first. Don't mistake a lack of internet access for a route problem, or repeatedly reimport your subscription instead of checking the basics.

If your basic connection works, check whether the client has loaded its configuration. An empty route list points to the subscription section; if routes are listed but none connect, continue with connection troubleshooting. Note the exact message shown when you tap Connect—for example, connection timed out, configuration parsing failed, permission denied or certificate validation failed. Specific error terms are more useful than “the network is broken.” Don't disable certificate checks to clear an error, or replace your account configuration with a supposed fix from an unknown source.

Run checks in an order you can undo

Check the user panel to make sure your subscription is active, then confirm that the client has selected an actual route—not an empty policy group or an expired custom entry. Try another region in the list while leaving the other settings unchanged. If the result is the same, test a different network connection if possible. Record route changes and network changes separately. If one route fails while others work, focus on that route. If the same device works on another network, investigate the original network environment.

Your operating system may ask for permission the first time you connect to a VPN. If you previously denied it, revisit system settings and the client’s connection screen to grant access. On desktop, check that any required network extension or virtual adapter is installed and authorized. Managed work devices may restrict these features; ask your administrator which connection methods are allowed rather than removing management settings. An incorrect system clock can also disrupt the encrypted handshake, so restore automatic time settings before testing again.

Other network tools may compete for the system proxy, VPN interface or traffic-routing permissions. Quit similar tools temporarily, test again and note which ones you closed. If security software blocks the client, verify where the file came from and why it was blocked, then follow that software’s normal approval process—don’t disable all protections. Save the error before restarting the client, and restart the device only if needed. If a reboot restores service only briefly, that pattern is a clue; restarting over and over isn’t a lasting fix.

When to stop troubleshooting on your own

If the same configuration works on other devices but fails on this device across different networks, focus on local permissions, network extensions and leftover proxy settings. If multiple devices fail only on the same network, treat the network environment as a common factor. If all devices on different networks show the same subscription or handshake error, open a ticket in the panel and include the comparisons you’ve already made. X8VPN covers 90+ countries and 220+ routes, but coverage figures can’t diagnose your particular connection.

A connection icon doesn't guarantee that a website is reachable

A connected status usually means that local traffic routing or the connection process has started. It doesn’t prove that every website is reachable. First work out whether all websites fail, only international sites fail, or just one domain is affected. Note the browser’s exact message: DNS lookup failed, connection timed out, certificate error or access denied. If the page shows a region or account notice, the request may have reached the service. Check the exit region and the platform’s rules instead of assuming local DNS is the cause.

Test in a fresh browser session, then compare with another browser or app. A browser may retain an old connection, proxy extension or site cache, so it can keep using the previous route after the client changes. Temporarily disable extensions that set their own proxy and check whether the browser uses a different proxy from the system. If only the browser is affected, check its settings first. If all apps fail, check whether the client’s system proxy, tunnel mode and DNS settings are configured consistently.

Check DNS separately from website access

DNS translates domain names into addresses that a connection can use. A successful lookup only means an address was returned; it doesn’t prove the address is reachable. A failed lookup doesn’t necessarily mean the route is down—the lookup request may not have taken the expected path. On desktop, use the command below to inspect system DNS resolution. The test domain only checks whether the command runs; it doesn’t indicate whether any service is available. If the command isn’t installed, skip it. There’s no need to install tools from unknown sources just to troubleshoot.

nslookup example.com

Note whether the command returned an address or timed out, and which resolver appears in the output. Don’t post the full output publicly; it may include internal network details. Then check the client’s connection log for the rule matched by the domain and whether the request entered the connection process. System commands, browsers and clients may use different DNS paths, so inconsistent results need explaining; they don’t prove that one of the tools is necessarily broken.

A browser’s encrypted DNS, the system’s private DNS and a client’s built-in DNS may all be active independently. Before troubleshooting, record the original settings, then restore the relevant options to the defaults recommended in the client documentation to avoid conflicting configurations. Don’t copy public DNS addresses at random or edit the system-wide hosts file to fix one website. If you previously added a custom mapping, back it up, remove the relevant entry, clear the related cache and try again.

Understand the limits of caches, certificates and network sign-in pages

On Windows, if you’ve confirmed that the system DNS cache needs clearing, run the command below. It only clears the local cache; it won’t fix a subscription, change a service’s regional policies or replace route checks. On other platforms, reconnect and close and reopen the app to test again rather than copying commands intended for a different system. If you see a certificate warning, check the system time, any network sign-in page and the certificate issuer. Don’t ignore the warning and enter your account password.

ipconfig /flushdns

If only one domain fails and the result changes with the route, note the domain, time, region and exact error, then ask support to investigate. The network check page can help you inspect your exit route, but a single test can’t prove that every app uses the same path. When you open a ticket, say whether DNS resolution failed, the connection could not be established, or the service returned a page. This helps support avoid repeating checks you’ve already completed.

Describe what's slow before deciding whether a route is congested

Slow initial page loads, slow downloads, video buffering and call latency aren’t the same problem. Initial loading depends more on DNS resolution and connection setup; sustained downloads depend on conditions across the entire path; real-time apps are more sensitive to latency changes. Describe what you see—for example, text appears quickly but images load much later, or a video starts but keeps buffering. “The speed is bad” doesn’t help distinguish between the site, Wi-Fi, client rules and the international route.

Pause large transfers on other devices and apps, and check that your device isn’t syncing files, updating its system or downloading content. A strong Wi-Fi signal doesn’t rule out interference. If possible, move closer to the access point or test over a wired connection. First check whether websites you usually access directly are also slow. If the basic network is already unstable, switching international routes may only change the symptoms. Fix the local connection first so your comparisons have a consistent baseline.

Keep test conditions consistent and change one variable at a time

Use the same content and compare routes under similar conditions. Don’t draw conclusions from different websites, video quality settings or file sizes. After switching routes, reconnect the target app and make sure its old connection has ended. Latency figures in a client’s route list reflect a specific test request, not actual download speed. A lower-latency route may not work better for the content you’re accessing. Choose a region based on the service’s requirements, not just geographical distance or list order.

For peak-hour issues, note when they start and when service recovers. One instance of buffering doesn’t prove the whole service is congested. And don’t compare results from different content accessed in the morning and evening. If direct access is also worse on the same network in the evening, factor in network fluctuations. If direct access is fine but some international routes repeatedly buffer, record those routes alongside routes that work for support to compare path differences.

Consider content sources and platform restrictions

Streaming quality can depend on your platform account, playback settings, device decoding and content delivery—not just your exit route. If playback buffers, check whether the app has lowered the quality automatically and try another title. Don’t treat differences between sources as proof of a bandwidth issue. AI tools may also take longer while requests are queued on the service side. If the page loads normally and other requests work, switching regions repeatedly may trigger more account checks without speeding up the service.

If your usual region continues to have problems, use the route guide to choose another region that meets the target service’s requirements. Keep a working route as a fallback and avoid repeatedly changing encryption, DNS and traffic-routing modes. Running out of subscription traffic is an account or billing issue; check the panel rather than treating it as congestion. Compare plan capacity and usage on the Plans page. More capacity won’t fix local network interference or an issue with the target website.

Open a ticket when the issue follows a consistent pattern. Include the type of content, test conditions, route names and comparison results. You don’t need to run repeated speed tests to prove buffering; they can use up traffic and affect other apps on the device. Support needs to know what works, what fails and whether the issue is reproducible—not just see a speed-test screenshot without context.

Note what happens just before the disconnect

Locking the device, switching networks, entering power-saving mode or opening a particular app may trigger a disconnect. First check whether the client is still running or the system has closed it. If the client still shows connected but apps can’t send or receive data, investigate stale connections after a network change. If the client process has disappeared or the VPN indicator is gone, check background permissions and system management policies. Distinguishing these cases helps avoid trying to fix an app being stopped by the system by switching routes.

Observe what happens in the foreground and after locking the screen without changing settings. If things work normally in the foreground but fail in the background, note the battery mode, whether power saving is enabled and whether background activity is allowed for the client. If both foreground and background connections are unstable, compare networks and routes. After switching from Wi-Fi to mobile data, the old connection may need to be re-established. That doesn’t mean the subscription has expired, and you don’t need to reimport the configuration after every network change.

Android and iOS require different checks

Android battery optimization, background activity limits and manufacturer-specific app management can each affect the client. Find the client in system settings and check that it’s allowed to run in the background as needed. If your device offers app hibernation or automatic cleanup, make sure the client isn’t included. Change only settings related to this client; you don’t need to disable power management system-wide. Reconnect and repeat the action that previously triggered the disconnect to see whether the change helped.

On iOS, check that the VPN configuration in system settings matches the client’s status, and make sure no other connection configuration is taking over automatically. A regular app being suspended in the background doesn’t necessarily mean the system connection has dropped, so check the VPN status and what happens when you reopen the app. On managed devices, some connection policies may be controlled by a management profile. Don’t delete a known work configuration while troubleshooting; check its purpose and permissions first.

After a mobile device wakes from the lock screen, the target app may still be holding a stale long-lived connection. The client reconnecting doesn’t necessarily restore the app’s session, so reopen the app after confirming that the network is back. If only one app needs reopening while others work, note that as an app-session recovery issue. For initial Android permissions, see the Android setup from scratch guide. For troubleshooting, just recheck the relevant steps; you don’t need to repeat the entire installation.

Desktop sleep, route changes and reconnection

When Windows, macOS or Linux wakes from sleep, network interfaces, routes and DNS services may be reinitialized. Wait for basic network access to return, then reconnect the client and check that the system proxy still points to a running client. If the client has exited but the system proxy still points to an old address, your browser may keep showing errors. Use the client or system’s normal exit and recovery options rather than repeatedly killing processes to keep things running.

If the client offers automatic reconnection, check when the feature takes effect. It can help after a connection drops, but it can’t resolve account issues or guarantee that app sessions will persist. If the log shows repeated attempts to connect to the same failing route, temporarily select another working route and see if the retry loop stops. Don’t enable traffic takeover in multiple tools at once; changes to system interfaces can make them compete for the connection and cause seemingly random disconnects.

If the disconnect isn’t related to a network change or background restrictions and can be reproduced on different networks, include the interruption reason and timestamp from the client log in a support ticket. Don’t send only a screenshot of the last successful connection. Support needs to see the events before and after the issue to tell whether the app closed, the interface restarted or the remote connection ended.

First identify whether fetching or parsing failed

A subscription update involves two steps: retrieving the configuration and reading it. A timeout, authentication failure and format-parsing error need different fixes. First check your account and subscription status in the panel, then note the client’s full error category. If the update request never completes, check your basic network and the route used for the request. If the content was retrieved but can’t be read, check the format, import method and client compatibility instead of repeatedly refreshing.

Use the user panel overview to get the current subscription link for your account. Make sure you haven’t copied a webpage or sharing-page address, or text rewritten by a chat app. Don’t edit the link parameters manually or mix links from another account or an old device into your current configuration. A subscription link contains access credentials. Keep it in a trusted client; don’t paste it into public forums, online conversion tools or public screenshots.

Keep your working configuration and check the update route

If your current route still works but the update fails, keep the existing configuration; don’t delete it and start over. Some clients let you choose a separate network path for subscription updates. If the request depends on the current connection and that configuration has stopped working, you can end up in a loop with no way to recover. Compare the update methods offered by the client and note the difference between using the system network and the existing connection. Don’t add an unknown relay service to download the configuration.

If you see a parsing error, check that you selected an import method compatible with your client. A login page, error page or network sign-in page returned by a website can be mistaken for configuration text and cause a format error. Don’t rewrite the whole configuration just because the error mentions a particular field. Try importing again from the panel and note the name of the import option you used. If it still fails, send support the error type and client name—not the full subscription content.

Custom rules, external resources and the main subscription may be updated through different methods. If the main subscription updates but a rule resource fails, check them separately rather than assuming the account is unavailable. If you’ve merged multiple configurations, back them up and use the original configuration from the panel for an isolated test. If the original works but the merged one doesn’t, investigate the custom settings. Don’t make a test configuration your permanent default until you’ve confirmed that your routing and privacy needs are still met.

Understand traffic balances before trying to reset anything

Monthly subscription traffic resets each month on the activation date; don’t assume it resets on the first day of the calendar month. When you upgrade partway through a billing period, the price difference is converted into remaining days. Check the panel for the current status. Monthly plans include ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Check the active subscription and traffic records for your account. Past payment screenshots don’t prove your current status, and an old value cached in the client doesn’t prove the panel has updated.

Traffic packs don’t expire and remain available until used up. Options are ¥158/300GB, ¥358/1000GB and ¥658/3000GB. Packs work differently from monthly subscriptions, so first identify which product you’re using before deciding whether the displayed balance looks right. See the plan details for a full price and capacity comparison. If the panel hasn’t updated as expected after payment, keep the order status and payment result for support to check. Don’t try to fix a display issue by paying repeatedly.

Before resetting a subscription link, be aware that the old link may stop working and plan to reimport the subscription on your devices. If you think the link has been exposed, secure your account and subscription in the panel first, then update each client. X8VPN requires no email address: you can create an account with a username and password. Keep your account details safe. A subscription link is not a substitute for your account password; don’t share your password with anyone while troubleshooting.

Apps on the same device may use different network paths

A browser reaching a website doesn’t mean a desktop or mobile app uses the same network path. Some apps follow the system proxy, some connect directly, and others need the client’s tunnel mode to use the intended route. Note the affected app, what you were doing and the exact error, then compare it with the service’s web version. If the website works but the app doesn’t, check the app’s connection method and routing rules first. Don’t assume the account is restricted or the route is unavailable.

Check the client to see whether the relevant request appears and which rule it matched. If it doesn’t appear, the app may not be using the current traffic-routing mode, or it may not have sent the request yet. If it appears but uses direct access or another policy group, check the rule order and selected route. Don’t guess the path from an app icon or domain name. Some apps connect to separate services for login, static assets, content delivery and real-time communication. If the main page works but a feature doesn’t, look at the request associated with that feature.

Use a temporary comparison to check whether a rule is the cause

If your client offers a global traffic-routing mode or similar test option, you can try it temporarily after checking what it affects. Keep the route and target action the same. If the app works in the temporary mode but fails with your usual rules, investigate the routing rules rather than keeping broader traffic routing enabled permanently. Return to the original mode after testing and note the domain or rule associated with the problem. Follow your organization’s network policy on work devices and apps; don’t casually reroute all work traffic.

An app may have its own proxy setting, or read the system proxy when it starts and never refresh it. After switching routes or modes, close the session and reopen the app before comparing results. If the app has a separate proxy setting, check whether it still points to an old tool or stopped local service. Don’t copy unknown ports and addresses from online guides. Unless you have a specific need, use the client’s standard system integration to avoid maintaining conflicting settings in multiple places.

Messaging, voice calls and real-time features may use different transport methods from regular websites. Text messages working while voice calls fail doesn’t prove the entire route is broken. Check whether the client supports and has enabled the traffic-routing mode required by the app, then check whether the network restricts that traffic. Don’t blindly change low-level settings over and over. Record which features work, the client mode and any log messages so support can assess whether the issue is app compatibility or the network environment.

Check region, account and service-side restrictions separately

AI tools may use your exit region, account history, payment details and session state to determine access. A connected route only provides a network path; it doesn’t change the target platform’s account rules. If the page shows a region or verification notice, check the platform’s guidance and use a consistent region and session that meet its requirements. Avoid rapidly switching among regions to test; it can make your account environment harder to explain. For related scenarios, see the AI Tools connection guide and Claude region checks and route selection tips.

Streaming libraries, playback eligibility and quality aren’t determined by your exit route alone. Account region, content licensing, app cache and device capabilities can all affect playback. If you can search but not play a title, note the specific playback message instead of sending only a screenshot of the home page. Re-establish the playback session after switching routes, then test again. X8VPN doesn’t guarantee a fixed match between a particular route and a streaming library in this guide; check the platform and your client’s actual connection for current results.

When reporting an issue with one app, say whether other apps and the web version work, and how the usual rules compare with the temporary test mode. Redact account details. If the request reached the platform and it returned a specific account-management message, contact the platform through its official support channel as well. Network support can help investigate the route, but it can’t change a third-party platform’s account eligibility or content licensing.

Unlimited devices doesn’t mean every error is unrelated to the device

X8VPN allows unlimited simultaneous devices. If a client displays “device limit reached” or a similar message, don’t assume you need to remove other devices or upgrade your plan. First check whether the message came from the X8VPN panel, the client itself or the third-party app you’re using. Client authorization, organizational policies and the target platform’s session rules may use similar wording. Keep a note of where the message appeared and what you were doing. Identify the source before taking action, so you don’t sign out a device that was working normally.

Multiple devices sharing a network connection also share its local resources. Unlimited simultaneous devices doesn’t remove limits on Wi-Fi or network capacity. If everything slows down after adding a device, check for large sync or download tasks and compare performance with each device used on its own. Don’t assume a speed change is caused by the number of devices on your account, and don’t create duplicate accounts to test a route; that can make subscriptions and configurations harder to track.

Check traffic routing for each platform

On Windows, browsers, Store apps and standalone desktop programs may use different proxy interfaces. Apps that were already running may also keep using old settings after you change the system proxy. Compare a newly launched app with an existing session before changing traffic-routing modes. If direct access still fails after closing the client, check whether the system proxy has been restored properly. Don’t delete items from the registry or system folders if you’re unsure what they do.

On macOS, distinguish network extension permissions from proxy settings for the active network service. Settings may differ after switching between Wi-Fi and Ethernet. Check that the system has allowed the client’s required extension, then verify the active network service. Handle permission prompts in system settings; don’t use unknown scripts to bypass them. For iOS setup and account access, see the iPhone client and configuration guide.

On Linux, desktop proxy settings may not apply to terminal processes, and terminal environment variables may not affect desktop apps that are already running. First identify whether the issue occurs in a browser, terminal tool or background service, then check the corresponding launch environment. A service may run as a separate user with its own permissions; don’t run the entire client with elevated privileges just for convenience. If tunnel permissions are needed, use an authorization method supported by the client documentation and keep the original settings so you can revert.

Reinstalling isn’t the first step

Consider reinstalling only if the installation is damaged, components are missing or support specifically recommends it. Record the client settings first and store any necessary configuration securely. Don’t upload backups containing subscription credentials to public sites. Get the client from the client section of the user panel. You must log in to get your subscription. After logging in, you can download the client on platforms other than iOS; on iOS, available options depend on your account status in the panel. Don’t use unknown installation files from search results.

If the same account works on other platforms but not this device, report the platform difference as an important clue instead of changing your plan. If you see a device restriction message, include where it appeared, the client name and the platform. You don’t need to list all your personal devices. Support can determine whether the issue involves client authorization, a system policy or a third-party app session once the message source is clear.

When to contact support

Open a ticket if the issue is reproducible, you’ve compared your basic network and routes, or the error concerns account status, payment records or subscription authentication. You don’t need to work through every section on this page; use the one that matches your symptoms. Stop and ask support before resetting system networking, deleting management settings or changing security policies. The goal is to narrow down the issue, not overwrite the original evidence with changes you can’t undo.

Submit your issue through the support ticket section in the panel. Start with the expected result and what actually happened, then list the steps that reproduce the issue. For example, “The page loads, but submitting the request times out” is easier to investigate than “Nothing works.” If the issue has temporarily resolved, note when it happened and what changed: did it recover on its own, after switching routes or after reopening the app? Don’t just say “It’s fixed.”

Organize details by environment, steps and results

For your environment, include the operating system, client, network connection type, connection mode and selected route. Copy the exact system and client versions from your device; don’t guess based on an online guide. Include the time zone with timestamps so support can match them to logs. For the target, provide only a public domain, app name or feature type. Don’t send private documents, conversation contents or a full account page. If you’re using a work network, check which diagnostic details you’re allowed to share first.

Describe whether basic network access worked before connecting, when you switched routes, what action triggered the failure and whether the same conditions ever worked. Include only checks you actually performed; don’t copy every suggestion on this page and claim it was ruled out. Results can be described in text; screenshots aren’t required. If a screenshot helps, include the error and only the context needed to understand it. Logs should show relevant events from before and after the issue, not an isolated message with no clear source.

If support needs to check an order, provide its status from the panel and the identifying details they request, following the panel’s instructions. X8VPN supports Alipay, WeChat Pay and USDT. Payment confirmation, order status and subscription activation are separate steps, so describe each one clearly. Don’t pay again to check whether an earlier payment went through, and don’t share a full payment page publicly. For refund questions, X8VPN offers a 30-day money-back guarantee. See the refund policy for details.

Verify the fix and follow up with support

After receiving a suggestion, make one change at a time and keep a note of the original setting and result. Once the connection works again, test the app and action that first failed—not just whether the client shows as connected. If you temporarily disabled custom routing, a browser extension or background restrictions, check which settings you should restore and which should stay changed. Support can’t see what’s happening on your device, so “It still times out after this change; everything else is unchanged” is more useful than “It didn’t work.”

Report results even when they’re unexpected. For example, if another network still fails but another device works, focus the investigation on the original device. If the original route works again while other routes are unchanged, include the timing; don’t assume a local setting was the cause. Don’t mix a new, unexplained issue into the same ticket. If a new symptom appears, say how it relates to the original problem and what you changed in between so separate causes aren’t treated as one.

After resolving the issue, keep a brief personal record with only the details you need: symptoms, useful checks, final changes and how to undo them. Delete sensitive information you no longer need from temporary logs, and store any subscription configuration you still use securely. For everyday setup, refer to the Quick Start Guide; when something goes wrong, use the relevant section on this page. For a broader introduction, see the complete VPN beginner’s guide. There’s no need to keep changing settings that are already working.