Understand the service and cross-border routes
Know the difference between the service, dashboard, and client
VPNCar is a subscription service for cross-border connectivity. Your purchase gives your account access to the service; it is not an installation file or a membership to any third-party website. The service covers 100+ countries and 250+ routes, with support for Windows, macOS, iOS, Android, and Linux. To use it, import your account subscription into a client. The client then handles traffic based on your selected route and operating mode. Understanding how these pieces fit together helps avoid mistaking a downloaded app for an active connection.
The marketing site explains plans, routes, and setup. The user dashboard manages your account, orders, subscription, and support tickets. The client establishes a connection on your device. Each serves a different purpose. Opening the dashboard in a browser does not mean the client is connected; seeing the client running does not prove that an app's traffic is using the selected route. When troubleshooting, check account access, subscription contents, client status, and the actual result in order instead of repeatedly refreshing different pages.
Think of routes as different lanes
An international connection may pass through your local network, an access link, a service route, and the destination website. IEPL, relay, and direct routes describe how the path is organized, not what kind of website you are visiting. Think of them as different lanes: dedicated lines may suit tasks sensitive to path consistency, relays add a routing step between access and exit, and direct routes offer another path option. Route labels can help you narrow down choices, but they cannot tell you on their own which route will be faster for a particular visit.
The region indicates where a route exits; the city can distinguish routes within that region. A destination service may determine availability based on exit region, account region, billing details, or its own policies. Choosing a Japan route does not automatically grant access to every Japanese service, and switching to a US route does not change the region associated with a third-party account. First check which regions the service supports, then test with a route that meets its requirements. This helps avoid treating an account eligibility issue as a network problem.
Quantum encryption and device-side security
VPNCar describes its security as quantum encryption. Safe use still depends on your device: get the client from the dashboard, keep your operating system up to date, and protect your account password and subscription details. Network connections and account security are separate layers of protection. Even when connected, check website domains, pay attention to browser certificate warnings, and be cautious with attachments from unknown sources. Using the service is no reason to disable device security, ignore warnings, or share your login details.
Treat your subscription details like account credentials. They let a client retrieve route settings, so don't post them publicly or share them in discussion groups. When taking screenshots, hide the subscription URL, QR code, and personal details on your order, as well as your password. To get help, start by sharing the platform, the client's error message, and the step where the problem occurred. If more information is needed, use a dashboard support ticket and avoid posting your full configuration publicly.
Define your needs before setup
Before you begin, note your main uses: everyday browsing, remote work, AI tools, or streaming. For browsing, check whether pages load fully; for work, whether sessions stay connected; for streaming, also consider content region and playback quality. Each use calls for a different test. Relying on a single speed-test button can miss the things that matter in practice, such as sign-in redirects, file uploads, and uninterrupted playback.
Unlimited simultaneous devices means there is no device-count limit on concurrent connections; it does not change your plan's data rules. Streaming, syncing, or downloading on multiple devices can all use account data. After setup, keep track of which devices are running and which apps need the service. If subscriptions, nodes, protocols, and split tunneling are new to you, start with the VPN glossary for beginners before choosing a plan.
Choose a plan to match your usage
Compare billing models first, then data allowances
A monthly subscription suits regular use; a data package suits more occasional or variable use. The key difference is how data works, not what the client can do. Monthly subscription data resets each month on the activation date. Data packages last until used and never expire. Before choosing, consider how often you'll connect and how much of your use involves browsing, video, file transfers, and background syncing. Don't choose solely by the lowest price, or treat uncertain future use as guaranteed consumption.
| Type | Price | Data | How it works |
|---|---|---|---|
| Monthly subscription | ¥9.9/month | 60GB | Resets monthly on the activation date |
| Monthly subscription | ¥18/month | 250GB | Resets monthly on the activation date |
| Monthly subscription | ¥28/month | 500GB | Resets monthly on the activation date |
| Data package | ¥158 | 300GB | Valid until used; never expires |
| Data package | ¥358 | 1000GB | Valid until used; never expires |
| Data package | ¥658 | 3000GB | Valid until used; never expires |
A monthly subscription resets on its activation date, not on the first day of the calendar month. When checking your remaining data, check the reset date shown in the dashboard too; crossing into a new calendar month does not start a new data cycle. Also, “resets monthly” does not mean unused data carries over. Use the entitlements and dates shown in the dashboard as your reference. If a date looks different from what you expected, check the order and activation status before contacting support.
Estimate data needs from real tasks
Data use varies widely by task. A text search in a browser is not the same load as hours of video playback; cloud sync, system updates, and background downloads can also use data continuously. When choosing a plan, list your regular tasks and note which need an international route and which can connect directly over your local network. This can help you pick a plan and set up split-tunneling rules later. Without reliable usage history, there is no need to invent a precise monthly data forecast.
With multiple devices, consider their combined data use. File transfers on a computer and video on a mobile device can happen at the same time. Unlimited devices does not give each device a separate data allowance. For personal or household use across several devices, first work out who is using the service, what they are doing, and whether background syncing is involved. See how simultaneous use across multiple devices works, then decide based on the actual plan rules.
Know when to upgrade or add a data package
If you upgrade a monthly subscription mid-cycle, the price difference is converted into remaining days. It does not simply subtract the old price from the new one while preserving all your original time. Before upgrading, read the entitlement changes shown in the dashboard and check the remaining time and data before confirming. If your usage has temporarily increased, don't assume how an upgrade will add data. For your specific account, rely on the calculation displayed in the dashboard; if anything is unclear, submit a support ticket first.
“Never expires” applies to the validity of a data package; it does not mean monthly subscriptions follow the same rule. Don't assume how multiple products are used up, or that a monthly subscription and a data package can always be combined. If you want to add another product to an existing plan, check the available options and entitlement details in the dashboard first. If the terms are unclear, ask support to confirm your current plan and intended use rather than guessing the order in which data will be used.
Check payment and refund details
VPNCar accepts Alipay, WeChat Pay, and USDT, and offers a 7-day no-questions-asked refund. Before paying, read the specific terms in the Terms of Service. Refund requests are handled through account support. Your payment method does not change the client import process or the data rules for your product. If paying with USDT, follow the network, currency, and amount shown on the order page. Never send funds to an address found in chat history or from an unverified source.
Once you've compared the options, revisit the plans page to check the prices and full details, then choose a product in the dashboard. The goal isn't to find one plan that suits every situation, but to match the billing model to how you use the service. Leaving room to adjust and watching your actual usage is more useful than choosing the largest allowance based only on the number of routes or devices.
Create your account and place an order
Save the dashboard link and login details
VPNCar requires no email address to create an account; just choose a username and password. Open the user dashboard from the get started for free page on our site, then follow the prompts to set your username and password. Button text is not a substitute for checking plan details. Once your account is created, review the products, orders, and availability shown in the dashboard. Creating an account and activating paid access are separate steps, so successfully opening the dashboard does not mean you already have a route you can connect to.
Choose a username you can recognize, and use a password that's different from the ones you use on other sites. Consider saving your login details in your device's password manager and bookmarking the dashboard. Since account creation does not require an email address, don't assume every account can be recovered by email. If you can't log in, first check your saved username, which site your password manager is filling in, and your keyboard input settings. Then use the recovery or support options available in the dashboard.
After creating your account, sign out and back in once to confirm your saved details work. Do this before paying so you can keep login issues separate from payment problems. If another account was used on a shared device, check the current username to avoid placing an order on an account you don't intend to keep using. Don't repeatedly create new accounts to troubleshoot; scattered orders and subscriptions make everything harder to track.
Check the product and order before checkout
In the plans section of the dashboard, check the product type, price, data allowance, and applicable rules. Pay particular attention to the difference between monthly subscriptions and data packages: the former reset each month on the activation date; the latter last until used and never expire. If the page offers an upgrade or change, read the entitlement changes first rather than treating every button as a standard renewal. When you're ready to pay, check the product summary in the current order instead of relying on what you remember from an earlier page.
Once an order is created, note its status and details that will help you find it later. If you need to open a payment app, first make sure the browser still shows the order you intended to pay for, then follow the payment page. After paying, return to the original dashboard and check the result. Don't close the order page just because the payment app says the payment succeeded. The payment status and service access still need to sync; confirm both the order status and account entitlements in the dashboard.
Handle payment issues based on the evidence
If the payment page closes or the browser session is interrupted, return to the dashboard's order list and check for pending or completed orders. Don't place the same order repeatedly just because you didn't see a success message. If your payment was charged but your entitlements haven't changed, keep the payment receipt and order details. If the status still differs after refreshing the order, explain the issue through a dashboard support ticket. “Payment charged, order still awaiting payment” is more useful than simply saying “it doesn't work.”
When paying with USDT, the selected network must match the payment page's requirements. An on-chain transfer record does not prove that every step of order processing is complete; check the order, payment status, and account entitlements too. If the amount or network was wrong, don't send additional funds to an address that hasn't been confirmed, and don't trust private messages offering to process the payment for you. Keeping the conversation within the original order and dashboard support channels ties the issue to your account.
Make account security part of your routine
Passwords, subscription URLs, and login sessions serve different purposes, so handle them separately when something goes wrong. After changing your password, check the other sessions and subscription status using the dashboard's available features; don't assume all old configurations are automatically invalidated. If you think your details have been exposed, include what was exposed, when you noticed, and the current device status in a support ticket. Follow the steps provided by support, and don't keep sending the old configuration to others for testing.
After using the dashboard on a public device, sign out and close the related pages. Don't save your password or subscription URL in a public browser. For screenshots sent to support, keep the status and error text visible while hiding login details and sensitive payment information. Only after your account is created and the order is complete should you move on to retrieving your subscription. First check that the product in the dashboard matches your choice. That way, any later client issues can be isolated to setup instead of being compounded by uncertainty about the account.
Get and protect your subscription settings
A subscription URL is not an ordinary web address
Once your account entitlements are confirmed, open the dashboard overview and look for the subscription, import, or configuration options. A subscription URL lets a client retrieve routes, rules, and other settings. It is not a webpage to browse or an account login page. Clients may require different configuration formats, so use the import option in the dashboard that matches your client rather than copying the dashboard URL from your browser's address bar.
The dashboard may offer a copyable URL, a QR code, or an option to open the client. These are different ways to transfer configuration, not different account entitlements. If this is your first time, leave the dashboard open and launch the client separately so you can check which option you used if something goes wrong. If an import link opens an old client you don't want to use, cancel and add the subscription manually from the subscription manager in your chosen client. This avoids importing the settings into the wrong app.
Check that the import actually worked
A successful import should show recognizable configuration entries, route details, and an update status. A configuration name with no route list is not enough to confirm setup is complete. Open its details or update history and look for download errors, unsupported formats, or empty contents. Some clients retain previously working data, so old routes may still appear even if an update failed. Check the current display alongside the latest update result.
When copying manually, make sure you haven't included explanatory text, leading or trailing spaces, line breaks, or symbols added by a chat app. Password and clipboard managers can also alter copied text. After pasting, verify that the URL came from the dashboard option you just used. We don't show real subscription URLs here because they are linked to individual accounts. Examples in articles cannot replace the URL in your own account, and you should never import someone else's configuration from an unknown source.
If an update fails, distinguish network issues from format issues
If the client can't download the configuration, first check whether your device's basic network can reach the dashboard. If ordinary websites won't open either, fix the local connection first. If the dashboard works but subscription retrieval fails, check whether you selected the right client format, copied the full URL, and have the correct system time. Don't disable certificate checks to get past a certificate error. Keep the error message, retrieve the configuration again through the official entry point, and decide what to do next based on the actual message.
A configuration parsing error is different from a failed route connection. Parsing errors usually occur before the client has established a route, so first check the format and client source. Connection failures happen after the route list is available; then check the route, mode, and local network. Distinguishing these stages can prevent you from repeatedly switching regions before the subscription has even loaded. For more about route types, see the route list after the configuration loads correctly.
Avoid duplicate configurations and accidental overwrites
Keeping multiple subscriptions with the same name on one device can make it hard to tell which configuration you're editing and which one is running. Give each configuration a local name that identifies the service and its purpose. After adding it, select the one you intend to use before connecting. Before deleting an old configuration, confirm the new one can update and connect. Don't delete everything just to tidy the list; a verified configuration can be a useful reference if the network later has problems.
Subscription updates may change routes and rules maintained remotely. If you need custom settings, first check whether your client supports separate overrides, rule extensions, or merging. Editing the remote subscription file directly may mean your changes are overwritten on the next update. You don't need to review every item after each update, but confirm that your usual routes are still available, the current mode hasn't changed unexpectedly, and custom settings remain in a location supported by the client.
Move your setup to another device safely
When setting up a new device, sign in to the dashboard on that device and use the matching import option. If you transfer the configuration with a local QR code, make sure no one nearby can photograph it and don't save it in a shared photo library. After importing, delete screenshots and temporary text files you no longer need, but keep useful setup notes, such as the client you used and when the configuration was last updated. Notes should describe the status, not preserve reusable credentials.
Once you've confirmed the configuration source, format, and update status, move on to network permissions for each platform. The order matters: the subscription is the input, and the client is the environment that uses it. System proxy settings, network extensions, and routing changes can't make up for incomplete input. If you're still unsure which stage is failing, say in your support ticket: “dashboard accessible, subscription can be copied, client update reports an error.” Include the checks you've already completed.
Import the client on five platforms
Shared setup and download entry points
On every platform, start in the client section of the user dashboard. After signing in, you can get the client for Windows, macOS, Android, and Linux. The iOS download entry requires an active, unexpired plan on your account. Use the client and configuration options currently shown in the dashboard; this guide does not link directly to installers. Save your work before installing and make sure the device can access its local network, so existing system issues don't interfere with connection tests.
| Platform | Setup | What to check |
|---|---|---|
| Windows | Import the subscription and choose a configuration and route | System proxy, background operation, and permission prompts |
| macOS | Import the subscription and confirm network permissions | Menu bar status, network extensions, and waking from sleep |
| iOS | Get and import through the dashboard entry for your plan | System connection permissions and network changes |
| Android | Import the configuration and confirm connection permissions | Background restrictions and conflicts with other connection tools |
| Linux | Import the configuration as described in the dashboard | Desktop proxy, environment variables, and app compatibility |
Windows: Check the active configuration first
After installing and launching the client, import the configuration from its subscription manager. Wait for the route list to load, then choose a specific route by region. If the client offers a system proxy switch, make sure another proxy tool isn't already managing the system settings before turning it on. Some apps need a restart to pick up new proxy settings, so test in a newly opened browser page rather than relying on a connection that was already open.
The first launch may show system permission or network access prompts. Check that each prompt refers to the client you just obtained before granting access. After closing the main window, check whether the app is still running in the system tray; closing the window may not disconnect it. If you want the app to start automatically with your computer, first verify a manual connection. Otherwise, an unverified configuration may reconnect automatically every time the system starts.
macOS: Separate the app window from network status
After opening the client and importing the subscription, check the menu bar or app status area to confirm the active configuration and selected route. If macOS asks to add a network configuration, enable an extension, or grant permission, follow the client's instructions in the dashboard rather than skipping the prompt and assuming the service is at fault. If browsing works but other apps are unaffected, check whether those apps use the system proxy before blaming the route.
After a Mac wakes from sleep or switches networks, an existing connection may need to be re-established. First make sure the underlying network is back, then check the client connection status. If leftover proxy settings cause pages to behave strangely after you quit the client, make sure the client has stopped before checking system network settings. Avoid changing multiple interfaces at once. For general guidance, see desktop proxy modes and split tunneling; platform permissions still depend on the operating system.
iOS: Grant system connection permission
Once your account has an unexpired plan, continue through the iOS download option shown in the dashboard. During installation and import, iOS may ask to allow a connection configuration. Verify the app's source before granting permission. Return to the client and check that the subscription details are complete, select a route, and connect. A connection indicator in system status only shows that the configuration is active; you still need to open the target service and check its route and account-region requirements.
After switching between Wi-Fi and mobile data, check the target page again, especially in apps that stay signed in for long periods. If an app still shows content for the old region, close and reopen it before assuming the exit region hasn't changed; cached content can be misleading. Don't run multiple apps that manage the device's network at the same time. If your device has a work-managed configuration, don't delete its management policies to test a personal subscription.
Android: Check background operation settings
Get and install the client from the dashboard, import the subscription, and confirm the system connection permission. The permission prompt should come from the client you're using; don't accept requests from an unfamiliar app as a routine step. After connecting, keep the client in the foreground while you test, then check whether the connection stays active when you switch apps. If it disconnects only when the screen is locked or the app is in the background, first check battery management and background restrictions.
The names of background management menus vary by device. Look for settings that control whether apps can run in the background or use the network, rather than following menu paths from another device. Keep any necessary power-saving features; you don't need to disable system management entirely. If other network-management tools are installed, stop their connections before testing VPNCar to avoid conflicts over the system connection.
Linux: Distinguish system proxies from app environments
Get the client using the method provided in the dashboard for your system, then import the configuration. A desktop environment's system proxy may not be used by terminal programs, and proxy environment variables in a terminal may not affect graphical apps. Test your browser and the command-line tools you actually use separately; success in one does not prove all processes are using the same route. If extra permissions are required, understand what they are for and never run commands from an unverified source as an administrator.
You can check in a terminal whether proxy environment variables are currently set. The command below only displays their status; it does not change system settings. If the output contains authentication details, redact them before sharing troubleshooting notes. Follow the client instructions and app documentation to decide whether to set these variables. Don't guess an address without knowing the local listening configuration. Once the platform setup is complete, continue to the next section to test connectivity; a successful import does not mean every app is ready to use.
printenv http_proxy
printenv https_proxy
printenv all_proxy
Verify your connection step by step
Establish a baseline for your local network
Before testing the connection, confirm that your device's basic network works while the client is disconnected. Make sure you can open familiar local sites and complete any network sign-in page before testing an international route. Hotel, office, and public Wi-Fi may require you to confirm access in a browser first. If you skip that step, the client may keep trying to connect without a working network. Complete the network sign-in and don't delete your subscription just because the client shows an error.
Once the basic network works, start the client and confirm that you're using the configuration you just imported and the intended route region. Note your current network, route, and mode, then open a new browser page and visit the target service. Keep other conditions unchanged during the test. If you switch Wi-Fi, update the subscription, change modes, and switch regions all at once, you won't know what made the difference—and you'll have to repeat the trial and error next time.
Distinguish exit region, access, and account results
Use the site's IP lookup page to see exit information for the current browser request. It shows the route used by that request, not what every app on your device is doing. With split tunneling, different destinations may use different routes. If the lookup request goes direct, that alone doesn't prove other international services aren't using a route. Check the current rules, client logs, and what happens in the target app together.
Once the target site opens, test the actual task too: signing in, searching, uploading, or playing content. If the home page loads but sign-in fails, the cause might be account region, a verification flow, or browser state. If a video page loads but playback fails, content rights or playback requirements may be involved. The network service provides a connection route; it doesn't determine eligibility on third-party platforms. Read the original error message instead of treating every restriction as a connection failure.
Troubleshoot based on where the error occurs
If the client can't update the subscription, go back to the previous step and check the configuration. If a route is selectable but won't connect, compare it with another route for the same purpose. If the connection comes up but no websites open in the browser, check system proxy settings, name resolution, and local network access. Start with observable symptoms rather than guessing at complex causes. Keep the exact error text, especially the difference between a connection timeout, a resolution failure, and a certificate warning.
If one app fails but the browser works, first check whether the app uses the system proxy, has an old connection open, or uses its own network settings. Restarting the app can be a useful comparison, but reinstalling the client every time something fails is not. For programs with their own network stack, check the program's proxy support. Only compare route regions and types after confirming the app's traffic is using the intended path.
Name resolution and browser cache
Name resolution turns a website name into a connection destination. If resolution fails, some sites may not open even though others using the same route work normally. Browser secure DNS settings, system resolver settings, and client rules may take different paths. Note the current settings, then check the client documentation; avoid changing multiple resolution options at once. A different exit region alone does not prove that DNS is leaking.
Browser cache, existing sign-in sessions, and a destination platform's region preferences can also affect what you see. You can compare results in a new browser session, but don't make clearing all browsing data your default step; it may sign you out of other work accounts. If the target site has a region setting, check it alongside the route region. If you still see old content after changing exits, first confirm that the request was sent again before changing routes.
Test ongoing tasks and keep useful records
Test work apps, AI tools, and streaming separately. For work, check document syncing and session stability; for AI tools, check sign-in and an actual request; for streaming, check the specific title and playback. 4K playback also depends on the platform plan, source content, device decoding, and local network, so a route name alone can't guarantee it. For more on content-region requirements, read our guide to accessing region-specific content and assess network factors separately from platform conditions.
If the problem persists, your support ticket should state the platform, current network, whether the configuration updated successfully, route region, operating mode, error text, and checks you've already tried. Don't include the full subscription URL. This helps distinguish a local network problem from a configuration issue, connection failure, or rejection by the destination service. Keep a working setup until you have a reason to change it; don't discard a verified configuration just to chase a single metric.
Everyday maintenance and renewal checks
Check account status separately from device status
You don't need to keep changing settings during everyday use, but when something goes wrong, check your account entitlements first. The remaining data, product status, and dates in the dashboard determine whether the account is eligible for use; the connection switch in the client only shows whether the device is trying to connect. A client may still display an old route list, so seeing routes does not prove your entitlements are unchanged. Once the account checks out, inspect the local configuration to avoid unnecessary reinstalls and route switching.
Monthly subscription data resets each month on the activation date. When reviewing usage, note the reset date alongside the tasks you performed instead of comparing calendar months alone. If data use suddenly increases, first check common causes such as cloud syncing, system updates, video playback, and background downloads. Then check whether other devices were active at the same time. Unlimited devices are convenient, but you still need to know what devices on the account are doing; unexplained use doesn't automatically mean a billing error.
Make updates in a traceable order
Updating the client, subscription, and operating system are separate actions. A subscription update retrieves service-managed configuration; a client update changes the app; an operating system update may affect permissions and network behavior. If something goes wrong, note recent changes and avoid changing every layer in the same round of testing. After each update, check the basic connection and your usual tasks before continuing. This gives you a clear checkpoint to return to if a problem appears.
Before updating the client, make sure you can still sign in to the dashboard and note the current configuration name and operating mode. Get the client only through the dashboard; don't download purported fixes from lookalike pages in search results. If the system asks for network permission again after the update, check the app's source and what the permission is for. Don't disable system security checks just to dismiss a prompt. Keeping the full error message and asking support is safer for long-term maintenance than installing an unverified patch.
Check the product and changes before renewing
When you want to continue using the service, check your current entitlements in the dashboard, then review the available renewal or change options in the plans section. Don't assume a new order will extend your current product, or that every product can be combined automatically. If the order page shows changes to your entitlements, read them before confirming. Monthly subscriptions and data packages follow different rules, so choose based on your current usage rather than automatically repeating your last purchase.
For a mid-cycle upgrade, the price difference is converted into remaining days. Check the time and data before and after upgrading; don't use your original subscription's end date to infer the new entitlements. If the dashboard's explanation doesn't match your expectations, stop before confirming and submit a support ticket with your current product and the result you want. Don't place multiple orders to test how the system calculates upgrades. More orders make it harder to check what happened and explain the issue.
Check your connection after a network change
After switching from home to an office network, or from Wi-Fi to another connection, an old session may need to be re-established. First confirm the basic network works, then check that the client is still using the intended configuration, and finally reopen the target app. Follow your organization's network rules; don't change managed proxy settings or network policies yourself. Keep the scope of your personal subscription separate from what your work environment allows.
After waking from sleep, a system crash, or an unexpected shutdown, proxy settings may no longer match the actual running state. For example, the client may be closed while the browser still tries to use a local proxy. First make sure no other network tools are running, then restore system settings according to the client's instructions. Don't delete every network interface or reset the whole system; that can affect other configurations and make it harder to trace the problem.
Canceling, refunds, and device cleanup
VPNCar offers a 7-day no-questions-asked refund. See the Terms of Service for the specific request requirements. Handle orders through a dashboard support ticket to keep the issue linked to your account; describe the product, order status, and what you're requesting without posting payment receipts publicly. Disconnecting the client, deleting the app, and managing an account order are separate actions. Removing the app doesn't manage the order or prove that your dashboard entitlements have changed.
Before replacing or transferring a device, disconnect, remove the local subscription, sign out of the dashboard, and delete configuration details from clipboard tools, screenshots, and temporary files. If you can't access the old device, follow the dashboard's security options and support guidance for your account and subscription. Don't assume changing your password completes every cleanup step. Keep setup notes that contain no credentials, such as the platform, mode, and usual purpose, to make it easier to set up your next device.
Split tunneling, route selection, and advanced troubleshooting
Understand traffic paths through routing modes
Split tunneling determines which requests use service routes and which use your local network. Rule mode typically handles requests according to matching conditions in the configuration, while global mode sends requests within the client's interception scope through the selected policy. “Global” depends on how the client handles traffic: apps that don't use the system proxy may be unaffected if that's the only setting enabled. Before working out an app's route, check whether its traffic enters the client instead of relying on the mode name alone.
If you're new to the service, keep the configuration logic provided in the dashboard until you've tested your usual tasks. If a destination behaves unexpectedly, temporarily using a more direct mode can help determine whether the rules are involved; restore the intended mode when you're done. Don't leave a temporary troubleshooting setting in place and forget what it does. Background updates, local services, and everyday downloads may then take an unexpected route.
Compare regions and route types by use case
Choose a route by first checking which regions the destination service supports, then considering the task's requirements for connection stability and path, and finally comparing the actual results. AI tools may depend on account eligibility and session state; remote work often needs a stable connection; streaming requires checking content rights too. IEPL, relay, and direct connections are route options to compare, not types you can assume will work best on every network. The same route may perform differently depending on your local connection.
| Symptom | Check first | How to compare |
|---|---|---|
| Only the target app fails | App proxy support, account requirements | Keep the route unchanged and compare with browser access |
| A route in one region fails | Destination region requirements, route status | Compare other routes for the same purpose |
| Connection drops after switching networks | Basic connectivity, restoring the old connection | Reconnect, then reopen the target app |
| Rule mode behaves unexpectedly | Rule matches, traffic interception scope | Change modes temporarily for diagnosis only |
Use the same task for each comparison—for example, open the same page, submit the same type of request, or play the same content. Don't treat different sites' loading behavior as direct evidence of a route difference. Don't change both the region and client configuration at once and then conclude that one route type is better. For more on filtering routes by region, type, and purpose, see how to choose a VPN route, then check the site's route list for current availability.
Custom rules and local services
Before adding rules, define the specific problem you're trying to solve—for example, local devices can no longer connect or a tool isn't using the intended route. Learn how your client orders matches and handles domain-based and address-based rules, then use its supported override mechanism. Direct edits to subscription-generated content may be lost on update. Before changing anything, keep a record of the differences without credentials. Afterward, test only the affected tasks and basic connectivity.
Local printers, LAN file sharing, and development environments often rely on local addresses or domain names. If these services stop working after enabling a traffic interception mode, check how local traffic is handled instead of forcing every request through an international route. Internal services at work may also depend on private DNS and access policies; ask the appropriate administrator. Don't upload service addresses or internal configuration to public rule-generation sites.
Narrow troubleshooting down to repeatable conditions
Advanced troubleshooting isn't about running more commands; it's about making the problem repeatable. Keep the device, basic network, configuration, and task fixed. Change one condition and note the result. If the problem occurs only on one network, check network access restrictions first. If it occurs in only one app, check that app's settings. If no device can update the subscription, check the account and subscription entry point. This order helps separate issues at different layers.
Client logs can show whether a request reached the client, which policy was selected, and where an error occurred, but logs may also contain destination domains and configuration details. Before sharing, keep only the relevant excerpts and hide subscription information and personal content. A large volume of unrelated logs is no substitute for a clear problem description. If support needs to investigate, include the steps to reproduce the issue and comparison results; that's more useful than sending a screenshot that only says “connection failed.”
Build a stable setup that works for you
Once everything works, keep your main route and a backup approach for changes in network conditions. There's no need to chase every region in the list. Different devices can use different local settings, as long as each has a clear purpose: keep work sessions stable on a work device, check content regions on a media device, and define the proxy boundary between terminal and browser on a development device. More settings mean more maintenance. Keep only changes that serve a real purpose and have been tested.
The full process is now in place: account entitlements are clear, the subscription comes from a trusted source, the client import is complete, the connection has been tested, and later changes are recorded. When a new issue comes up, return to the relevant stage instead of starting again with account creation. For common symptoms, see the FAQ; for account-specific help, use a dashboard support ticket. Network connections, third-party accounts, and local systems each have their own limits. Working within those boundaries helps you maintain a reliable setup over time.