01 · Layers
Put the problem back into four layers
The same complaint — "the route is bad" — can point to four completely different places. Keep them apart and later judgements stop contradicting each other. This page is a technical reference organised in the order you choose: path first, then protocol, then device and client. If you are just getting started, read the main steps on the setup guide page, install the client and connect; come back here when you want to know why a choice is made or why speed varies.
What each layer covers
Physical and routing layer decides which cities, carriers and exchange points your data passes through from local to exit. It sets the floor on latency and determines which segment queues up at peak hours. Changing client or protocol cannot change the path at this layer.
Transport layer is TCP or QUIC (UDP) and the congestion control behind them. It decides how loss is repaired, how the window grows, and how multiple requests share one connection. Much of the "fast, then slow" feeling comes from this layer.
Proxy protocol layer is the names: Shadowsocks, VMess, Trojan, VLESS, Hysteria2, TUIC. It decides authentication, whether TLS wraps the outside, whether multiplexing is used, and how much extra header there is. A protocol does not change the physical path, but it changes handshake count, retransmission behaviour and CPU cost.
Client and device layer covers OS version, permissions, Wi-Fi signal, router NAT table, power-saving policy, DNS settings and MTU. This layer is the easiest to overlook, because on a different device the earlier configuration looks identical yet behaves differently.
Terms that get mixed up
Node is a connectable server or entry; entry is the address the client connects to first; exit is the address a destination site sees; landing is the region where the exit sits. A route is the combination of paths from entry to exit — direct, relayed, or over a dedicated line. A protocol only describes how the client talks to the entry; what happens after the entry is decided by the route.
| Symptom you see | Layer most likely involved | First step |
|---|---|---|
| Every site is slow, worse at peak hours | Physical and routing layer, transport layer | Switch route type, note the time window |
| Only one site is slow or won't load | Destination site, exit region | Change exit region first, leave the protocol alone |
| Same route works on desktop, fails on phone | Client and device layer | Check power saving, permissions, Wi-Fi and system proxy |
| Gets worse right after changing protocol | Protocol layer, transport layer | Revert to the previous protocol, change one variable at a time |
This table is for narrowing things down, not a substitute for testing. Change one variable at a time, otherwise you cannot tell which one mattered.
Fix the layer first, then the cause. If every device and every protocol slows down at the same time, suspect your local network or congestion on the international segment first; if only one device or one app misbehaves, check the client and device layer first. Treating "the route" as the only explanation will miss half the problems.
02 · Protocols
Design trade-offs across six protocols
A protocol is not a brand, and newer is not automatically better. It is a set of conventions for authentication, encryption, transport and multiplexing. Below we cover the trade-offs rather than config snippets; option names differ between clients, but the reasoning is the same.
Lightweight forwarding: Shadowsocks and VLESS
Shadowsocks is simple at heart: a pre-shared key for AEAD encryption, forwarding TCP and UDP requests to the exit. It has no built-in multiplexing and no native TLS camouflage; overhead is low and implementations are mature, which suits routers, older devices, or cases where you only need stable forwarding. The trade-off is a thin outer profile that needs plugins or a relay to compensate; whether UDP forwarding works depends on the specific server and client implementation.
VLESS is more of a lightweight transport carrier: it does not encrypt on its own and hands the security boundary to outer TLS or REALITY; the header is small and state is minimal, and flow control such as XTLS can cut duplicate encryption. Its strengths are high throughput and low CPU, which suits long, heavy sessions — provided the outer layer is configured correctly. Without reliable TLS outside, VLESS does not magically provide encryption.
TLS-camouflaged: Trojan and VMess
Trojan puts authentication inside a TLS connection, so from outside it looks like an ordinary HTTPS visit. Its strength depends on the certificate, TLS version and server configuration, not on the protocol name. It suits setups with a domain, a certificate and a shared entry with a normal website; when misconfigured, handshake failures are harder to diagnose than with lightweight protocols.
VMess authenticates with a user ID and timestamp, carries more fields in the request header, and supports multiplexing. Compatibility is good and older clients work; the cost is slightly higher header overhead and implementation complexity, plus sensitivity to system time. With a large clock skew you can hit "the config is right but it won't connect".
QUIC-based: Hysteria2 and TUIC
Hysteria2 is built on QUIC (UDP) and pushes congestion control harder, so it fills the pipe more easily on links with heavy loss and high RTT. It supports connection migration, so a phone moving from Wi-Fi to cellular does not have to rebuild the connection from scratch. The trade-off is sensitivity to UDP quality: if the local network or carrier rate-limits or drops UDP, the experience degrades noticeably; QUIC runs in user space, so CPU and battery cost is usually higher than with lightweight TCP protocols.
TUIC also runs over QUIC and emphasises 0-RTT, multiplexing and connection migration, which suits frequent network changes and fast recovery. It is relatively new and implementations differ more between clients; when something goes wrong, confirm the client version and UDP reachability before blaming the route.
| Protocol | Underlying transport | Security boundary | Resource cost | Best for |
|---|---|---|---|---|
| Shadowsocks | TCP / UDP | Pre-shared key, AEAD | Low | Routers, older devices, simple forwarding |
| VMess | TCP | User ID + timestamp, optional TLS | Medium | Older clients, multiplexing needs |
| Trojan | TCP + TLS | Password auth + real TLS | Medium | Domain and certificate, shared entry with a website |
| VLESS | TCP, outer TLS | Depends on outer TLS / REALITY | Low | High throughput, low CPU, long heavy sessions |
| Hysteria2 | QUIC(UDP) | TLS 1.3 | Higher | Weak links, heavy loss, mobile handovers |
| TUIC | QUIC(UDP) | TLS 1.3 | Higher | Frequent network changes, fast recovery |
Three common mistakes
Judging by protocol name, not the outer layer. VLESS without TLS has no encryption; Trojan's strength depends on the certificate and TLS configuration; Shadowsocks' plugins decide what it looks like from outside. The protocol name is just the door; the security boundary sits outside it.
Treating multiplexing as a cure-all. Multiplexing cuts handshakes, but head-of-line blocking on one TCP connection affects every stream; QUIC multiplexing avoids TCP head-of-line blocking yet depends on UDP quality. Interactive browsing and large downloads do not want the same connection strategy.
Ignoring the client implementation. The same protocol has different congestion control, buffers, log levels and battery policy in different clients. When "the same route works fine in another client", the problem is usually the implementation, not the protocol.
A protocol only covers client to entry. Whether traffic goes direct, through a relay or over a dedicated line after the entry is decided by the route. If it is still slow after cycling through protocols, go back to route topology instead of trying more protocols.
03 · Handshake
Connection setup and time to first byte
"Pages take seconds to open" and "large downloads are slow" are two different things. The first usually stalls at connection setup; only the second is about throughput. Splitting time to first byte apart tells you quickly which segment is slow.
How many handshakes one visit involves
The client first resolves DNS to turn a domain into an IP, then opens a TCP connection to the entry and completes the three-way handshake; if TLS wraps the outside, a TLS handshake follows; then the proxy protocol's own authentication and request header; the entry forwards the request to the exit, and the exit does DNS, TCP and TLS again with the destination site. The "first byte" a user sees is the sum of all these steps.
Local DNS and the RTT to the entry are usually short; entry-to-exit and exit-to-destination paths are longer. In other words, a slow first byte does not necessarily mean you are slow to the entry — the exit-to-destination segment may be queueing. Conversely, if the entry is nearby and the exit sits near the destination, first byte is noticeably shorter.
Connection reuse and 0-RTT
Browsers and clients both reuse connections: HTTP/2 runs multiple requests over one TCP connection, HTTP/3 runs multiple streams over one QUIC connection, and proxy clients may multiplex several requests into one tunnel. Reuse cuts handshakes but binds multiple streams to one connection; once the underlying link drops packets, every stream on TCP waits for retransmission, while QUIC only affects the stream concerned.
TLS 1.3 and QUIC support session resumption, so a second connection can send data early with 0-RTT. It does save a round trip, but it is not unconditionally faster: servers may reject 0-RTT data, and some networks are more cautious about replay protection. Treating 0-RTT as "always faster" leads to wrong conclusions.
Time, DNS and MTU
Clock sync affects VMess timestamp authentication and also TLS certificate validity checks. A large clock skew shows up as "the config is right but the handshake fails". Turning on automatic system time is the easiest fix to try.
DNS decides how long the first resolution takes and which entry you land on. A browser's own DoH may bypass system DNS, so the client and the browser see different addresses; when troubleshooting, first establish who is resolving.
MTU is the largest packet that still fits after encapsulation. Proxies add another header on top of the original data, so if the path MTU is small, large packets may be dropped — showing up as "small pages load, large files stall" or "TLS handshake completes, then no data moves". This is often misread as a slow route.
curl -o /dev/null -s -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n' https://example.comThis command tests one public example site and contains no account information. dns is resolution time, connect is the TCP handshake, tls is the TLS handshake, first is time to first byte, total is the whole thing. Run it a few times and take the median; that is more useful than a single result.
A slow first byte is not low bandwidth. Use the breakdown above to confirm whether it is DNS, the handshake or the destination's response; only when large transfers consistently fail to ramp up do you need to look at throughput and route congestion.
04 · Resources
Resource use and battery on mobile
Protocol comparisons often say "lightweight" or "efficient", but resource use is not a single number. It covers at least CPU, memory, radio wake-ups and power policy. The same protocol can behave completely differently on a desktop and an old phone.
Where the CPU goes
First, encryption. Devices with AES hardware instructions run AES-GCM cheaply; without hardware acceleration, a stream cipher such as ChaCha20 is usually cheaper. Second, TLS: handshakes, certificate checks and record-layer encryption all cost compute. Third, QUIC: it runs in user space and includes congestion control, retransmission and stream management, so CPU cost is usually higher than kernel TCP. Fourth, multiplexing and logging: more connections and more verbose logs mean more overhead.
So "VLESS is lighter than Trojan" only holds for a particular outer layer and client, and "Hysteria2 is faster on weak links" does not mean it saves battery on every device. Judge the whole chain, not the protocol name.
Where the battery goes
On mobile, battery is mostly consumed not by encryption but by how often the radio wakes up. Every heartbeat, every reconnect, every DNS lookup pulls the cellular or Wi-Fi module out of its low-power state. Too short a heartbeat interval keeps waking the device; too long an interval may be cut by NAT timeout, forcing a rebuild on the next request. Client defaults are usually a compromise — resist the urge to make heartbeats aggressive just to "stay online".
Network handovers cost power too: walking from Wi-Fi to cellular and back may break the TCP connection and force a reconnect; QUIC connection migration reduces rebuilds, but migration itself has to handle crypto state and path validation. Power-saving modes, background restrictions and low-power mode all affect whether the client can hold a connection in the background.
Choosing by device and scenario
| Device / scenario | Recommendation | Why |
|---|---|---|
| Old phone, long standby | Lightweight TCP protocol, enabled on demand | Avoids QUIC user-space cost and radio wake-ups |
| Laptop on mains power | Stability first, multiplexing is fine | Battery is not the bottleneck; fewer handshakes matter more |
| Phone switching networks often | A QUIC protocol with connection migration | Fewer reconnects and re-authentications |
| Router / older hardware | Shadowsocks or lightweight VLESS | Limited CPU and memory; simpler configs are steadier |
VPNVL monthly plans allow unlimited devices, so you can use several at once; but battery and performance remain separate problems per device and do not substitute for each other.
Habits that cut needless drain
First, split by need: route only the apps that need it and let the rest go direct, cutting unnecessary encryption and forwarding. Second, avoid double proxying: a proxy inside a proxy encrypts and forwards every packet twice. Third, turn off verbose logging: enable it when troubleshooting, keep defaults otherwise. Fourth, do not make "always on" the only goal: devices on mains power can stay connected, battery devices are better served by on-demand use. Fifth, update clients regularly: congestion control, reconnect strategy and power optimisations improve across versions, but do not chase every release — prefer stable builds.
Battery life is a combined result. Protocol, client, radio type, signal strength and background policy all affect it. Judging power efficiency by protocol name alone usually leads to the wrong conclusion.
05 · Topology
Route topology: direct, relay and dedicated lines
Route topology describes how traffic gets from entry to exit. It shapes latency, jitter and peak-hour behaviour more directly than the protocol name does. That is why VPNVL's server page labels routes as direct, relay and IEPL dedicated.
Direct: shortest path, dependent on peering quality
Direct means the client connects straight to the exit node — entry and exit are the same server or the same data centre. The upside is a short path, fewer handshakes and simple implementation; the downside is that the middle segment depends entirely on peering quality between your local carrier and the destination data centre. With good peering, direct is clean; with poor peering or peak-hour queueing, direct jitters too. Direct suits nearby destinations where the exit region matches the target site.
Relay: one extra hop for a steadier middle segment
With a relay, the client connects to the entry, the entry forwards traffic to a relay node, and the relay node reaches the exit. That is one hop more than direct and adds a little latency in theory; but relay nodes are usually placed where peering is better, replacing the "local carrier to international segment" leg with a more controllable path. The value of a relay is not the shortest path but stability: when direct jitters at peak hours, a relay is often smoother.
A relay has preconditions: the entry should be close to the user, the relay segment needs enough bandwidth, and the exit must satisfy the destination site's requirements. Congestion in any one segment cancels the advantage. So "relay" is not a fixed quality grade — it is a path design.
Dedicated line: a fixed channel, stability first
An IEPL dedicated line runs over a relatively fixed channel between entry and exit and does not compete with ordinary traffic for the same public peering segment. The advantages are low jitter and steadier peak-hour performance, which suits long meetings, cross-border work and anything sensitive to disconnects. The trade-off is higher cost, and it only covers entry to exit: your home Wi-Fi, local carrier and the destination site are all outside the dedicated line.
So a dedicated line is not magic. If the local broadband is already congested or the Wi-Fi signal is poor, the dedicated line cannot rescue the last leg. The right expectation: a dedicated line reduces the unpredictability of the middle segment and confines problems to the local and destination ends, which makes them easier to diagnose.
| Type | Path | Latency profile | Jitter and loss | Suits |
|---|---|---|---|---|
| Direct | Client → exit | Short path, depends on peering | May rise at peak hours | Short distance, matching destination region |
| Relay | Client → entry → relay → exit | One extra hop, but a more controllable middle segment | Usually smoother | Cross-border access, peak-hour stability |
| IEPL dedicated line | Client → entry → fixed channel → exit | Not aimed at the shortest path | Lowest jitter | Meetings, office work, long-lived connections |
Why the same route behaves differently in different cities
Because the last mile differs. Different carriers, neighbourhoods and access types all take different paths and peering quality to the same entry; within one city, fibre and mobile can behave in opposite ways. The server page lists route types and coverage regions, not a guarantee for every household. When choosing, check whether the entry is close to you first, then whether the middle segment is steady, and finally whether the exit matches the destination site's region requirements.
Pick a nearby entry first, then a steady middle segment, then check the exit. Choosing nodes by country name alone ignores entry and middle segment; choosing by latency number alone gets misled by momentary spikes.
06 · Congestion
Packet loss and peak-hour congestion
Latency, jitter, loss and throughput are four different metrics. Latency is how long one trip takes; jitter is how much latency varies; loss is packets that never arrive; throughput is how much gets through per unit of time. The usual peak-hour problem is not a broken server but one segment queueing, which pushes latency up, loss up and throughput down.
Why packet loss slows everything down
TCP treats loss as a congestion signal: on detecting loss it shrinks the congestion window, slows down, then gradually ramps back up. The longer the link RTT, the slower the recovery; the more frequent the loss, the harder the window grows. QUIC retransmits too, but it handles each stream separately, so loss on one stream does not make every stream wait; however, on networks that rate-limit UDP or drop it heavily, QUIC's advantage is cancelled out.
So "1% loss" affects different workloads very differently: real-time voice may just stutter occasionally, a large download may visibly slow, and interactive browsing shows up as "click and wait". Do not sum up the whole experience with one ping result.
Common causes at peak hours
First, congestion on the international segment: cross-border traffic concentrates at peak hours, public peering queues, and latency and loss rise together. Second, home upload saturated: family video, backup uploads and update downloads all lengthen router queues. Third, Wi-Fi interference: overlapping neighbour channels, distance and walls show up as loss and jitter. Fourth, router NAT table or session limits: old hardware slows down under many connections. Fifth, MTU mismatch: large packets are dropped while small ones pass. Sixth, UDP rate-limiting: QUIC-style protocols can be worse than TCP on some networks.
One more case is often overlooked: bufferbloat. A router with a large buffer raises latency while queueing without dropping packets, so a speed test looks fine while the actual feel is laggy. Fix it with queue management or rate limiting on the router; changing protocol helps only marginally.
How to tell whether it is peak-hour congestion
Start with time: if it only degrades between 19:00 and 23:00 and is fine during the day, shared-link congestion is more likely; if it is bad all day, suspect the local network, entry choice or device. Then change variables: switch route type at the same time of day — if relay or dedicated is clearly steadier, the middle segment is the problem; if every route behaves the same, check locally first. Then change medium: wired versus Wi-Fi, to rule out wireless interference. Finally change protocol: try TCP and QUIC once each to see whether UDP is rate-limited.
For diagnosis you can use the built-in network tools or a traceroute to see whether the path changes, but do not treat a single ICMP latency reading as a conclusion: ICMP may be rate-limited or take a different queue, so it is only a reference. What matters more is comparing the same time window, the same destination and different routes. To confirm your current exit address, see the network check page.
Peak-hour trouble is a capacity issue, not a fault. If one route is consistently unstable at peak times, changing route type beats reconnecting over and over; if every route is bad at the same time, look at your local broadband and home network first.
07 · Selection
Choosing protocols and routes by scenario
No single configuration fits every scenario. The recommended order is: choose the route, then the protocol, then tune the client. The route sets path and stability, the protocol sets handshakes, overhead and weak-link behaviour, and the client determines whether those capabilities actually show up.
AI tools and long-lived connections
ChatGPT, Claude and Gemini share one trait: they hold a connection open for a long time and then stream responses. They are not extremely sensitive to first byte, but they are sensitive to mid-conversation drops and re-authentication. Prioritise stability: relay or dedicated line plus Trojan/VLESS over TLS to reduce reconnects, and do not switch nodes mid-conversation. The exit region must satisfy the service's requirements, otherwise you may hit regional restrictions. For more detail, see VPN recommendations for ChatGPT.
Streaming and 4K
Streaming is about sustained throughput and the reputation of the exit IP. Direct or relay both work; the key is that the exit region matches the platform and the route has headroom at peak hours. Hysteria2 may be steadier on lossy links, but if the platform restricts UDP or data-centre IPs, a TCP protocol is less trouble. VPNVL's streaming support page lists available regions per platform — check it before choosing.
Cross-border work and meetings
Meetings are most sensitive to jitter and less to absolute latency. This is where an IEPL dedicated line earns its keep: a fixed channel reduces queueing and long connections rarely drop. Choose a TCP protocol such as Trojan or VLESS, and use client-side split routing to keep intranet and local services out of the proxy, cutting unnecessary forwarding. For travel, see the usage estimates and checklist in VPN recommendations for business trips.
Mobile and gaming
Phones hop between Wi-Fi and cellular constantly, so a QUIC protocol with connection migration is less hassle; but if you are unsure whether UDP is rate-limited, keep a TCP fallback ready. Gaming is about latency and jitter: pick a nearby entry, an exit in the same region as the game server, and prefer wired or 5GHz Wi-Fi; do not run downloads in the background.
| Scenario | Preferred route | Preferred protocol | Notes |
|---|---|---|---|
| AI Tools | Relay / dedicated | Trojan / VLESS + TLS | Stability for long connections, fewer switches |
| Streaming | Direct / relay | VLESS / Trojan | Matching exit region, headroom at peak hours |
| Cross-border work | IEPL dedicated line | Trojan / VLESS | Low jitter, with split routing |
| Mobile | Relay | TUIC / Hysteria2 | Connection migration, TCP fallback ready |
| Gaming | Direct / dedicated | Hysteria2 / TUIC | Nearby entry, same-region exit, wired preferred |
| Large downloads | Relay / dedicated | VLESS / Shadowsocks | Throughput first, avoid multiplexing bottlenecks |
Stability first
Relay or dedicated line + a TLS protocol
Suits meetings, office work and AI chats. Keep the connection alive first, talk about peak speed second.
Weak links first
Hysteria2 / TUIC + relay
Suits mobile use with heavy loss and frequent handovers; confirm UDP reachability first.
Lightweight first
Shadowsocks / VLESS + direct
Suits routers, older devices and simple forwarding; the less configuration, the steadier.
How budget and plans fit together
Selection does not only happen in the client; it happens at checkout too. VPNVL monthly plans reset traffic each month on the activation date: ¥9.9/month with 60GB, ¥18/month with 250GB, ¥28/month with 500GB; traffic packs are use-until-gone and never expire: ¥158/300GB, ¥358/1000GB, ¥658/3000GB. If usage is steady, take a monthly plan; if it swings or you want headroom, add a traffic pack. On a tight budget, see what the ten-yuan tier buys you first, then decide the combination.
When to change provider
If every route, every protocol and every device fails at the same time, check your local network and account status first; if only one route is unstable long term, change route; if only one protocol fails on a particular network, change protocol; only if all routes are congested at peak hours over a long period while other times are fine do you need to consider the provider's capacity. Making "change provider" the first reaction usually skips a simpler fix.
Choose the route, then the protocol, then tune the client. Reverse the order and you will keep tweaking parameters in the client while never replacing the segment that is actually congested.
08 · Troubleshooting
A layered troubleshooting flow
The goal is not to try every setting but to locate the problem with as few variables as possible. Work through the five steps below in order and keep a record of each; if it is still unresolved, contact support with that record — far more useful than "it won't connect".
- Define the scope. One device or all devices? One site or all sites? All day or peak hours only? Answer those three and the problem is already half narrowed.
- Check locally. Try wired and Wi-Fi once each; confirm automatic system time sync; confirm two proxies are not running at once; confirm DNS has not been rewritten by the browser or security software; confirm the router's upload is not saturated.
- Change one variable only. Route first, then protocol, then device. Record the result each time. Do not change route, protocol and DNS together, or you cannot tell which one mattered.
- Read the logs. Handshake failures, DNS timeouts, TLS errors and connection resets in the client log carry more information than "it won't open". Before screenshotting or copying logs, mask the subscription URL and token.
- Ask with details. Time, device and OS, route name, protocol, error message, and the steps you already tried. The more specific the information, the faster the diagnosis.
Common symptoms and fixes
Connected but pages won't load. Check DNS first: the browser's own DoH may bypass the client; then check whether the system proxy is only half enabled; finally check MTU, especially when small pages load and large ones stall.
Only one app fails. Check whether split-routing rules exclude that app; some apps use certificate pinning and reject proxy certificates; some use UDP only, and UDP may be unavailable on the current route.
Frequent disconnects. Phone power-saving policy, Wi-Fi roaming, NAT timeout and heartbeat interval are all candidates. Lift the power-saving restriction first, then compare networks; if it only drops on cellular, prefer a protocol with stronger connection migration.
Slow speed. Separate slow first byte from low throughput first; then check whether the device CPU is pegged; then Wi-Fi signal and the router; finally change route type. Do not stare at the protocol name.
Security and privacy boundaries
When troubleshooting, do not post your subscription URL, token or full logs to public groups or screenshots. VPNVL keeps no logs, but the subscription URL is itself an access credential — treat it like a password. When you need help, share only the route name, protocol, error type and time, never the credential.
FAQ
Same route: fast on desktop, slow on phone — is that the route?
It looks more like the device and client layer. Compare Wi-Fi and cellular first, check power-saving restrictions and background policy, then verify with another client. If the phone is slow on the same Wi-Fi too, look at the router and signal.
A protocol change made things slower — should I switch back?
Switch back to the original protocol first to confirm the difference, then judge whether the new protocol is restricted by the current network. QUIC protocols depend on UDP and can be slower on some networks; TCP protocols visibly slow down when loss is heavy. Compare at the same time of day against the same destination, and do not conclude from one page load.
Do I have to move to a dedicated line at peak hours?
Not necessarily. First check whether only peak hours are worse; if a relay is already steady, there is no need to upgrade. A dedicated line fixes jitter and queueing in the middle segment — if the problem is local broadband or Wi-Fi, it will not disappear.
What if UDP doesn't work?
Switch to a TCP protocol first to confirm the account and route are fine, then judge whether the current network restricts UDP. If you need a QUIC protocol, compare on another network or route; reconnecting repeatedly on the same network will not change UDP reachability.
Monthly plans or traffic packs?
Monthly plans reset each month on the activation date: ¥9.9/month with 60GB, ¥18/month with 250GB, ¥28/month with 500GB; traffic packs are use-until-gone and never expire: ¥158/300GB, ¥358/1000GB, ¥658/3000GB. Take a monthly plan for steady usage; add a traffic pack when usage swings or you want headroom.
How does the refund work?
A full refund can be requested within 60 days of the first payment, no reason required; the exact process and payout method follow the refund policy page. You do not need to give a complicated reason, but keep the order details so it can be verified.
Next steps. If the client is not installed yet, start with the setup guide; to compare prices and traffic, see the plans page; to pick a route by region, see global servers. VPNVL monthly plans start at ¥9.9 with 60GB, traffic packs never expire, 60-day money-back guarantee, no email address needed — a username and password are enough, with Alipay / WeChat / USDT accepted.