Cross-Border Network Service Selection Guide

Start with the need: which kind of connection you are buying

When it comes to cross-border networking, far more people buy the wrong tier than pick the wrong provider. The reason is simple: most people order after looking at a price table and a few recommendations, without translating their own usage into something they can compare against that table. The result is either paying month after month for capacity they never use, or getting throttled mid-month every month.

This chapter does not evaluate any specific service. It does one thing: break the vague phrase “normal internet use” into five questions you can write down. Once you have answered all five, the comparisons in the following chapters actually mean something.

Type 1: information-gathering access

Typical activity: searching, reading documentation, looking things up, browsing forums, sending and receiving email, filling in forms. The pattern is many connections, small payloads, sensitivity to time-to-first-byte, and little sensitivity to sustained bandwidth. A page may transfer only a few hundred KB of real data, but it goes through a dozen or more requests; if any one of them stalls, the page stops halfway.

For this kind of use, the enemy is not slowness but disconnection. Two seconds slower is just a worse experience; a drop at the moment a form is submitted wipes out everything typed before it. So for this profile, route stability matters more than peak speed. Relay and direct routes both cover it; a dedicated line's advantage does not show, and there is no reason to pay extra for one.

Type 2: production-tool access

Typical activity: AI chat, code completion, collaborative documents, remote repository operations, cloud builds. The connection profile is completely different from the previous type: sessions last a long time, data arrives as a continuous stream of small packets, and a single conversation may run for tens of seconds to several minutes without a break.

Streaming is especially sensitive to packet loss and jitter. Lose a packet and the output pauses before resuming; high jitter shows up as text appearing one character at a time instead of in paragraphs. Upstream demand is also bigger than people expect: pasting a long document, uploading a screenshot, or submitting a large code context all consume upload bandwidth.

If this is your main use, money spent on route quality is the best value. That is also why the site has a separate AI Tools section — different services require different exit regions, so the logic for choosing a route differs too.

Type 3: content-consumption access

Typical activity: video, music, live streams. The pattern is long sessions, large volumes, and a high requirement for bandwidth stability. Because of buffering, this use is not sensitive to time-to-first-byte — a slow start is tolerable — but it is very sensitive to mid-stream speed drops: once the buffer runs dry, the spinner starts.

This is usually where the bulk of monthly data goes. In the same hour, video can consume dozens of times the traffic of web browsing. Chapter 3 gives an estimation method; you do not need to memorise numbers, just remember that video sets the order of magnitude. There is also a separate streaming support note on the site covering the exit-region requirements of different platforms.

Type 4: multiple devices and whole-home coverage

Typical setup: a TV box, a games console, a tablet, several phones and computers at home, with the hope that one configuration covers everything. The pattern is many concurrent connections but low load per device. The key here is not the individual device but the network entry point — either configure it on the router, or connect each device separately.

Each approach has its costs; Chapter 5 goes into detail. For now, confirm one thing: do you have devices at home that cannot run a client (TV, console, smart speaker)? If so, the router approach is effectively mandatory, and when choosing a service you should look first at how clearly it documents router configuration.

Write the need down as five questions

• Roughly how much data per month? Estimate as “hours per day × main use”; precision is not required.
• Which hours are concentrated? Daytime work, evening peak entertainment, or late-night downloads.
• How many devices online at once? Two and ten are two different solutions.
• Is there a device that is always online? Router, NAS, TV box all count.
• Which applications dominate? Web, AI tools, video, or a mix.

Write these five down and you can basically match them to the tier table in Chapter 4. If you cannot, that is fine too: run the smallest tier for two weeks; real data beats estimates.

Why start small and scale up

The site's monthly subscription starts at ¥9.9/month with 60GB, and when you upgrade mid-cycle the difference is prorated over the remaining days. The practical meaning: buy the small tier to validate, upgrade when you find it is not enough, and you will not overpay for buying early; buy the largest tier up front, by contrast, and unused capacity simply resets to zero at the end of the cycle.

So the sensible order is: smallest tier → observe for two weeks → decide whether to upgrade based on actual usage. That is also the first item on the decision checklist in Chapter 8.

Route types: IEPL dedicated, relay and direct

Data travels through many segments between your device and the target server. The local segment (device to router, router to ISP) is under your control; the cross-border segment is not, and it is exactly the segment most prone to congestion and jitter. Route type describes how that segment is handled.

The physical difference between the three approaches

IEPL dedicated line is an international Ethernet private line provided by a carrier. The cross-border segment runs over a dedicated circuit and does not pass through congested nodes on the public internet, with guaranteed bandwidth. You can think of it as a fixed channel between two locations: whether or not the outside is congested, this channel's capacity is reserved.

Relay splits the cross-border segment in two: first connect to an entry node near you (commonly Hong Kong, Tokyo or Singapore), then the entry node forwards to the final exit. The first leg is short and controllable in quality; the second leg follows an optimised path. Overall it is more stable than direct and cheaper than a dedicated line.

Direct connects straight to an overseas data centre. The cross-border segment is left entirely to public routing; which path it takes and whether it is congested depend on network conditions at the time. Lowest cost, widest variation.

How the cost structure feeds into subscription prices

Dedicated lines are expensive because of the monthly circuit rental. International private lines are billed on guaranteed bandwidth; even if you use it for not a single minute, the monthly rental is still due. The cost is fixed and high, so dedicated capacity is usually supplied in limited amounts or placed only in the higher-priced tiers.

Relay cost sits in the entry nodes. One entry can serve a large number of users, spreading the resource thin, which is why the price lands in the middle. The trade-off is that an entry node has a capacity ceiling and needs expansion when users grow quickly.

Direct cost is simply the bandwidth fee at the exit data centre — the cheapest. But cheap has a reason: it does not guarantee the quality of the cross-border segment, leaving the uncertainty to the user.

When the differences actually show

At ordinary hours the three route types feel much the same. Cross-border links are relatively lightly loaded during weekday daytime and late at night, and direct routes can perform well too.

The real dividing line is the evening peak. Public cross-border exits are most congested then, and direct routes vary most visibly — the same page that opens instantly in the daytime makes you wait at night. Relays vary less because the first leg is short and the second is optimised. Dedicated lines run on fixed circuits and are largely unaffected by public-routing congestion.

The second difference is jitter — the range over which round-trip time fluctuates. For web browsing, high jitter just feels “sometimes fast, sometimes slow”; for real-time voice, video meetings and streaming output, high jitter means stalling, dropouts and accumulating delay. Dedicated lines have the least jitter, which is the main reason they cost more.

The third difference is recovery after packet loss. Packet loss happens on any route; what differs is the length of the retransmission path. A dedicated line follows a fixed path, so retransmission is short; a direct route has to traverse uncertain public routing again, so recovery is slow.

How to tell which type a route belongs to

• Check the naming: labels such as “IEPL dedicated”, “relay” and “direct” are usually the type description. If there is no label at all, assume direct.
• Check whether entry and exit differ: entry in Hong Kong and exit in the United States necessarily involves forwarding, so it is a relay or a dedicated line.
• Check whether the same region offers several types: if Tokyo has both dedicated and relay options, the provider has built tiers and you can choose by need.
• Check the ratio of total routes to types: a list that is all direct is cheap, but expect evening-peak performance to be discounted.

The site's routes page groups every route by region and lists its type, so you can check them one by one. At the scale of 90+ countries / 190+ routes, the type distribution is itself a clue to the provider's resource structure.

A mixed strategy: you do not need the most expensive option all the time

Most people do not need all traffic on a dedicated line. A sensible approach is layered: daily browsing and reading go over relay; important meetings, large file transfers and operations that demand stability switch to dedicated. Most clients support rule-based routing, pointing different applications at different routes.

This costs far less than dedicated all the time, with little loss of experience — because the moments that genuinely need a dedicated line may amount to only an hour or two a day.

Bandwidth and concurrency: how much is enough

The answer to “is the speed enough” usually does not lie with the provider. There are four links in the chain of a cross-border connection, and if any one is the bottleneck, the whole thing stalls there. Knowing where the bottleneck is stops you from spending money on the wrong thing.

Three quantities that get confused

Subscription data allowance is how much data you can use in a month, measured in GB. Once it runs out you are throttled or suspended until the next cycle resets. It constrains the total volume.

Route bandwidth is how fast a route can go, measured in Mbps. It is a shared resource, used jointly by everyone on that route. It constrains instantaneous speed.

Local broadband is the upload and download bandwidth your ISP provides. It sets the ceiling.

The relationship between the three is that the smallest wins. No matter how large your allowance, if local broadband is only a few tens of megabits, you will not go faster; no matter how wide local broadband is, if route bandwidth is saturated you will still be slow. So to judge “enough”, first find out which one is the constraint.

How to estimate monthly data

Precision is unnecessary; a rough calculation that maps to a tier is enough. The method is: session length × consumption per unit time × number of sessions × days.

Web pages and documents consume little. An illustrated page is usually a few hundred KB to a few MB; reading dozens of pages a day often adds up to less than a few GB a month. Email, chat and form submissions are the same.

AI chat consumes less than intuition suggests. Plain-text conversations are in the hundreds of KB per session, and even heavy monthly use comes to a few GB. What really raises the figure is upload: pasting long documents, sending images, submitting large code contexts — these go upstream and push the volume up noticeably.

Video is the item that sets the order of magnitude. In the same hour, video can consume dozens of times the traffic of web browsing, and the gap widens as bitrate rises. A stream labelled 4K typically runs at several times the bitrate of 1080p, and an hour's consumption is substantial. So when estimating monthly data, calculate your daily video hours separately first, then add the other uses.

Two more large items are easily overlooked: system updates and cloud sync. A major version update can be several GB, and syncing photos and videos to the cloud uses data too. If these also run over the same route, remember to include them.

What concurrency and sharing really mean

The site's rule is unlimited devices: the same account can be signed in on multiple devices at once, with no extra device slots to buy. This removes a limit at the account level, not at the bandwidth level.

In practice: multiple devices can be online at once, but they share the bandwidth of the same route. Several devices streaming high-bitrate video at the same time would overwhelm any service — that is a physical limit, not an account limit. In a real household, two or three devices under heavy load already stretch bandwidth; the rest doing light browsing is the normal state.

So the value of “unlimited devices” is that you do not have to upgrade a plan just to add one more phone — not that the whole family can watch high-bitrate video at once. Understand that and you will not have unrealistic expectations of concurrency.

How to judge performance at peak hours

The same route can perform more than twice as well at one time of day as another. The test is simple: on the same device and the same route, do the same operation once in the daytime and once at the evening peak, and note the difference. If the difference is obvious, the bottleneck is in the cross-border segment; if both are equally slow, the bottleneck is probably local.

That is also why validation inside the refund window is recommended — 14 days is enough to cover two full weekend evening peaks.

Order for checking local bottlenecks

Before suspecting the service is slow, spend a few minutes ruling out local factors. The order is: wired or wireless, 2.4GHz or 5GHz, router performance, ISP-side throttling policy.

A wired connection rules out wireless interference. If plugging in a cable is clearly faster than Wi-Fi, the problem is Wi-Fi coverage or channel congestion, not the cross-border route. In dense residential areas the real throughput of the 2.4GHz band is often only a fraction of the nominal rate; switching to 5GHz often improves things immediately.

Router performance is also often overlooked. On older routers, enabling encrypted forwarding makes the processor the bottleneck, which shows up as “the bandwidth is clearly there, it just will not go fast”.

# First check whether the local gateway is stable (replace the address with your router's admin address)
# Linux / macOS use -c, Windows uses -n
ping -c 20 192.168.1.1

# Then look at round-trip time variation on the cross-border segment
ping -c 20 example.com

If the first command already shows non-zero packet loss, the problem is inside the local network — fix Wi-Fi or change the cable first. The second command shows the range of round-trip time variation: small variation means a stable link, large variation means the cross-border segment is jittering.

Billing models: monthly plans versus data packs

Cross-border network services bill in two basic ways: monthly by time, or by data pack. The two are not substitutes; they cover different usage rhythms. Work out which rhythm you are on first, then pick a tier against the price table.

How monthly plans work

A monthly subscription resets every month on the activation date: not the 1st of the calendar month, but one cycle counted from the day you activated. This matters when reconciling — if you activated on the 18th, your allowance refreshes on the 18th of each cycle.

The mid-cycle upgrade rule prorates the price difference over the remaining days. An example of the mechanism: with half the month left, upgrading from a lower tier to a higher one requires only the difference between the two tiers prorated over the remaining days, not another full month's payment. The practical effect is to lower the risk of “buy the small tier and see” — the cost of trying is kept very low.

How data packs work

Data packs are use-until-exhausted and never expire. Buy 300GB and it will still be there a year later; there is no end-of-month reset. They constrain total volume, not time.

This suits three kinds of people: low-frequency users who use little in a month; those who need a long-term backup channel; and those who travel or run short projects and need a temporary top-up. The downside is that there is no periodic refresh — once it is gone, you buy again.

How to choose among the three monthly tiers

¥9.9/month with 60GB is the entry tier. It suits a single person mainly using web and AI tools with occasional video. If daily video stays under an hour and other uses are scattered, this tier is usually enough.

¥18/month with 250GB is the middle tier. It suits one or two people sharing, with a regular daily video slot and several devices online. Compared with the entry tier, the headroom is enough to cover occasional large flows such as system updates and cloud sync.

¥28/month with 500GB is the high-volume tier. It suits family sharing, multiple devices and frequent video. The precondition is that you genuinely consume that much; otherwise the allowance is wasted at each cycle reset.

How to choose among the three data packs

The data packs come in three tiers: ¥158/300GB, ¥358/1000GB and ¥658/3000GB. The unit price falls with each step, so the more you buy the lower the unit cost — provided you use it up.

300GB suits low-frequency users as a long-term backup; at a dozen or so GB a month it lasts a long time. 1000GB suits people who travel often or need concentrated usage for a period. 3000GB suits those who want it as their main channel without being tied to a monthly cycle.

Mixed use

Monthly plans and data packs can coexist, and this is the most worry-free combination: the monthly plan as the daily main channel, the data pack as backup. In a month when the main allowance runs out, switch to the pack instead of upgrading on the spot; when travelling, you do not need to change your subscription for a few days' use.

Another pattern is seasonal: use a monthly plan in peak periods (a project phase, say) and keep only a data pack in quiet periods. The annual cost is lower than staying on a monthly plan all year.

Three common misreadings

• Reading “never expires” as “available forever”. It means the allowance has no expiry date, on the premise that the service itself is still running. That premise applies to any subscription product.
• Reading “unlimited devices” as “unlimited bandwidth”. Device count is an account-level limit; bandwidth is a physical resource. The two are unrelated.
• Treating a monthly plan as a calendar month. It resets on the activation date, similar to a credit card billing date, not on the 1st.

The three monthly tiers reset every month on the activation date, and mid-cycle upgrades prorate the difference over the remaining days; the three data packs are use-until-exhausted and never expire. The six tiers in the table cover most usage rhythms. If you are still unsure, start with the cheapest tier, run it for two weeks and compare the real data against this table — that beats any estimate. Full prices and inclusions are on the plans page.

Device count and family sharing

“How many devices can connect” is one of the most common buying questions, but the answer is often misunderstood. There are two kinds of device limit: account-level (how many can be signed in at once) and resource-level (how much bandwidth is enough for several at once). The first is product policy; the second is physical fact.

The boundaries of unlimited devices

The site's rule is unlimited devices: the same account can be signed in on multiple devices at once at no extra charge. This removes the annoyance of having to kick one device off when switching to another, and makes family sharing simple.

The boundary is in the use. An account is for one person or one household, not for providing service to others. Handing the account to unrelated people, or redistributing it, goes beyond the permitted use. This boundary exists in any subscription service; it is not specific to this site.

The other boundary is bandwidth: however many devices there are, they share the capacity of the same route. The previous chapter covered this; the conclusion bears repeating — unlimited devices does not mean unlimited bandwidth.

Two ways to do family sharing

Approach one: connect each device separately. Install the client on the phone, computer and tablet, and import the subscription on each. The advantage is simple configuration and mutual independence — one device having trouble does not affect the others; the disadvantage is maintaining each one, confirming subscription updates device by device, and the fact that TV boxes and consoles that cannot run a client are not covered.

Approach two: do it on the router. Configure once on the router and every device in the home automatically uses the same route. The advantage is that one configuration lasts, and every device (including those that cannot run a client) is covered; the disadvantage is that the router becomes a single point — if it fails, the whole home goes offline — and router performance caps the speed.

The practical choice comes down to two things: whether you have devices at home that cannot run a client, and whether anyone at home can maintain router configuration. If both answers are yes, choose the router approach; otherwise configuring each device is less trouble.

For the details of the router approach — main router versus side router, where to put the optical modem, and when you should configure each device separately instead — there is an article on the site: whole-home setup: hands-on testing and trade-offs.

How the five platforms differ

Windows and macOS are desktop clients; the difference is mainly the permission model. Windows needs administrator rights for the first install, then works normally; macOS requires you to allow the network extension manually in System Settings, and if that step is not completed the client will show connected while traffic does not go through the proxy — the most common trap on macOS. The site has a record of item-by-item testing by chip and OS version.

iOS uses a system-level configuration installed under the client's guidance; once installed, the connection status is visible in System Settings. Android's in-app service supports proxying only selected apps, which is useful for people who want only a few apps to use the cross-border route and avoid routing the whole phone.

Linux is usually provided as a command-line or desktop client and needs the appropriate system permissions. On servers, the more common approach is to configure forwarding rules at the system level rather than installing a graphical client.

Management habits once devices multiply

With more devices, three things get messy: an expired subscription that was never updated, old devices still signed in, and not knowing which device has the problem.

Three habits are worth building. First, give devices recognisable names instead of the default model string, so you can tell at a glance in the panel which is which. Second, update the subscription regularly — the client reads the route list from the subscription, and without a refresh it keeps using the old routes. Third, sign out on shared or borrowed devices after use rather than staying signed in long term.

None of these habits is technical, but they save most of the “I paid and still cannot connect” confusion. Clients are available from the download page in the user panel once you are signed in.

Refunds and support: what to confirm before paying

Cross-border network services are prepaid subscriptions: you pay first, use later. That structure means guarantees you can confirm before paying are worth more than promises made after. This chapter lists four things to confirm before ordering.

How long is the refund window

The site's rule is a 14-day no-questions-asked refund. The full wording is: within 14 days of the first payment you may request a full refund without giving a reason; the Terms of Service govern the details.

The practical meaning of 14 days is that it covers two full weekends. Cross-border route performance is strongly time-dependent; one day proves nothing. Two weekends are enough to test the evening peak, late night and weekday daytime, and then decide whether to stay.

So the right way to use it is not “buy first and refund if it does not work” but “treat the 14 days as a structured trial”: use it normally in the first week and note which hours are slow; verify in a targeted way in the second week, and request a refund within the window if you are not satisfied. Chapter 8 gives a concrete validation checklist.

What the payment methods mean

The site supports Alipay, WeChat Pay and USDT. The first two are the most common channels in mainland China, with fast settlement and a transaction record you can check; USDT is for people who prefer not to use fiat channels.

How stable the payment methods are is also an observation point for whether a service can operate long term. If payment channels change frequently over a period, it usually means something is wrong on the channel side and is worth noting.

Registration requirements

The site's registration requirement is: no email address needed — a username and password are enough.

This looks like a small detail but affects two things. First, the length of the process: one less verification step can mean the difference of a minute or two between deciding to try it and actually being connected. Second, information retention: no email needed means the service does not hold your email address, and cannot use it for marketing later.

For someone who just wants to try it, the barrier is low enough — nothing extra to prepare, just think of a username and start. The connection itself uses military-grade encryption, and the corresponding protocol information is visible in the client.

Support and the order of self-troubleshooting

The sensible order when something goes wrong is: help yourself first, then ask for help. The reason is not convenience but that self-checks produce more information and make the subsequent conversation faster.

1. Start with the Help Centre. Account, connection, speed and billing each have their own entries, and most common cases are solved at this step.
2. Then check the relevant platform chapter on the Tutorials page. Installation and import problems cluster around a few steps.
3. Finally, open a ticket in the panel. Include the platform, client, route name, symptoms and time of occurrence — far more useful than “it will not connect”.

“Symptoms” should be specific: does the client show connected but pages will not open, or does it not connect at all; is everything slow or only a few sites; is it all day or only at the evening peak? These three descriptions point to completely different causes.

Judging whether a service can operate long term

There is no 100% test, but several things are worth watching: whether announcements keep being updated, whether the route list is genuinely expanding, whether prices are relatively stable, and whether payment channels remain continuously available. A service stable on all four will most likely keep running; if three of the four are abnormal, be cautious.

This applies to any provider, including this site. The next chapter turns these observation points into a table you can check against.

Common pitfalls: how to spot overselling, inflated counts and operational risk

This chapter covers several problems common in the industry and is not aimed at any specific provider. The aim is to give you a workable set of checks — rather than trusting marketing copy, verify for yourself.

Overselling: the most common experience killer

Overselling means selling more subscriptions than the routes can actually carry. It is not necessarily malicious: expanding capacity takes time, and short-term overselling is common when users grow fast. The questions are how far it goes and whether there is a scheduling mechanism.

The typical symptom of overselling is a time-of-day pattern. Everything is fine in the daytime, then everyone slows down at the evening peak; weekdays are acceptable, weekends clearly worse. Those are the hours when users come online together and shared bandwidth is saturated.

The way to identify it is comparison: on the same device and the same route, do the same operation once in the daytime and once at the evening peak, and note the difference. If the difference is consistent and large, that route's capacity is tight; if it is not obvious, there is headroom.

To be clear: a reasonable degree of resource sharing is normal in the industry and is why prices can be low. Demanding a completely exclusive route would raise the price by an order of magnitude. What you want to avoid is “oversold to the point of being unusable”, not “a little sharing”.

Inflated node counts: a big number does not mean more choice

Advertised node counts often mix different measures: some count countries, some cities, some data centres, and some split different entry points in the same data centre into several routes. There is no common standard, so the numbers cannot be compared directly.

There are three checks. First, see whether the list expands to specific cities. If there are only country names and no cities, a whole country is probably counted as one node. Second, see whether the same city appears with a lot of numbering. Ten routes split out of one data centre still give you one usable exit. Third, look at the distribution of route types. A list that is all direct has a cost structure that will discount its evening-peak performance.

The site's figures are 90+ countries / 190+ routes; the routes page groups them by region and labels each with city and route type, so you can check. That scale is not the largest, but every route can be found in the list.

Warning signs of operational risk

A service rarely stops operating suddenly; there are usually traces beforehand:

• Announcements stop for a long time. A normal service keeps posting maintenance, capacity expansion and route change notices.
• Payment channels change frequently. Problems on the channel side usually show up first in how payments are collected.
• Support channels shrink. From several channels to one, then to no response for long periods.
• Unusually large price cuts. Cutting prices sharply without a fall in costs usually means cash is being brought in quickly.

These are probability signals, not verdicts. One signal alone is no reason to panic; several at once call for caution — especially if you have already paid for a long period or bought a large data pack.

The language of “forever” and “unlimited”

“Never expires” means the allowance has no expiry date, not that the service will exist forever. Every subscription product rests on that premise; the difference is only whether it is stated clearly.

“Unlimited data” in the industry usually comes with a fair-use clause: throttling after a certain volume. This site has no unlimited product; all six tiers have explicit allowances, which is something you can check item by item — a stated allowance is easier to verify than “unlimited”.

Subscription link leaks

The subscription link is the address the client uses to read the route list, and it is itself a credential. If it leaks, someone else can use your allowance for free, and it is often hard to notice.

What to do: reset the subscription address in the panel, which invalidates the old one immediately, then re-import the new address on each device. If you notice abnormal allowance consumption, do this first before investigating other causes.

Two everyday precautions: do not post the subscription link in public places (forums, group chats, screenshots), and when taking screenshots be careful not to capture the address bar. There is an article on the site about getting, importing and updating subscription links for the details.

Self-hosting versus subscribing

This comparison comes up often; objectively, each has its costs.

Self-hosting gives you control: you choose the server, set the configuration and manage the data. The cost is time — choosing a data centre, installing the system, configuring protocols, dealing with unavailable addresses, monitoring availability; each takes effort, and when something breaks nobody handles it for you.

Subscribing buys peace of mind: you pay for a route that has already been tuned, with support when something goes wrong. The cost is a higher long-term price and dependence on the provider continuing to operate.

The test is simple: how do you value your time? If tinkering with servers is fun, self-hosting suits you better; if you just want stable access to a few sites, a subscription is better value. The two are not mutually exclusive — many people subscribe for daily use and self-host as a backup.

Decision checklist: from scenario to specific tier

The previous seven chapters set out the criteria; this chapter condenses them into a checklist you can follow. You do not need to remember every detail — just work through it in order.

A five-step decision process

1. Quantify the need. Write down five questions: monthly data, peak hours, concurrent devices, whether any device is always online, and which applications dominate. If you cannot, run the smallest tier for two weeks.
2. Choose the route type. For web and AI tools mainly, relay is enough; for meetings, large files and a hard requirement for stability, prefer dedicated; if budget comes first and use is light, direct is acceptable.
3. Choose the billing model. For steady monthly usage, choose a monthly plan; for scattered usage or a long-term backup, choose a data pack; the two can coexist.
4. Confirm the guarantees. How long the refund window is, whether the payment methods suit you, and what registration requires. Confirm all three before paying.
5. Validate on a small tier, then decide on an upgrade. Run the smallest tier for a full two weeks and decide whether to upgrade against actual usage. Upgrades prorate the difference over the remaining days, so you do not pay twice.

Paths for five typical scenarios

Single light user. Mainly web, documents and occasional AI chat, with under an hour of video a day. Path: ¥9.9/month with 60GB, relay routes first. This combination covers most daily use, usually with allowance to spare.

Family with multiple devices. Three or more devices, a TV box or console, and a regular daily video slot. Path: first confirm whether the router approach is feasible, then choose ¥18/month with 250GB or ¥28/month with 500GB. The more devices and video, the more you should move up a tier.

Heavy AI tool user. Long daily use of AI chat, code completion and long-document processing. Path: ¥18/month with 250GB, relay or dedicated routes first. This use does not consume much data but is sensitive to jitter, so route quality matters more than allowance. For exit-region choices, see how to choose routes for services with strict region checks.

Streaming first. High-bitrate video every day, possibly on several devices at once. Path: ¥28/month with 500GB. Video is the big consumer, and this tier's headroom covers most households' monthly usage.

Travel or temporary. Needed only for a few periods a year, unused otherwise. Path: a data pack, starting at ¥158/300GB. Use-until-exhausted and never expiring, so there is no “wasted this month” problem.

Three-step validation during the trial

Once you have the subscription, do not jump to conclusions. Three steps confirm most problems in a few minutes.

Step one: check the exit IP and its location. After connecting, look up the current exit IP and confirm the location matches the route you chose. If it does not, requests are not going through the proxy, or the route configuration is wrong.

Step two: check for DNS leaks. Sometimes traffic goes through the proxy but DNS queries still go out locally, with the result that the sites you visit still see your real region. It shows up as “I am connected, but some services still say my region is unsupported”.

Step three: test application by application. A browser opening pages does not mean every application goes through the proxy. The client's rule-based routing may exclude some apps; testing each one is more useful than a general speed test.

For the detailed method and common judgements for these three steps, the site has a complete three-step self-check guide, including several typical cases of “it looks connected but is not going through”.

When to upgrade and when to downgrade

The signal to upgrade is clear: two cycles in a row where the allowance runs out mid-month, or frequent interruptions because the allowance is insufficient. Upgrading under the prorated rule keeps the cost under control.

The signal to downgrade is equally clear: two cycles in a row using less than 30% of the allowance. The allowance resets to zero at the end of the cycle, so unused capacity is wasted. Drop a tier and put the savings into a data pack as backup — a more sensible combination.

Frequent tier changes are not recommended. Each change takes time to adapt to, and judging requires at least one full cycle of data.

The last step

The point of choosing is not to find “the best service” but to find “the tier that matches how you use it”. Route type sets the floor of the experience, billing model sets the ceiling of the cost, and the refund window sets the cost of trying. Get those three clear and the rest is execution.

If you just want to run through the full flow once, go to the Tutorials page and follow the steps; if you want to see prices and tiers first, go to the plans page; if you want to confirm coverage where you are going, go to the routes page and check route by route.

Prices, refund window, device counts, country coverage and route counts in this handbook are subject to the site's plans page and Terms of Service; route types and time-of-day performance are explanations of principle, and actual experience depends on your local network, your ISP and the destination service.