Cross-Border Network Service Buying Guide

What this manual answers

The page that splits the work with this one is Quick Start — that page covers only the follow-along main line: create an account, pay, pull your subscription, import it into a client, verify the connection, with every step spelling out what to click, what you should see and what comes next. This page does not repeat those steps; it answers the questions that come before and after them: which route type to buy, how much data, which billing model, and what to suspect first when the experience is unstable.

Put another way, Quick Start gets you running; this page helps you get it right. The two link to each other, and which one to read depends on the question you have right now: if you do not have an account yet, start with Quick Start; if you already have one and want to check you bought the right thing, or you are comparing services, stay here.

Three reading paths

How this manual sources its facts

Every figure about this service — plan tiers and data allowances, refund window, simultaneous device count, route and country coverage, supported platforms and payment methods — matches the Plans and Nodes pages exactly; this page does not offer a second version of the numbers. Industry knowledge — how route types differ physically, how bandwidth units convert, how overselling happens — is written as checkable reasoning, with no unverifiable third-party benchmarks and no single speed test treated as the norm.

There is one kind of claim this manual deliberately avoids: turning stability into an absolute promise. Cross-border performance depends on your local network, the time of day and the region the target service sits in, and no provider controls all of those variables. What you can verify is route type, bandwidth figures, refund terms and device counts, all stated up front; adjectives you cannot verify deserve a discount when you read them.

A note on search terms

Many users who search for terms like cross-border access actually have a very specific problem in mind: a work platform will not load, a series the family wants to watch is not licensed locally, or an AI tool says it is unavailable in their region. These are concrete use cases, and this manual is organised around them — no vague slogan-versus-slogan comparisons, and no advice to buy the longest plan for a short-term need.

Terminology

• Route: one selectable egress path, usually labelled as region + route type. A dedicated-line entry for Hong Kong and a direct entry for Hong Kong are two different routes.
• Egress: the point where traffic finally leaves the service network and enters the public internet; it determines the region the target service sees.
• Subscription: the configuration credential a client uses to pull the route list. You get it after logging into the user panel; it is not handed out on marketing pages.
• Data allowance: the amount of data included in a plan. Monthly plans reset on the activation date each month; data packs last until used up.

Route types: IEPL, relay and direct compared

The single most overlooked factor when buying — and the one that shapes day-to-day experience most — is route type. Two entries both labelled Hong Kong may travel completely different paths, at costs that differ by an order of magnitude. This chapter lays out the physical differences, the cost drivers and the best-fit scenarios for all three types, so the node list reads much more easily afterwards.

How the three route types differ physically

Direct is the plainest: the client connects straight to the public entry point of an overseas data centre, passing through the public egress and public routing of the international internet. The path depends on peering relationships between carriers; it is the cheapest option and the most exposed to congestion at international egress — the same machine can feel completely different at midday and at peak evening hours. That is not a provider quietly throttling you; it is the objective state of public egress at peak times.

Relay adds one hop: the client first connects to an entry data centre closer to home, then travels from that entry over a managed high-quality link (usually a dedicated line or an optimised cross-border path) to the overseas egress. The user-to-entry leg is short, and the cross-border leg where problems usually appear is handed to the provider to optimise. Relay therefore sits in the middle on both stability and cost, and is today the most common compromise.

IEPL dedicated lines are the heaviest of the three: International Ethernet Private Line, a point-to-point Layer 2 channel whose traffic never touches public internet egress, with a fixed path and bandwidth guaranteed at the committed rate. The direct result is markedly lower jitter and packet loss. For interactive applications — video meetings, remote desktop, AI tool conversations — jitter affects the experience far more than peak speed: a single 300-millisecond stall is more painful than an average speed 10% slower.

Where the cost differences come from

Cross-border dedicated capacity is billed as a monthly bandwidth lease, and the cost per unit of bandwidth runs several to several dozen times that of ordinary public bandwidth. Relay combines short local access with a managed cross-border segment, so it sits between the two. Direct is almost nothing but data centre and egress cost. That cost chain is itself a test: if a service claims dedicated lines across the board yet prices well below its peers, either the word dedicated is marketing (it is really relay or direct), or something else has been traded away in bandwidth and oversell ratio. Nobody sells dedicated bandwidth at direct-connection prices.

Which route type suits which scenario

• Interactive use (video meetings, remote desktop, AI tool conversations, real-time collaboration): choose dedicated lines first. These applications are far more sensitive to jitter than to peak bandwidth.
• Streaming: dedicated lines or high-quality relay. A steady bitrate decides whether the picture drops mid-play; for region availability see the Streaming Support page.
• Large file transfers, backups, non-real-time downloads: relay or direct is usually enough, and it is more cost-effective to keep dedicated lines for interactive devices.
• Backup routes: direct will do — lowest cost, ready to switch to when the primary route has problems.

How to read route labels on the nodes page

To judge whether a service really separates resources by route type, look at whether its node list labels the type. The route table on the Nodes page has four columns: country/region, city, route type and streaming support. It is normal for the same region to have both dedicated and direct entries — dedicated capacity is limited and cannot cover every region, and spelling out which regions are dedicated tells you far more than a blanket claim of all high speed.

Two easy misreadings when scanning the table. First, treating the country count as the route count: one country may have several cities and several routes, and this service states its coverage as 120+ countries / 220+ routes — two different dimensions. Second, reading supports a given streaming service as this route will definitely unblock it: unblocking also depends on the target platform changing its own policies, so the nodes page gives reference labels, not promises.

Bandwidth and concurrency: working out what is enough

There is no single answer to how much bandwidth is enough, but it can be calculated. This chapter standardises the units first, gives bandwidth figures for common applications, then separates concurrency from overselling — two things often confused — and closes with a cross-check method that tells you whether the problem is the route or your own network.

Units first: Mbps vs MB/s

Network bandwidth is measured in Mbps (megabits per second), while the download speed shown in most clients is in MB/s (megabytes per second) — the two differ by a factor of 8: 1 byte equals 8 bits, so 100Mbps works out to roughly 12.5MB/s. This conversion looks basic, yet it is where plan comparisons go wrong most often — a line advertised at 100Mbps and one advertised at 12MB/s are in fact about the same speed; flip it around, and comparing 100MB/s against 100Mbps as if they were the same unit leaves you off by a factor of 10. Whenever you see a speed figure, confirm its unit first.

How much bandwidth common apps need

The figures below are industry-standard estimates for rough sizing, not measured results for this service:

• Web, email, messaging: negligible — under 1Mbps is plenty, and this kind of use barely eats into your bandwidth headroom.
• 1080p streaming: official guidance from mainstream platforms generally sits around 5Mbps.
• 4K streaming: usually needs 25Mbps or more, depending on the codec and the platform's bitrate strategy.
• Video meetings: upload matters more than download; 1.5–4Mbps generally keeps a clear picture.
• Large cloud-drive files, system updates: no fixed requirement — they will take as much as they can get.

Compare these with your own habits and you can roughly place your monthly usage: office work, web and messaging mostly, 60GB is usually enough; daily video and video meetings, 250GB is more comfortable; if 4K streaming dominates or several people share the account, only 500GB leaves real headroom.

Concurrency: being online together and being loaded together are two different things

This service's device policy is unlimited devices, meaning the account is not charged per device and the number of logged-in devices is not capped. But unlimited devices solves a licensing question, not a bandwidth one: every device at home shares the same egress route, and three devices streaming 4K at once need three lots of 25Mbps of headroom. No service can conjure that out of nothing.

The practical advice is to layer devices by purpose: office devices that need low jitter go on dedicated lines, download and backup devices go on relay or direct, and streaming devices get a stable route of their own. That way, if one route is crowded at peak hours, the other devices do not all degrade with it.

Overselling: why speeds drop at peak hours

A provider buys a finite amount of bandwidth, and users do not all run at full speed at the same time, so buying capacity on the statistical assumption that peak concurrency is lower than the total user count is standard industry practice and not a problem in itself. The problem is the oversell ratio: when the same capacity is sold to far too many users, everyone slows down together at peak hours. The typical signs are everything running fine by day but the same route clearly slower in the evening, or differences between routes in one region widening at peak.

Three ways to spot it. First, does the provider publish route types and bandwidth figures? A service that only says high speed and never names a type usually has no resource tiers it can commit to. Second, does it offer alternative routes in the same region? Being able to switch means the provider kept headroom. Third, are peak and off-peak differences stable and predictable? Occasional fluctuation and a nightly collapse at a fixed hour are two different things.

Is it the route or your own network?

1. Swap routes: switch to another route in the same region at the same moment. If only one is slow, the problem is most likely that route; if all of them are slow at once, look at your local network or your carrier.
2. Swap devices: connect a different device to the same route. If the new device is fine, the original device's system settings, background load or client state is the issue.
3. Swap networks: try wired and wireless once each, and if you can, try another carrier's network. A clear difference points to your local connection as the bottleneck.
4. Swap time slots: test once off-peak and once at peak, and write down what you see. This step separates a crowded route from a configuration problem.

Once all four are done you can usually reach a clear conclusion. Write the results down and then look up the symptom in the Help Center or open a ticket — it gets handled far faster than a message that only says it is very slow.

Billing: monthly plans or data packs?

This service offers two billing models: monthly plans (with a monthly data allowance that resets on the activation date) and data packs (bought once, used until they run out, never expiring). Neither is better than the other — only better or worse for a given user. This chapter sets out the rules, the user profiles and the combination strategy for both.

The essential difference between the two

A monthly plan buys time plus a monthly allowance: for as long as the subscription is active, each month brings a fixed data allowance, and once it is used up you either wait for the reset or upgrade the tier. A data pack buys a one-off quantity of data: no time limit, valid until used up, however long that takes, then buy another. The first suits a steady, predictable rhythm; the second suits intermittent or seasonal needs.

The three monthly tiers and who they suit

The reset on the activation date rule deserves a note of its own: the allowance does not clear on the 1st of the calendar month, but counts from the day you activated, resetting once every full month. The upside is that the cycle lines up with your billing, so there is no waste from buying at month end and seeing a reset two days later; the trade-off is that you have to remember your activation date. If you upgrade mid-cycle, the price difference is prorated across the remaining days, so there is no need to wait for the cycle to end — upgrade straight away when you need more data.

The three data packs and who they suit

Data packs get cheaper per gigabyte as the tier grows, so if you know you will be using this for the long haul, the larger pack is better value; if you are not sure you will use it all, start with the smallest. They suit three kinds of people especially well: those who need cross-border access only during a few periods a year; those who keep a cross-border route as a backup and rarely use it; and those who want a separate allowance for a family member who is online only occasionally.

How to choose: three questions

1. Will you use it every month? For steady use, choose a monthly plan — the allowance refreshes regularly and the long-run cost is lower. For intermittent use, choose a data pack and avoid paying for idle months.
2. Roughly how much per month? Estimate from the bandwidth figures in the previous chapter: office and web use points to the 60GB tier, daily video to 250GB, 4K or multiple devices to 500GB.
3. Will several people share it? When sharing, multiply your estimate by the number of people and go one tier up — less hassle than upgrading repeatedly later.

Combining both, and how to read never expires

The most common combination is a monthly plan as the base with a data pack as the safety net: day-to-day use draws on the monthly allowance, and in a month when a trip or a short project pushes you over, the data pack covers the gap instead of upgrading the whole month for a few days of use. Data packs and monthly plans can coexist, each consumed under its own rules.

Never expires means the data inside a pack has no expiry date: it does not clear with the subscription cycle and does not lapse if you stop using the service. It does not mean the account is valid forever, and it does not mean data can be transferred between accounts — a distinction worth keeping in mind with any provider's terms. Reading data does not expire and account valid forever as two separate statements avoids a lot of misunderstanding.

Devices and family sharing: what unlimited devices means

Unlimited devices is one of the phrases that comes up most often when buying, and one of the most misread. This chapter sets out its boundaries, then covers a few ways to share at home, advice on splitting bandwidth, and how to manage account credentials.

What unlimited devices actually covers

This service's device policy is unlimited simultaneous devices: one account can be connected on many devices at once, with no per-device charge and no cap on logged-in devices. This differs from the usual a few devices approach, where logging in a fifth device typically kicks the first one offline — with unlimited devices that does not happen.

Five platforms are supported: Windows / macOS / iOS / Android / Linux, covering desktop and mobile clients. The clients themselves are in the download area of the user panel, and the subscription is also pulled after logging in; marketing pages carry no static installers or subscription URLs, so the link between account and subscription always stays with the account holder.

Three ways to share at home

• Each device logs in on its own: the most direct approach — every device signs in to the same account with its own client and picks its own route. Suits households where each member has their own phone and computer.
• One always-on device as a shared egress: keep one computer running as the egress and let other devices share its connection over the local network. This is an advanced setup with more configuration work, but it is the least trouble for family members who are not comfortable with clients.
• Assign account users by purpose: if only one or two people use it heavily, keep one device as the main one and log in others as needed — no elaborate planning required.

Splitting bandwidth when sharing

Unlimited devices solves a licensing question, not a bandwidth one. When several devices at home are under heavy load at once, the egress route's bandwidth still has to be shared: two devices streaming 4K at the same time need two lots of 25Mbps or more. A workable approach is to layer devices — put the ones that need low jitter (video meetings, remote work) on dedicated routes, put insensitive jobs such as downloads, backups and system updates on relay or direct routes, and give streaming devices a stable route of their own. Then not every device slows down together at peak hours.

Managing account credentials

Signing up needs only a username and password — no email address. One less email entry point means one less channel that can be credential-stuffed or phished, but it also means account recovery can only be handled through in-site channels, so look after the password itself: do not reuse it across services, do not forward account details in plain text in group chats, and tell family members verbally when sharing.

There is one easily overlooked detail when several people share an account: anyone changing the password affects every user, so it is worth mentioning it at home before you do, rather than letting someone else discover the next day that they cannot connect and not know why.

Choosing routes across many devices

Once you have several devices, choosing routes becomes a chore. Two habits save a lot of time: save your usual routes in the client so you are not scrolling the list by hand every time, and fix devices to purposes — office devices stay on the same dedicated line long term, download devices on another, without constant switching. That is how you build up a sense of how a given route performs for you. Route performance shifts with the target service and the time of day, so a stable routine tells you more than endlessly trying new routes.

Refunds and support: how the 30-day refund works

The refund policy is the passage most worth reading word by word before buying, and the clearest single clue that separates a legitimate service from short-term opportunism. This chapter covers this service's refund terms, the checks worth doing before you apply, how to choose a payment method, and a few standards for judging whether a support promise is trustworthy.

How to read a refund policy

This service's terms are a 30-day no-questions-asked refund: within 30 days of your first payment you can request a refund without giving a reason — no need to prove the route was bad, no need to explain. The point of no questions asked is that it moves the burden of proof away from the user. Many services require you to demonstrate that the service did not meet its promises, while the promises themselves are written vaguely enough that it ends in an argument.

The window starts from your first payment, so the earlier you decide, the more room you have. The refund entry is in the ticket area of the user panel, and requests are processed through the standard flow. The full terms are on the Refund Policy page; this page is only a summary.

Three things to do before requesting a refund

1. Run a cross-check: use the four-step method from the Bandwidth and concurrency chapter — swap route, device, network and time slot, one at a time. Most cases of cannot connect turn out to be local settings, such as client permissions not granted, a leftover system proxy, or a subscription that has not been refreshed.
2. Confirm the subscription is refreshed: the route list changes as operations are adjusted, so refreshing the subscription manually in the client works better than restarting the client repeatedly.
3. Keep your order details: order time, tier and payment method, all stated when you open the ticket, speeds up handling.

These three steps are not conditions for a refund — a no-questions-asked refund needs no reason at all — they simply make the judgement more accurate: if the problem is local, sorting it out and carrying on is better value than a refund; if the route genuinely does not match your needs, the refund makes the decision cleaner too.

Payment methods

Three methods are supported: Alipay / WeChat / USDT. Alipay and WeChat suit users who pay that way day to day, with a short path from order to payment; USDT suits those who already hold crypto assets. Whichever you use, the allowance takes effect immediately after ordering, with no manual confirmation to wait for. One thing worth noticing when choosing a payment method: a service that offers several payment channels usually also has a more formal payment flow and more complete order records — a trust signal you can observe for yourself.

Support channels and what to expect

Support runs mainly through tickets, opened from the ticket area of the user panel; the Help Center offers self-service troubleshooting across four common categories — account and subscription, connection and troubleshooting, routes and speed, payment and refunds — and most symptoms have a fix listed there. When you open a ticket, state the symptom, the time, the route you were using and the device platform; that is far more effective than writing it does not work.

Which support promises are worth trusting

The test comes down to four points: is the refund window written into the terms page; do the terms say which day the window starts from; are there several payment methods and traceable orders; and is there a submission channel that does not depend on someone being online? Conversely, a service whose only promise is a slogan like refund any time you are unhappy, with no written terms to be found, or where refunds can only be requested verbally in some chat window, is clearly higher risk.

Common pitfalls: spotting overselling, inflated claims and exit risk

This chapter gathers the problems you are most likely to run into when buying cross-border network services, with a way to spot each one. Everything is based on observable facts, aimed at no particular provider and carrying no subjective verdict — the criteria are public, and anyone can check them.

Pitfall 1: peak-hour collapse from overselling

Overselling is itself a standard statistical practice in the industry; the problem is what happens when the ratio is too high. Three signals: is the speed difference between day and evening both stable and obvious; are there alternative routes in the same region to switch to; and does the provider publish route types? If one subscription slows every route down at peak hours with no alternative to switch to, the hours in which it is actually usable shrink sharply. The response: favour services that label route types and offer several routes per region, and judge by peak-hour experience rather than an off-peak speed test.

Pitfall 2: inflated node counts

Claimed coverage that does not match the actual list is the most common problem of all. It shows up as writing only a region and never a city, counting different domains of the same entry point as separate nodes, or mixing country counts with route counts. Checking is straightforward: de-duplicate the cities in the list and compare with the claimed country count; see whether each entry labels a route type; and see whether the provider states that one region can have several routes of different types. This service states 120+ countries / 220+ routes, and the Nodes page groups cities and route types by region — two figures, two dimensions, never mixed.

Pitfall 3: lifetime low prices and exit risk

Long-term plans priced clearly below the cost floor usually mean one of two things: the resources are thinner than advertised, or new users' money is funding short-term operations. Warning signs include: only irreversible payment methods; no written refund terms, or vague ones; no ticket system, only a chat window; domains and brands that change frequently; and no traceable operating history. The response is simple and effective: verify at the smallest possible cost first — the shortest cycle or the smallest tier — and only consider a longer commitment once the experience and support response meet expectations. Any service asking for several years of payment up front deserves a second thought.

Pitfall 4: reading privacy claims

No logs is a standard privacy commitment in this industry and a positive one in itself, but when you read it, separate two questions: is it written into the privacy policy text, and does it say what is and is not recorded? A service that puts no logs on the homepage as a slogan but has no privacy policy page to be found has given you nothing to rely on. The checkable approach is to open the privacy policy and see whether it states which data is collected, what it is used for and how long it is kept. The same goes for encryption: rather than adjectives, look for a statement of which encryption is used.

Pitfall 5: three shapes of pricing traps

• Low first term, full price on renewal: the promotional page shows only the first-term price, with the renewal price buried in the small print. How to check: find both the first-term and renewal prices before ordering.
• Bonus data that expires: gifted allowances carry their own short validity, different from the main allowance rules. How to check: read the rules for bonus data and purchased data separately.
• Opaque overage handling: what happens after you exceed the allowance — throttling, disconnection, metered billing — is not clearly stated. How to check: look for the sentence about what happens after you exceed it; if you cannot find it, treat it as a risk.

A reusable checklist

Distilled into seven points you can run against any service:

1. Is the refund window written down, and which day does it start from?
2. Is the route type labelled on every entry, rather than a blanket high speed?
3. Are the billing rules clear: how the allowance resets, whether it expires, what happens after you exceed it?
4. Is the device count stated — a fixed number, or unlimited devices?
5. Are there several payment methods, and are orders traceable?
6. Is there a submission channel independent of someone being online (tickets or a help centre)?
7. Are there privacy policy and terms of use pages, and is the content specific?

Passing all seven does not guarantee a good service, but any vague answer is worth one more question before you order. For the technical detail behind protocols and routes, read the comparison criteria in the 2026 VPN ranking, or the piece on 4K picture quality and route metrics.

Decision paths by user type

The previous chapters covered the criteria; this one combines them into concrete paths. Find the one closest to your situation and work through the decisions in order; when in doubt, starting with the smallest commitment is always right.

Students abroad and expatriate staff: stability first, clear cycles

The pattern here is long-term, regular use, with a dependence on video calls and on stability to domestic platforms. Suggested path: start with the 250GB monthly tier (¥18 / month) and put video calls and online classes on dedicated routes; if you also stream, then assess whether to move up to 500GB. Monthly billing is enough — no need to buy a long cycle up front, since mid-cycle upgrades are prorated across the remaining days, making a tier change cheap.

Cross-border e-commerce and remote work: many devices, low jitter

The pattern here is several devices in parallel, sensitivity to latency and jitter, and moderate-to-high data use. Suggested path: a 500GB monthly tier as the base, office devices fixed to dedicated lines, and customer service and operations devices on another route in the same region for redundancy; the account allows unlimited simultaneous devices, so manage passwords carefully when a team shares it. For a larger team, verify route quality with one subscription first, then decide whether you need more.

Heavy streaming users: work back from bitrate to data

The pattern here is heavy data use and a need for specific regions. Suggested path: first confirm which regions the target platform is available in (see Streaming Support), then set up the 500GB monthly tier, choosing dedicated lines or high-quality relay for 4K playback. If you only watch occasionally, a data pack is better value — the 300GB pack is enough for several series, and it lasts until used up, never expiring.

AI tool users: jitter matters in interactive sessions

The pattern here is a long-lived connection, with small data use per session but a need for prompt responses. Suggested path: the 60GB or 250GB monthly tier is enough; the key is route choice — AI tools are sensitive to time-to-first-token and interruptions, so favour dedicated lines. For availability and regional details see the ChatGPT Acceleration page.

Light and backup users: start with a data pack

The pattern here is irregular use, small amounts at a time, possibly only once every few months. Suggested path: go straight to the 300GB data pack (¥158) — valid until used up, never expiring, with no paying for idle months; if you find you use it more often than expected, switch to a monthly plan, and the pack you already bought does not go to waste — it stays as a top-up allowance.

The general decision order

1. Fix the intensity and the number of people: single light user, single heavy user, or several people sharing — settle this first.
2. Fix the route requirement: whether interactive applications dominate decides whether dedicated lines come first.
3. Choose the billing model: monthly plan for steady use, data pack for intermittent use, and a combination when needed.
4. Check refunds and payment: confirm the refund window and payment methods suit your habits before ordering.
5. Verify at the smallest cost first: start with the lowest tier or the smallest data pack, and only consider a long-term commitment once routes and support meet expectations.

The order of these five steps is best not rearranged: settle usage before routes, settle the model before price, and check the terms last. Do it the other way round and it is easy to be drawn in by a cheap tier while overlooking the route type and refund protection that actually shape daily experience.

Specs quick reference and pre-order checklist

This chapter gathers the facts covered on this page in one place, so you can check them off before ordering. Every figure matches the Plans, Nodes and Refund Policy pages.

Key specs at a glance

Route coverage

120+ countries / 220+ routes

Simultaneous connections

Unlimited devices

Refund promise

30-day no-questions-asked refund

Sign-up requirements

No email address required

Supported platforms

Windows / macOS / iOS / Android / Linux

Payment methods

Alipay / WeChat / USDT

Route types at a glance

Billing models at a glance

Platforms and clients at a glance

Clients and subscriptions are both obtained inside the user panel; marketing pages provide no static installers or subscription URLs.

Eight-point pre-order checklist

1. Confirm which tier your usage falls into: 60GB, 250GB or 500GB.
2. Confirm whether you need dedicated lines: if video meetings, remote work and AI tools dominate, put dedicated lines first.
3. Confirm the billing model: monthly plan for steady use, data pack for intermittent use.
4. Confirm the number of devices and how you will share: unlimited devices, but bandwidth still has to be split.
5. Confirm the refund window and the day it starts from.
6. Confirm the payment methods cover the channels you normally use.
7. Confirm the support channels: where the ticket entry and the Help Center are.
8. Confirm you will verify at the smallest cost first before committing long term.

Quick answers