The Complete Guide to VPN Troubleshooting

Can't connect at all: pinpoint where it fails

“Can't connect” can mean the client won't launch, clicking Connect does nothing, or the status stays on Connecting. These symptoms occur at different stages and don't share a single fix. Note the exact message on screen and identify whether the failure happens when opening the client, loading the configuration, establishing the connection or opening a webpage. “It doesn't work” isn't enough to distinguish an account issue from a network issue, so troubleshooting can end up back at square one.

Establish a baseline without the proxy

Disconnect in the client first, then check whether everyday local websites open. If they don't, check that the device is connected to the network, complete any required browser-based network authentication, and make sure the router is working. Public Wi-Fi authentication pages don't always open automatically. Complete the network provider's sign-in process before starting the proxy; a client showing as active doesn't mean the underlying connection is working.

Next, if possible, switch to a different network while keeping the device, client and configuration unchanged. If the connection works on the new network, the issue is more likely with the original network path than the subscription itself. If it fails on both networks, test the same account on another device you already have. This cross-check helps determine whether the issue follows the network or the device, rather than prompting repeated reinstalls.

Check that your system date, time and time zone are correct, and enable automatic time sync if needed. An incorrect clock can cause certificate validation or authentication failures that look like connection timeouts. Don't disable certificate checks to hide the problem. If you see a certificate error, save the exact message and check whether network authentication is complete and whether any unknown certificates or network filtering profiles are installed.

Distinguish configuration, permissions and route failures

Open the route list and confirm that it contains selectable routes—not an empty list, a failed import or only local configuration names. If it's empty, check the subscription update section before testing the connection. If the list looks normal, select another existing route and note its region and type. If one route fails but others work, there's usually no need to clear the entire client.

If the client immediately returns to a disconnected state after you tap Connect, check whether it reports denied network permission, a stopped service or a configuration parsing error. Mobile devices need permission to establish a VPN connection; some desktop modes require additional permissions or a companion service. Follow the permission prompts in the client. The absence of a connection icon in the system tray alone doesn't mean the route is unavailable. Managed devices may also be subject to organizational policies.

If the client stays on Connecting for a long time, stop other proxies or VPNs that are also managing network traffic, then try again. Multiple tools changing system routes, proxy settings and DNS can send requests back to the device or to a service that has already stopped. Disconnect using each tool's own controls; closing its window may leave background services running. Don't delete system network settings outright, as that could also break a working connection.

When to stop changing device settings

Change one thing at a time, reconnect and check the result, keeping the original settings available. If the issue goes away, test again under the original failing conditions so you don't mistake a temporary recovery for a confirmed fix. Check that you have permission before changing system services, managed devices or corporate networks. If you're unsure about a security software rule, don't disable protection altogether to test it; check its block log or contact your device administrator instead.

Submit a support ticket if the underlying network is working, the subscription list is complete, and the issue also occurs on other networks and devices. Include the operating system, where you got the client, the failing route, when it happened and the full error message. Describe the cross-checks you've already performed. Don't include your password or subscription link. If only one route is affected, you can use a route you've confirmed works while the issue is investigated; there's no need to stop everything.

Connected but websites won't load: check DNS and the exit route

“Connected” usually means only that the client has established some kind of connection. It doesn't guarantee that browser requests are taking the right path or that the destination website will allow access. Break the issue down into DNS resolution, connection establishment, encrypted session and website response. “Server not found,” a connection timeout, a certificate error and “access denied” point to different stages. Saving the exact error is more useful than saying the page is blank.

Check how widespread the issue is before changing DNS

Test an everyday local website and the international website you want to visit, then check whether only one domain fails. If all websites fail, check the client mode and system proxy first. If local sites work but international sites generally don't, check the proxy path and route. If only one site fails, the cause may be the site's own status, your account region or app cache. Don't reset all network settings as a first step.

Try opening the website's regular homepage in your browser, not just an old deep link saved some time ago. An expired link, a signed-out session or a browser extension blocking the request can all make a page appear unavailable. You can compare using a fresh browser session, but note that private browsing doesn't necessarily disable every extension, clear the operating system's DNS cache or change your account's region settings.

DNS translates domain names into the addresses needed to connect. If resolution fails, a connected route still won't have a valid destination to reach. However, a DNS response doesn't guarantee that the website is reachable. Conversely, if the client uses its own DNS resolver, system command results may not reflect what the app actually uses. Check which component—browser, system or client—is handling DNS.

Use commands as clues, not definitive answers

The commands below use an example domain to show basic DNS lookup and web request behavior. Windows typically supports nslookup; macOS and Linux can use it when the command is available. Whether curl uses a proxy depends on your environment variables and current traffic-routing mode. A command failing doesn't automatically mean the service is down, and a successful command doesn't replace testing the target app itself.

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

If a lookup returns no result, first check whether DNS from your current network is working, then see whether the client has its own DNS handling configured. Don't copy DNS addresses from an unfamiliar configuration or enable browser-level DNS, manually set system DNS and multiple client DNS rules all at once. More settings can make the same domain take different paths in different apps, making the problem harder to reproduce.

If DNS resolution succeeds but the webpage request times out, check the client's connection log to see whether the request matched the expected rule and used an available route. Some configurations use internal mapped addresses, so the appearance of an address alone doesn't tell you whether the result is wrong. Don't replace the HTTPS domain with its resolved address: certificates and site selection depend on the domain, and failure to reach an address doesn't prove DNS was the problem.

Clear leftover settings and identify website-side issues

If all webpages stop loading after you exit the client, check whether the system is still pointing to a local proxy service that has stopped. Reopen the original client, disconnect through its normal controls and then check the system proxy settings. If you changed DNS manually, note the current value before restoring the previously working setting. Clearing the cache may help with stale results, but it can't fix incorrect rules or an unavailable network path.

A certificate warning, regional restriction, account check and access denial are different issues. Don't ignore a browser certificate warning and enter your account details anyway. Likewise, a restriction on your account at the destination site doesn't mean all routes are unavailable. Even after changing exit routes, a site may determine availability based on account details, payment region or session history. For streaming, see the streaming region guide.

When submitting a support ticket, include the domain that failed, the browser's exact error, whether the issue affects only one app and what changed when you switched routes. Redact account details and full request parameters in screenshots. VPNText's privacy commitment is anonymous, no-logs service; troubleshooting materials should follow the same data-minimization principle. The affected domain is usually enough to describe the issue—don't upload your full browsing history or an unredacted page containing private information.

Slow speeds and peak-hour slowdowns: compare the network path

Slowdowns can occur while establishing a connection, loading the first part of a webpage, loading images, buffering video or transferring a file. First note where the delay occurs, then decide whether to change routes. A page that takes a long time to start responding but transfers normally afterward is a different issue from a consistently slow download. Browser cache, the destination server, Wi-Fi signal and network activity on other devices can all affect performance. One test isn't enough to judge an entire route.

Keep the comparison conditions consistent

First check whether your local network is also slow. Pause system updates, cloud sync or large transfers, and check that your Wi-Fi signal is stable; if possible, compare using a more reliable connection. This is only to reduce interference temporarily, not a suggestion to stop everyday tasks for good. If local and international websites are both slow, address the network connection first; simply changing exit routes usually won't fix shared bandwidth that's already in use.

When comparing routes, keep the device, app and destination the same; don't switch both route and website at once. A streaming platform may change its data requirements depending on caching or video quality, so different clips aren't always comparable. Note whether the page is slow to open or keeps buffering after playback starts, along with the network and region you were using. Results from inconsistent conditions are clues, not performance guarantees.

The latency shown in a client mainly reflects probe response time. It isn't the same as download capacity and doesn't indicate how quickly the destination website will respond. The probe and the destination may use different paths, while routing, congestion and server-side limits also affect transfers. Don't assume a route is best just because it has the smallest number in the list. How well it handles your actual tasks is the result that matters for everyday use.

Understand route types and peak-hour differences

VPNText offers IEPL dedicated lines, relayed routes and direct connections. These types describe how the network path is organized; the name alone can't predict a fixed speed at any given time. If problems occur during peak hours, compare the different route types actually available in your client and keep the one that works for your current task. Available regions and options depend on the client. For a full guide to choosing a route, see nodes and routes.

If the issue is noticeably worse during peak hours, distinguish local network congestion from changes along the international route. Switching networks at the same time while keeping the route unchanged helps determine whether the problem follows the local network. Comparing available routes on the same network helps show differences between paths. Don't keep switching automatically and record only the last result, or you won't know which route caused which behavior.

Choose a region based on what you need to do, not simply how close it is geographically. A nearby region can be a useful starting point, but actual routing may differ, and some apps require you to keep the same exit region. Avoid switching regions frequently while an AI tool is generating a task or a video account is being verified. For drawing tools, see the Midjourney region selection guide, then test with your actual task.

Don't use a plan change as a substitute for troubleshooting

Data allowance and current speed are different things. If you see buffering, check your remaining data, route status and network connection first; don't assume you need a more expensive plan. Monthly subscription data resets each month on the activation date, not on the first day of the calendar month. If you've used the allowance, check your status in the user panel before taking further action. Compare plan terms with permanent data packages on the pricing page.

If other destinations work on the same network but one service remains slow, submit a ticket with its domain, task type and the time the issue occurred. If multiple devices on different networks show similar symptoms on the same route, include those comparisons too. Describe what you experienced; there's no need to run repeated speed tests that consume data or present one test result as true for every region and time of day.

Frequent disconnects and mobile background disconnects

First determine whether the client actually disconnected or only one app lost its connection. A video stopping, chat reconnecting or webpage failing to refresh can happen while the proxy is still connected. A disconnected client status, a missing system connection icon or a service-exit alert is more likely to indicate a full disconnect. Check both the app and the client, and note their statuses so you don't mistake an expired session at the destination service for a network-wide disconnect.

Identify what triggers the disconnect

Note whether the issue consistently occurs after locking the screen, switching networks, putting the device to sleep or waking it. When a device changes its network connection, an existing session may need to be re-established and ongoing tasks may be interrupted. If reconnecting fixes it, record what you did and how the connection recovered. If it disconnects frequently while the device stays on the same network, check the route, background management and conflicts with local services.

Desktop sleep can pause some network activity, and the client status may not reflect the actual connection promptly after waking. Try disconnecting normally and reconnecting, then reopen the affected webpage or task. Don't immediately change routing parameters or reinstall system components. If the issue only happens after sleep, compare it with behavior while the device stays awake to confirm the trigger instead of classifying every intermittent failure as the same route issue.

An unstable Wi-Fi signal, renewed sign-in on a public network or a brief router reconnection can also interrupt the connection. Check whether other apps lose network access at the same time or another device shows the same issue. If all devices are affected, check the network connection first. If only one device's client exits, check that device's system management, background services and error logs.

Check background behavior by platform

On Android, check whether the system restricts the client's background activity, battery use or auto-start. Menu names vary by device, so use the settings actually available rather than looking for an identical option in screenshots from another brand. After allowing background activity, reconnect and reproduce the original screen-lock scenario. If it still fails, keep the exit message; don't grant every app every permission at once.

On iOS, check the system VPN status first and look for other configurations that may be managing network traffic. Check the system connection and client interface together; don't draw conclusions from a single status line you see after switching back to the app. Don't remove managed configurations you don't recognize. If the device is managed by an organization, contact its administrator. Get the client and access it through the user panel; iOS availability depends on your account status.

On Windows, macOS and Linux, whether the background network service keeps running matters more than whether the window is closed. Some clients leave the service running after the window closes; others disconnect. Check what your client actually does before deciding whether to enable startup at boot or restart the service. Include security software filtering and persistent processes from other proxy tools in your checks, but investigate specific conflicts rather than routinely disabling all protection.

Distinguish a brief reconnect from a persistent issue

After the network recovers, the original app session may not resume automatically. You can refresh a browser, but a persistent-connection app may need you to reopen the page or restart the app. Check whether an upload was submitted before trying again, to avoid sending it twice. If the client has recovered and other websites work, but the original task is still stuck, check the app session rather than continuing to switch regions and triggering more sign-in checks or state changes.

If disconnects are clearly associated with a particular route, or multiple devices lose connection at the same time, give support the time, route region and route type. If only one mobile device fails after the screen locks, include its background policy settings and a comparison showing that it works in the foreground. Don't share a continuous screen recording that captures private notifications. A brief description and redacted screenshots are usually enough to help support identify the trigger.

Subscription update failed: check the source and account status

A subscription is how the client gets route configuration. It's not a regular webpage or a public link to share. An update can fail before the request is sent, during account verification or when the client reads the configuration. Save the full error and distinguish between a timeout, authentication failure, empty response and parsing failure. Each requires a different response; repeatedly tapping Update usually just repeats the same failure.

Verify the source in the user panel first

Check your account and subscription status in the user panel overview, then use the panel's download or import option. Don't copy the address from old chat history, unfamiliar guides or links forwarded by someone else. VPNText doesn't require an email address: you can create an account with a username and password. If you've used different usernames, first confirm you're signed in to the account that holds the relevant service.

If you copied the subscription manually, check for extra spaces, line breaks or explanatory text, whether a chat app truncated it, or whether you copied the panel page address instead of the subscription address. Prefer the import option provided directly in the panel to reduce copying. If you need to view the address, do it on your own device. Don't paste the full link into a public checker or upload a screenshot of it to a public forum.

If an existing configuration still connects but updates fail, keep it for now instead of deleting it. The update request may use a different path from the one carrying your current connection, or it may be affected by a cache or temporary network issue. Once you've confirmed the underlying network is working, compare update results on different networks. Don't clear the client first: without a working configuration, you may lose the connection you need for recovery.

Choose what to do based on the error message

A timeout usually means the request didn't complete before the client stopped waiting, but that alone doesn't tell you whether the issue is with the server or your network connection. First check whether the user panel opens, then look for leftover system proxy settings, network sign-in requirements or conflicts with other networking tools. If the panel opens but the subscription update times out, note that difference. It helps support distinguish the path used to access the page from the one used to retrieve configuration.

If authentication fails or access is denied, return to the panel and check your account status. Don't keep changing URL parameters. If the panel offers a subscription reset option and you have a genuine risk of exposure, follow its on-screen instructions. After resetting, update your clients; the old link may no longer work. Never send anyone your password, verification details or full subscription content for troubleshooting.

A parsing error means the client couldn't read the returned content as expected. The import format may not be supported, or the request may have returned a network sign-in page or an error page instead. Use the method the panel provides for your client; don't edit configuration fields yourself. Clients don't all support the same formats, and a generic snippet from a tutorial can't replace the content generated by the panel.

Distinguish data allowance, account status and update behavior

Monthly subscription data resets each month on the activation date, not on the first day of the calendar month. Permanent data packages last until used and never expire. Updating a subscription retrieves the configuration again; it doesn't reset your data or change your account status. If the panel shows that your allowance is used up, follow the panel's instructions rather than expecting an update to the route list to restore it automatically. For billing details, check the plans page.

Get both clients and subscriptions through the user panel. On Windows, macOS, Android and Linux, sign in to get the client; iOS availability depends on your account status in the panel. Getting the client and obtaining a usable subscription are related but separate steps. Installing the software doesn't mean the current account configuration has been imported correctly. If you still need help with the initial import, read the beginner's guide to subscription links.

When submitting a support ticket, say which platform the update failed on, include the error message, whether the panel is accessible, whether the old configuration still connects and what happened after switching networks. Mention if you reset or imported the subscription again, but don't include the actual links from before or after the reset. If only one client fails while other devices update successfully, keep a working device as a comparison and make that clear to avoid reporting a client compatibility issue as an account-wide problem.

An app isn't using the proxy: check rules and mode

It's common for a browser to work while a particular app can't connect. The app may ignore system proxy settings, use its own connection or DNS resolver, or rely on a background helper process. So “system proxy enabled” doesn't prove that every app is using it. First check whether other apps work on the same device and route, then see whether the client logs a connection when the affected app makes a request.

Find out which traffic the current mode handles

System proxy settings generally affect only apps that honor them. Some command-line tools, games and programs with their own network settings may need configuration within the app, or a tunnel mode if the client supports one. Tunnel mode affects a broader range of network traffic and may require additional permissions. Check the current client's interface to see whether this mode is available and what it's called; don't assume the options match those in other software.

Rule mode determines how requests that reach the client are routed. Getting a request into the client and assigning it to the proxy are separate steps. If there's no log entry, check how traffic is being intercepted; if there is an entry but it takes the wrong path, check the rules. Don't start by deleting the entire rule set: existing rules may handle local websites, LAN devices and everyday apps, and replacing everything can create new access issues.

If the client actually offers a global proxy mode, you can use it temporarily to check whether traffic routing rules are the cause. Restore the original mode after testing rather than leaving the diagnostic setting in place. If global mode works but rule mode doesn't, note the app's relevant domains and which rules matched. If both modes fail, check the app's own settings, route region and destination service instead of only changing rule order.

Observe the app's full connection flow

An app often connects to more than one domain. Its main screen, sign-in, images, file uploads and real-time communication may all use different services, so opening the home screen doesn't prove the full workflow works. Reproduce the issue by following the actual steps until it fails, then check the connections logged at that time. Don't guess every domain from the app's brand name or paste a large rule list from the internet that makes it impossible to tell where each rule came from.

Desktop apps may send requests through background helper processes. If routing by process, check whether the main program or a helper process is actually connecting. If routing by domain, check that domain matching and DNS handling work together. App behavior may change after an update, so old rules are only clues. What the client actually logs is more reliable than guessing from an install directory or window title.

A browser proxy extension, an app's own proxy settings and the system proxy can all be active at once, sending different apps down different paths. First identify what's managing the connection, then keep only the layers you need. Closing and reopening an app can clear some old connections, but it won't change account region or server-side session state. Don't force-quit an app before saving your work, especially during an upload or content generation task.

Separate network errors from platform restrictions

If an AI tool reports that a region is unavailable, the account needs verification or access is restricted, start with the platform's own explanation. Changing your network exit route can't replace the platform's account eligibility or usage rules. An existing session may retain its previous region assessment, so verify again after changing routes rather than cycling through multiple countries. Keeping the exit region stable can reduce variables, but it doesn't guarantee that any platform will be available.

For streaming, distinguish between being unable to connect, being able to play different content and seeing a proxy-related warning in the app. Catalogs and playback eligibility may depend on your account, licensing region and platform policies; they aren't necessarily route problems. Compare the website and app on the same route and note the difference. If only a particular app fails, check its cache and network settings before resetting the system network.

Include the app name, the action that fails, the client mode, whether a matching connection is logged and what happened when you temporarily changed modes. Keep only the necessary domains and rule-match details in logs; hide query parameters and private content. If you need an exception rule, back up the original configuration and explain the intended behavior, for example, “route this app through the currently selected route.” Don't send a snippet of unknown origin and leave support to guess what it's for.

After troubleshooting, verify the full original task—including signing in, opening content and submitting actions—and confirm that local websites and LAN access still work. Seeing the app's launch screen isn't enough to confirm that traffic routing has been fixed. If a change merely moved the problem elsewhere, restore the original settings and investigate further. A clear, reversible rule is more useful for everyday use than a pile of temporary exceptions.

Device count alert and account status check

VPNText allows unlimited devices online at the same time. If the interface says something like “device limit exceeded,” don't assume the service has an undisclosed device cap or buy extra device slots to troubleshoot. First identify whether the message comes from the client, system, destination app or user panel, then save the exact wording. Similar messages from different sources may refer to account sign-in, software licensing or the destination platform's own usage rules.

First identify who issued the alert

If the alert appears on a website or in an app, check its account management and device policies. The destination service's session or device requirements are separate from VPNText's unlimited device allowance. A working network connection doesn't mean the destination account can be used on any number of devices. Don't confuse a destination app's device management page with your service account page, or mistake signing out there for disconnecting the proxy.

If the message comes from the client, confirm that you got the software from the user panel and imported the configuration for the current account. Older devices may still have other accounts, services or saved configurations. List names may also have been changed manually, so they don't prove where a configuration came from. Check in the panel first, then use its import option. Keep old configurations for reference, but explicitly select the one you're testing.

If the message comes from the system, check whether it's related to managed-device policies, network extension permissions or another running VPN. System restrictions aren't the same as plan device limits. For a work-managed computer or mobile device, ask the administrator which network configurations are allowed. Don't remove management profiles, disable security policies or change system protections to get around the alert; that can take troubleshooting beyond a safe scope.

Check service availability in the account overview

In the panel, check your username, service status and data allowance. If you've used different usernames on different devices, first confirm which account holds the service. Even without an email address, keep your username and password safe. If you forget your sign-in details, use the recovery process actually offered by the panel. Don't send your password to support or create another account instead of recovering your existing service account.

Monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets each month on the activation date. These plan differences aren't differences in device limits. If you can't connect, first check that your allowance is available and the configuration belongs to the current account. Then decide whether your usage needs to change; adding devices doesn't mean you need a different plan.

Permanent data packages are ¥158/300GB, ¥358/1000GB and ¥658/3000GB. They last until used and never expire. “Never expire” describes the package terms; it doesn't mean you can keep using it after the data is gone. Check the panel for the current billing details. If your account status doesn't match a completed order, submit the order details for support to review. Don't try to resolve it by making repeated payments.

Security and resource considerations on shared networks

Unlimited devices doesn't mean you should share your subscription publicly. Your subscription is linked to account access; keep it only on trusted devices and remove its configuration before handing a device to someone else. If you suspect it has been exposed, use the management option in the panel and update your own devices. Anonymous, no-logs privacy describes the privacy policy; it doesn't replace safeguarding account credentials or remove the risks of sharing them publicly.

Large transfers running on several devices at once share the network connection and account data allowance. This competition for resources may cause buffering or slow responses, but it doesn't mean the service has refused a device because of its count. Temporarily pause high-data tasks on other devices and see whether the current task improves. If it does, manage concurrent tasks and network resources rather than looking for a device limit that doesn't exist.

If you upgrade mid-cycle, the price difference is converted into remaining days; don't recalculate it using a different billing period. Payment methods are Alipay, WeChat Pay and USDT. Check order status in the panel. VPNText offers a 30-day no-questions-asked refund; see the refund policy for details. Keep billing questions separate from technical issues: technical troubleshooting materials don't replace order information, and order details don't explain why a route failed.

When submitting a ticket about a device alert, include the screen where it appeared, the device platform, where the current configuration came from and the panel status. Hide sensitive account details. If the issue occurs on only one device while others on the same account work, state that clearly. This helps support focus on a client or system issue instead of repeatedly checking a plan and data allowance that are already working.

Submit a support ticket and verify recovery

The goal of troubleshooting isn't to change as many settings as possible. It's to narrow down the cause and restore a connection you can understand. Once you've confirmed the underlying network works, the configuration came from the right source and the issue is reproducible, ask for help through a user panel support ticket. Don't delay because you don't know every technical term, and don't risk breaking an existing connection just to gather “complete” diagnostic details.

Describe the issue as a reproducible sequence

Start the ticket by stating the scope: unable to connect at all, only one route fails, one app won't open, or the issue happens only after locking the screen. Then give the steps that trigger it, what actually happens and what you expected. For example: connect to a particular route on the current network, open a domain and get a timeout; switch routes and it works. This gives support a clear way to reproduce the issue, unlike “the network is bad, please fix it.”

Include when it happened, the time zone, the type of network connection, your operating system and where you got the client. The time helps correlate the issue; don't invent details just to sound precise. If you aren't sure, give an approximate time. If the client shows its version, you can include it, but don't guess based on a tutorial. For managed devices, also note which system settings you can't change yourself.

List what you've tried and the result of each step, especially switching networks, devices or routes and changing the operating mode. Don't just say “I tried everything,” or mix up results from changing several things at once. If you haven't tested something, say so. Comparisons you've actually made can help rule out causes. Untested areas are useful to know too, so support can plan the next step instead of asking you to repeat checks you've already done.

Provide enough detail while protecting account information

Screenshots should show the exact error and enough of the interface to identify where it appeared. Hide passwords, subscription links, QR codes and private content. Include only the log entries related to the failed action; full logs may contain domains, request parameters or local information, so review them before uploading. Don't publish troubleshooting materials publicly and then send support the public link. Providing the necessary details directly through the panel gives you better control over what you share.

Issue: After the client connects, a specific app still can't load content
Device platform: Enter the name of the operating system you're actually using
Network connection: Enter the network type, not private access credentials
Selected route: Enter the region and type shown in the client
Triggering action: Describe the steps in the order you performed them
Error message: Keep the original text and redact sensitive information
Cross-checks: Describe what happened after changing networks, routes or devices
Current status: Say whether any routes or devices are still working

If the issue concerns an order, provide its ID and status from the panel. Don't submit your payment account password, wallet private information or transaction records unrelated to the order. If payment is complete but the status hasn't updated, describe the difference between what the panel shows and the payment result, then wait for support to check. Don't pay again, and don't combine technical logs and order details into a long, hard-to-read collection of screenshots.

If support asks you to run further checks, first understand what the action will change and how to undo it. Save your original settings before exporting configuration, changing network permissions or modifying system services. If the suggested instructions don't match your client, send a screenshot of the actual interface instead of searching for a similarly named button that does something else. Small, verifiable steps are better for finding the cause than running a long list of unfamiliar commands at once.

Verify the full task after recovery, not just the connection status

After recovery, check the client status and then retry the actual task that failed. Also confirm that local websites, everyday apps and LAN access still work. Opening a webpage is only a first check; verify sign-in, content loading and submission as needed. If the original issue occurred after locking the screen or switching networks, reproduce that trigger to make sure the connection isn't only temporarily working in the foreground.

Restore temporary test modes to your everyday settings, remove temporary exceptions you no longer need and keep a working configuration. Don't leave multiple diagnostic changes layered on top of one another, or it will be hard to tell which setting caused the next problem. For configurations that update automatically, use the panel and client tools to maintain them instead of continually editing untracked copies, which can make behavior differ across devices.

Update the ticket with what ultimately worked and any remaining issues, such as the connection recovering after switching routes while the original route still fails, or the connection staying up after changing background permissions. This helps distinguish a temporary workaround from a root-cause fix. If the issue happens again, refer to the earlier troubleshooting findings and describe what's changed; there's no need to repeat every step from scratch. Clear records help establish whether the same issue has truly returned.

For everyday setup, follow the getting started guide; see nodes and routes for route selection and the plan details for billing questions. This page provides a troubleshooting framework; it can't guarantee that every external network or destination platform issue can be fixed by changing settings on your device. Knowing when to stop making changes, keep a working connection and submit clear diagnostic details is part of the troubleshooting process.