VPN Troubleshooting Guide

How to Diagnose a Total Connection Failure

If you can't connect at all, first determine whether the client won't start connecting, reports an error during connection, or shows “connected” with no traffic. These point to different layers. Note the exact error, when it occurred and which network you were using before trying anything. Don't clear all your settings first: that removes useful comparisons between routes, rules and error logs, making it harder to tell what changed after the reset.

Check the basics: verify your connection outside the proxy

Disconnect the client and check whether your device can still open websites you normally access directly. If not, check that your Wi-Fi has internet access, your wired connection is active and the network doesn't require a sign-in. Hotel, campus and guest networks can connect you to Wi-Fi while still waiting at a captive portal. Complete the network's normal sign-in process before returning to the client; proxy settings can't replace network access.

Once basic access is restored, check that your system date, time and time zone are correct. A badly incorrect system clock can cause certificate validation or secure connection errors. Correct it through the system's normal time-sync settings; don't disable certificate checks. If several apps report certificate errors, check the device clock and network sign-in first instead of switching routes one by one.

Check your account and subscription: make sure a connection is available

Open the account dashboard and check your subscription status, data allowance and current plan. Completing payment doesn't mean the client has loaded the corresponding configuration; it may still be using an old one. Once the dashboard confirms the subscription is available, open the client's configuration list and verify that the active profile belongs to VPNLD and includes selectable routes. If the list is empty, see the subscription update section.

If you see an authentication error, first check whether it came from signing in to the dashboard or connecting to a route. Your dashboard password and the connection credentials inside a client are separate settings; don't enter your username and password into a route editor. Get the subscription from the dashboard and let the client parse it. Don't construct a subscription URL manually or replace your current profile with a configuration copied from an unverified chat message.

Check the client and route: narrow down the cause by comparison

Check whether the connect button actually enters a running state and whether system proxy or tunnel mode turns on successfully. If the system requests permission, read the app name and purpose in the prompt and confirm it was triggered by the client you're using. If the client reports insufficient permissions or a network component failed to start, restore the required permissions according to the client's instructions before testing routes. Switching regions repeatedly won't help at this stage.

Next, keep the network and client mode unchanged and reconnect using a different route. If only one route fails, note its name and the error. If all routes fail, compare results on another available network. Change one factor at a time to see whether the issue follows the route, device or network. Don't update the configuration, switch modes and restart the router all at once; even if the connection returns, you won't know why.

Troubleshooting sequence: network works → dashboard subscription is available → configuration includes routes → client components start → compare routes and networks. If a step fails, investigate that layer.

If your device has other proxy, tunnel or network-filtering tools, note their names and status, then temporarily disable overlapping features. Multiple programs changing the system proxy or routes can result in one setting overriding another even when the connection appears successful. Don't uninstall security software on a managed work device; ask your administrator whether the connection method is permitted so troubleshooting doesn't disrupt existing network policies.

If the network, account and configuration are all in order but the same error occurs on different routes, submit a support ticket. Include the client name, operating system, connection mode, network type and a redacted error excerpt. Whether another network works is more useful than simply saying “connection failed.” If the connection returns but websites still won't open, skip repeating this chapter and check request routing and DNS in the next one.

Connected but Pages Won’t Load: Request Routing and DNS Issues

A “connected” status only means that a connection component is running; it doesn't confirm that browser requests are using the intended route. Website access also depends on DNS resolution, routing rules, app proxy settings and the site's response. Start by identifying the type of error: DNS lookup failures, connection timeouts, certificate errors and website access denials are different problems and shouldn't all be blamed on route speed.

How much is affected: all traffic or one website?

Try both a website you can access directly and the site you need to reach through your current route. If all websites fail, check whether the system proxy points to a stopped client and whether the local proxy listener is running. If only the target site fails, check whether its domain appears in the client's connection log. If it doesn't, check the app's network entry point and routing rules. If it does and uses the expected route, check DNS and the site's response.

For a problem affecting one website, try a new browser window or another browser to rule out cache, extensions and site sessions. Don't start by deleting all browsing data; that signs you out of other accounts and removes conditions needed to reproduce the issue. If access is denied only after signing in, the cause may involve the website account, regional policy or risk controls. Keep the site's message and don't confuse a working connection with restored account access.

DNS: check whether the domain resolves

DNS translates domain names into network addresses. A website failing to load doesn't automatically mean there's a DNS leak, and a failed lookup doesn't automatically mean the route is down. Start by using a system tool to look up a domain you can access. Check whether it returns an address, times out or reports that the name can't be found. The example below demonstrates the lookup format only; for troubleshooting, use the affected domain, never a subscription URL or account credentials.

nslookup example.com

The server shown in lookup output usually reflects the resolver used by that tool; it may not include browser secure DNS or resolution inside a tunnel. Browsers, operating systems and clients can use different paths, so a successful command alongside a browser failure isn't necessarily a contradiction. Check whether the browser has its own resolver enabled and compare it with the client settings. Don't conclude that the device's entire DNS path is working as expected based on one lookup.

Fix in order: restore consistent settings, then address the cache

First note your current DNS settings, then restore a consistent resolver configuration as described by the client. Don't combine resolver addresses, rules and tunnel options from unrelated guides. Some configurations rely on specific routes to reach the resolver; mixing settings can cause loops or timeouts. After making changes, reconnect and check the same domain to confirm the change came from the settings, not a different test target.

On Windows, after changing DNS settings, you can use a system command to clear the local DNS cache. This only removes cached records; it won't fix a broken resolver. If the issue persists, return to the settings and network path instead of running the command repeatedly. Cache management differs by platform and system configuration. Follow the system's documentation rather than copying administrator commands from unknown sources.

ipconfig /flushdns

Don't fix certificate errors by disabling validation. For DNS troubleshooting, there's no need to submit a list of your browsing history; provide only the affected domain, error type and relevant redacted logs.

If neither the system tool nor the browser can resolve the domain, but switching networks fixes it, focus on DNS and network authentication on the original network. If the failure happens only when the client is enabled, send support your connection mode, DNS setting type and a redacted error excerpt. For advice on protecting your account and subscription link, see the online safety guide for beginners. Treat troubleshooting evidence as account-related information, too.

Slow Speeds and Peak-Hour Buffering

Slow speed is a symptom, not a single cause. Slow-loading pages, video buffering, slow downloads and lag in remote sessions can each be affected by DNS, connection setup, sustained throughput and the network path. First describe the specific task, then compare the same task under different conditions. Don't treat a one-off test result as a substitute for everyday experience or rank routes by download results from different websites.

Check your local bandwidth first

Pause large transfers, cloud sync and system updates on other devices, then see whether the problem improves. Upload congestion on a home network can affect interactive requests, too; downloads don't have to max out for things to lag. If you're on Wi-Fi, move closer to the access point and check for signal changes; use a wired connection for comparison if possible. Wireless interference, router issues and your ISP connection can all affect performance before international routing comes into play.

Keep the device, browser and target content the same, then compare a task that should be directly accessible with the client off and on. If it's still slow with the client off, focus on the local network. If it slows down only when the client is on, check the actual routing result and make sure a service that should be accessed directly isn't being sent through a remote route. Fixing the request path is more useful than blindly switching regions and avoids unnecessary network hops.

Compare routes: route type is an option, not a speed guarantee

VPNLD covers 110+ countries / 160+ routes. Choose a route based on both the target service's region and your current network. A shorter distance is a useful reference, not a guarantee; routes in nearby regions can still take different paths. Keep the task the same and compare available routes in the client, noting which ones can complete it consistently. For route types and locations, see the server locations page.

These categories help structure comparisons; they don't guarantee that any route type will be faster on every network. If a route loads websites normally but is slow on sustained large downloads, note the task and target domain. If the slowdown starts during connection setup, compare DNS and handshake logs. Don't submit only a region name: the same region may have multiple routes, and support needs to identify the exact entry in your client.

Peak hours and streaming: track timing and picture quality separately

To investigate peak-hour issues, compare the same task during a typical period and a busy one; don't change the content and time at once. Video quality that drops automatically can be caused by available sustained bandwidth, the platform's content delivery, player adaptation or local decoding load. Note whether buffering comes before the quality drop, whether only one platform is affected and whether playback still stutters at a fixed quality. That's more useful than saying “video is slow.”

If you check the player's connection or buffering information, keep a written note rather than sharing screenshots that expose your platform account, full playback URL or access credentials. For how bandwidth relates to high-resolution video bitrates, see streaming quality and route selection. Restored access doesn't necessarily mean the platform allows your account or region to watch; check its policies separately.

Don't try to fix ordinary slowdowns by raising system privileges, disabling certificate checks or changing low-level settings at random. First check whether the task is using the right route, then compare routes and networks under the same conditions. Change a setting only when the client identifies a specific parameter-related error and provides instructions; keep a record of the original value. VPNLD's quantum encryption is a security claim, not a performance guarantee across all networks.

When reporting a speed issue, describe “the task, network, route and when it started, plus how the comparison went.” Don't enter a speed figure without actually measuring it, and don't use the client's “connected” label as a substitute for recording your experience.

If the issue consistently affects one route or time of day, send support the conditions needed to reproduce it. If all routes slow down on one network but work normally on another, keep investigating the original network. Check your plan's data status, but don't assume plan tiers determine speed. For verified plan prices and data allowances, see the plans page; don't infer hidden restrictions from a slowdown.

Frequent Disconnects and Interrupted Sessions

Before troubleshooting frequent disconnections, determine whether the tunnel, app session or local network is dropping. A client exit, tunnel reconnect, browser timeout and chat app going offline may all be described as “disconnecting,” but they call for different fixes. When it happens, check whether the system network changed, then the client status, then the target app. The sequence of events is usually more useful than a screenshot taken after everything has recovered.

Track the sequence: identify what changed first

Note whether the disconnection follows locking the screen, sleep, closing the lid, switching networks or the router reconnecting. When a device switches from Wi-Fi to another network, the previous connection path may stop working and the client may need to establish a new session. That doesn't mean there's an account problem. If the client reconnects normally after the network returns but one app remains offline, reconnect the app before checking for a persistent route issue.

If other apps that don't use a proxy also lose network access when the disconnection happens, focus on the local connection first. A brief Wi-Fi signal loss, a sleeping wired interface or expired network authentication can interrupt basic connectivity. Note changes to the system network indicator and try to reproduce the issue on a stable connection. Client logs may show that the upstream network disconnected without explaining why it dropped, so don't rely on them alone.

Read the logs: separate the cause from the recovery

Open the client logs and look for errors around the time of the issue, not just a “connected” message after recovery. Check for network unreachable, connection closed, resolution failure, component exit or configuration reload. Keep the exact error text; don't rewrite it as a different diagnosis. Before sharing logs, redact addresses, credentials, account identifiers and subscription parameters unrelated to the issue.

Some clients reconnect when updating a configuration, applying rules or switching routes. If the interruption always coincides with one of these actions, check whether it's an intentional reload rather than an unexpected disconnect. Note the original settings before disabling unnecessary automatic actions. Restore sensible update settings after testing; don't leave obsolete rules or subscriptions in place just to avoid interruptions.

To compare stability, keep the device, network, app task and route the same. Check whether the session stays connected and whether it recovers automatically after an interruption. Then change only the route and compare again. Establishing a connection and keeping it stable are different measures; see how to assess VPN stability and troubleshoot it for ways to record results. This page doesn't make unmeasured uptime or disconnection-rate claims.

Desktop and network setup: avoid overlapping controls

Desktop devices may run a system proxy, tunnel tool, browser proxy extension and network filter at the same time. One program can rewrite settings while another still appears to be running, changing the path your traffic takes. Note all programs that control network traffic, keep one clear connection entry point and disable overlapping features temporarily before reproducing the issue. Don't treat permanently disabling security software as a fix.

If the system reports a network driver or service error, save your current settings and the error details, then repair the component according to the client's instructions. On managed devices, ask your administrator to confirm permissions. Before reinstalling, find out which settings will be removed and how to restore your subscription. Repeated reinstalling without keeping logs changes the situation but rarely explains a persistent issue. Get the client through the dashboard; don't use installation files from unverified sources.

Security first: don't disable certificate validation or permanently remove system protections just to stay connected. Before making a repair that requires administrator privileges, confirm where it came from and what it will affect.

If one route keeps disconnecting but the same task stays stable on another, send support the route name, time and error. If all routes disconnect on one network but work on another, check the access network first. If it happens only after a long idle period, also check app session timeouts, system sleep and client status. Don't infer a fixed service disconnection rule from idle time alone.

If the client is running normally but a video call, remote desktop or AI session drops, check whether the app has its own reconnect behavior or session limits. A website may end a long-lived connection, or an app may reuse a stale connection after a network change. Re-establish the app session and note its message before testing further. For problems that occur only after locking a mobile device, see the background section. Handle device-limit alerts using the account checks near the end of this guide.

Subscription Update Failures and Configuration Issues

A subscription update is the process of downloading and parsing a configuration; a route connection is the network connection established after that configuration is loaded. An update failure doesn't necessarily mean every route is unavailable—an older configuration may still work. And a working connection doesn't mean the subscription was updated successfully. Save the current working configuration first, then identify whether the update failed while fetching the URL, downloading, parsing or applying it.

Check the source and status in the dashboard

Sign in to the account overview, check your subscription status and data allowance, then get the current subscription URL from the dashboard. That link is an account credential; never post it in a public group, forum or online conversion tool. If the client says the URL format is invalid, check for extra spaces, line breaks, quotation marks or punctuation added by a chat app. Don't try to fix it by manually editing the URL parameters.

This example shows what a URL in the input field might look like: https://example.com/sub?token=xxxx. It isn't a VPNLD subscription URL and can't be used to get routes. Get your actual subscription from your own dashboard and import it using a method supported by your client. Don't treat the example as a working configuration or send your full, real link in a support ticket to prove that you copied it correctly.

If the dashboard shows that your plan is unavailable, your data status is abnormal or your order is incomplete, check the dashboard record instead of changing client parsing settings. Monthly subscription data resets each month on the activation date; data add-ons don't expire and remain available until used. Mid-cycle upgrades are prorated based on the remaining days. For exact prices and data allowances, see the plan details. Don't calculate the reset time based on the calendar month.

Download failed: check how the update request connects

When updating a subscription, the client may use a direct connection, the system proxy or an active route, depending on its settings. If the current route is unavailable and the update request has to use it, you can get stuck in a loop: you need an update to restore the route, but the update depends on that route. Check whether the client lets you choose how update requests connect. Follow its instructions to use a path that can currently reach the dashboard and subscription URL, then try again.

An update timeout and a server denial are different errors. For a timeout, check the basic network and request route; for a denial, verify the dashboard status and URL source. If the client downloads a sign-in page, authentication page or network notice, its parser may report a format error. First confirm that the request returned configuration data. Don't immediately blame the subscription format, and don't disable HTTPS validation.

Parsing and applying: use a format your client supports

If the download succeeds but the client says the format isn't supported, check that the import type provided by the dashboard is compatible with your client. Clients can accept different configuration structures; not every subscription URL is plain text. Recheck your platform and import method in the setup guide. To get a client, visit the downloads section in the dashboard, then sign in to get your subscription.

If new entries appear in the configuration list but your routes haven't changed, check whether the old configuration is still active. Some clients handle downloading, saving and activating as separate steps, so a successful update doesn't mean the active profile has changed. Check the routes in the new configuration, confirm it's enabled and then test the connection. Don't delete every old entry; keep a fallback until you've confirmed the new configuration works.

If a subscription update fails, keep the working configuration. Support doesn't need your full subscription URL, account password or access credentials; provide the import type and a redacted error instead.

If you've manually edited rules or routes, distinguish the original subscription from your local changes. An update may overwrite manual edits, or the client may be unable to apply an incomplete local configuration. Back up your changes and compare them with a configuration from the dashboard. If the original works, restore only the edits you need, one at a time. Don't merge an entire rule set copied from another service and then attribute every error to a VPNLD subscription issue.

Submit a support ticket if the dashboard looks normal but updates fail on different networks, or a supported format keeps failing to parse. Include your platform, client name, import type, how the update request connects and the stage at which the error occurs. Note whether the old configuration still connects and whether getting a fresh URL from the dashboard changes the result. This helps support identify an account delivery, request routing or client parsing issue; they don't need your full configuration file.

An App Won’t Use the Proxy: Traffic Routing and Connection Checks

If a browser works but an app doesn't, the difference may be whether the app reads the system proxy, which domain its requests use, how it connects or how its traffic is routed. First check that the app's normal network features work, then watch for a corresponding request in the client when you start the affected feature. Don't assume every app on the device uses the same route just because the browser works; apps can use their own networking implementations.

Identify the entry point: a system proxy doesn't capture all traffic

A system proxy is generally used by apps that follow system settings. Some apps have their own proxy options; others don't use the system proxy and need a supported tunnel mode to cover their traffic. Check the client mode and the app's documentation to see whether they're compatible. If tunnel mode requires system permission, let the client you're using request it normally. Don't use unverified scripts to change network permissions.

This table lists areas to check; it doesn't mean VPNLD supports every client option shown. Refer to your current client's interface and documentation. On Linux in particular, desktop settings, terminal environments and background services may not share settings. It's normal for a browser to use the desktop proxy while a command-line program doesn't; that alone doesn't mean the route is faulty.

Check rule matching: the feature may use a different domain

An app's home page, sign-in, media and live sessions may use different domains. If the home page loads but sign-in fails, check the request triggered by the sign-in action—not just the home page domain. If the client shows connection logs or rule matches, check whether the request was routed directly, through a proxy or by a deny rule. Keep only the necessary domains and match results; don't upload your entire browsing history.

If the app has an inclusion or exclusion list, make sure the target app isn't excluded and check whether related system services are involved in sign-in. Change only settings relevant to the app, then fully quit and reopen it so the old session doesn't keep using an existing connection. Don't permanently delete all routing rules; overly broad changes can send local services over a remote route unnecessarily.

To check whether a rule is the cause, temporarily use a broader mode if your client supports one, then restore the original mode after testing. If the app works in the broader mode but not the original one, check the matching rules. If it still fails, look at the network protocol, DNS and website restrictions. A comparison mode is a diagnostic tool, not a recommendation to route every app through the same exit long-term.

Long-lived connections and toolchains: separate network access from feature permissions

Chat, voice, meetings and AI tools may use both regular web requests and long-lived connections. A website loading doesn't mean the session channel is working. If the app hangs or disconnects, note the specific feature and exact error text. Don't change protocol settings at random without an error to justify it. If the client explicitly says a connection type isn't supported in the current mode, follow its instructions and keep other conditions unchanged.

AI tools can also depend on account region, sign-in session and the service's own policies. If a network request returns a denial page, read the service's message instead of repeatedly switching regions; frequent changes can make session conditions harder to diagnose. See the AI acceleration guide and choosing a ChatGPT route for long-term use for related scenarios. Network access optimization doesn't override the platform's account rules.

To fix app routing, identify the request entry point first, then check which rule matches. Don't include sign-in credentials, developer tool keys or full request headers in screenshots. Diagnostics usually need only the target domain, error type and routing result.

If the browser works but an app keeps failing, send support the app name, operating system, client mode, whether a connection entry appears and the steps you tested. Specify whether the failure occurs on launch, sign-in, content loading or session setup, and include what happened after restoring the original rules. This helps separate client traffic handling, routing rules and app issues instead of guessing based on “this app doesn't work.”

Mobile Background Disconnects and Lock-Screen Recovery

If the connection works in the foreground but drops after locking the screen, first check system background management and network changes. Whether the client keeps running, the system still shows a connection and the target app is paused are separate things to observe. Note the route and mode before locking, then check the status after waking the screen before changing anything. Tapping connect immediately can erase the evidence and make it hard to tell whether the client stopped in the background or the route disconnected.

Android: background activity and app scope

In system app settings, check the client's background activity and battery-management status. The setting names and locations vary by device; they may be under battery, background activity or app management. Follow your device's documentation to allow the client to perform necessary background tasks, then compare what happens after locking the screen. Change only settings related to the client; there's no need to alter every app's battery policy for one test.

Also distinguish the client interface process from the system network component. The app disappearing from the recent-apps list doesn't necessarily mean the connection stopped; seeing the interface doesn't guarantee the tunnel is working either. Check the system connection status and the client's logs after reopening it. If the system explicitly says the app was restricted or stopped, address that first, then compare routes. Don't report a background restriction as a persistent route failure.

Check the client's app inclusion and exclusion settings to make sure the target app is in the intended scope. Data-saving modes or background network restrictions can also affect the target app itself: the tunnel may still be running while the app can't maintain its session. Check permissions for both the client and the target app; allowing the client alone doesn't guarantee the issue will go away. After testing, keep only the permissions your normal use requires.

iOS: system extensions, network changes and session recovery

On iOS, the system network extension manages the connection; background tips for other platforms don't necessarily apply. First check whether the system still shows the expected connection and whether the client logs a reconnection. If another network tool is configured, make sure the active connection belongs to the client you're using. The system may have enabled a different profile even while the app interface shows an old status.

The device may switch networks while locked, and the existing session may not carry over. After waking the device, if the client has recovered but the target app still shows offline, reopen the affected feature and check whether new requests work. If only the old session fails but new requests succeed, record it as an app session recovery issue. If new requests also fail, check the tunnel, DNS and route instead of repeatedly toggling every system setting.

Confirm battery-saving behavior, permission changes after system updates and connection profile conflicts using system alerts and logs. Don't disable system security to keep a connection running or install configuration profiles from unverified sources. If you need to import the configuration again, get the subscription from your own dashboard and follow the setup guide. Before importing, note the current configuration source and any relevant settings so you can compare them.

Shared troubleshooting steps: check foreground, screen lock and wake-up

First complete the same access task in the foreground to confirm the route is working. Then lock the screen and wait for the conditions that usually trigger the issue. After waking the device, check basic network access, system connection status, client logs and the target app in that order. Don't switch routes or update the subscription during the test. This helps distinguish a system background shutdown, a network change or an app ending its own session.

If the problem occurs only on a particular Wi-Fi network, repeat the same steps on another network. If it follows the network, check its authentication or idle-connection behavior; if it follows the device, focus on system background settings and client status. Note conditions such as charging, screen lock, battery-saving mode and network changes in writing. There's no need to expose other apps, notifications or personal account details on the device.

Useful evidence for a background disconnection is the order in which statuses change: did basic network access fail first, did the client stop first, or did only the target app go offline? What happened before and after locking the screen is more useful than simply saying “it's connected again.”

If the system still shows a connection but all new requests fail, start with the web and DNS troubleshooting section. If the client exits or the network extension keeps reporting errors, send support your operating system, device manufacturer, relevant background settings and redacted logs. If an app maintains its own long-lived sessions, include its error too; don't use one app's offline status to judge the entire device's connection.

If a background issue is reproducible, you don't need to keep reinstalling the client. Keep the steps to reproduce it and the recovery method. Note whether returning to the foreground restores the connection automatically, whether you have to reconnect manually and whether the same thing happens on another network. This helps support identify a traffic-control component, system policy or route issue. If you can't reproduce it reliably, describe the occasional conditions honestly instead of claiming an unverified fixed interval.

Device Alerts, Account Checks and Support Tickets

VPNLD allows unlimited simultaneous devices. So if you see a “device limit exceeded” or similar alert, don't immediately remove devices, upgrade your plan or assume the service has a device cap. First check whether the message came from the VPNLD dashboard, client, target website or another network tool. Limits mean different things in different places. Keep the exact message and where it appeared so a target app's session limit isn't mistaken for a subscription device limit.

Device alerts: verify which configuration and limit are involved

Check whether the active client configuration belongs to VPNLD and whether it still includes subscriptions from other providers. If the interface contains multiple profiles, identify the one in use before checking your dashboard account. Don't apply an old provider's instructions, a built-in client alert or a target website's account restriction to this service. If you can't identify the source, send support the redacted message and where it appeared so they can determine which layer it belongs to.

If only one device fails while others work with the same account, compare that device's configuration, permissions, system proxy and basic network. Unlimited devices doesn't mean every device is configured automatically or every app uses the same proxy entry point. The setup guide covers the initial import; this guide helps troubleshoot each layer. Check what differs on the affected device instead of repeatedly changing your account password to fix a local network issue.

If several devices fail at the same time, check whether they share a network, route or outdated configuration. Shared conditions are often the best place to start. Also check your dashboard's data and plan status: device count and data allowance are different things. Unlimited simultaneous devices doesn't mean unlimited data. For more on data usage and everyday questions, see the VPN FAQ for beginners.

Accounts and billing: network diagnostics don't verify orders

If you can't access your account, first determine whether the failure occurs when signing in to the dashboard or connecting to a route. No email address is required; create an account with a username and password. Don't enter your account credentials on other websites while troubleshooting. For order or payment issues, check the order and plan in your own dashboard and use the support ticket portal. Don't share payment details in public comments.

VPNLD accepts Alipay / WeChat Pay / USDT and offers a 7-day no-questions-asked refund. Troubleshooting can help identify a problem, but don't change billing choices based on guesses. See the Terms of Service for refund and usage terms, and the plans page for verified prices and data allowances. A failed client connection doesn't automatically mean an order was canceled, and a restored connection doesn't prove your account status has updated.

Support ticket details: reproducible, specific and limited to what's needed

Start your ticket with the symptom and the stage at which it occurs. Then list the device platform, client name, connection mode, network type and route name. Include when it happened and your time zone, and say whether the issue is ongoing or occasional. Next, describe the comparisons you've actually tried: switching routes or networks, restoring the original rules or importing the subscription again. If you haven't run a test, say so rather than guessing.

Crop screenshots to the relevant area and cover passwords, full subscription URLs, payment credentials and other account details. Include only the log excerpts needed from around the time of the issue, not a full history of long-running logs. If support needs more detailed diagnostic information, confirm its purpose and how to redact it first. Never send session credentials to prove you're signed in, or submit your full configuration to a public online analysis tool.

Contact support through the support page or a ticket in your own dashboard. Describe the facts and what you've compared; you don't need to share your account password. Support ticket materials are account-related information, so provide only what's necessary.

If basic network access and dashboard status are normal, the configuration source is correct, and the same error persists across different routes or networks, ask support to investigate. If the issue is limited to a target website's account policy, check that platform's help documentation as well. After a fix, repeat the original task to confirm the result and restore any temporary settings changed during testing. Keep the final working configuration so you won't have to start from guesswork next time.