Cross-Border Network Service Buying Guide

What this guide solves

This page and the Guides section play different roles. The Guides are one linear path: create an account, pick a plan, import the subscription in your client, verify that traffic really goes through the route — follow along and the service is up and running. This page does not repeat those steps. It answers the harder questions that come up before you order or renew: is the price gap between IEPL, relay and direct routes actually worth it? How should you read the bandwidth numbers in marketing copy? Which costs less, a monthly subscription or a data pack? When several devices at home share one account, do they compete for bandwidth? Which details in the refund terms decide whether you can actually get your money back? There is no single answer to these questions, but there is a reusable way to check them.

The criteria in this guide are not tied to any single provider. Specific prices, refund periods and device rules shown here follow this service's published terms, so you can compare providers in one table; everything else is general principle and applies to any provider. If you only want the conclusion, jump straight to the decision checklist in Chapter 8. If you are troubleshooting a specific problem, Chapters 3 and 7 are more relevant.

Pick a reading path by goal

• About to order: Chapter 2 (Route types) → Chapter 4 (Billing models) → Chapter 6 (Refunds and support) → Chapter 8 (Decision checklist). About twenty minutes for all four.
• Comparing providers: Chapter 3 (Bandwidth and concurrency) and Chapter 7 (Common pitfalls). These two chapters are your main tools for spotting inflated marketing claims — read them with a candidate provider's sales page open and check it line by line.
• Already using the service: Chapter 5 (Devices and family sharing) and Chapter 9 (FAQ), together with the connectivity check section in the Guides.
• Want technical detail: the three-segment breakdown in Chapter 2, read alongside the live route list on the Routes page, explains why the same service can feel very different depending on the direction you connect to.

Quick glossary

These terms come up again and again below. Defining them once keeps concepts from different layers from being compared as if they were the same thing.

Entry / Exit

The entry is the first hop where a connection is established, usually the one closest to you. The exit is where traffic finally leaves the service network and appears to the destination site — it determines the region the other side sees.

Route type

How the path between entry and exit is organised. There are three common tiers — IEPL, relay and direct — and the differences in cost and experience all come from this segment.

Bandwidth

The amount of data that can be transferred per unit of time. Distinguish peak bandwidth from guaranteed bandwidth, and dedicated from shared — they are not the same thing.

Concurrency

The number of simultaneous connections and the number of devices online at once. The first is a capacity of the route, the second is an account rule — the two are often confused.

Overselling

Selling one exit's bandwidth to far more users than it can carry. The symptom is a cliff-edge drop in performance at peak hours — the most common quality problem in consumer-grade services.

Data pack

A prepaid allowance billed by total volume and used until it runs out. It and time-resetting subscriptions are two different billing logics, suited to different usage curves.

Subscription link

A credential string containing your account's route configuration; importing it into a client syncs routes automatically. It is equivalent to your account credentials and should never be forwarded to public places.

Refund window

How long after ordering you can request a no-questions-asked refund. It decides whether you have a way out when the experience falls short, and says more about a provider's trustworthiness than any single speed test.

Three-minute check

If time is short, run through these six steps — they filter out most unsuitable options.

1. Start with your most common use case: work meetings, AI tools, streaming, gaming or large file transfers. The use case decides which route type matters most.
2. Estimate your monthly data volume to decide between a monthly subscription and a data pack.
3. Check that the refund window covers your trial period. This service offers a 60-day no-questions-asked refund.
4. Check that the route list is public and verifiable. This service offers 100+ countries / 170+ routes, listed region by region.
5. Check whether sign-up asks for unnecessary information. This service requires no email address — a username and password are enough.
6. Check that the payment methods work for you. This service supports Alipay / WeChat Pay / USDT.

Route types: IEPL / relay / direct

A single provider's route list often contains all three tiers at once, with prices differing several-fold — and experiences differing just as much. Understanding the difference between them is the most valuable section in this guide.

Splitting a cross-border connection into three segments

Any cross-border connection can be split into three segments: your device to the entry, the entry to the exit, and the exit to the destination site. The first segment is determined by your local network (home broadband, office network, mobile data) and no provider can optimise it. The third depends on the international capacity of the exit data centre and the routing to the destination site, which a provider can only partly influence. The segment a provider really controls is the second. Many arguments about whether a service is "fast" actually come down to the first and third segments, while marketing copy almost always talks about the second. Sort out who is responsible for what before discussing route types, and the picture becomes much clearer.

How the second segment is organised is exactly what "route type" means. It determines whether the path is fixed, whether you share public links with other users, and how much headroom remains when international exits are congested at peak hours.

Why IEPL costs more

IEPL (International Ethernet Private Line) is a point-to-point Layer 2 circuit. Data travels over a dedicated line, bypassing the public internet's exchange points and never competing with other users for the same public link. That gives three direct results: a fixed path, low jitter and little degradation at peak hours. The trade-off is that private lines are priced by bandwidth and cost a great deal, so IEPL capacity is scarce for every provider and usually covers only a few core directions, such as between major Asian cities.

Two things tell you whether a route is really IEPL. First, whether it is listed as its own high-priority tier rather than lumped in with ordinary routes under one name. Second, whether its peak-hour performance is clearly different from ordinary routes in the same direction. If a "dedicated line" feels no different from a direct route at peak hours, it is probably just an ordinary route with a new label. IEPL's value shows up not during the day but in the few hours when everyone is online.

Relay versus direct: the trade-off

Relay uses optimised data centres and paths on the entry side — typically a high-quality BGP facility plus tuned routing — to carry traffic to the exit data centre before it goes international. It does not monopolise a physical circuit, but the path is controllable with few detours, and the cost sits between IEPL and direct. For most everyday use it is the balance point. Direct routes go international straight from the exit data centre: the lowest cost, but the most exposed to congested international exits and circuitous routing, and the most visible fluctuation at peak hours.

The rule of thumb fits in one sentence: for latency-sensitive work, prefer relay or IEPL; for bandwidth-heavy, latency-tolerant work, direct is enough and usually better value; for everyday browsing and streaming in between, start with relay and move up to IEPL only if it is not enough.

This table only describes differences that come from how the path is organised. The same tier also performs differently by direction (Asia / Europe and North America), so judge by your own network.

How to verify a route is really in use

After switching routes, confirm that traffic really takes the new one — not that the client merely shows "connected" while traffic still goes out locally. Verification has three layers: check that the exit IP's location matches the route you selected; check that DNS resolution goes through the service rather than your local ISP; and make a real request in the target app, such as opening a streaming page for that region or confirming an AI tool returns content normally. All three must pass. The full steps, plus several typical cases of "looks connected but isn't", are broken down one by one in How to confirm your VPN is really working.

A mixed-route strategy

There is no need to lock a whole device to one route. Switching by task works better: relay or IEPL for daytime work, direct for evening downloads, and back to IEPL when you need low jitter. Per-app rules in the client can automate this — pin meeting apps and code repositories to a stable route, and send download tools and image mirrors over direct. The simpler the rules, the easier they are to maintain; a split-tunnel config with more than ten rules usually just creates trouble, because when something breaks you can hardly tell which rule did it.

Bandwidth and concurrency: how to read the numbers

Bandwidth is the number most easily inflated on a sales page. The number itself is not the problem — the problem is that one word is used for three different things.

Three meanings of bandwidth

Peak bandwidth is the link's ceiling under ideal conditions; guaranteed bandwidth is the floor a provider promises even under congestion; shared bandwidth is a pool several users draw from, where what you actually get depends on how many are online at that moment. Most consumer services sell shared bandwidth, which is not a problem in itself — the problem is whether they say so clearly, and whether the service stays usable at peak hours. When you see wording like "up to", remember it describes a peak, not the norm.

Concurrent devices and concurrent connections are two different things

Concurrent devices means how many devices are online on one account and using the route at the same time; concurrent connections means how many sessions are open at that moment — a browser loading one complex page can open dozens. The first is an account rule, the second is a capacity of the route. This service's account rule is unlimited devices, so device count is not a restriction; the route's concurrency is still finite, though. Run dozens of heavy connections through one exit — several devices downloading at once, several containers pulling images at once — and the bandwidth available to each connection is naturally diluted. Unlimited devices does not mean unlimited total bandwidth, and that matters most in a family-sharing setup.

Peak hours are the only meaningful test window

Speeds measured during the day tell you little. The tightest window for cross-border links is 20:00 to 23:00, when international exits are most congested and home networks are at their busiest too. To judge whether a route is reliable, test repeatedly at peak hours and look at how consistent the results are — not at the single best run.

You do not need third-party tools for this — the commands built into your system are enough:

# 20 consecutive latency and packet-loss tests (replace the domain with your target site)
ping -c 20 www.example.com

# Show the hop-by-hop path and where packets are lost (use tracert on Windows)
mtr -rw www.example.com

1. Start with latency and packet loss: ping twenty times and watch the packet-loss rate and how much latency varies. Packet loss says more about link quality than latency does — one occasional high reading can be ignored, sustained loss cannot.
2. Then look at the path: use mtr to spot obvious detours — reaching an Asian destination via Europe or North America, for example — and to see at which hop loss begins. Detours are usually harder to fix with client settings than insufficient bandwidth.
3. Finally, test throughput: download the same file once over a direct route and once over the route you are evaluating, and compare the time. Test both single-threaded and multi-threaded; the single-threaded result is closer to what everyday browsing and meetings actually feel like.
4. Log the time of day: run one round in the morning and one in the evening, and write the results down. Three days of records are far more useful than a single speed test, and they help you tell a persistent problem from a one-off.

How to read the six metrics

When to suspect bandwidth is oversold

If a route performs well in the early hours, drops off a cliff at peak hours and repeats that pattern for several days, the exit is almost certainly oversubscribed. There is a simple way to tell overselling from congestion at the destination itself: in the same time window, reach targets in several different directions — pick one in Asia and one in Europe or North America. If everything slows down at once, the problem is on the exit side; if only one target slows down, the problem is at the destination or on the route to it. Once you have done that, there is nothing left to guess.

Billing models: monthly subscription or data pack?

Your choice of billing model affects total spend more directly than your choice of route type, yet it is easier to overlook — many people default to a monthly subscription and then use less than a third of the allowance in half the months of the year.

The essential difference between the two billing models

Subscriptions bill by time and reset the allowance each period, which suits steady usage; data packs bill by total volume, last until used up and are not tied to time, which suits irregular use or heavy use in specific periods. Neither is better than the other — they match two different usage curves. The tiers this service currently offers are listed below; what you can actually buy is whatever the Pricing page shows at the time.

A monthly subscription resets its allowance on your activation date, not on the 1st of the calendar month. That hardly matters if you activated early in the month, but it matters a lot if you activated at the end: your cycle starts on your own activation date, so the allowance is never cut short by a month boundary. If you upgrade mid-cycle, the price difference is prorated by the remaining days — no need to wait for the next period. Data packs ignore time entirely: you are charged only for what you use, and nothing is wiped if you leave them untouched for months.

Estimate monthly data first, then pick a tier

You do not need precision — the right order of magnitude is enough. Per device, the main consumers rank roughly like this:

• Web browsing, document collaboration, messaging: the smallest consumers, usually not what decides your tier.
• HD video: the single biggest consumer. Each step up in quality roughly doubles the data, 4K is far above 1080p, and hour after hour it can easily eat a whole tier's allowance.
• Video meetings: moderate per hour, but they run long — several meetings a day add up.
• Cloud drive sync, system updates, container image pulls: a single run can consume a noticeable chunk, and this is the most under-estimated category.
• Online gaming: live matches use very little data; game updates and patch downloads are the real cost.

Add these up according to your own habits, leave a little headroom, and that is the tier to pick. If your estimate lands between two tiers, start with the lower one, watch actual usage for a month or two, and upgrade — the price difference is prorated by remaining days, so nothing is wasted.

When to choose a data pack

Three kinds of users are better off with data packs. First, seasonal users — people who only connect during business trips, holidays or a project. Second, light users who connect a few times a month, for whom a monthly fee mostly sits idle. Third, users who need a large allowance at short notice, such as a one-off data migration or a batch of downloads. Conversely, if you use the service every day at a steady volume, a subscription usually costs less per unit and is less to think about.

A practical test: look back at the last three months of usage. If your monthly volume varies by more than double, a data pack fits better; if it stays near one tier, just subscribe to that tier. The "lasts until used up, never expires" nature of data packs matches the first curve exactly.

Upgrades and renewals

When you upgrade mid-cycle, the price difference is prorated by the remaining days, which makes moving between tiers practical — no need to sit out a low tier to the end of the period just to avoid "wasting" it. Data packs have no upgrade concept; simply buy another when one runs out. One caution: with any billing model, it is unwise to stock up for a very long period at once. Chapter 7 explains why long prepayment is itself a risk exposure, and the two forms here — monthly subscription and data pack — already cover almost every usage rhythm.

Devices and family sharing

This service's account rule is unlimited simultaneous devices. You can use the same account on your computer, phone, tablet and home router at the same time — no per-device fee, and no logging in and out.

Where the unlimited-device rule ends

Unlimited devices means there is no cap on device count, not that the route has unlimited capacity. Every device on one account shares the exit resources of the route you are on, so the more run at once, the less bandwidth each gets. Three devices streaming video and ten devices downloading at once are completely different loads. Sensible habits: keep frequently used devices connected and disconnect the rest; schedule heavy tasks — downloads, syncs, image pulls — outside peak hours so they do not compete with meetings and live streams for the same exit.

Two ways to share at home

The first is to install the client on each device. The advantage is simple setup and per-device routes — the kids' video goes over direct while a parent's meeting goes over relay, with no interference; the drawback is that every device needs its subscription maintained, which gets fiddly once there are many. It suits households with a mix of device types and very different uses.

The second is to connect at the router so every device in the house uses the route automatically. The advantage is configuring once for the whole home, covering smart TVs and consoles that cannot easily run a client; the drawback is that the whole house shares one route with no per-device control, and router performance directly limits throughput — on low-end routers, forwarding capacity is often the real bottleneck. If you have a NAS, a TV box or a console, the router approach is less work; if you only have two or three computers and phones, installing per device is more flexible. Router setup has its own section in the Guides.

Account security and subscription links

A subscription link is equivalent to account credentials: whoever has it can import it and consume your data. When sharing at home, the right approach is to have family members import it on their own devices rather than posting the link in a family chat, a cloud drive or a notes app for long-term storage. If it leaks, reset the subscription in the user panel immediately — the old link stops working at once — then import the new one on the devices that need it. The full process for getting, importing, updating and handling a leaked subscription link is in The complete beginner's guide to subscription links.

Two more habits are worth forming. Give your devices recognisable names, so the connection log in the panel shows at a glance which is which; and clear out devices you no longer use. Both sound trivial, but they save a lot of time when you are working out why speeds dropped — at least you can tell which devices are using the exit.

Refunds and support: what protection to expect

The refund policy is the first thing to judge when deciding whether a provider is worth a long-term commitment, and it is faster and easier than running your own speed tests. The reason is simple: a speed test only reflects the moment you ran it, while the refund policy decides whether you have a way out when the experience falls short.

This service's support terms

• Refunds: 60-day no-questions-asked refund.
• Sign-up: no email address required — a username and password are enough.
• Payment: Alipay / WeChat Pay / USDT.
• Platforms: Windows / macOS / iOS / Android / Linux.
• Routes: 100+ countries / 170+ routes, with the full list published on the Routes page.

Four details to check in a refund policy

1. Window length. The window needs to cover your trial period, not just "seven days, no questions asked". What you really need to judge is peak-hour performance, whether your target apps work, and compatibility with your network — things a week often cannot cover. A 60-day window is long enough to span several billing cycles and to include real situations such as business trips and travel.
2. Whether it is really "no questions asked". Some policies say refundable but attach conditions — "unused data must not exceed a certain share", "first purchase only", "proof of fault required". The terms page should state its boundaries clearly; read it sentence by sentence rather than trusting the big type in the marketing copy.
3. The refund path. Is it submitted through a ticket, or only by messaging a support agent's personal account? The first has an ID and a timestamp and can be traced; with the second, if the other side stops replying you have no record. Refunds here go through the ticket system in the user panel.
4. Whether the terms match the marketing. "60 days" in the ad and "7 days" in the terms is a common gap. Comparing the two numbers is the quickest credibility check there is, and it takes two minutes.

How to make full use of the refund window

Treat the refund window as a planned trial rather than a "buy first, think later". Four things are worth completing inside it:

1. Test at peak hours three days in a row, logging latency, packet loss and how it felt. Three days of data separate the normal from the occasional.
2. Run your three most common scenarios once each: a meeting or remote desktop session, streaming from your target region, and the AI tools you rely on. Scenario tests mean more than benchmark numbers.
3. Import the subscription once on every platform you plan to use, and confirm the client works. This service supports Windows / macOS / iOS / Android / Linux.
4. If you plan to use the router setup at home, configure the router too and confirm whole-home coverage and forwarding performance are up to the job.

If all four pass, the route suits your network and you can renew with confidence. If any one fails, submit a ticket within the window — no need to wait for the last day, and no extra reason required. Verifying first and deciding after beats comparing sales pages over and over.

Support channels

Judging support quality comes down to whether the channel leaves a trace. The value of a ticket system is that every exchange has a record and a status, so issues do not drown in a chat log; with services that offer only instant messaging, the handling process is usually impossible to verify. Accounts, orders, tickets and subscription management all live in the user panel here, with history available after you log in. Self-service troubleshooting entries are collected in the Help Center; if that does not solve it, submit a panel ticket with the time window, the route and a description of the symptom, and it will be handled noticeably faster.

Common pitfalls: overselling, disappearing providers and inflated server counts

The earlier chapters were about choosing well; this one is about avoiding obvious traps. Three problems account for the vast majority of complaints: overselling, providers that disappear, and inflated server counts. All three have observable warning signs.

Overselling: the most common and the hardest to notice on the spot

Overselling means selling one exit's bandwidth to far more users than it can carry. The symptoms follow a pattern: normal in the early hours and during the workday, a cliff-edge drop at peak hours; latency that still looks acceptable but with obvious jitter and rising packet loss; a lower connection success rate and a client that keeps reconnecting. There are three steps to identify it: test at fixed times three days in a row; test different directions, one target in Asia and one in Europe or North America, and if everything degrades at once the problem is on the exit side; and check whether the provider separates route tiers — a service where every user is squeezed through the same public exit with no priority design at all is the most likely to be oversold.

There is limited mitigation: choose a service that offers several route tiers, put latency-sensitive work on IEPL or relay, and move heavy transfers to direct routes or off-peak hours. Overselling cannot be fixed with client settings — only by choosing and scheduling. That is why Chapter 2 on route types is worth reading first.

Disappearing providers: long prepayment is the biggest exposure

Providers usually leave traces before they vanish: they sell only long periods with no short-term option; prices sit clearly below the cost structure of comparable routes; terms and privacy policies are missing or contradict each other; payment is limited to channels that leave no trace; support appears only in a single private chat channel. One of these proves nothing, but two or three together are worth taking seriously.

The most effective mitigation is to control how far ahead you pay: prefer a service that offers monthly billing and data packs, keeping your exposure within a range you can absorb. A long refund window is the second layer of protection, letting you walk away when the experience falls short instead of staking a year's fees on an unknown. This service offers both monthly subscriptions and data packs, plus a 60-day no-questions-asked refund; together they mean you never have to accept a long lock-in just to get a lower unit price.

Inflated server counts

Server count is the easiest number to dress up, and there are three common tricks. The first is double counting: several routes in one city counted as several "servers". The second is counting entry data centres as servers: an entry is only a relay point and does not decide which region you appear in. The third is changing the IP without changing the region: the list names many countries while the actual exit locations cover only a few.

Checking is straightforward. Pick three routes in different regions at random, switch to each and look up the exit IP's location to see whether it matches the list; then check whether routes in the same region are duplicate entries for one exit. This service publishes its route list on the Routes page, listed as 100+ countries / 170+ routes, so you can verify it entry by entry and confirm it yourself after switching in the client.

Three more common problems

• Clients of unknown origin: installers from unclear sources, or ones that require you to disable system security settings before they will install. The risk from such clients far exceeds any problem with the route itself. The proper approach is to distribute clients through official channels and get your subscription from the user panel.
• Resold or shared accounts: an unusually cheap "shared account" is usually one subscription sold to several people, so everyone shares a single exit with no guarantee of speed or stability, and the account can be disabled at any time.
• Asking for too much information: collecting personal details unrelated to billing at sign-up is unnecessary and widens your exposure. This service requires no email address — a username and password are enough — and keeps payment to three options: Alipay / WeChat Pay / USDT.

Decision checklist: match the setup to your use case

The first seven chapters boil down to two actions: choose a route type and billing model for your use case, then check the provider against a list. The two tables below are ready to use as they are.

Pre-order checklist

1. Are route types publicly tiered and freely switchable in the client?
2. Is the route list verifiable? This service: 100+ countries / 170+ routes.
3. Does billing offer both monthly subscriptions and data packs? This service offers both.
4. Do data packs never expire? Data packs here last until used up and never expire.
5. Does the refund window cover your trial period? This service: 60-day no-questions-asked refund.
6. Does the device rule fit your household? This service has no device limit.
7. Does it cover the platforms you actually use? This service supports Windows / macOS / iOS / Android / Linux.
8. Are the payment methods usable for you? This service supports Alipay / WeChat Pay / USDT.
9. Does sign-up ask for unnecessary information? This service requires no email address.
10. Does support leave a traceable record? Tickets here live in the user panel, with history available after login.

Once the list checks out, only testing remains: after ordering, complete the four tests in Chapter 6 within the refund window. There is no shortcut here — no marketing claim can replace real experience on your own network. If you are ready to order, start by confirming current tiers and data allowances on the Pricing page.

FAQ

These are the eight questions asked most often about choosing and using the service. Answers are kept short; anything that needs more detail is covered in the chapters above.

For anything not covered here, start with the categorised answers in the Help Center; for questions about your account, orders or subscription, submitting a ticket after logging into the user panel is the fastest route.