Complete Setup Guide

Before touching any configuration, separate three things: the client installed on your device, the routes the service provides, and the subscription that connects the two. Most "it won't connect" problems don't come from a broken route — they come from one of these three layers being out of alignment. This chapter sets out what each layer does, so every operation in the chapters that follow has somewhere to land.

1.1 Three layers: client, route, subscription

The client is the program installed on Windows, macOS, iOS, Android or Linux that builds an encrypted tunnel between your device and a route. It doesn't produce connectivity itself; it just connects according to its configuration. Every route you see in the client list corresponds to a real exit on the service side.

A route is an exit. Pick a Hong Kong exit and the target service sees a visit from Hong Kong; pick a US exit and it sees the US. The figure of 90+ countries / 160+ routes describes the range of available exits. By access method, routes fall into three types: IEPL dedicated lines, relays and direct connections. Dedicated lines use a separate channel and hold up better at peak hours; relays pass through one internal hop and cover more ground; direct connections attach locally and have the lowest latency. None of the three is absolutely better — it depends on what you're reaching.

The subscription is the configuration file that ties the first two layers together. It isn't an installer package but a list: which routes exist, which protocol each one uses, what encryption, what port. Only after reading that list does the client know where to connect and how.

Once you understand the three layers, troubleshooting has an order: first confirm the client starts properly, then confirm the subscription can be fetched, and only then suspect the route. Doing it the other way round — swapping routes immediately — usually doesn't solve anything and just stirs more variables into the mix.

1.2 Route quality matters more than route count

160+ routes is a coverage figure, not a quality promise. What actually determines the experience is three things: whether the exit has enough bandwidth, whether the routing takes a detour, and whether there's headroom left at peak hours. A route that goes halfway around the world can feel worse in practice than a nearby relay, even if it's labelled direct.

When choosing, work backwards from the target service: for AI tools, favour routes with stable latency that don't drop long-lived connections; for streaming, favour routes with plenty of bandwidth; for gaming, favour routes that are physically close with low packet loss. Chapter 9 gives concrete recommendations by scenario.

Routes also change. When the service adds exits or adjusts routing, new routes appear in the subscription. So a subscription isn't something you import once and forget — it needs updating periodically. Chapter 8 covers when to update and what to watch out for.

1.3 Subscription versus one-off purchase

This service is billed monthly: ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. The only difference between the three tiers is the monthly data allowance; route coverage, supported platforms, device count and the refund promise are identical. Data resets monthly on your activation date, not on the 1st of the calendar month — activate on the 15th and it resets on the 15th every month after that.

If your monthly data isn't enough, there are also data packs: ¥158/300GB, ¥358/1000GB and ¥658/3000GB, used until exhausted, never expiring. Packs don't reset monthly, which suits occasional high-volume demand.

The advantage of a subscription is that you can stop at any time without committing a large sum up front. Combined with the 60-day no-questions-asked refund, the cost of trying is very low — chapter 2 goes into this in more detail.

1.4 The factual boundaries of this service

Supported platforms: Windows / macOS / iOS / Android / Linux. Concurrent devices are unlimited — phone, tablet and computer can all be connected at once. Payment is by Alipay / WeChat Pay / USDT. Signup needs no email address; a username and password are enough.

Traffic is protected with bank-grade encryption, and both panel sign-in and subscription fetches go over encrypted channels. To be clear: encryption addresses transport security, which isn't the same as anonymity — account information and payment records are retained the way a normal commercial service retains them, and the privacy policy is the authoritative scope. Saying this up front saves more trouble than explaining it afterwards.

There are six numbers on the plans page: three monthly subscriptions and three data packs. They serve completely different purposes, and comparing them side by side is an easy way to pick wrong. This chapter separates the two categories first, then gives concrete choices for three typical situations.

2.1 The three monthly tiers differ only in data

¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. There are no hidden differences between tiers — no speed caps on the cheaper one, no reduced route list. All 90+ countries / 160+ routes are available, all five platforms (Windows / macOS / iOS / Android / Linux) are supported, concurrent devices are unlimited, and the refund promise is the same.

So the choice comes down to one thing: roughly how much data you use in a month.

The "typical usage" column is a rule of thumb, not a hard limit. The used-data figure shown in the panel is the authoritative number.

2.2 Data resets monthly on your activation date

This is the most commonly misunderstood point. Data doesn't reset on the 1st of the calendar month; it resets on your activation date — activate on the 15th and it resets on the 15th every month. The upside is that the billing cycle and the usage cycle line up, so you never waste a plan by activating at the end of the month and watching the data zero out two days later.

If you upgrade mid-cycle, the price difference is prorated by the remaining days. Data you've already used isn't recalculated, and the remaining days in the current cycle aren't voided. The prorated amount appears on the order confirmation page, so you can check it line by line before paying.

If you use up the current cycle's data early, there are two options: upgrade the tier, with the difference prorated by remaining days; or buy a data pack, which is counted by total volume and doesn't reset monthly. The first suits a permanently higher demand; the second suits a one-off spike.

2.3 Data packs: use them up, they never expire

There are three data packs: ¥158/300GB, ¥358/1000GB and ¥658/3000GB. They're a separate quota from your monthly plan data: packs are counted by total volume, don't reset monthly, are used until exhausted and never expire.

The whole value of a data pack is the "never expires" part. Unused monthly data is gone at the end of the cycle; a pack isn't — use 20GB this month and the remaining 280GB is still there next month, so a one-off spike never forces you into a higher tier.

2.4 Three typical situations and what to pick

First, new to this and unsure of your usage: start with ¥9.9/month for 60GB. After a full month the panel shows your real usage, and you can decide next month whether to move up. Upgrading mid-cycle prorates the difference by remaining days, so starting small never costs you more.

Second, daily use across several devices: ¥18/month for 250GB is the balance point. Concurrent devices are unlimited, so a phone, tablet and laptop together cost nothing extra — this is the tier best suited to multi-device users.

Third, long HD playback or large file transfers: ¥28/month for 500GB, plus a data pack as a buffer. That way a month where usage suddenly doubles doesn't cut you off mid-stream, and you're not scrambling to buy more at short notice.

From picking a tier to an active plan there are three steps: sign up, place the order, pay. None of them is complicated, but each has details that are easy to skip — and those details are exactly where most "I paid but can't use it" cases come from.

3.1 Signup: no email address needed

Signing up takes a username and a password — no email address. Dropping that one field isn't just one less click: email is the most common vehicle for account recovery, notifications and follow-up marketing, and if it's never collected, the whole "email database gets breached" risk chain doesn't exist either.

The trade-off is that your username and password become the only credentials for signing in. Store both somewhere reliable when you register — a password manager or a written record both work — but don't rely on browser autofill alone, because once browser data is cleared they're gone. The signup page won't remind you of this repeatedly, but it's the most common source of later trouble.

Pick a username that avoids anything linkable, such as your real name or a social handle you use elsewhere. It's only a login name for this service and doesn't need to carry any identity — the more ordinary, the better.

3.2 Ordering: from tier to order

After signing in, go to the plans area in the panel, choose a tier and confirm the order. The order page lists four things: the tier you chose, the amount due, the billing period and the data allowance. Check each one before paying — especially that the tier and amount match. ¥9.9 goes with 60GB, ¥18 with 250GB and ¥28 with 500GB; they can't be mismatched, but confirming takes seconds.

If this is an upgrade rather than a new purchase, the order page also shows the difference prorated by remaining days. The proration rule is in the previous chapter; here you only need to confirm the final amount is what you expect. If it isn't, don't pay — go back a chapter and recheck the tier.

Don't close the page right after ordering. The order number and the payment entry point are both here; close it and you'll have to go back into the order list, which is an extra step.

3.3 Three payment methods

Payment is by Alipay / WeChat Pay / USDT.

Alipay and WeChat Pay settle instantly: scan the code or follow the redirect, complete the payment, and the order status usually updates within seconds. If the page doesn't redirect back automatically after paying, refresh the order page manually — there's no need to order again.

USDT is an on-chain transfer, so arrival time depends on network congestion, not on this service. When transferring, use exactly the amount and network shown on the page: send too little and the payment arrives short; pick the wrong network and the funds may be unrecoverable. Keep the transaction hash after transferring so you can check it later.

3.4 What to do if payment doesn't take effect

Refresh the order page first. Most "it didn't take effect" cases are just page caching; the status updates after a refresh and nothing else is needed.

If it still hasn't updated after refreshing, check three things in order: whether the payment channel really did charge you; whether the order is still marked as awaiting payment; and whether the amount paid matches the order amount (this is especially common with USDT — one decimal place short and the payment arrives underfunded). If all three check out and it still hasn't taken effect, open a ticket from the panel and include the order number and a screenshot of the payment receipt.

Don't place a second order while submitting a ticket. A duplicate order means two orders, a longer refund process and a harder reconciliation.

3.5 The 60-day no-questions-asked refund

60-day no-questions-asked refund: apply within 60 days and no reason is required. The point of this promise is that you can test route quality on your real network and real devices instead of judging from a page description — how a route performs in your city, on your ISP, behind your router is something only an actual connection tells you.

The refund entry point is in the orders area of the panel; submit it and follow the on-screen instructions. Arrival time depends on the payment channel — USDT, Alipay and WeChat Pay are processed at different speeds — so wait for the status to update after submitting.

One reminder: the refund is a safety net, not a trial pack. If a route is just poor one evening, switching routes or protocols is usually less hassle than a refund — chapter 7 has the full troubleshooting order.

Once your plan is active, the panel gives you a subscription link. That string is the bridge between your client and the routes; with it in hand, importing on all five platforms is the same set of actions in different dialects.

4.1 Where the subscription link is

Sign in to the panel; the overview and subscription areas show the subscription link and its QR code. The link looks roughly like this (the example only shows the format, it isn't a real address):

https://example.com/sub?token=YOUR_TOKEN

The token in a real link is an account-specific credential, equivalent to a password. The copy button on the page is more reliable than selecting by hand — manual selection easily drops trailing characters, and one missing character makes the fetch fail, while the error message usually just says "format error", which rarely makes anyone think of an incomplete copy.

4.2 Protocol priority: start with the most compatible

The same subscription can be output in several protocol formats. If your client supports more than one, choose in this order:

1. clashplus:// — pick this first; it has the best compatibility and feature coverage.
2. Shadowrocket — the common format on iOS.
3. Stash — rule syntax is close to the previous one.
4. sing-box — common in newer clients.
5. Clash — the generic format, as a fallback.

The logic behind the order: the earlier in the list, the more complete the support for routing rules, protocol features and route metadata. If your client only supports a later format, it still works — some advanced features may just not be visible, such as rule groups and route filtering.

4.3 How to look after your subscription link

A subscription link is not public information. Anyone who has it can use your routes against your data allowance while the bill stays in your name. So: don't post it in public forums, group chats or screenshots; don't share the QR code on social platforms; don't commit the link to a public config repository.

If you suspect a leak, reset the subscription in the panel — the old link stops working immediately and clients need to import the new one. Resetting doesn't affect your remaining data or expiry date; the only cost is re-importing on each device.

4.4 Four reasons an import fails

First, an incomplete link. The symptom is a format error or an empty fetch result. Fix: copy it again from the panel, using the page button rather than manual selection.

Second, an outdated client. The symptom is that content is fetched but the client reports an unsupported protocol. Fix: update to the latest client offered in the panel; don't use old builds from third-party sources.

Third, an abnormal network at fetch time. The symptom is a timeout or a reset connection. Fix: retry on a different network, for example switch from Wi-Fi to cellular, or try again later.

Fourth, the device clock is out of sync. The symptom is a failed handshake or a certificate check failure. Fix: set the system time to sync automatically, then restart the client.

The import flow on the three desktop platforms is the same set of actions in five dialects: install the client, sign in, import the subscription, pick a route, connect. The differences are mainly system permissions and first-run authorisation, plus the one or two settings that are easy to overlook on each system.

5.1 Windows

1. Get the Windows client installer from the download area of the panel, run the installer and follow the prompts.
2. Launch the client and sign in with the username and password you registered with. Once signed in, the client pulls in your subscription automatically — no manual pasting.
3. If the client doesn't sync automatically, open the subscription or configuration page, paste the subscription link you copied in chapter 4, save, and wait for the fetch to finish.
4. Pick a route from the server list. For a first run, choose the one with the lowest latency, then adjust by use case once you're connected.
5. Click connect and wait for the status to change to connected.

The most common snag on Windows is a mismatch between the system proxy and the client mode: the client says connected but the browser still uses the local network. Check the client's proxy mode, confirm whether it's global or rule mode, and check whether the system proxy has been rewritten by other software — security tools, download managers and older proxy clients can all change system proxy settings.

5.2 macOS

The macOS flow is the same as Windows, with one extra system authorisation. On first connection the system asks for permission to add a VPN configuration or allow a network extension — you must allow it, otherwise the client can't take over traffic. If you accidentally deny it, re-authorise under Privacy & Security in System Settings and restart the client.

On Apple silicon (M-series) the client runs natively and doesn't need Rosetta translation. If macOS reports that the developer can't be verified after installation, allow it under Privacy & Security in System Settings — this is macOS's standard restriction on apps distributed outside the App Store.

Another easily overlooked point is iCloud Private Relay. It and the acceleration client both take over the default route, and running both can interfere — the symptom being "connected but very slow" or "some apps don't use the route". When troubleshooting, turn one of them off first and compare; it saves a lot of trial and error.

5.3 Linux

The Linux client follows the same path as the other two desktop platforms: install, sign in, import the subscription, pick a route, connect. Two things need attention.

The first is permissions. Taking over system traffic requires the appropriate privileges; if the client reports that it can't create a virtual network adapter, check whether it's running with enough permission. On some distributions a security policy blocks this additionally and you have to allow it manually.

The second is distribution differences. Network management components vary between distributions; if the system's built-in network settings conflict with the client, trust the client's status and turn off the duplicate proxy settings at the system level. When two proxies are active at once, which one traffic takes is unpredictable.

On a machine without a graphical interface, you can fetch the configuration file with the subscription link first and then import it into the client — when fetching, the same care applies to link completeness and to escaping special characters on the command line.

5.4 Settings common to all three platforms

Launch at startup: recommended on desktop. The acceleration service runs in the background, connects automatically after boot, saves a manual click each time, and avoids misdiagnoses like "I forgot to connect and assumed the route was broken".

Disconnect before quitting: closing the client window doesn't necessarily disconnect. Click disconnect first, then quit, so a leftover system proxy doesn't leave you offline.

Automatic updates: client updates usually include protocol support and route compatibility fixes, so leave them on. Connecting to a new protocol with an old client is the most common cause of "the subscription is fine but it won't connect".

For more detailed Windows installation steps, see the complete Windows walkthrough from install to subscription import; macOS permission and chip compatibility issues are covered in macOS client recommendations and compatibility notes.

The biggest difference on mobile isn't importing — it's whether the connection stays up afterwards. The system actively reclaims background processes to save power, and that's the real reason behind most "it worked and then dropped" cases on mobile.

6.1 iOS

1. Get the iOS client entry point from the download area of the panel and install it following the prompts.
2. Open the client and sign in with your registered username and password.
3. On first connection the system asks you to add a VPN configuration — you must allow it, otherwise the connection can't be established.
4. Pick a route and connect; when the VPN indicator appears in the status bar, the tunnel is up.

There are two more details on iOS. One is Low Power Mode: it limits background activity, so after a long lock screen the connection may be dropped by the system and you need to reopen the client to restore it. The other is network switching: moving from Wi-Fi to cellular rebuilds the tunnel, and a brief interruption is normal — you don't need to re-import the subscription.

6.2 Android

1. Get the Android client installer from the download area of the panel and install it. On first install you need to allow installation from that source in system settings.
2. Open the client and sign in; on first connection the system shows a VPN service authorisation prompt — choose allow and tick always allow.
3. Import the subscription (automatic sync or manual paste), pick a route and connect.

Android's power-saving policies are more aggressive than iOS. Most manufacturers freeze the process a while after the app goes to the background, which shows up as the VPN icon disappearing from the notification bar and the app being listed as "stopped". The fix is to add the client to the battery optimisation whitelist: in the system's battery or app management settings, set the client's power-saving policy to unrestricted.

6.3 General practices for background keep-alive

First, allow the client to keep a persistent notification. The notification icon is how the system knows the app is running a foreground service; turning it off makes the app more likely to be reclaimed.

Second, turn off battery optimisation for the client. This is the single most effective step, and it matters more than any other setting.

Third, don't use the task manager's one-tap clean-up. Manually clearing background apps kills the tunnel process outright — more thoroughly than the system would.

Fourth, disconnect deliberately when you won't use it for a long time. Keeping a tunnel up in standby drains battery continuously, so disconnecting is the better trade.

6.4 Two common mobile issues

Connected, but a particular app doesn't use the route: check the client's per-app proxy settings and confirm the app is in the proxied list. Some system-level apps (such as the app store's update service) bypass the VPN — that's system behaviour, not a configuration error.

Other devices get no acceleration after turning on the hotspot: when the phone acts as a hotspot, by default only the phone's own traffic goes through the tunnel, and connected devices use the carrier's original network. If you need to share it, enable the hotspot-sharing option in the client (if it offers one); otherwise each device needs its own client and its own sign-in.

The client showing "connected" only means the tunnel is up, not that traffic really leaves through the exit. This chapter gives a verification routine you can finish in five minutes, plus the trade-offs between the three proxy modes.

7.1 Three signals

Signal one: client status. Connected, with live upload and download rates, and the current route name. All three together mean the tunnel layer is working.

Signal two: the exit changes. Visit any site that shows your exit IP and note the result before and after connecting. The location shown after connecting should match the route you picked.

Signal three: the target is reachable. Open the service you normally can't open; if it loads normally, the path works.

Of the three, signal two matters most. Many "connected but useless" cases are the client being connected while system traffic never enters the tunnel, so the exit IP doesn't change — and at that point switching ten routes won't help.

7.2 Checking the exit and DNS yourself

Exit check: look up your IP location once before connecting and once after. If it's the same, traffic isn't going through the tunnel; if it differs, it is. This needs no tools at all — a browser is enough.

DNS check: besides the exit, confirm that domain resolution also goes through the tunnel. If lookups still go to your local ISP, you can get the odd effect of "the IP changed but some sites still resolve to the wrong address". Most clients take over DNS by default; in rule mode, confirm the DNS policy matches the proxy policy.

Browser fingerprinting and WebRTC: some browsers expose the real network interface through WebRTC. If you care about privacy, turn WebRTC off in the browser settings, or use the client's rule mode to take over everything uniformly. It isn't a required step, but it's worth knowing it exists.

7.3 Choosing between the three proxy modes

For everyday use, rule mode is the recommendation: local sites connect directly and keep their speed, while traffic that needs cross-border access goes through the route. When troubleshooting, switch to global mode to tell quickly whether the problem is the rules or the route — if global works, the rules are wrong; if global still fails, the problem is the route or the account.

7.4 Connection strategy for peak hours

The peak-hour problem usually isn't that you can't connect, but that you connect and it's slow. There are two layers to the cause: overall congestion on international exits, and the bandwidth allocation of a single route.

Work through the fixes from cheapest to most expensive: first try another route in the same region, then a route in a different region, and finally a different protocol. The client supports protocols such as WireGuard and IKEv2, and different protocols behave differently on different networks, so try each before settling.

If only one particular service is slow and everything else is fine, the problem is probably not the route but that service's own scheduling, and switching routes won't help much. The test is simple: open two different services at the same time and compare — if both are slow, it's the route.

7.5 Verification checklist

1. The client shows connected, with live rates.
2. The exit IP location matches the route you picked.
3. The target service opens normally and content loads fully.
4. DNS resolution goes through the tunnel and doesn't fall back to the local ISP.
5. Ten minutes of continuous use with no mid-session drop.

If all five pass, the configuration is done and you can move on to everyday use. If any one fails, work down the troubleshooting order in chapter 9 — don't try things at random.

Finishing the configuration is only the start. Long-term use means managing four things: data, subscription updates, renewal and refunds. None of them needs a technical background, but each needs doing at the right time.

8.1 Checking data and watching for limits

The overview area of the panel shows data used and data remaining for the current cycle. Check it twice in your first week: once after a normal day of use, and once after a heavy weekend. Those two readings let you estimate your monthly usage far more accurately than guessing.

Video and large files are usually where data goes. For the same hour, standard definition and HD can differ several-fold. If usage is higher than expected, first check whether some app is autoplaying or auto-updating in the background — that kind of consumption usually happens when you're not looking.

The panel warns you as you approach your allowance. Your options at that point are in chapter 2: upgrade the tier, or buy a data pack. Neither requires reconfiguring the client.

8.2 Mid-cycle upgrades: the difference is prorated by remaining days

An upgrade isn't a second purchase, it's paying the difference. The difference is prorated by the remaining days in the current cycle: more days left means a bigger payment, fewer days left means a smaller one. Data you've already used isn't recalculated, and the remaining days aren't voided.

The practical meaning of this rule is that upgrading never costs you extra, whenever you do it. The only difference between upgrading at the start of the month and at the end is the prorated amount; the tier benefits you get are the same. So there's no reason to wait for the next cycle — upgrade on the spot when you need more.

Downgrades are different — the options available for changing tiers are whatever the order page shows. If the page doesn't support a mid-cycle downgrade, just pick the lower tier once the current cycle ends; no extra steps needed.

8.3 Renewal and expiry

When a monthly subscription expires, the plan benefits stop. Renewal happens in the plans area of the panel, and after renewal data is recalculated from the new activation date.

Before expiry, do two things: confirm the current tier still fits (your usage may have changed), and check whether the subscription link needs updating. Renewing doesn't affect data packs you already have — packs are counted by total volume and don't expire when a subscription ends, which is genuinely useful over the long run.

If you don't plan to continue after expiry, remember to disconnect on every device and delete the subscription, so a stale configuration left on a device doesn't get in the way later.

8.4 Refunds: the 60-day no-questions-asked refund

60-day no-questions-asked refund: apply within 60 days and no reason is required. What this promise covers is exactly the case where "the routes don't suit your network" — the part no page description can verify for you, and only an actual connection can settle.

The refund entry point is in the orders area of the panel. Submit it and follow the prompts; arrival time depends on the payment channel. USDT refunds need a receiving address, so check the address before submitting — a wrong on-chain transfer is just as irreversible.

After a refund the account itself remains, the subscription link stops working, and clients need to re-import before they can be used again — if you buy a plan later. The configuration already in an old client won't update by itself, so handle it manually.

8.5 Managing multiple devices

Concurrent devices are unlimited. That means a phone, tablet, laptop and desktop can all sign in to the same account at once, with no per-device charge and no signing in and out.

Two practical suggestions. First, when several devices use the same route on one account, data is counted together — more devices means faster consumption, so include all of them when you check usage. Second, if a device won't be used for a long time, signing out reduces the surface on which the subscription link is exposed.

The number of devices is unlimited, but there's only one subscription link. Resetting the subscription invalidates all devices at once and each has to be re-imported — that's the trade-off between security and convenience, and it's only worth doing when the risk of a leak is high.

After the first eight chapters the service is usable. This chapter answers two questions: how to use it better, and how to locate a problem as fast as possible when something goes wrong.

9.1 Choosing a route by scenario

No route is absolutely better than another — only better matched to a scenario. The criteria are three: latency, bandwidth and stability, and they often can't all be optimal at once, so you have to rank them by purpose.

The full route list and regional grouping are on the route list page. When choosing, filter by region first, then by type, and test last — the same route can perform differently on different ISPs, and a real measurement beats any description.

9.2 How to write split-routing rules

The core of rule mode is a list of what traffic goes where. Below is a generic example; the syntax differs slightly between clients, so the client's own documentation is authoritative:

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-KEYWORD,cdn,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

What the four rules mean: domains with the specified suffix go through the route; domains containing the given keyword go through the route; IPs geolocated locally connect directly; everything else goes through the route. Matching runs top to bottom and stops at the first hit, so the more specific rules go higher.

Two mistakes are easy to make when writing rules. One is putting MATCH at the very top, which means the rules below it never match. The other is referencing a policy group name that doesn't exist — the client either errors out or silently skips it, and the latter looks like "the rule is written but has no effect", which is harder to track down.

9.3 Working across devices

Unlimited devices means you can use them all at once. In practice there are two ways to organise it: each device imports the subscription and picks its own route, or everything uses one main route to reduce variables.

The first is flexible: the phone takes a low-latency route for browsing, the computer takes a high-bandwidth route for video, each getting what it needs. The second is easier to troubleshoot: when every device behaves the same, the problem is most likely the route or the account; when they differ, it's the local configuration. Either works day to day, and switching to a single route makes troubleshooting simpler.

9.4 Troubleshooting order: outside in

1. Confirm the underlying network first. Turn the client off and check that the local network itself works. If that doesn't, nothing further applies.
2. Then check the client. Does it start, can you sign in, can it fetch the subscription? A failed fetch is an account or link problem, not a route problem.
3. Then check the tunnel. After connecting, check the exit IP. If the exit hasn't changed, traffic isn't going through the tunnel, and the problem is the mode or the system proxy.
4. Next, switch routes. Try another route in the same region, then one in a different region. If that fixes it, the problem was a single route.
5. Finally, switch protocols. WireGuard and IKEv2 behave differently on different networks, and switching protocols rules out compatibility problems at the protocol layer.
6. Still not working — open a ticket. Include the client version, operating system, the route you selected, the exact error text and when it happened; that makes locating it much faster.

The value of this order is that each step rules out a class of causes instead of trying things at random. Most problems are located in the first three steps; the rest are a safety net. More entries are in the help center.

9.5 Quick reference for common snags