Cross-Border Network Buying Guide

The decision order: use case first, price second

Look at these four separately and each maps to a question you can answer on its own. The use case decides the exit region; the exit region decides the route type; usage intensity decides the billing model; the refund window and payment method decide what a wrong guess costs you. Get any link in the chain backwards and you redo the work later: buying the largest tier first and then finding the route does not fit the use case, or picking the cheapest route and then finding meetings are unusable at peak hour.

How this page differs from the setup guide

The setup guide covers the main path: create an account, choose a plan, get the subscription, import it into a client, verify the connection — do those in order and it works. This page does not repeat them. It handles the judgement calls around them: why two routes that look identical behave differently, when a monthly plan beats a data pack and vice versa, and how to use the refund window. For hands-on steps, start with the setup guide; for trade-offs, come back here and use the contents.

The relationship between the two pages is simple: the setup guide is about getting the service running, this page is about getting the choice right. The first only needs one pass; the second comes back every time you change plan, device or use case. That is why this page is longer — and why it is worth reading before you pay.

Why price should not come first

On the same cross-border path, what decides the experience is route quality and the probability of congestion, not how much you paid. A cheap option that lands on a congested public peering segment will still degrade at peak hour; a mid-priced option whose exit sits in a well-chosen landing facility can be steadier day to day. Price belongs at the end because it is the only variable left for the final trade-off once the first three are settled.

There is a more practical reason too: the refund window. This service offers a 60-day refund with no questions asked, which pushes the cost of a wrong guess very low — pick the smallest tier that fits your use case, test it, and refund within the window if it does not. That beats three days of comparing tables on paper. The right way to use a decision order is to narrow the field first and then verify with one real trial, not to stake everything on a comparison chart.

Write the use case as one sentence

The practical version is to write yourself one sentence: “I mainly use it to reach ___, roughly ___ per day, concentrated between ___ and ___.” The blanks do not need to be precise, but they should name actual services and hours. That sentence decides the next three chapters. Reaching AI chat tools and code repositories is sensitive to packet loss and jitter but does not need sustained high bandwidth; HD video is the opposite — sensitive to sustained bandwidth, indifferent to a few tens of milliseconds of jitter. Both concentrate at peak hour.

Once the sentence is written, going back to the plan table is much faster. The 60GB tier matches “documents, web pages and messaging as the main load”; the 250GB and 500GB tiers match “steady video or large file transfers every day”. This is not a precise conversion, just a starting point — real usage becomes obvious after a month, and the refund window means the starting point does not have to be right first time.

Route types: IEPL, relay and direct

Route type is the chapter worth the most time on this page. Routes in the same city can take different data paths, and the path decides how they behave at peak hour. Once the three types are clear, the choices in the next two chapters become straightforward.

How the three route types differ in data path

Direct is the easiest to picture: the client connects to an exit data center, traffic leaves that data center straight onto the public internet and reaches the target service. It is the cheapest, because the provider only pays for bandwidth at the data center. The catch is that the cross-border leg runs over public peering, with routing decided by carrier policy. It may be fine during the day; at peak hour all traffic on that segment crowds in together, and the result is higher latency and more packet loss.

A relay adds one hop in the middle. The client connects first to a relay node with better landing conditions, and that node forwards to the target. The value of the hop is that the provider can choose where traffic enters the public internet and over which upstream, avoiding a poor-quality peering segment. Relays cost more than direct but far less than a dedicated line, which is why they are the mainstay of most subscription services.

IEPL is an international Ethernet private line: the carrier provides a dedicated channel between two points that does not cross public internet congestion points. It is the most expensive, usually billed by bandwidth, so it is only deployed in cities with concentrated traffic. The point of a dedicated line is not “faster” but “steadier”: when public links jitter at peak hour, a dedicated line barely changes.

Trade-offs across the three route types

Read this table across, not by picking a single row. What decides the experience is which row your use case falls into, not which row looks best. Meetings and code commits sit in the dedicated-line row because their tolerance for a single lost packet is very low; someone who only watches video in the evening may not get better value by putting the whole budget into a dedicated line rather than a relay.

Why the same city has more than one route type

Route types are not divided by city but by data center and upstream. The same city can host both a direct data center and a dedicated-line landing point — the first cheap, the second steady — and providers list them separately. Seeing “Hong Kong · IEPL” and “Hong Kong · Direct” side by side is not duplication; they are two different data paths. When choosing, look at the type first, then the city.

This also explains a common question: why someone else says a route is great while the same route is ordinary for you. The answer is usually not that the route is broken but that the targets differ — a route optimised for services in one region may not be for another. There is only one way to judge: test it on your own use case.

Choosing by use case

Interactive work — AI chat, code commits, online meetings — is the most sensitive to packet loss: one lost packet is one retransmission, felt as a stall. For these, prefer a dedicated line, then a relay with a good upstream. Sustained downloads and streaming tolerate loss well but are sensitive to sustained bandwidth; relay or direct both work, and the key question is whether that route's exit has been optimised for the target service.

Games are the third case: sensitive to both latency and jitter, and hard-constrained on exit region — it has to sit where the game servers are. Do not choose for this by “most nodes”; fix the server region first, then pick a route type within those regions. For a closer look at how latency and packet loss affect gameplay, the site's game accelerator comparison breaks it down.

The full route list and regional grouping are on the route list page, which shows each route's city, type and streaming support by region, so you can check them one by one instead of trusting a single total.

Bandwidth and concurrency: what unlimited devices really means

Nine out of ten “why is it slower than advertised” questions come from mixing up three ideas: bandwidth, traffic and concurrency. Separate them and most of the confusion disappears.

Bandwidth, traffic and concurrency are three different things

Bandwidth is the ceiling on instantaneous speed; traffic is the total transferred within a billing period; concurrency is how many connections are running at the same moment. A subscription sells a traffic allowance and shares exit bandwidth. Understanding the difference explains most speed questions.

For example, a 60GB monthly allowance does not cap how fast you can go in any given minute — it caps how much you can transfer in the month. How fast any given minute is depends on how many other people are using that route at the time. Slowness at peak hour is usually not your allowance running out but momentary pressure on the shared exit. The two have completely different fixes: the first means a bigger tier, the second means a different route or a different hour.

Unlimited devices is not dedicated bandwidth

Plans from this service are not limited by device count, meaning one account can be used on several devices at once with no per-device charge. It does not mean each device gets its own bandwidth — every device shares the account's traffic allowance and the same route exit. Three devices streaming at home put different pressure on that exit than one device does.

The difference shows up most clearly in a household. If several people use it at once, go straight to the 500GB tier and assign different routes to different devices in the client: send video traffic down one route and work and meetings down another so they do not compete. Desktop clients usually support per-app or per-domain routing, and doing it well makes the allowance go further.

Why peak hour happens

Cross-border links run over submarine cables and carrier peering points. The capacity of those facilities is fixed, while usage concentrates in the evening. Between 20:00 and 24:00 traffic on the same peering segment rises at once, queues get longer, and the result is higher latency and packet loss. This is not one provider's problem but a shared feature of public links; the only things you can change are which link you take and whether there is a dedicated channel on it.

So do not test a route in the morning and call it. Test during the hours you actually use it, and test with real work — open the services you actually use rather than reading numbers off a speed-test site. A speed test measures throughput to some test node, which is often neither the same path nor the same hour as your real target.

What platform differences actually cost you

Clients behave differently across platforms in how they handle “global” versus “split” modes. Desktop (Windows / macOS / Linux) can usually route per app or per domain, sending only the traffic that needs to cross borders down the route and leaving the rest on the local network; mobile (iOS / Android) tends to take over by rule or globally. That means the same subscription consumes different amounts of traffic on desktop and mobile — good split routing on desktop makes the allowance last longer.

If most of your use is on mobile, decide before you take out a subscription which apps need the route and which do not. Excluding the ones that do not is cheaper than upgrading later. Per-platform import steps and permission handling are covered in the setup guide.

Billing models: monthly plans vs data packs

There are two billing shapes here: a monthly subscription, and data packs that you use until they run out. The difference is not the unit price but whether the allowance expires with time. Get that straight and the choice becomes easy.

The three monthly tiers differ only in allowance

The monthly subscription is billed by time, with traffic resetting each month on your activation date. The three tiers differ only in monthly allowance: ¥9.9/month for 60GB, ¥18/month for 250GB, ¥28/month for 500GB. There is no feature difference between them — all include 100+ countries / 180+ routes, unlimited simultaneous devices, and Windows / macOS / iOS / Android / Linux support. In other words, the extra money buys allowance, not permissions.

Why data packs are a different animal

Data packs are not billed by time: ¥158/300GB, ¥358/1000GB and ¥658/3000GB, used until they run out, never expiring. The difference from a monthly plan is not the unit price but whether the allowance expires. A monthly plan's allowance resets each month and unused traffic does not roll over; a data pack's allowance does not move with time — whatever is left today is still there months later.

That difference decides who should pick which. For people who use it every day at a steady rate, the monthly plan is better value because the allowance refreshes and there is no mental accounting about rationing. For occasional use — business trips, short projects, a backup route — a data pack fits better, since idle months consume nothing.

Upgrading mid-cycle

Monthly plans support mid-cycle upgrades, with the price difference prorated over the remaining days, so you do not have to wait for the next reset date. The practical value of this rule is that it makes choosing the wrong tier cheap: verify the route on the smallest tier, then upgrade once you know it works, which is steadier than buying the largest tier up front.

Note that prorated upgrades only fix “the tier was too small”, not “the estimate was too high”. If you buy 500GB up front and only use a fraction each month, that unused portion does not roll over. So the order is still small first, large later — not the other way round.

A selection table

One more point that is often missed: data packs and monthly plans can coexist. If the monthly allowance runs out mid-month, adding a data pack is more flexible than upgrading outright, especially when only a few days remain. The two billing shapes are not mutually exclusive options but tools you can combine month by month.

Device sharing: how far one account reaches

The device chapter looks like the simplest one, but it is where misunderstandings start — because “unlimited devices” is easily read as “unlimited resources”.

What unlimited devices actually solves

Traditional subscriptions charge per device: one licence each, so three computers and two phones at home means five purchases. Plans from this service are not limited by device count, so one account can be online on several devices at once at no extra charge. It solves “many devices”, not “many people”, and it does not change the fact that the traffic allowance and exit bandwidth are shared.

Where sharing ends

One account covering family members who live together is reasonable use. Sharing an account with people elsewhere brings two real risks: once the password spreads you cannot take it back, and several people sharing one exit look like a single IP to the target service — if one of them triggers a risk-control rule, the whole account is affected.

Registration needs only a username and password, with no email address required, which keeps the barrier low and also means the password is the only credential. Use a password manager to generate and store a unique password, and do not reuse one from elsewhere. This is the most basic rule of account security and the one most often skipped. For a fuller self-check on minimising what you hand over at sign-up and payment, the site's privacy VPN guide has a longer checklist.

Platforms and typical scenarios

Household sharing in practice

When several people at home use it, confirm the route works on one always-on device first, then import the subscription to the others. Do not put every device on the same route — video, meetings and downloads place different demands on a link, and separating them means less interference. If there are many devices, take the 500GB tier directly and avoid topping up mid-month.

One more thing worth stating plainly: more devices does not mean more traffic. What really consumes traffic is video and sustained downloads; chat, email and document sync use very little. Whether to upgrade depends on how many hours a day you move large files, not on how many devices you own.

One command for connection troubleshooting

On desktop, the easiest way to tell a route problem from a local network problem is to look at the path packets take. The same target over two different routes with different hop counts and directions usually means they really do take different upstreams.

# macOS / Linux: trace the path packets take between hops
traceroute -n example.com

# Windows: the equivalent command for the same path
tracert example.com

Put the two outputs side by side. If one of them is clearly longer across the cross-border hops, or shows timeouts, the problem is almost certainly the link rather than your local network. That result is also one of the most useful things to include in a support ticket.

After-sales: which promises you can check one by one

The point of this chapter is not to restate the terms but to give you a way to judge: which promises are real and which are just words on a marketing page.

The refund window is a promise you can verify

This service offers a 60-day refund with no questions asked. The number matters not because refunds exist but because of the length of the window: it covers a full billing period with room to spare, which means you have enough time to judge a route in real use instead of deciding within a few days of paying.

To judge whether a refund promise is credible, check two things: whether the window length appears on the terms page, and whether there is a clear way to apply. “Cancel anytime” that exists only in advertising and cannot be found in the terms usually comes with extra conditions in practice. The full wording is on the refund policy page; the body copy and the pricing page both say “60-day refund, no questions asked”, which is the same thing stated for different contexts.

Payment methods and registration requirements

Payment methods are Alipay / WeChat / USDT. The first two cover most people's everyday payment habits; USDT suits users who would rather not link a payment record to an account. There is no functional difference between them — all three activate the same subscription, and the choice only affects your payment habits and what record is left behind.

Registration requires no email address — a username and password are enough. The point of that design is data minimisation: the service does not need an email to identify you, so it does not need to store an identifier that links to your other accounts. The trade-off is that password recovery works differently from a conventional site, so you have to look after the password yourself. This was mentioned in the previous chapter and is worth repeating, because it is the single weak point in this account system.

How to describe a problem

When you open a ticket, state three things clearly and it will be handled much faster: which route (city and route type), which platform (Windows / macOS / iOS / Android / Linux), and what happens (it will not connect at all, it connects but one service will not load, or it is slow). “It doesn't work” cannot be diagnosed; “Hong Kong IEPL, on macOS it connects but one AI tool will not load” can.

Before opening a ticket, also check two things yourself: whether another route works, and whether another network works. Those two results immediately separate a route problem from a local network problem and save a round of back and forth. The help center is grouped into accounts and subscriptions, connections and faults, speed and routes, and billing and refunds, and most common questions are answered there directly.

More detailed account and billing questions are in the help center, organised as Q&A by category so you can look them up by symptom.

Spotting pitfalls: overselling, exit scams and inflated node counts

This chapter names no one and compares no specific providers; it only covers how to tell. The evidence is all in public information: billing structure, terms, and how the route list is written. Read those three and most traps can be avoided in advance.

Overselling: everyone slows down at peak hour

Overselling means selling far more users onto one exit than its bandwidth can carry. The typical pattern: everything is fine during the day, then at peak hour every route slows down at once and switching routes does not help. The reason is simple — all users share the same exit segment, and at peak times they queue.

The way to spot it is not the marketing but the structure: does the provider publish the mix of route types (how much dedicated, relay and direct), does it treat route count as the only selling point, and is the price too low to cover dedicated-line costs. Dedicated lines are billed by bandwidth and the cost is what it is, so an unusually cheap offering cannot be laying dedicated lines everywhere. That reasoning needs no insider information — matching price against route mix is enough.

Exit scams: the risk of long prepaid cycles

The longer the prepaid cycle, the more users lose if a provider stops operating. Warning signs include: only long-term plans, no short tiers; a refund window that is very short or simply absent; a single payment method that leaves no trace.

Conversely, a service that offers short cycles, writes its refund window into the terms page and supports several payment methods has far less incentive to disappear — it has to keep processing refunds and keep traceable transaction records. This site's approach is to offer monthly plans and data packs that never expire, and to write the 60-day refund into the terms.

Inflated counts: how node numbers get multiplied

Node count is the easiest metric to inflate. Three common tricks: counting several relays behind one entry point as several routes; counting different entry points in the same data center as different “countries”; and leaving temporary test nodes in the list long-term. The result is a long list with few usable entries.

Checking is straightforward: see whether the country-to-city mapping in the route list is specific, whether each route is labelled with a type, and whether the same city distinguishes dedicated from direct. Vague lists (“global nodes”, “data centers in many locations”) are easier to pad than specific ones. This service's route list is grouped by region with city and type on every route, so it can be checked item by item.

And another: treating unblocking as a blanket promise

Streaming unblocking depends on the exit IP and the target platform's risk controls; whenever a platform changes policy, a route's unblocking status can change. Services that write “supports every platform” as an absolute promise usually leave a disclaimer in the terms. The more credible approach is to list support platform by platform and say which routes are optimised for streaming. This site lists support by platform on the unblocking support page.

A side note: many people searching for the Chinese term “机场” (jichang, literally “airport”) are really looking for a long-running subscription service with clear billing and refund terms. The criteria are exactly the same as above — read the terms, the route structure and the refund window, not the adjectives in the marketing copy.

Before you order: a checklist you can tick off

The previous seven chapters need to converge into one concrete purchase. The checklist below can be ticked item by item; once everything passes, the choice is unlikely to go wrong.

Check each item

• I have written a one-sentence use case that names the services and the hours I use them most.
• I know which region the services I use sit in, and I have found the matching city in the route list.
• I have checked whether that city has a dedicated line or a better-quality relay, rather than only looking at the total route count.
• I have estimated my monthly usage and have a first choice among 60GB / 250GB / 500GB.
• I know the allowance resets monthly on my activation date, not on the calendar month.
• If my use is occasional, I have considered a data pack instead of a monthly plan.
• I know plans are not limited by device count, and I have planned which devices use which route.
• I have confirmed there is a payment method I can use (Alipay / WeChat / USDT).
• I know registration needs no email address, and I have a unique password ready.
• I have noted the 60-day refund window and know how to apply if it does not fit.

Decision matrix

This matrix is only a starting point. When you actually order, apply the previous chapter's reasoning too: if your usual region has no dedicated line, put the budget into allowance rather than route type; if your usage estimate is on the conservative side, buy the smaller tier first and top it up with a prorated upgrade.

The one-line conclusion