VPNYV Routes and Protocols

Connection layers: protocols aren't routes

Follow the request's actual path

When you open an international website, the app first determines which domain to reach. Client rules then decide whether the request uses your local network or a proxy. Traffic that needs a proxy enters the client, connects to a server in your subscription, and reaches the destination through that server's exit. The response follows the corresponding route back to your device. This process involves the app, DNS resolution, the proxy entry point, the transport path, and the destination server. A slowdown at any stage can leave a page loading without displaying content.

A proxy protocol defines how the client and server identify each other, specify the destination, and transfer data. The transport method determines how that data travels across the network, while route topology describes the network segments between the entry point and the exit. Names such as Shadowsocks and Trojan refer primarily to protocols; direct routes, relays, and IEPL dedicated lines describe how traffic is routed. Protocols and routes can be combined. A protocol label alone cannot tell you which dedicated route is in use or whether it will work well at peak times.

The client is another layer. Clients with similar interfaces may use different cores, DNS rules, and connection-management strategies. The same core can also behave differently across operating systems because of background scheduling and network permissions. To check subscription compatibility, verify that the protocol, transport method, and required fields are all supported—not just the client name. A successful import only confirms that the format can be read. Authentication, resolution, and transport conditions must also be met for a connection to work.

What regions, exits, and DNS resolution each do

The region shown for a route usually indicates the exit location. It does not represent the physical distance from your device to the server or describe the full path. The entry point may be closer to your local network, while the exit is in another region. The destination website may also route requests to different data centers. When choosing a region, first consider the destination service's regional rules, then compare connection performance through exits in the same region. Proximity is one factor, not a substitute for testing access.

DNS resolution determines which address an app tries to connect to. If DNS uses your local network while traffic exits elsewhere, the resolved address may not be suitable for that exit. If resolution fails, a healthy proxy path may still be unable to open the page. Split-tunneling rules may also send different domains through different DNS paths. When troubleshooting, distinguish between “the domain won't resolve” and “a known destination won't connect.” Repeatedly switching servers can hide a DNS configuration problem rather than fix it.

Also distinguish between an app proxy and a system tunnel. A system proxy is usually used only by apps that honor that setting. Tunnel mode takes over more traffic at the system network layer, but still depends on routing and exclusion rules. Games, work apps, and browsers may use different network paths, so browser access does not mean every app will automatically use the same route. Check the target app's actual connection rather than relying on a connection icon in the status bar.

First determine whether the issue is with the app, DNS resolution, protocol, or route, then change settings accordingly. Protocol names describe communication rules; route names describe path types. Neither alone proves that a particular international service will be accessible.

Keep a repeatable record of your tests

When comparing connections, keep the destination website, network, exit region, route type, and client mode consistent. Change only one factor at a time to see what made a difference. For example, keep the exit region the same and switch routes, or keep the route the same and compare system proxy mode with split tunneling. If you change the region, protocol, and network all at once, restored access won't reveal what caused the original problem—and it will be harder to repeat the fix next time.

VPNYV offers 100+ countries / 190+ routes. Check your user dashboard and current subscription for the available entry points and protocol combinations. Broad coverage gives you more options; it doesn't mean every route suits every task. See the full list on the Servers page. The comparison methods here can help you avoid random trial and error: check compatibility first, then the route, and finally whether the target app uses the expected exit.

Common protocols: features and implementation differences

Shadowsocks and VMess

Shadowsocks provides a relatively lightweight encrypted proxy tunnel that forwards the destination address and app data to a remote server. Its behavior depends on the cipher suite, client implementation, and any additional transport components. A simple native proxy layer doesn't mean every configuration has the same overhead. If the client uses a plugin, that changes connection setup and compatibility requirements too. Treat the plugin as part of the complete setup rather than evaluating the protocol on its own.

VMess has its own authentication and data-encapsulation mechanisms and is often combined with different transport methods. When you see the VMess label, check whether the outer transport is direct or uses components such as WebSocket or TLS. The outer layer affects handshakes, proxy-server compatibility, and troubleshooting. Some implementations rely on accurate system time for authentication, so a device clock that is significantly off can cause connection failures. If import succeeds but authentication fails, check the system time as well.

Trojan and VLESS

A common Trojan setup uses TLS to protect the connection between client and server, then handles authentication and destination forwarding inside the tunnel. The client must be able to reach the server and correctly verify its certificate and server name. This is not the same as a browser's complete behavior when visiting a website. Using TLS alone does not determine how the destination service will interpret a request. Keep certificate verification enabled; if you see a name or certificate error, first check the subscription fields and device time.

VLESS keeps its own authentication and data-forwarding mechanisms relatively simple, but does not include a general-purpose data-encryption layer. Deployments typically rely on secure transport at the outer layer. That makes the subscription's security settings, server name, and transport parameters important. To compare VLESS with other protocols, compare complete configurations. Comparing a setup without outer protection to one using TLS makes it difficult to assess resource costs and can blur the security boundaries.

Don't confuse encapsulation with multiplexing

The outer transport determines how proxy data reaches the server. Multiplexing determines whether multiple app connections share an underlying channel. Multiplexing can reduce the cost of repeatedly establishing connections, but congestion on a shared connection may leave more requests waiting. Its benefits differ between long-lived transfers and short requests, and implementations vary across clients. Unless you have clear evidence of a problem, avoid changing the subscription's multiplexing settings just to chase an abstract idea of “faster.”

A protocol's support for a type of traffic doesn't mean the system is actually routing that traffic through it. With UDP, for example, the result depends on whether the app is covered by the tunnel, the client has enabled the relevant forwarding, and the route and destination network allow it. If a game can't match while websites work, check the entire path. Switching to a protocol that claims UDP support may not solve a routing exclusion or client-permission issue.

You can't rank resource use by protocol name alone. Hardware encryption support, implementation language, buffer management, outer encapsulation, and concurrent connections all affect performance. When transferring the same content, a device may spend more time on DNS resolution, data copying, or app decoding than on proxy encryption. Without consistent test conditions, don't claim that one protocol uses fewer resources on every computer and mobile device. Prioritize full compatibility and predictable behavior.

In everyday use, keep the original subscription parameters and choose from the combinations it supports. If a problem occurs, use the client's error details to distinguish “unable to parse format,” “authentication failed,” “secure transport failed,” and “destination connection failed.” These point to different layers; they are not all signs of a slow server. If you need to import again, get the current subscription from your dashboard rather than manually adding fields and creating hard-to-check configuration variants. See the Guides for the basic import steps.

Hysteria2 and TUIC: QUIC trade-offs

UDP transport doesn't mean giving up reliable delivery

Hysteria2 and TUIC are both based on QUIC, but their protocol behavior and congestion strategies differ. QUIC runs over UDP and handles connections, security, and reliable stream delivery itself. It doesn't simply send data that needs reliable delivery without safeguards, nor does it make apps handle every underlying packet loss directly. This distinction helps separate two requirements: UDP must be allowed by the underlying network, and the upper layer must be able to deliver data reliably.

QUIC can organize multiple data streams within one connection, making it easier to isolate delivery blocking between streams than with a shared ordered byte stream. Network congestion can still reduce the capacity available to the entire connection, and streams still compete for the same route. QUIC changes how some blocking and connection management work; it doesn't create extra bandwidth. With QUIC as the outer transport, web requests still depend on DNS resolution, server response times, and destination network quality.

Hysteria2 bandwidth settings should suit the network

Hysteria2 offers transmission behavior tied to bandwidth estimates, and deployment parameters and configuration on both ends affect its actual pacing. Aggressive settings can create queues at a bottleneck and affect other apps on the same network; conservative settings may not fully use the available path. Don't copy bandwidth values from online posts, especially if they confuse a plan's data allowance with route bandwidth. Keep the parameters supplied in your subscription, and contact support to confirm suitable settings if something seems wrong.

Some networks allow UDP but throttle sustained traffic or clear idle mappings. The connection may work at first, slow down during extended use, or require reconnection after being idle. This does not automatically indicate an account-authentication problem. Keep the destination and exit unchanged and test on a different access network. If results differ between mobile and fixed networks, the underlying path is an important variable; then consider whether another transport method is worth trying.

TUIC's benefits depend on the implementation

TUIC uses QUIC for proxy communication. Connection management, UDP forwarding, and congestion control depend on the client and server implementations. Support for the same protocol name does not mean every configuration field is compatible. If the client reports an unsupported parameter after import, first confirm that the client can handle the configuration instead of deleting the field and proceeding. If a field is ignored, behavior may differ from what the server expects.

QUIC supports connection migration, but whether a mobile device can keep a connection going smoothly when switching from Wi-Fi to a mobile network also depends on the proxy implementation, system tunnel, network permissions, and server policy. The destination app may reconnect on its own as well. Migration support in the protocol design is not a guarantee that every network switch will be interruption-free. Check whether the task in progress resumes, rather than relying only on whether the client still shows a connection icon.

A working UDP path is one prerequisite for trying QUIC-based options. A protocol's design advantages have to hold up on your current network and client; the name alone can't replace testing the target app.

When is it worth comparing QUIC-based options?

If the same task frequently stalls over a reliable connection and you've ruled out DNS and app issues, try comparing supported QUIC-based routes. Keep the exit region, task, and access network as similar as possible, then check the initial page load, ongoing interaction, and longer transfers. Looking only at a momentary download peak can miss higher interaction latency or network queueing. A configuration that works for video may not suit an office app that sends frequent short requests.

On networks with restricted UDP, limited client compatibility, or unreliable background operation, another fully supported protocol combination is often the more practical choice. There's no need to change system settings just to use a particular protocol. Choosing a protocol isn't a race to use the newest technology; it's about finding an option that works reliably on your current network. If your current setup completes tasks consistently, keep a tested alternative route instead of switching back and forth and introducing new variables.

Direct, relayed, and dedicated routes: how paths affect performance

A direct route is shorter, but may not have less queueing

A direct route usually means the client connects straight to the remote entry point, without an additional relay arranged by the service. Its routing is relatively straightforward and can be easier to troubleshoot, but the route across networks is still determined by the networks along the way. “Direct” doesn't mean data travels in a straight line on a map or passes through only a few devices. Detours, limited peering capacity, and differences in return paths can make a nearby exit respond more slowly.

A direct route is a useful baseline: with fewer configuration variables, it helps show whether an extra relay actually improves the current path. But if peering between your local network and the remote entry is poor, fewer logical hops won't eliminate congestion. Capacity and queueing also vary by time of day. Compare the results of the same task rather than assuming direct routes always mean low latency or all relays are inefficient.

Relays optimize the route combination

A relay adds a service-managed forwarding step between the client and the remote exit. Your device may first connect to an entry point that's easier to reach, then use another path to reach the exit. Adding a hop means more processing, but the overall experience may improve if the relay avoids a poor-quality public network segment. To tell whether a relay helps, consider entry-point reachability, the link from entry to exit, and the final leg from the exit to the destination service.

A relay also introduces another potential point of failure. A reachable entry doesn't mean the remote exit is healthy, and a healthy exit doesn't mean the path between them is clear. If a route suddenly stops working, trying another entry in the same region may help; switching regions changes more variables and makes the problem harder to isolate. Route names can hint at the path type, but the full topology may not be public. Describe what you observe when troubleshooting rather than guessing the data center or carrier from a name.

A dedicated-route label isn't an end-to-end guarantee

Routes labeled IEPL dedicated lines generally indicate that a dedicated-link arrangement is used on a cross-region segment, helping distinguish that segment from some public peering routes. The connection from your device to the entry, the path from the exit to the international service, and shared-resource scheduling can still affect performance. Dedicated lines also have capacity limits and cannot guarantee how quickly a destination website handles requests. Be specific about which route conditions a dedicated line improves instead of describing the entire connection as exclusive.

Every route also depends on the return path. A request reaching its destination successfully doesn't mean the response can return under the same conditions; routing may be asymmetric. The latency and transfer results you see reflect both directions, so a diagram of the outbound path alone rarely explains the whole problem. Likewise, if an exit works well with one website but not another, the cause may be differences in connectivity between the exit and each destination—not necessarily a problem with the entire subscription route.

Choose a region based on the task

For services that restrict account regions, check the platform's supported regions and account requirements before choosing an exit. For everyday browsing and work, start by comparing routes that are easy to reach from your current network. Streaming also depends on content region and exit recognition, so a server's location cannot guarantee access to a particular catalog. Use the server page as a route-selection reference, then verify access based on your account, the service's regional rules, and the current connection.

To narrow down your options, first set the required exit region, then compare direct, relayed, or dedicated routes. If you don't need a specific region, start with a route that feels responsive and keep another route type as a backup. A route that worked well before may later become congested, but one failure doesn't discredit an entire category. Check current regions and entry points on the Servers page rather than assuming the examples in this article correspond to available server configurations.

Connection setup and resource costs: slow to start or slow to transfer?

Break down the initial wait

The first page-load delay may include DNS resolution, contacting the proxy server, establishing secure transport, completing proxy authentication, connecting to the destination, and waiting for the destination to respond. Different protocol combinations require different exchanges, and round-trip time along the route can magnify their cost. Record “the page takes a long time to start loading” separately from “downloads are slow once they begin.” The former may point to the connection setup; the latter is more likely to involve sustained capacity, packet loss, or the destination's response speed.

A slow first visit followed by a faster repeat visit may be due to cached DNS, connection reuse, or the destination app's cache—or the route may have recovered temporarily. A faster second visit alone doesn't prove that a protocol improved performance. Keep your steps consistent when comparing, and distinguish visits just after starting the client from those made over an established connection. On devices that frequently sleep and wake, an old connection may have expired; waiting for the app to time out and reconnect can add extra delay.

Connection reuse has benefits and shared costs

Connection reuse can reduce the work of repeatedly setting up an underlying connection, which may help with many short requests. But shared connections make multiple tasks compete under the same transport conditions, and packet loss or congestion can cause delays to spread across more requests in some setups. Whether to enable it and how to manage it depends on the full implementation and task. Copying a reuse setting from another configuration may conflict with your transport method or make an otherwise easy-to-diagnose problem more complicated.

QUIC-based transport uses different approaches to isolating blocking between streams, but still requires congestion control, data encryption, and buffer management. It doesn't eliminate device processing costs or bypass destination-side handling. If the route is unstable and connections frequently recover, the implementation may need more retransmissions and state management. Focus on whether the task completes smoothly; descriptions such as “a more advanced handshake” don't prove the device will use less battery or transfers will be faster.

Consider the device and task when assessing resource use

On a computer, check resource use across the client process, system network activity, and destination app. High processing load during video playback may be mostly due to decoding; scripts can also use substantial resources when a browser opens a complex page. Attributing every change to the proxy process can lead to the wrong conclusion about protocol differences. When comparing, pause unrelated background transfers, keep the destination content the same, and check whether resource use occurs only during connection setup or continues throughout.

Memory use is best judged by its trend, not a single snapshot. Active connections, DNS caches, rule sets, and buffers all use memory, so it may not drop immediately when you close a task. But if it keeps rising under similar workloads and causes lag or the system to terminate the client, note the pattern and report it to support. Mobile operating systems restrict background resources more aggressively. A reconnect after the client is terminated may be mistaken for the remote server disconnecting on its own.

“Slow to start” and “slow to transfer” call for different troubleshooting steps. Note where the delay occurs before comparing protocols. A single latency figure can't explain all the costs of DNS, authentication, app processing, and sustained transfer.

How to compare without drawing the wrong conclusions

Choose one short interactive task and one sustained task, then observe each separately. A short task might be opening the same page and submitting a routine request; a sustained task might be playing the same content or syncing the same file. Keep the access network, client mode, and exit region the same, then switch between supported protocol or route combinations. Don't download other content during testing or compare a first request with a result served from the app cache; those changes aren't caused solely by the protocol.

If resource use seems abnormal, change just one testable condition—for example, pause background syncing, restore the subscription's default settings, or restart the client. If the issue persists, note the protocol and network type shown in the client, along with the error message. Your troubleshooting notes can describe relative changes; there's no need to invent speed-test results. This guide doesn't rank protocols by performance because setup costs and sustained-transfer benefits can vary in opposite directions across hardware, network paths, and implementations.

Packet loss and peak-hour congestion: find the cause of fluctuations

Packet loss is a symptom; find out what caused it

Data may fail to arrive as expected because of wireless interference, a busy access network, overflowing router queues, routing policies, or an issue with the remote service. Reliable transport usually retries, but retransmissions take time and change the sending pace. You may see intermittent pauses on websites, fluctuating file-transfer speeds, or video buffering. A connection that hasn't dropped completely can still have a poor-quality path; frequent brief interruptions can significantly affect interactive use.

Wireless problems can be mistaken for proxy-route issues. A device that's far from the access point, crowded wireless conditions, or a local file upload can cause delays even when accessing a local service. Start troubleshooting by pausing unrelated traffic and comparing the same device on another network. If the local network is already unstable, switching remote routes may help occasionally but won't address the underlying cause. On a fixed network, also check whether the router is handling other heavy tasks.

Why queueing is more common at peak times

During busy periods, more traffic competes for limited access and peering capacity. Data may queue up before it can be sent; long queues add delay, while overflowing queues can cause packet loss. The bottleneck may be at home, in a carrier network, on a relay link or exit, or at the destination platform. If the same route works during the day but fluctuates at peak times, time of day is an important variable—but that alone doesn't prove the issue is on the service side.

Bandwidth and interactive latency can move in opposite directions. A large download can fill the link and make other short requests wait longer. Filling the local upload path can also delay acknowledgments and page requests. High sustained transfer speed doesn't automatically mean a better work experience. When comparing routes at peak times, check how quickly pages start responding, how fast you get feedback after input, and whether sustained tasks pause—not just whether a brief transfer reaches a particular peak.

Narrow down the problem by its scope

If every destination is affected, start with the access network, client status, and current entry point. If only one platform is affected, check its status, regional rules, your account, and the route from the exit to that destination. If one app has problems while the browser works, focus on the app's network behavior and split-tunneling rules. A clearer problem scope makes it easier to choose the next step. Reinstalling the client repeatedly can erase useful evidence, so it shouldn't be the default before you've identified the issue.

Give every connection test a clear purpose. Keep the exit region the same and switch entry points to compare the first part of the route. Keep client settings the same and switch access networks to compare local conditions. Keep the route the same and change destinations to check whether one target is affected. Repeat the same task after each change before drawing a conclusion. Changing several conditions at once can make a temporary recovery look like a lasting fix and makes it harder to tell support where the change occurred.

What diagnostic tools can and can't tell you

Interpret system connectivity-tool results in context. Some devices deprioritize diagnostic packets, and an intermediate node that doesn't respond doesn't necessarily mean app traffic was dropped. Conversely, a successful diagnostic response doesn't prove proxy authentication, secure transport, and the destination app are all working. Route probes may also be affected by asymmetric routing. Treat them as supporting evidence, not a final diagnosis based on a single hop.

At peak times, first distinguish between the local network, the proxy route, and the destination service. Compare the same task under consistent conditions instead of treating a one-off speed peak or a diagnostic response from an intermediate node as a substitute for the app's actual results.

When reporting a problem, include when it occurred, the access network type, current exit region, route category, affected app, and whether switching routes helped. Check client error details for subscription links, authentication fields, or account information, and remove sensitive data before sending. Contact support through the user dashboard. “Every page has slowed down” or “only one app fails when submitting” is usually more helpful than the vague description “the network is bad.”

Platforms and battery life: limits beyond the client

On desktop, first check what traffic is being routed

On Windows, macOS, and Linux, system proxy settings, app-specific proxies, and tunnel mode cover different traffic. Browsers generally follow the system proxy, while some games, command-line tools, and work apps use their own network settings. Tunnel mode also needs appropriate exclusion rules to avoid routing local devices or existing corporate network paths incorrectly. First verify that the target app actually uses the proxy; otherwise, you're comparing different network paths, not protocols.

After a desktop wakes from sleep, old connections, DNS caches, and network-interface state may no longer be valid. If only proxy traffic has a problem after waking, first confirm that the local network is back, then have the client reconnect. Work environments may also use a corporate tunnel or security software whose routing and DNS rules overlap with the subscription client. Don't disable all system protections just to restore the connection. Identify the conflicting setting and follow the requirements of your environment.

Mobile battery use has several contributing factors

Mobile battery use reflects wireless communication, screen activity, app workload, proxy processing, and background wake-ups. Continuous video playback uses power differently from occasional message checks, and a weak signal can increase the wireless radio's workload. Frequent reconnects, connection probes, and retransmissions may also use more power, but a protocol name alone can't provide a battery-life ranking. For a fair comparison, keep the content, network, and usage pattern the same. Watch for unusual heat and repeated interruptions to the task.

On Android, background-management and battery-optimization settings may restrict the client when the screen is off. Behavior varies by system and client, so follow the official settings guidance to check background activity and network permissions rather than granting every permission by default. iOS manages network extensions at the system level; network switches, sleep, and activity in other apps can affect the connection. On both platforms, check the task itself: an enabled status in the client doesn't prove that the background connection is continuously transferring data.

Test network switching and background recovery separately

When switching from Wi-Fi to a mobile network, entry-point reachability, UDP mappings, and destination addresses may all change. An app's upload or long-lived connection may also fail and restart on its own. Test recovery after a network switch as a separate task rather than stopping after a single test on a fixed network. If the issue only happens after switching networks, reconnect the client first, then check whether the app is holding on to an expired session. You may not need to change the exit region.

VPNYV has no limit on the number of devices that can be online at the same time, but all devices share the data allowance included in the plan. Tasks running at the same time also share local network capacity. No device limit means there is no restriction on the number of devices—not that each device gets its own data allowance or dedicated bandwidth. If mobile interactions slow down while a computer is syncing files, pause the sync and check again before blaming mobile protocol compatibility for a local network bottleneck.

Getting and protecting your subscription

Get the client and subscription through the download section of the user dashboard. Sign in to access your subscription. Don't post your subscription link in public discussions or paste it into an unverified conversion service; it may contain access credentials. Hide account and subscription details in troubleshooting screenshots as well. “Anonymous, no logs” is VPNYV's privacy messaging, not a substitute for securing your device, account password, and shared links.

For iOS client downloads and system permissions, see iOS Clients and Configuration Profiles. For Windows system proxy and split-tunneling options, see Windows Proxy Modes and Compatibility Tips. Check the platform setup first, then compare routes. This can help you avoid mistaking a permission failure, background restriction, or app-routing issue for a protocol problem—and reduce unnecessary reimports.

Choose based on your use case

For browsing and work, prioritize consistent interactions

Everyday browsing and work apps make many short requests, so initial response, feedback after submitting, and reliable reconnection often matter more than peak download speed. First choose a protocol combination fully supported by your client, then compare the same task through a fixed exit. If browsing works but a work app doesn't, check routing coverage and split-tunneling rules before trying a more complex protocol. Keep a stable route and choose a backup with a clear, practical difference.

For games and real-time communication, also check UDP forwarding, app routing, and the destination service's region. Being able to open websites doesn't mean the app's traffic is going through the proxy, and global mode shouldn't be taken to mean every game is automatically supported. First verify that the app connects as expected, then check delays and interruptions. If things only get worse while other devices upload heavily on the same network, pausing local activity may help more than changing protocols. If performance varies significantly across access networks, focus on the underlying path.

For AI tools, check the exit region and session continuity

AI tools may use exit region, account requirements, and session behavior to determine access. Network connectivity is only part of the picture. First check the platform's supported regions and account requirements, then choose an appropriate exit. Switching regions frequently can add variables to an active session, so it shouldn't be your default response to access problems. If a long response is interrupted, distinguish between a client reconnect, an expired web session, and the destination platform stopping its response rather than attributing every delay to route speed.

For services with stricter region checks, keep a verified exit route. If something goes wrong, narrow it down in this order: try another route in the same region, switch access networks, then check your account. Protocol choices support stable data transfer; they don't change the platform's account rules. See the AI Tools page for an overview. For Claude region checks and route-selection tips, see Choosing a VPN and Route for Claude. These tips do not guarantee access to third-party services.

For streaming and file transfers, check sustained performance

Streaming depends on content region, exit recognition, and sustained transfer. Opening the home page doesn't mean a specific title will play, and successful playback at first doesn't guarantee it will continue during busy periods. Keep content and quality settings the same when comparing routes, watch for repeated buffering, and check for other local transfers. For file downloads, check whether the task completes and can resume; a short-lived peak doesn't show that the entire route is stable. The destination platform's throttling and caching can also affect the results.

Mobile use also calls for testing network switches and screen-off behavior. A setup that works well on a fixed network may not suit a mobile network. QUIC-based options also need a working UDP path and client support. If a configuration reconnects frequently, compare it with another tested option rather than adding more custom parameters. The goal is to reduce interruptions and maintenance—not to cycle through every supported protocol.

Keep data-plan choices separate from technical choices

VPNYV monthly plans are ¥9.9/month for 60GB, ¥18/month for 250GB, and ¥28/month for 500GB. Data resets monthly on the activation date; mid-cycle upgrades are prorated by the remaining days. Data add-ons are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB. They remain available until used and never expire. Data capacity determines how much you can use, not the speed tier of a protocol. See the Plans page for full pricing and terms. Don't infer a route's bandwidth from the plan price.

Payment methods: Alipay / WeChat Pay / USDT. The service offers a 7-day no-questions-asked refund. No email address is required; you can create an account with a username and password. Keep these account and billing terms separate from connection choices. If you have access problems, first check your plan and subscription status, then follow the troubleshooting steps above. If your account is in good standing, compare the app, DNS, protocol compatibility, and route rather than repeatedly purchasing a plan to fix a technical issue.

A practical choice of route and protocol should come with clear reasons: why you chose the region, whether your client fully supports the setup, whether the transport method suits your current network, and how you'll test it with the target task. Understanding those factors is more useful than memorizing a protocol ranking.

Keep a short record of your usual tasks, primary route type, backup route, client mode, and troubleshooting steps that have worked. When your network environment changes, repeat the same checks. If you need help with the basics, return to the Quick-Start Guide. For account and subscription-link security, see Security Basics for Beginners. Separating setup steps, technical diagnosis, and credential management makes connection problems easier to pinpoint and explain to support.