Route and protocol technical reference

What happens during a cross-border connection

Break a single request down and the data passes through five stages from your device to the target service: the client on your device → your local network (router, modem, wireless access) → your ISP's outbound link → the cross-border link → the exit node → the target service. You control the first two stages, your ISP controls the third, and only the fourth and fifth are what an acceleration service can actually optimise.

This is worth understanding: a cross-border acceleration service cannot change the quality of your home broadband, nor the response speed of the target service itself. What it can do is replace the "ISP outbound → exit node" segment with a more controllable path. So when things feel slow, work out which segment is at fault first — that beats switching nodes over and over.

Protocols and routes are two independent dimensions

Many discussions mix the two together, which makes them harder to follow. They are different things:

• Protocol decides how data is packaged, encrypted and handshaked. It is a software-layer agreement, and the same protocol can run over many different routes.
• Route decides which physical path the packets actually take, which data centres they pass through and where they cross the border. It is a network-layer fact, and any protocol can run over the same route.

An analogy: the protocol is like the envelope and sealing method you choose when posting a parcel; the route is the transport path the courier actually takes. A fancy envelope still arrives slowly if the road is jammed, and a smooth road won't help if the envelope doesn't meet the rules. Evaluate them separately; only the combination matters.

In this service's client the distinction is visible: every row in the region sidebar carries a route-type badge (dedicated / relay / direct), while the protocol is chosen separately below the current route card. That way you can fix the route and change only the protocol, or fix the protocol and change only the route, ruling out one variable at a time. The full route list is on the routes page.

Latency has four components

What users feel as "fast" or "slow" is mostly latency in technical terms. Latency is not a single number; it is at least four parts added together:

1. Physical propagation delay. Light travels through fibre at roughly 200,000 km per second — that is the hard limit. From eastern China to Tokyo, for example, the straight-line distance is about 2,000 km, so the theoretical one-way floor is around 10 ms and the round trip around 20 ms. In other words, 20–40 ms round-trip within Asia is already close to the physical limit, and there is very little room to push it lower.
2. Routing detours. Packets do not necessarily travel in a straight line. Routing on the public internet is determined by the peering relationships between carriers, and going via a third location is normal. A path that is 2,000 km as the crow flies may actually travel 5,000 km.
3. Queueing delay. Routers and switches have limited outbound bandwidth, so packets queue when traffic is heavy. Queueing delay rises quickly once link utilisation passes 70%, which is the main reason things slow down at peak hours.
4. Protocol handshake overhead. Establishing a connection itself takes round trips. TCP's three-way handshake plus a TLS handshake usually costs an extra one to two round-trip times. This part has nothing to do with route quality, but it can be compressed by choosing a protocol and reusing connections.

The first two are decided by the route, the third by route quality together with the time of day, and the fourth by the protocol. That is why "choosing a protocol" and "choosing a route" are separate jobs — they optimise different segments.

Jitter and packet loss affect the experience more than average latency

Average latency is only one of three metrics. The other two matter just as much:

• Jitter: how much latency fluctuates. A route averaging 60 ms with ±5 ms variation feels far better than one averaging 50 ms with ±40 ms variation. Video calls and real-time voice are the most sensitive to jitter.
• Packet loss: packets that never reach the other end. TCP-based protocols retransmit and reduce their sending rate when they see loss, and 1% loss on a long fat pipe (high latency, high bandwidth) can cut throughput by more than half.

So when you evaluate a route, don't just look at the latency figure — check whether its jitter and packet loss stay steady during peak hours. The routes page labels each route's type, and the type itself hints at its stability characteristics, which the route topology section below covers.

Design trade-offs of six mainstream protocols

No protocol is absolutely better than another; they simply have different design goals. The six below are the most common choices in clients today. There is one dividing line more important than any other difference: the first four are TCP-based, the last two are QUIC-based (that is, they run over UDP). That line decides how differently they behave on poor networks.

• Shadowsocks TCP / AEAD

  Lightweight encrypted proxy, lowest resource use, friendly to older devices.

• VMess TCP / multiple transports

  Feature-complete, supports complex routing rules, handshake overhead on the high side.

• Trojan TLS / 443

  Makes proxy traffic look like standard HTTPS, hard to fingerprint.

• VLESS TLS / lean

  Drops the built-in encryption layer, lighter handshake, strong throughput.

• Hysteria2 QUIC / UDP

  Tuned for lossy links, best at holding bandwidth.

• TUIC QUIC / UDP

  0-RTT resumption, reconnects fast after a mobile network switch.

Shadowsocks: the lightweight option that is good enough

Shadowsocks aims to be "good enough": a lightweight encrypted proxy that encrypts local traffic and forwards it to a remote node. It has no complicated handshake protocol, uses AEAD ciphers, and keeps per-connection header overhead very small.

The advantages are clear: simple to implement, low CPU and memory use, it runs on old devices and routers, and the client ecosystem is extremely mature. Its drawbacks come from the same place — restrained features. There is no native multiplexing, so every connection is established on its own; camouflage depends on plugins or the transport layer, and bare traffic has a fairly fixed signature.

Who it suits: routers, old phones, old computers, and scenarios limited to web browsing and light office work. If device performance is limited, Shadowsocks is often the least troublesome choice.

VMess: feature-complete but heavier

VMess is a protocol developed by the V2Ray project, and it is far more complete than Shadowsocks by design: it supports multiple transports (TCP, WebSocket, gRPC, HTTP/2) and full routing rules, so you can decide which route to use by domain, IP or port.

It uses a timestamped authentication handshake, and this is the part to watch: the client and server clocks must be roughly in sync, and a large drift causes authentication to fail outright. Many "it worked yesterday, today it won't connect" cases come down to a wrong device clock.

Handshake overhead is a little higher than Shadowsocks, and establishing a connection takes more round trips. That cost is worth it when you need complex routing rules; for simple proxying it is on the heavy side. Who it suits: users who need per-domain routing, multiple outbound rules, and are willing to spend time on configuration.

Trojan: making the proxy look like standard HTTPS

Trojan takes a completely different approach: instead of inventing new encryption, it disguises proxy traffic as standard HTTPS traffic and uses TLS directly. From the outside it is an ordinary TLS connection — because at the protocol level, it really is one.

The benefit of this design is a hard-to-fingerprint signature: the traffic looks almost identical to visiting a real website. The cost is deployment coupling — it must occupy port 443 and be configured with a valid certificate, so if another service grabs 443 there is a conflict.

In performance terms, Trojan's overhead comes mainly from TLS itself. TLS 1.3 handshakes in modern clients are already fast, and the real-world experience is close to VLESS. Who it suits: scenarios where proxy traffic should be hard to distinguish from ordinary HTTPS, and deployments that already have certificates in place.

VLESS: the lean, high-throughput route

VLESS can be thought of as a slimmer VMess: the built-in encryption layer is removed and encryption is left entirely to the transport layer (usually TLS). One less encryption layer means one less pass over the data, so CPU cost and handshake size are both smaller.

Paired with XTLS flow control, VLESS can skip one "decrypt then re-encrypt" step while forwarding, giving it some of the best throughput of the six. The trade-off is that it must be used with TLS — bare VLESS has no encryption and is not suitable on its own. Its configuration looks much like VMess, so anyone familiar with V2Ray-family clients will have no trouble.

Who it suits: modern clients, throughput-focused use, and setups that already have TLS. For everyday browsing and long-lived AI tool sessions, VLESS is a very solid default.

Hysteria2: built for lossy links

Hysteria2 is based on QUIC and runs over UDP. Its most notable feature is not encryption but congestion control: it uses an algorithm tuned for lossy links (the BBR family), so on long-distance cross-border paths with packet loss it holds throughput noticeably better than traditional TCP-based protocols.

The reason is that TCP reads every packet loss as "network congestion" and slows down to retransmit, whereas loss on cross-border links often has nothing to do with congestion — slowing down just wastes bandwidth. QUIC-based protocols can make smarter judgements in user space and tell "real congestion" apart from "random loss".

There are two costs: first, it runs over UDP, and some networks impose extra restrictions or rate limits on UDP, so real-world results can suffer; second, encryption and congestion control both run in user space, so CPU and battery use are a little higher than TCP-based protocols. Who it suits: long-distance cross-border paths, obvious peak-hour loss, and scenarios that need steady bandwidth, such as 4K streaming and large downloads.

TUIC: compressing connection setup to 0-RTT

TUIC is also QUIC-based, but its design leans towards speed: it compresses connection setup to 0-RTT, meaning that on session resumption it can send data without a full handshake.

This matters a lot on mobile. When a phone switches between Wi-Fi and cellular the connection breaks and is rebuilt; TUIC rebuilds faster, so in practice "you switch networks and the video keeps playing". Its ecosystem is smaller than the others, and client support is limited in places, so check that your usual client supports it before choosing it.

Who it suits: phones, tablets and other devices that switch networks often, and scenarios that need fast connection recovery.

Six protocols side by side

Connection setup speed and resource use

"It takes a second or two to connect" and "it's slow once connected" are two different problems: the first is handshake overhead, the second is route quality. This section covers the first, and its other side on mobile devices: battery.

The first connection costs several round trips

Opening a connection to an exit node doesn't start moving data with a single packet. Take TCP-based protocols:

1. TCP's three-way handshake costs 1 round-trip time.
2. The TLS handshake (TLS 1.3) costs another round-trip time.
3. The protocol's own authentication can usually ride along inside the TLS handshake.

So on a route with 60 ms round trip, the first connection's "meeting cost" is about 120 ms. You won't notice that when opening a web page, but if the client opens a new connection for every request, it adds up quickly.

Session resumption brings the cost under one round trip

TLS 1.3 supports session resumption: after the first connection the client and server exchange a ticket, and later connections can go straight into encrypted transport with a 0-round-trip handshake. QUIC-based protocols (Hysteria2, TUIC) support this natively, and TUIC makes 0-RTT a headline feature.

The practical effect: if the same client revisits the same node within a few minutes, there is almost no handshake overhead after the first time. That is also why "it's smooth once connected, but every reconnect takes a second or two" is usually not the route itself but something in the handshake path being slow — for example the client running a latency test, or the route list syncing.

Multiplexing: one connection for all requests

Multiplexing means running several requests at once inside one established connection. The upside is that only one handshake is needed and later requests reuse it; the downside is that if that connection has a problem, all requests suffer together.

Shadowsocks has no native multiplexing, VMess and VLESS support it, and QUIC-based protocols support it inherently at the transport layer. For everyday use, multiplexing mainly improves situations like "opening a page with lots of small requests" — for a first screen that loads dozens of resources, reusing the connection feels noticeably smoother.

Battery on mobile: three real sources of drain

Battery drain on a phone comes mainly from three places, in decreasing order of how much protocol choice matters:

1. Heartbeats and keep-alive. To keep the connection usable, the client sends small packets at intervals. The more often, the more battery used. A sensible range is once every few tens of seconds; doing it very often (say once a second) noticeably shortens standby time.
2. UDP and radio wake-ups. QUIC-based protocols run over UDP, and some mobile systems manage UDP power more aggressively, which can wake the radio more often. This is the main reason Hysteria2 and TUIC use a little more battery on mobile than TCP-based protocols.
3. Encryption and congestion-control computation. Both run in user space, so higher CPU use means more battery. Modern mobile chips handle this load easily, so this is the smallest factor in practice.

Practical advice: if the device mostly sits idle and only sends the occasional message, choose a TCP-based protocol; if you watch video or download for long stretches, the bandwidth advantage of QUIC-based protocols usually outweighs their battery cost.

Resource use compared

The round-trip counts in the table are relative descriptions at the protocol-design level, not measured results. Real experience also depends on the quality of the client implementation, the route's round-trip time and the device itself. Before switching protocol, make sure your client really supports it — partial support is worse than not switching at all.

Route topology: direct, relay and dedicated lines

Route topology is about which nodes packets pass through between the client and the exit node, and what kind of links they travel over. It decides how stable the route is during peak hours, which is often the real answer to "fine during the day, unusable at night".

Direct: shortest path, least controllable quality

Direct is the simplest topology: the client connects straight to an overseas exit node, and every hop in between is decided by public internet routing.

The advantages are a short path, low cost and flexible deployment. The drawback is just as direct: the cross-border segment is fully exposed to congestion and routing swings on the public internet. The same direct route may run beautifully at 3 a.m. and become barely usable after 8 p.m. Its behaviour depends on the peering quality between carriers and on how many people are using that path at the time. Treat direct routes as the "good enough" option, not the stability-first one.

Relay: trading one controllable hop for stability

The relay idea is to add an entry node between the client and the exit node. The client connects first to an entry point near it, and the entry node then carries the traffic to the exit node along an optimised path.

The benefit: the client-to-entry segment is usually within the same region or the same carrier network, so the path is short and good; the entry-to-exit segment is planned by the provider and can avoid the badly congested peering points on the public internet. The latency a user feels = client to entry + entry to exit, and both segments are more predictable than the single uncontrollable direct path.

The cost is one extra hop, which in theory adds a little latency. But during peak hours that extra hop often makes total latency lower, because it bypasses the congested point. Another advantage of relay routes is that the entry can be chosen nearby: with the same relay route, users in different regions can pick different entries, and the provider does not need a separate exit deployment for every region.

One thing to note: the quality of the relay node sets the ceiling for the whole route. If the entry itself is overloaded, no amount of downstream optimisation helps. That is also what is worth checking when evaluating a provider — for entries labelled as relay in the route list, what matters is not how many there are but whether the entries are spread out.

Dedicated lines: fixing the cross-border segment

A dedicated line (IEPL, International Ethernet Private Line) is the heaviest of the three topologies: the cross-border segment does not use the public internet but a private link leased by the provider from a carrier. That link has agreed bandwidth and quality targets and does not compete for the same egress with anyone else's traffic.

The direct result is stability: small latency swings, almost no peak-hour impact, and packet loss that stays very low over time. For applications that need to hold a connection for a long time (video calls, remote desktop, long AI tool sessions, large file transfers), the value of a dedicated line shows up as "it doesn't suddenly collapse" rather than "how fast the peak is".

The cost is money and coverage. Dedicated bandwidth costs far more per unit than the public internet, so it is usually deployed only in the regions and cities with the highest demand, and it will not be as widely spread as direct routes. In this service's route list, the entries labelled IEPL dedicated lines are concentrated in commonly used exit regions such as Japan, Singapore, the United States, Hong Kong and Italy — which fits the deployment logic of dedicated lines: put them where users go most.

How to choose between the three topologies

A practical rule for choosing: use relay by default, switch to a dedicated line when a task demands stability, and leave direct for light, latency-insensitive use. This service's client lets you switch route type straight from the region sidebar, with no need to re-import the subscription. To browse the full route list first, open the routes page and go region by region.

What causes packet loss and peak-hour congestion

Slowness at peak hours is the most common complaint about cross-border access and the most misunderstood. It is usually not the provider throttling you, but several explainable mechanisms stacking up. Understanding them helps you decide whether to change route, change protocol, or simply use a different time of day.

Egress bandwidth is shared

Peering bandwidth between carriers is limited and shared by all users. Between 8 and 11 p.m. home broadband use peaks: many people are watching video, downloading and gaming at the same time, and cross-border traffic rises with them. Once a peering link passes 70% utilisation, queueing delay starts to climb noticeably; past 90%, packet loss appears.

This explains a common pattern: the same route has steady latency during the day and multiplies at night. The route itself hasn't changed; what changed is how crowded the pipe it shares with everyone else has become.

Why packet loss costs more speed than you'd expect

In TCP's design, loss is treated as a congestion signal: as soon as loss is detected, the sender halves its window and then climbs back slowly. That works well on a LAN, but on a high-latency cross-border link it amplifies the problem.

The reason is the "long fat pipe" effect: on a link with high round-trip latency and high bandwidth, the sender must keep a lot of data in flight to fill the pipe. One loss halves the window, and the time needed to climb back is proportional to the round-trip time — on a route with 200 ms round trip, recovery can take several seconds. During those seconds throughput is half the peak or less.

So 1% packet loss can cost more than 30% of throughput on a high-latency link. This is the fundamental reason QUIC-based protocols (Hysteria2, TUIC) perform better in cross-border scenarios: they can make finer congestion judgements in user space, telling random loss apart from real congestion, so a single lost packet doesn't trigger a big slowdown.

The wireless access segment contributes loss too

Not all packet loss happens on the cross-border segment. Wireless access is the most easily overlooked part:

• Weak Wi-Fi signal. Through a load-bearing wall or far from the router, wireless retransmissions rise noticeably. It shows up as latency jumping up and down rather than being steadily slow.
• A crowded 2.4 GHz band. With many devices on the same band, channel contention brings random loss. Switching to 5 GHz usually fixes it immediately.
• Mobile network handovers. A phone moving between base stations has brief connection interruptions, and QUIC-based protocols recover faster.
• An underpowered router. An old router maxes out its CPU running encrypted traffic and becomes the bottleneck itself, which shows up as "everything got slower after connecting".

The way to check is simple: use the same device and the same route, and test once over Ethernet and once over Wi-Fi. If Ethernet is clearly better, the problem is in the wireless access segment, and changing routes won't fix it.

A troubleshooting order you can follow

1. Confirm the scope. Is everything slow, or only one site? If it's only one, the problem is most likely the target service or the path to it, not your route.
2. Change route type. Move from relay to an IEPL dedicated line. If it improves clearly, the original route was being hit by peak-hour congestion.
3. Change protocol. Move from a TCP-based protocol to a QUIC-based one (Hysteria2 / TUIC). If that helps clearly, the bottleneck was loss-driven slowdown rather than the link itself.
4. Change how you connect. Swap Wi-Fi for Ethernet, or move to the 5 GHz band. This step rules out interference in the local wireless segment.
5. Change the time. If none of the above helps, the whole period may genuinely be congested. Testing at a quieter time confirms it.

The order of these five steps matters: start with the step that has the widest impact and is easiest to do, then narrow things down. In most cases you can locate the problem within the first three. If troubleshooting means re-importing your subscription, the flow is on the setup guide.

Choosing protocols and routes by use case

The previous sections explained the mechanisms; this one turns them into a reference you can use directly. The core principle: first decide whether the scenario is most sensitive to latency, bandwidth or stability, then pick the protocol and route combination.

Web browsing and document work

These scenarios have many requests, each one small, and are sensitive to time to first byte. For protocol, VLESS or Trojan is recommended: both are TCP-based, handshake overhead is manageable, and with session resumption repeat visits are almost unnoticeable. A relay route is enough, unless relay entries in your region are also strained at peak hours.

If what you open are collaborative documents or online spreadsheets that hold a connection open, switch to an IEPL dedicated line. The bottleneck in those apps is not peak speed but "does it stutter while I type", and a dedicated line's low jitter is exactly the right fix.

AI tools and development

AI chat tools and code completion tools share a trait: a session may last from a few minutes to tens of minutes, with many small requests going back and forth, and if the connection drops the whole session context may have to start over. For these, stability beats peak speed.

The recommended combination is VLESS + an IEPL dedicated line. VLESS uses few resources on long connections, and the dedicated line keeps the session from being interrupted. If your network handles UDP well, Hysteria2 is also worth trying, since it holds throughput better on long-distance links. For proxy settings in command-line tools and development environments, see the article on developer scenarios.

4K streaming

Streaming needs sustained bandwidth: 4K playback usually needs a steady 25 Mbps or more, held for the whole session rather than spiking up and down. For protocol, Hysteria2 comes first, since its congestion control holds bandwidth better on long-distance links; use an IEPL dedicated line or a good relay route.

Another easily missed point is choosing the exit region. A streaming platform's regional library is tied to where your exit IP is registered, so the wrong region gives you "it connects but the content is wrong". When choosing a region, first look at where the platform actually has content, then check whether that region has a dedicated node. You can check region-to-route mapping line by line on the routes page.

Mobile devices and frequent network switches

Phones and tablets move back and forth between Wi-Fi and cellular, and between base stations. In these scenarios connection recovery speed matters above all. TUIC is the first choice, since its 0-RTT resumption makes reconnecting after a switch almost unnoticeable; if your client doesn't support TUIC, fall back to VLESS.

On routes, relay is enough — mobile networks already fluctuate a lot, so the stability advantage of a dedicated line is less visible there. If battery matters, prefer a TCP-based protocol, since idle heartbeats cost less.

Routers and multi-device sharing

When the proxy runs on a router, CPU and memory are hard constraints, so the lighter the protocol the better. Shadowsocks is the safest choice here: simple to implement, low resource use, widely supported by clients. If the router is powerful, VLESS is also worth considering.

This service's plans do not limit the number of devices, so a router, phone and computer can all be online at once without buying a separate plan for each. Traffic is shared and resets monthly on your activation date — if you route every device on the router through it, traffic will be used up much faster than on a single machine, so plan for that.

Use-case quick reference

Route and protocol settings in the client

This service's client turns all of the above into a few switches, with no hand-written configuration. This section explains which layer each switch maps to, and when to touch it.

Region sidebar and route-type badges

The left side of the client is the region list; each row shows a region and city plus a route-type badge:

• IEPL dedicated the cross-border segment runs on a private link, the most stable, good for long connections and streaming.
• Relay forwarded through a nearby entry, the default for everyday use.
• Direct straight to the exit node, shortest path, quality varies with the public internet.

The same region may offer several route types at once; in that case choose using the use-case table above. Switching routes does not require re-importing the subscription — the client simply rebuilds the connection.

Current route card and automatic route selection

The current route card above the main area shows three things: the exit city, the route type and the protocol in use. With the "Auto select route" switch on the right of the card turned on, the client picks a route in good current condition within the region you have chosen.

Automatic selection suits "I don't want to pick manually every time"; it does not suit "I need a fixed exit IP" — some services remember your login region, and frequent changes may trigger extra verification. When you need a fixed exit, turn automatic selection off and specify a route by hand.

Switching protocol

Below the current route card is the row of protocol chips, listing the protocols that route supports. One tap switches. Switching protocol rebuilds the connection and briefly interrupts established sessions, so don't do it casually during a meeting or a download.

If a protocol won't connect on your network, there are usually two reasons: the transport it depends on is blocked by the local network (for example, QUIC-based protocols fail when UDP is restricted), or your client version is too old to support it. For the second case, just upgrade the client; clients are available from the download page in the panel once you're signed in.

Device list and subscription sync

The device list at the bottom of the window shows the devices currently using the same subscription, each row with a platform icon and sync status. This service does not limit the number of devices, so the list has no length limit — it just shows you which devices are in use.

Subscription sync is automatic: when routes change, the client picks up the new list on its next sync, with no manual update needed. A monospaced line at the bottom shows subscription status and the traffic reset rule — traffic resets monthly on your activation date, not by calendar month. This is also explained on the plans page.

What to watch for with manual configuration

If you use a third-party client, you need to import the subscription link by hand. You get the link from the panel once signed in, and you should not post it in public — it is equivalent to your account credentials. The format looks like this (for illustration only, not a working address):

https://example.com/sub?token=YOUR_TOKEN&flag=clash

A few common issues when importing:

1. No nodes after importing. Usually the subscription link was copied incompletely and truncated at the end. Copy it again in full.
2. Nodes appear but won't connect. Check the client's protocol support. If the imported configuration contains Hysteria2 or TUIC nodes and the client version doesn't support them, those nodes show up but cannot connect.
3. It connects but is very slow. First confirm which route you are on, then work through the troubleshooting order above.
4. Fewer nodes after updating the subscription. Check that the subscription link hasn't expired, and that you haven't mixed subscriptions from different plans.

Glossary and further reading

Finally, the terms used on this page, collected in one place for reference.

Common terms

Round-trip time (RTT)

The time it takes for data to travel from the client to the other end and back, measured in milliseconds. It is the largest component of latency.

Jitter

How much round-trip time fluctuates. A route with high jitter feels worse than one with slightly higher but steady average latency.

Packet loss

Packets that were sent but never reached the other end. TCP-based protocols slow down and retransmit when they see loss; QUIC-based protocols can make finer judgements in user space.

Long fat pipe

A link with high round-trip latency and high bandwidth. TCP window recovery is slow on such links, so the throughput cost of packet loss is amplified.

Multiplexing

Running several requests at once inside one established connection, saving repeated handshakes. The downside is that a problem with that single connection affects more at once.

0-RTT

Sending data without a full handshake when a session resumes, cutting connection setup cost to a minimum. TUIC makes this a core feature.

Congestion control

The algorithm a sender uses to adjust its sending rate based on network feedback. Different algorithms interpret loss differently, which directly determines real throughput on lossy links.

IEPL dedicated line

International Ethernet Private Line. The cross-border segment runs on a private link and does not compete for egress with public internet traffic, giving the best stability and jitter performance.

Relay

The client connects first to a nearby entry node, which then carries traffic to the exit node along an optimised path. Trading one controllable hop for stability.

Direct

The client connects straight to the exit node, using public internet routing all the way. Shortest path, quality varies with the public internet.

Exit node

The server location where traffic finally leaves, which determines the IP region the target service sees.

Traffic reset date

This service's traffic resets monthly on your activation date, not by calendar month. If your activation date is the 8th, the next cycle starts on the 8th of the following month.

Further reading

This page is a systematic reference; if you want to go deeper from another angle, the site also has:

• Setup guide — the full main flow from creating an account to importing into a client; start here if it's your first time.
• Routes page — the full region and route list, grouped by area, with route types and streaming support marked.
• Plans page — full details of the three monthly plans and traffic packs, plus what every plan includes.
• How to pick a route — an introductory article on choosing nodes in three steps: region, route type, purpose.
• Ten beginner questions — the most frequently asked questions about multiple devices, traffic accounting, speed limits and subscription links.
• VPN buying pitfalls — what to confirm before ordering, and how to judge details like refund promises and payment channels.
• ChatGPT acceleration — a topic page on access and stability for AI tools, including settings advice for long connections.

About this page

This page covers general principles of protocols and routes. The round-trip counts and handshake overhead described here are relative comparisons at the protocol-design level, not measured conclusions for any specific network — real experience depends on your broadband quality, your region, where the target service is, and the time of day.

The only figures about this service are these: 110+ countries / 150+ routes, no limit on the number of devices, monthly plans from ¥9.9, traffic packs that never expire, a 7-day no-questions refund, support for Alipay / WeChat / USDT, and sign-up without an email address. No other number represents a commitment by this service.