Complete User Guide
End-to-end subscription delivery

Understand the subscription service and the complete delivery process

Start by separating your account, plan, subscription, and routes

When using a cross-border network acceleration service for the first time, the most confusing part is often not finding a button but distinguishing several similar-sounding objects. Your account identifies purchase records and subscription ownership. A plan defines data allowance, billing method, and validity. A subscription is the entry point a client uses to read route data. A route is the network path the client actually selects when connecting. These four elements are related but not interchangeable. Creating an account alone does not provide usable routes, and installing a client does not make subscription data appear automatically. After payment, you still need to open the user dashboard, retrieve the subscription, and import it into the client.

Think of the full process as a delivery checklist: choose a monthly plan or data bundle based on how often you use the service, create an account with a username and password, complete payment, and wait for the order status to appear in your account. Once the order is active, the dashboard provides subscription details and client access. After importing the subscription on the appropriate platform, the client can read the route list, rule mode, global mode, and other settings. Finally, verify the connection to confirm that the app is actually using the expected route rather than relying only on the client’s connected indicator.

Coverage and device limits

35VPN covers 120+ countries and 250+ routes, supports Windows / macOS / iOS / Android / Linux, and allows unlimited devices to be connected at the same time. “Unlimited devices” addresses concurrent connections from one account across multiple devices; it does not mean every device must use the same route or mode. A work computer can use rule mode, a media device can select a route based on content region, and a Linux host can configure a proxy only for command-line tools. Separating use cases is easier to maintain than forcing every device into one mode.

The number of routes in the network is not the same as the number visible in a client. The displayed list can be affected by subscription updates, route groups, the current plan status, and client compatibility. If you have just paid but still see an old list, update the subscription before repeatedly reinstalling the client. If one platform works while another shows an empty list, begin by checking that platform’s import method, permissions, and cache. See the global routes page for the full coverage list and route-type details.

What rule mode and global mode do

Rule mode uses the client’s matching rules to decide which requests enter the accelerated route, making it suitable for everyday use. Local services can continue over the original connection while apps that need cross-border access use subscription routes. Global mode sends more requests through the current route and is useful for temporary route checks or ruling out missed rules. Neither mode is permanently better; the right choice depends on whether the task needs fine-grained routing, not on assuming that global mode is simply faster.

If a website does not connect as expected in rule mode, temporarily switch to global mode and test again. If global mode works, the route and subscription are broadly usable, so the likely issue is rule matching or the app’s own proxy settings. If neither mode works, continue by checking subscription status, the selected route, system permissions, and the local network. This layered approach is more effective than changing routes repeatedly because only one variable changes at a time, making the results comparable.

What to prepare first

Before you begin, prepare a stable local network, a username and password you can remember, and the platform you plan to use. No email address is required; a username and password are enough to create an account. Choose your primary device first, then complete the initial import and verification there. Once the process works, expand to other platforms. Avoid testing different configurations on several devices at once, or it will be difficult to tell whether the issue comes from the account, subscription cache, client permissions, or route selection.

This manual follows a linear sequence, but users who have already completed some steps do not need to start over. Use the contents at the top to jump to the relevant section. Wherever you begin, keep a stable reference point: a confirmed working account, an updated subscription, a clearly defined connection mode, and an app for verification. Change only one of these at a time so complex issues can be broken into checkable delivery steps.

Choose a plan and understand the billing terms

Choose billing based on your usage pattern

When choosing a plan, first decide whether your data use is continuous or occasional. A monthly plan suits everyday work, development, media, and long-term use across multiple devices; its allowance resets monthly on the activation date. A data bundle suits irregular usage when you want unused data to remain available: it is consumed until depleted and never expires. The key difference is not the one-time price but whether data resets on a schedule. Comparing only the listed price without considering your usage pattern can leave you with an unsuitable allowance or too much unused data.

Monthly plans come in three tiers: ¥9.9/month includes 60GB, ¥18/month includes 250GB, and ¥28/month includes 500GB. All three tiers use the same platform coverage and device rules; the main difference is the monthly data allowance. Data resets each month on the activation date, so treat that date as the boundary of your billing cycle rather than assuming a calendar-month reset. A change in allowance around the activation date is usually a normal reset and should not be used alone to conclude that a plan ended early.

Data bundles suit non-continuous usage

Data bundles are available in three options: ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. They remain available until used and never expire. They are better suited to concentrated projects, devices that sit idle for long periods, or highly variable consumption. Because the data does not clear monthly, you do not need to turn a short-term spike into a long-term requirement when buying; you should still consider whether you need the consistent cadence of a monthly service. The plans page lists monthly plans and data bundles separately, so review them item by item on the plans page before choosing.

Do not classify your allowance simply by asking whether you watch video. For media use, resolution, viewing time, background preloading, and simultaneous devices all affect consumption. For development work, dependency downloads, mirror synchronization, and remote resources can also create substantial differences. A steadier approach is to choose a tier matching your normal intensity, watch the remaining data in the account dashboard, and adjust if needed instead of guessing and overbuying at the start.

Understand how mid-cycle upgrades work

Monthly plans support mid-cycle upgrades, with the price difference converted into remaining days. An upgrade does not simply void the original plan and recalculate everything from scratch, and the displayed remaining term should not be confused with a complete new cycle. Before upgrading, check the current plan, remaining status, target tier, and settlement result together in the dashboard, then submit only after confirming them. Upgrades address insufficient allowance; if one app suddenly consumes unusually large amounts, check background synchronization or failed retries first instead of using an upgrade to hide a configuration issue.

Payment methods are Alipay / WeChat Pay / USDT. At checkout, follow the order details shown on the page at that time, paying particular attention to the plan name, billing method, amount, and account ownership. Do not keep multiple checkout pages open or repeatedly submit while the order status has not yet been written back. If payment is complete but the dashboard still shows the old status, return to the order or overview area and refresh, keeping the current account session active, then submit the order details through the support ticket entry.

Refund promise and decision boundaries

The service offers a 14-day no-questions-asked refund. This promise lowers the cost of deciding whether a plan is suitable, but it does not replace checking the details before payment. Platform support, data allowance, route coverage, payment methods, and usage mode can all be confirmed in advance. If your main need depends on a particular region or app, review the global routes and related notes before choosing a plan; that is more efficient than testing blindly after payment.

The final plan decision comes down to three questions: Is your usage continuous? Is your approximate monthly consumption stable? Do you need unused data to remain available long term? For steady use with a predictable pattern, compare the three monthly tiers. For intermittent use where permanent data retention matters, focus on the data bundles. If you are already on a monthly plan but need more allowance, check the price difference and remaining days under the mid-cycle upgrade rules. Choose the plan before creating an account and paying so every later step has a clear purpose.

Create an account and order, then verify payment status

Create an account that is easy to maintain

35VPN requires no email address for registration; a username and password are enough. The username identifies the account, while the password protects orders, subscriptions, and support tickets. Choose a username that will not be confused with accounts on other services and use a unique password. Because no email address is required, store the credentials carefully yourself. If you use several browsers or devices, complete registration, login, and payment on your primary device first, then expand gradually so different usernames are not mistaken for one account.

After submitting the registration form, first confirm that you have reached the user dashboard instead of clicking again immediately. The dashboard’s account overview, plans, client, and orders areas each have a different role: the overview confirms service status, the plans area handles billing choices, the client area provides installation access, and the orders area confirms payment. Once you know where each function lives, you can return directly to the right area instead of guessing across multiple pages.

Run four checks before ordering

In the plans area, confirm the signed-in username first, then verify whether you are choosing a monthly plan or a data bundle. For monthly plans, check the target tier: ¥9.9/month includes 60GB, ¥18/month includes 250GB, and ¥28/month includes 500GB. For data bundles, verify ¥158/300GB, ¥358/1000GB, or ¥658/3000GB. Finally, confirm which payment method you intend to use: Alipay / WeChat Pay / USDT. Proceed only when the account, billing method, allowance, and payment entry all match.

Keeping several pages in checkout at once makes it easy to lose track. The safer approach is to keep only one active order page, complete payment, and return to the same account to check the status. If you change plans, exit the old checkout flow first and select the new option from the plans area. Do not operate on two orders simultaneously. Order records are used not only to verify payment but also to determine subscription ownership. If the account looks wrong, stop and confirm the username in the login area before paying.

What to do when the status has not updated

If the overview still shows the old status after payment, refresh the dashboard and reopen the orders area. Confirm that the signed-in username matches the one used for the order, then check whether the order is marked complete. Do not immediately uninstall the client or delete the old subscription. Payment status belongs to the account and order layer; client changes will not make the order update faster and may remove a configuration that still works. Keeping each issue in its proper layer is the foundation of the troubleshooting system.

If the order is complete but the client still does not show the new allowance or routes, the payment stage is broadly finished and the next step is to update the subscription. Updating the subscription synchronizes the latest delivery from the account to the local client; it is not a new purchase. Conversely, updating a subscription repeatedly will not help if the order itself is still incomplete. Follow the sequence “order first, subscription second, client third” to keep the stages separate.

Account security and sign-out habits

After using the dashboard on a shared device, sign out instead of leaving the browser logged in. Subscription data is part of the account’s delivery and should not be copied into uncontrolled public environments. Do not place the complete subscription URL in screenshots, public documentation, or code repositories. To use it on another personal device, retrieve it again from the dashboard rather than forwarding it through public chat history. This makes future updates easier and reduces the amount of old data left scattered around.

If you suspect your password has been exposed, change the account credentials first, then check the current plan and order records, and update the subscription on each device. Renaming a client or deleting a route does not change account access permissions. Handle the account, subscription, and route layers separately: the account manages identity, the subscription manages delivery, and the route manages connectivity. With the layers clear, you can recover in order instead of reinstalling every device at once.

What to include in a support ticket

When you need help, submit the issue through the support ticket entry in the dashboard. Include the current username, the step you were on, the platform, selected mode, whether the order or subscription has updated, and the complete error text shown on screen. Do not submit your password or the complete subscription URL. A useful report answers “Where did it happen, what did you expect, what happened instead, and what have you tried?” so support can identify the account, order, or client layer without repeatedly asking for basic details.

After creating an account and paying, there is no need to configure every platform immediately. Move to the next chapter on your primary device, retrieve the subscription, and confirm that the client can read the route list. Once the first device completes the full loop, other platforms become an import problem for the same subscription in different clients, which significantly reduces complexity.

Get your subscription and prepare the client

Retrieve subscription data from the dashboard

Once the order is active, open the overview or client area in the user dashboard to retrieve the subscription data. Marketing pages do not provide public direct links to static installers or real subscription URLs; both clients and subscriptions are delivered through the dashboard. This keeps the download entry, account status, and plan ownership aligned. If you are not signed in, use the button on this page to enter the dashboard. If you are already signed in, open the client download area and choose the entry for your current platform.

Think of a subscription as a configuration list that can change over time. It may include route groups, connection parameters, and rules, so the local list created by the first import should not be treated as permanent. When routes or plan status change, have the client read the subscription again. As long as the account’s subscription remains valid, you usually do not need to remove the entire client. Use its update-subscription function first to preserve confirmed permissions and basic settings.

Distinguish subscription imports from manual entries

A subscription import reads server-maintained routes and groups in one operation, then synchronizes changes through later updates. Manual entry adds connection details one by one, costs more to maintain, and can leave you using old values after parameters change. 35VPN’s standard workflow is based on subscription imports. A client may call the feature “Add configuration,” “Import subscription,” “Import from link,” or something similar; the underlying action is the same: let the client read the subscription data delivered to your account.

When copying a subscription, make sure the content is complete and do not add spaces, line breaks, or explanatory text. If the client says the format cannot be recognized, return to the dashboard and copy it again instead of taking only part of it. To illustrate the format, examples in this guide use an obviously fake value, such as:

subscription: https://example.com/sub?token=YOUR_TOKEN
mode: rule
group: auto
update: manual

The address above illustrates field structure only and cannot be used for a real connection. The actual subscription must be retrieved from the user dashboard. Any real subscription data appearing in public guides, screenshots, or code repositories may fall out of your control. When troubleshooting, share only the error text and the necessary interface details; do not paste the complete content.

Confirm the platform before downloading a client

The service supports Windows / macOS / iOS / Android / Linux. Similar platform names do not mean the installation process is the same. macOS and iOS are both Apple environments, but their permission flows, import methods, and background behavior differ. Windows and Linux can both support desktop workflows, while Linux more commonly uses a tray interface, desktop proxy, or command-line process. Choose the client entry matching your current system from the dashboard; do not try to run an installer intended for another platform.

Establish a clear configuration naming scheme

After a successful import, give the configuration an easy-to-recognize name, such as one that distinguishes the brand and purpose, instead of keeping an unreadable default string. When several configurations exist, identify which one is the current 35VPN subscription and which are historical. Before deleting anything, confirm the source of the current connection so you do not remove a configuration that is still working. If the client shows update history or a last-updated time, use it as supporting evidence that the subscription refreshed successfully, but rely on the route list and actual connection result for the final check.

If the subscription list is empty, first confirm that the account plan is valid, then copy the subscription again and trigger an update. If the list exists but connections fail, investigate routes and permissions. If only one app fails, investigate rules or the app’s proxy settings. These three symptoms belong to different layers. Recording “no list,” “route cannot connect,” and “single-app failure” separately can significantly reduce unproductive actions.

Final checks before importing

Before starting the platform-specific steps, confirm four things: the order is active, the subscription comes from the current account, the client comes from the dashboard, and the device’s local network can access common services normally. The last item establishes a baseline. If the local network is already unstable, not every post-connection symptom can be blamed on the route. Once ready, import the subscription through the appropriate platform branch in the next chapter.

Complete one platform before moving to the next device. Unlimited concurrent devices allow multi-device use, but configuration should still proceed in sequence. After the first device is verified, use it as a reference. Comparing the same account, subscription, and a similar route on another device quickly shows whether the difference lies in platform permissions or the subscription itself.

Five-platform client import and permissions

Windows: import first, then enable the system proxy

On Windows, sign in to the user dashboard and open the client download area to get the appropriate client. After installation, open it and add the subscription from the configuration or subscription-management entry. Paste the content copied from the dashboard in full and confirm. Once the route list appears, choose a route suited to your current purpose and enable rule mode. Some clients also require the system proxy switch to be enabled. Browser and standard desktop traffic will follow the rules only when both the route selection and system proxy are correctly enabled.

If the client says it is connected but the browser behaves the same, check whether the system proxy is enabled, then see whether the browser has its own proxy or extension. An independent setting may override the system configuration. If only terminal tools fail, check whether the tool reads the system proxy. Some command-line programs need a proxy specified in their own configuration or the current terminal session rather than automatically following desktop settings. For troubleshooting, verify the basic connection in a standard browser before handling specialized apps.

macOS: pay attention to system network authorization

The macOS import process also starts in the user dashboard. Get the client, install it, and allow the necessary permissions when prompted on first launch. Then open subscription management, paste the subscription, and update the list. After selecting a route and rule mode, complete any prompt to add a network configuration or modify network settings. If you deny it, the client interface may remain usable, but system traffic will not enter the route as expected.

After connecting, check the current status from the menu bar or the client’s main window. If the app loses its connection after a network change, disconnect and reconnect the current route so the client can bind to the new local network again. When several tools that modify proxy or network settings run at once on macOS, they may overwrite one another. Temporarily close similar tools and verify with only the current client, then restore other software one item at a time.

iOS: allow system configuration after importing

Get the iOS client entry from the user dashboard. Open the appropriate client and use the subscription import method provided in the dashboard to add the configuration. On first activation, iOS will ask for permission to add a network configuration. This system step allows the client to handle the relevant network requests. After granting permission, return to the client, update the subscription, choose a route, and connect. If the system already shows a connection while the target app still uses an old session, fully close the app and reopen it.

After a network change, iOS may retain an old connection state. For example, the client may still show the original route after switching networks. Disconnect and reconnect manually rather than relying only on the status-bar icon. If the subscription update fails, first confirm that the dashboard opens normally, then return to the client and try again. If the dashboard is also unreachable, restore the local network before changing the subscription further.

Android: manage background operation and per-app routing

On Android, a successful import is only part of the job; background operation matters too. Get the client through the user dashboard, install it, import the subscription, choose a route and rule mode, and allow the system to establish the network connection. Then check battery management and background restrictions so the client can keep the necessary process running when the screen is locked or you switch apps. Settings vary by device, but the test is the same: the client should not be stopped immediately after leaving the foreground.

If only selected apps should use the route, configure per-app routing when the client supports it. Be clear whether the setting means “only selected apps use it” or “selected apps do not use it”; the meanings are opposite. After changing it, test one target app before adding many others. For more on Android background operation, per-app routing, and battery policies, see Android VPN picks and hands-on background testing.

Linux: distinguish desktop and terminal proxies

On Linux, get the suitable client or import method from the user dashboard, then choose a desktop or command-line workflow based on your environment. A desktop environment can usually route browser traffic through the client tray and system network settings. Terminal programs may instead need environment variables, their own configuration, or a local proxy entry. After importing the subscription, update the route list, choose a route, start the client process, and verify with an app that clearly supports the system proxy.

If a desktop browser works but a terminal tool fails, the subscription and route are probably usable; the issue is how the terminal app reads proxy settings. Check the project documentation for its proxy options, or set the local entry provided by the client for the current terminal session. Do not write the real subscription URL directly into project configuration. Examples should reference only the local proxy name or environment variable provided by the client, never account delivery data committed to a repository.

Keep configurations consistent across devices

Support for all five platforms does not mean they must be configured at once. Keep one verified device as your baseline, then retrieve the subscription again from the same account on each new device. If the new device shows a different list, update the subscriptions separately first. If the lists match but connection behavior differs, compare the mode, route, system permissions, and app settings. Do not migrate by copying the entire client directory; platform permissions, caches, and local paths are not interchangeable.

Unlimited concurrent devices suit personal multi-device use and household sharing, but each device still needs its own client permissions and subscription updates. For device-count calculations, household-use boundaries, and configuration roles, read the complete guide to VPN multi-device sharing. Multi-device use is genuinely maintainable only when every device can independently complete the chain: “update subscription—choose a route—enable a mode—verify the exit.”

Connect to a route and verify that it works

Choose a region first, then match the purpose

After importing the subscription, do not treat route names as a speed ranking. Narrow the choices by the target service’s region and your use case, then choose a stable route from that area. For region-specific content, the exit region matters more than other labels in the name. For ordinary browsing, development tools, or remote collaboration, prioritize connection continuity. See Global routes for the available regions and route types.

Route types describe how network paths are organized; they do not produce identical results on every local network. IEPL, transit, and direct routes differ in path, suitable use cases, and sensitivity to local network conditions. When troubleshooting, try different types within the same region and observe whether the result changes. Do not test a new region, mode, and app at the same time; even if the issue disappears, you will not know which change helped.

A connected indicator does not prove the app is using the route

The client’s connected indicator only shows that the local process has attempted to establish a route. You still need to verify from the app side. First open a browser without its own proxy settings and visit a network-check page, confirming that the exit information matches the selected region. Then open the target app and perform the real task. If the browser exit is correct but the target app fails, the cause is more likely app cache, an independent proxy, rule matching, or an old session than the account or subscription.

35VPN provides a network check page for confirming your current exit and basic network information. Before testing, disable browser extensions that may override the system proxy and avoid running other network tools at the same time. Restore your normal configuration after verification. This produces a result closer to the client’s actual behavior without interference from layered settings.

Compare rule mode with global mode

When the target app cannot connect, keep the route unchanged and temporarily switch from rule mode to global mode. If global mode works, the route is usable; next check whether the rule matches, whether the app uses special domains, or whether it has its own connection method. If global mode also fails, keep the mode unchanged and try another route in the same region. This single-variable test separates mode issues from route issues.

After troubleshooting, return to the mode suited to everyday use. Global mode is useful for verification but may send local traffic that does not need acceleration through the current route. Rule mode is better for long-term use and reduces unnecessary path changes. The goal is not maximum coverage, but sending the required apps along the right path while leaving other connections to work naturally.

Handle cache, sessions, and DNS resolution

After switching routes, an app may retain an old connection. Close and reopen relevant browser tabs, fully quit and restart desktop apps, and re-establish long-lived connections in development tools. AI coding tools, terminal assistants, and collaboration services depend especially on persistent sessions, so a brief interruption during a route change can make an old task lose context. See hands-on testing of long-connection stability for Cursor / Copilot for related choices and configuration.

If DNS resolution still reflects the old network, disconnect the client, confirm that the local network works, then reconnect the route and start the app again. Do not clear large amounts of system configuration before confirming the basic connection. Resolution, app cache, and route issues can all look like a page failing to open, but they require different comparisons: switching apps tests the app layer, switching modes tests the rules layer, and trying another route in the same region tests the route layer.

Keep a reproducible verification record

An effective verification record should note the platform, client status, current mode, route region, target app, and result. Do not record sensitive subscription data. If the issue appears only on a particular network, note the difference before and after switching networks. Reproducible records make later comparisons possible: when the same setup fails again, you can identify which conditions changed instead of starting over at account creation.

A successful connection should meet all three conditions: the subscription list is normal, the client route shows as connected, and the target app completes a real task through the expected exit. Any one condition alone is not enough to finish checking. After the first complete loop, keep the working configuration as a baseline before optimizing routes, split routing, or multi-device use.

Daily maintenance, upgrades, and renewals

Make subscription updates a regular task

The route list in a client is a local cache of the subscription and should not be assumed to match the dashboard forever. When route names, groups, or connectivity change, update the subscription first. After the update, choose a route again and reconnect if necessary. Deleting the configuration and importing it again is a later option because deletion also removes local selections, rule state, and some client preferences.

In a multi-device setup, each device maintains its own local cache. Updating the subscription on Windows does not automatically perform the same action on macOS, iOS, Android, or Linux. If lists differ between devices, update each one separately rather than assuming the account received different content. Clear configuration names and device-by-device verification help prevent historical and current subscriptions from being mixed.

Watch your data usage instead of guessing

Monthly-plan data resets each month on the activation date, so interpret the remaining allowance together with that date in the dashboard. App downloads, cloud synchronization, media preloading, system updates, and failed retries can all consume data continuously. If usage is far above expectations, check background tasks and global-mode usage before considering an upgrade. The number of web pages visited cannot accurately predict data use because tasks vary greatly in size.

Data bundles remain available until used and never expire, so maintenance focuses on the remaining allowance and actual usage pattern rather than waiting for a reset. Both monthly plans and data bundles should avoid sending background tasks that do not need acceleration through the route for long periods. Rule mode can separate local services from target apps. Android per-app routing, independent desktop-app proxies, and Linux environment settings can narrow the scope further.

Rule out abnormal usage before upgrading

For a mid-cycle monthly-plan upgrade, the price difference is converted into remaining days. Before submitting one, confirm that the low allowance comes from normal use rather than synchronization, failed retries, or global-mode settings on one device. If the abnormal task is still running, an upgrade only adds temporary capacity and does not stop the ongoing consumption. Stop the source first, then check the target tier and settlement result in the plans area.

When an upgrade is needed, use the plans area of the current account instead of creating another account. A second account scatters orders, subscriptions, and remaining status, making future maintenance difficult. After upgrading, confirm the plan change in the dashboard and then update the subscription on each device. If the dashboard has changed but the client has not, the issue is local subscription caching. If the dashboard itself has not changed, return to the order and checkout status.

Keep the account and order history continuous when renewing

Before renewing, confirm that you are still signed in to the original account and check the current plan and activation date. After payment, review the order status, plan status, and subscription update in sequence; do not skip the account layer and change the client directly. Keeping one account throughout centralizes orders, support tickets, and subscription data and makes past actions easier to verify. Payment methods remain Alipay / WeChat Pay / USDT, as shown at checkout.

If you plan to change tiers, first distinguish renewing the current plan from upgrading mid-cycle. Renewal continues the existing choice, while an upgrade addresses allowance needs during the current cycle; they serve different purposes in the account. Read the checkout summary before submitting and confirm that the amount, plan, and account match. For a consolidated explanation of all plans, return to the plans page.

Prioritize stability when maintaining the client

When the client works normally, there is no need to reinstall it whenever the interface changes. Prioritize subscription updates, system permissions, and the current mode. If a system update causes connection problems, check whether the original network permissions are still valid, then restart the client and device. Re-fetch the client from the dashboard only when the installation itself is confirmed damaged. Do not look for replacement installers on unknown pages; they may not be compatible with the current subscription delivery method.

Before uninstalling, note the current configuration name, mode, and verified route, but do not record the complete subscription URL. After reinstalling, retrieve the subscription again from the dashboard, import it, and restore the mode and route from your notes. This recovery process is more reliable than copying an old program directory because it avoids damaged caches and outdated local files.

Periodically organize devices and configurations

Unlimited concurrent devices does not mean configurations can accumulate without management. Sign out on devices you no longer use, and delete obsolete subscriptions in old clients after confirming they are no longer needed. Sign out promptly on shared devices, and avoid storing account credentials or subscription data in public sync folders even on personal devices. Device count is unlimited, but the account holder still maintains the security boundary.

Daily maintenance can be reduced to a short routine: check the account plan status, review remaining data and the activation date, update the subscription, then verify once with a commonly used app. Keep a known-working device as a reference when something goes wrong. With clear status at the account, subscription, client, and route layers, renewals, upgrades, and migration across devices do not become a fresh investigation.

Advanced routing and systematic troubleshooting

Build a layered troubleshooting model first

Check complex issues layer by layer: local network, account and orders, subscription configuration, client permissions, route connectivity, rule matching, and app sessions. The local network provides basic access. Account and orders determine whether service is active. The subscription delivers route data to the device. Client permissions determine whether system requests can enter the proxy. The route handles transmission, rules decide which requests use it, and the app session may retain an old connection. Any layer can appear as “the page will not open,” but each requires a different fix.

Start with the earliest and easiest layer to verify. Disconnect the client and confirm that the local network works. Then sign in to the dashboard to check the plan and order, update the subscription, and inspect the list. Choose a route in a known region and use global mode for a basic test. Once the basic connection works, restore rule mode and handle the individual app. This order prevents pointless rule changes when the account is inactive and avoids repaying when the route is already working.

Principles for designing split routing

The goal of rule mode is not to accumulate as many rules as possible, but to make the path explainable. Start by grouping rules by use case: keep local services on the original connection, send cross-border apps through automatic or specified routes, place region-specific content in the relevant regional group, and choose a stable group for development tools that need long connections. Every rule should answer what it matches, which group it uses, and where unmatched requests fall back.

After changing rules, verify with one clearly defined app instead of adding many domains at once. If an app uses several service domains, adding only the main domain may send login, resource loading, and API requests along different paths. Watch the client’s connection log to see the actual requests, then complete the rules required by that service. If the log includes account identifiers or sensitive parameters, redact them before sharing.

mode: rule
rules:
  - local-service: direct
  - work-tools: auto
  - media-region: selected-region
fallback: auto

This example illustrates rule structure only. It does not follow real client syntax and contains no real routes or subscription data. Use the client’s graphical interface and built-in subscription rules whenever possible. Edit manually only when you clearly understand the client format, and keep a recoverable local copy before making changes.

Handle long connections and ongoing tasks

Development tools, remote collaboration, and real-time content depend on persistent connections. For these tasks, avoid frequently switching routes or modes because each change forces existing sessions to reconnect. Select a route, verify the connection, and then start the task. If it stops, check whether the client reconnected, whether the local network changed, and whether the app retained the old session. Do not immediately switch through multiple regions; that makes the problem difficult to reproduce.

For command-line tools, a working browser does not mean the terminal inherits the same settings automatically. Check the app documentation for its proxy method and point it to the local entry provided by the client. Do not put the real subscription URL in environment configuration. The subscription delivers routes to the client; the app only needs to connect to the local client. Keeping these layers separate prevents project files from carrying account data.

How to assess a problem affecting only some websites

When most apps work and only one website fails, the account and subscription are usually not the first suspects. Fully quit and reopen the target app, then switch to global mode while keeping the route unchanged. If global mode works, inspect rule matching. If it still fails, test another route in the same region. If the same website behaves differently on two devices, compare their client modes, resolution methods, and app extensions.

Region-specific content may also depend on account region, app cache, or a previous session rather than the exit alone. After confirming the route exit, establish a new app session and check whether the content changes. Do not attribute every regional difference to the route. This guide can confirm whether the network path is correct, but the relevant platform controls its own account and content rules.

How to locate frequent disconnections

First note whether the device changed networks, entered sleep, or was restricted from running in the background when the interruption occurred. On Android, focus on battery policies. On iOS, observe reconnection after network changes. On Windows and macOS, check whether another tool overrode the system proxy. On Linux, check that the client process is still running. If interruptions coincide with device state changes, address platform permissions first. If several devices fail on the same local network, check the local network first.

If only the current route disconnects, keep every other setting unchanged and choose another route in the same region. If several routes behave the same way, switch the route type or local network. This sequence separates an individual route, a regional path, and the local network. When submitting a support ticket, include the platform, region, route type, mode, and reproduction steps, but not the complete subscription data.

What to do when a subscription will not update

First confirm that the dashboard opens and the plan is active. If the dashboard works, copy the subscription again and check for extra spaces or an old configuration in the client. If the dashboard cannot open, disconnect the client and test the local network before reconnecting. Do not create new accounts or orders repeatedly when a subscription update fails; that will not fix a local import format and will make the account relationships more complicated.

If the client reports a format error, delete the failed input and retrieve the complete content again from the dashboard. If it reports a connection failure while still showing the route list, subscription parsing has completed; move on to route and permission checks. If the list is empty, continue checking plan status, whether the subscription belongs to the current account, and whether the update actually completed. The error symptom itself is a diagnostic clue.

When to reset and when to submit a ticket

Consider resetting the client only after confirming that the account is active, the subscription is complete, platform permissions are correct, and multiple routes and modes have been compared. Before resetting, record the configuration name, mode, and symptoms, then import again from the dashboard. Resetting is not a first step because it removes useful evidence. If the issue concerns an order, plan activation, or account access, submit a support ticket instead of continuing to modify the client.

A high-quality support ticket should state the platform, current step, mode, route region, error text, whether the dashboard opens, whether the subscription list exists, and the results of comparison tests. You may attach a redacted screenshot, but do not include your password or the complete subscription URL. The closer the description is to reproducible steps, the more directly support can address the right layer.

Keep advanced configurations recoverable

The baseline for advanced use is always being able to return to a known-working state. Before changing rules, app proxies, or system permissions, note the original settings. Change one variable at a time, verify immediately, and restore it if the result is unexpected. Do not leave temporary test settings on every device indefinitely. A stable baseline can be one verified device, one current subscription, rule mode, and one commonly used route.

After this chapter, the workflow is complete: choose a plan, create an account, verify payment, retrieve the subscription, import it on Windows / macOS / iOS / Android / Linux, verify routes, manage data, handle upgrades and renewals, and troubleshoot by layer. When an issue appears later, you do not need to reread everything. Identify the layer first, then use the contents to jump to the relevant section. For basic terms such as subscriptions, routes, protocols, and split routing, continue with the VPN beginner glossary.