Proxy Protocols and Network Routes: A Technical Guide

Connection Layers and Troubleshooting Order

From an App Request to the Exit Server

When you open a page in a browser, it usually resolves the domain name, establishes a transport connection, negotiates application-layer security, and requests the content. With a proxy enabled, the client must also determine which requests to route through it, send the data to a remote entry point, and let that server reach the destination. The request may pass through several distinct stages: your device, access network, proxy entry, exit network, and destination service. A problem at any stage can make a page appear to hang, but the fix depends on where it occurs. Understanding the request path helps distinguish a slow route from an account issue, DNS problem, or destination-service outage.

A protocol describes how the client and remote server agree on identity, encapsulate data, and handle transmission. The transport layer delivers data and retransmits it when needed—for example, as a reliable byte stream over TCP or with QUIC over UDP. Network topology describes the path from entry to exit, while the client’s mode determines whether app traffic can use that path. These concepts work together but are not interchangeable. Switching protocols won’t automatically change the account region shown to a website, and enabling a global proxy won’t shorten a physically distant route.

Tell Connection Failures, Slow Loads, and Ongoing Stalls Apart

If you can’t connect, first check whether a connection was established. If the client reports an authentication failure, check your subscription status and whether the configuration is up to date. If the connection to the entry point times out, check your local network and current route. For slow page loads, distinguish the first request from subsequent ones: if only the first load is slow, DNS resolution, the handshake, or a cold connection may be responsible. If every action is slow, consider ongoing latency, queuing, or the app itself. Repeated stalls during a transfer point more strongly to packet loss, congestion, or client resource use.

A web page is made up of more than one request. Text, images, scripts, and video may come from different domains and match different proxy rules. So a working homepage doesn’t prove that every resource is using the same exit. To troubleshoot, choose a repeatable action—such as opening a specific page and using the same feature—and check the client’s connection log. The desktop connection toggle only shows that the client is running; it doesn’t confirm that a particular app is being routed through it correctly.

Set Up a Fair Comparison

For a useful comparison, keep other conditions as consistent as possible. Test the same destination on the same access network and in the same client mode. Change the route first, then the protocol—one at a time. If you also change regions, DNS settings, and rule groups, you won’t know which change improved the experience. Keep a simple record of the feature tested, what happened, network type, route name, and changes made. Client log error categories are more useful for reproducing an issue than an isolated speed-test screenshot.

Distinguish client-reported latency, app response time, and actual download speed. A latency check may contact only one test address, while an app request can involve authentication, a database, and a content delivery network. Download speed also depends on destination throttling, local bandwidth, wireless signal, and concurrent tasks. These metrics complement one another but none represents the whole experience. A successful probe doesn’t prove every destination is reachable, and a brief download peak doesn’t show what a connection can sustain all day.

This page compares technical mechanisms; it is not a list of VPNXB protocols. Check the subscription and client after signing in for the protocols, transport methods, and route names actually available. A protocol discussed here may not be offered on every VPNXB route.

Security also needs to be considered in layers. Claims about bank-grade encryption don’t mean you can ignore website certificates, account permissions, or device security. A proxy connection and an app’s own HTTPS connection protect different things. Keep certificate verification enabled during normal use; don’t leave security checks disabled as a speed tweak. If you see a certificate error, check your device’s time, the destination domain, and your subscription settings rather than routinely skipping verification.

How Common Protocols Differ

Shadowsocks and VMess: Different Encapsulation Methods

Shadowsocks centers on encrypted proxy encapsulation. The client typically accepts an app connection, then sends the destination address and data to the server. Implementations don’t all require the same outer transport. Check the configuration for the encryption method, any additional transport plugin, and UDP handling. Simpler encapsulation can reduce processing steps, but that doesn’t make it faster on every device: implementation quality, hardware acceleration, and remote server load also matter.

VMess has its own authentication and data encapsulation mechanisms and is often paired with different transport methods. Connection overhead may come from protocol authentication, an outer security negotiation, or additional encapsulation layers. Don’t compare options by saying only “this is VMess”; check the underlying transport, whether traffic passes through an additional entry point, and how the client reuses connections. Some implementations rely on time-sensitive authentication. If your device clock is wrong, correct it before deciding the route is at fault.

Trojan and VLESS: The Outer Configuration Matters Too

Trojan typically uses TLS for encrypted transport and performs proxy authentication within the connection. The server address, port, credentials, server name, and certificate verification are all part of the configuration. TLS uses a well-established security transport, but that doesn’t mean every handshake is faster. Initial connections, resumed sessions, and reused long-lived connections can perform differently; client implementation and server configuration also affect the overhead.

VLESS uses lightweight proxy identity and request encapsulation, but doesn’t encrypt data on its own. It relies on a configured security layer to protect transmission. Assess security and performance together with the outer layer; “lightweight encapsulation” does not mean the security layer can be removed. Transport combinations, flow control, and entry handling can differ even when an option is labeled VLESS. When a subscription provides the parameters, keep the full configuration rather than deleting fields you don’t understand.

A protocol name is not a performance rating

TCP-based transports deliver data in order. If a segment is lost, later data may already have arrived but can be held until the missing part is recovered, interrupting interactive traffic. The impact depends on where the loss occurs, round-trip time, buffering, and connection reuse. So a protocol can work smoothly on a clean network yet pause repeatedly on an unstable wireless connection. That isn’t a contradiction: transport conditions may have changed, not the protocol itself.

An additional transport layer can improve compatibility or deployment flexibility, but may also add headers, memory buffering, and processing overhead. Fewer layers don’t automatically mean a better experience, and more encapsulation doesn’t make a configuration more advanced. The right choice is the smallest combination that meets the current network and server requirements. Changing the transport on your device without a matching server listener and configuration will usually make the connection fail—not produce a meaningful performance comparison.

When choosing a protocol, first check whether the client can parse the subscription entry correctly, then test the feature you need. If an entry disappears after import or is marked unsupported, check client capabilities and the import format. Don’t piece together credentials by hand to force a connection. If the entry is present but fails to connect, note the error category and compare it with a known-working entry. Understanding protocol design should help you avoid unnecessary changes, not require you to redesign the server deployment.

When to Use Hysteria2 and TUIC

What QUIC Changes About Transport

Hysteria2 and TUIC both use QUIC capabilities to build proxy transports. QUIC runs over UDP, but that doesn’t mean it sends app data without taking responsibility for delivery. It includes security negotiation, reliable transport, congestion control, and stream management, allowing it to organize multiple data streams within a connection. In short, UDP is the underlying transport, QUIC is the transport system built on top of it, and the proxy protocol handles identity, destination addresses, and forwarding app data.

QUIC can prevent one stream from blocking others simply because of ordered delivery, but each stream still needs to handle packet loss and ordering. QUIC won’t eliminate persistent loss on your local wireless network or congestion at the remote exit. It uses different recovery and scheduling mechanisms that may help on some networks, but it can’t create unlimited bandwidth. Excessive serial requests from a website or a slow destination service won’t be fixed simply by changing the transport layer.

Hysteria2: Set Bandwidth Parameters Realistically

Discussions of Hysteria2 performance often involve bandwidth estimates and congestion control. The exact approach depends on the implementation and configuration at both ends. Some settings affect sending behavior based on bandwidth parameters, so entering a value far above your actual capacity won’t give you more speed. Sending too aggressively can fill your local upstream queue and slow down web browsing, voice calls, and other devices. Available bandwidth also varies with shared usage, wireless signal, and time of day; don’t choose a value based only on your internet plan’s advertised tier.

For everyday use, it’s safer to keep the subscription’s settings and the client’s defaults. Adjust these options only if you understand what they do, the server’s requirements, and your local network’s capabilities. After a change, check web responsiveness and interactive tasks while uploading—not just download speed. If the speed reading improves but interactions become noticeably slower, revert the change. The goal is a sustainable app experience, not a bigger number on a meter for a few seconds.

TUIC: Consider Stream Management and Compatibility

TUIC also uses QUIC to organize proxy connections and provides its own authentication and forwarding mechanisms. Connection reuse and stream management may reduce the work of creating underlying connections, but the benefit depends on the client implementation, request patterns, and network conditions. Both ends need to support the UDP forwarding behavior. Clients with the same name may not support identical options, so after importing a configuration, check for unsupported-field warnings rather than assuming every parameter will work as intended.

QUIC’s connection migration is often discussed in the context of switching mobile networks, but it doesn’t guarantee an uninterrupted connection. The client may need to reconnect, the access network may change its UDP mapping, or the remote server may reject the original path. After switching between Wi-Fi and mobile data, check both the proxy connection and whether the app’s own session recovered. App reauthentication, video rebuffering, and proxy reconnection are separate processes; observe them separately.

If UDP isn’t working, don’t just change the bandwidth settings. First check whether the current access network supports the required transport, then compare it with another available protocol in your subscription. If the underlying connection can’t be established, throughput settings aren’t the main issue.

If TCP-based entries connect on the same network but QUIC entries consistently time out, first check network support, UDP mapping, and client compatibility. If both types connect but perform differently during sustained transfers, compare packet-loss recovery and resource use. Test the same destination at similar times. Don’t make QUIC the only option for every region and network just because it was faster once. Keeping routes suited to different access conditions is more practical.

A tunnel and the app using it are not the same thing. The fact that a UDP-based app can be forwarded through a proxy doesn’t mean a proxy using UDP transport is automatically the best fit. The app may be more sensitive to jitter or affected by the destination service’s connection policies. Choose Hysteria2 or TUIC based on observed connection reliability, interactive responsiveness, and device impact—not on the transport name as a guarantee of suitability.

Connection Setup Time and Resource Use

A First Connection Is Not the Same Test as a Reused Connection

A first connection usually involves DNS resolution, setting up transport to the entry point, security negotiation, and proxy authentication. The destination website may establish its own connection as well. Some steps can run in parallel; others must wait for an earlier step, so the full process can’t be predicted from the protocol name alone. Perceived page-load time also includes remote processing and content delivery. To compare setup time, first establish whether you’re testing a cold connection or a repeat request with an existing session and underlying connection.

Connection reuse lets multiple requests share an established channel, reducing repeated negotiation and some resource allocation. This can help with pages that make many small requests, but also means requests share the same underlying connection’s problems. If that connection becomes congested, retransmits, or closes, more requests may be affected than with separate connections. Whether reuse makes sense depends on the client’s default behavior and request patterns; it’s not simply a speed-boost toggle that should always be on.

How CPU, Memory, and Connection Count Affect Each Other

A client handles encryption, decryption, data copying, rule matching, DNS resolution, and logging. Hardware acceleration varies by device, so the same encryption algorithm can have different costs across platforms. Sustained downloads can also increase buffering and the number of concurrent connections. If CPU use rises, check whether the client is simply processing more data or repeatedly reconnecting, writing extensive debug logs, or reloading its configuration. A snapshot of CPU use can’t show the long-term resource cost.

Memory use can’t be ranked by protocol alone, either. More connections, larger buffers, or long-lived sessions can all increase memory use; the operating system may also cache resources, so the number may not drop right after a task ends. Look for continued growth, device slowdowns, or the system terminating the client. For a fair test, pause unrelated syncing and downloads, keep the app workload consistent, and compare the change after switching entries. Don’t blame the proxy for memory used by the browser itself.

Avoid Unproductive Trial and Error

Timeout settings determine how long to wait before giving up; they don’t determine how fast data travels. A timeout that’s too short can trigger reconnects during a temporary disruption; one that’s too long can make failures more noticeable. Concurrency controls how much work happens at once. Too many concurrent tasks can compete for local bandwidth, remote resources, and device memory. Buffering involves trade-offs between throughput, responsiveness, and resource use. There is no best setting for every network: keep the defaults unless the symptoms clearly point to a specific setting.

Don’t disable certificate verification to shorten the handshake, and don’t remove authentication fields and continue testing. If a security check fails, the connection requirements haven’t been met; it isn’t a step that can be skipped. Check your device’s time, server name, and whether the subscription is current to distinguish an outdated configuration from a network issue. For subscription-managed routes, fetching the complete configuration again is usually more reliable than guessing field by field. Save the original settings before making changes so you can revert if needed.

A complete resource comparison should cover idle use, regular web browsing, and sustained transfers. At idle, check for frequent background activity; during browsing, look at response times and stutters; during sustained transfers, monitor heat, resource use, and speed consistency. Don’t combine these into an undefined overall score. What matters is where your device hits a bottleneck and whether a protocol change, lower concurrency, or a different route can improve the task with the least trade-off.

Direct, Relayed, and Dedicated Routes

A Direct Connection Doesn’t Guarantee the Shortest Path

A direct route usually means the client connects straight to an overseas entry point, or that there’s no additional service relay between entry and exit. The setup is easier to understand, but public internet routing doesn’t follow straight lines on a map. Carrier peering, traffic management, and return-path policies can send data on a detour; the outbound and return paths may differ, too. A nearby region doesn’t necessarily mean lower round-trip latency, and a simple entry-point name doesn’t mean the link is free from shared bottlenecks during busy periods.

A direct route may reduce extra processing steps, but it’s more exposed to local carrier peering and public interconnection conditions across regions. A route that works well on your home network may perform poorly at the office. Compare routes using the same local access network and test the actual destination rather than ranking them by geographic distance. Region information on the nodes page can help narrow your options, but it doesn’t replace checking your own network and usage times.

What Relays and Dedicated Links Can Improve

A relay adds a forwarding point between the client and the exit: requests first go to an entry location, then continue along a later path to the exit. The extra hop adds processing and propagation time, but the overall experience may still improve if the later path is better. More relay nodes don’t automatically mean a better route; the point is to replace a poor peering path with a more suitable combination. Check both reachability to the entry and sustained performance beyond the relay. Testing latency to the entry alone isn’t enough.

A dedicated link usually means one part of the route uses a dedicated connection or a network with explicitly managed resources. IEPL is one commonly discussed type. A dedicated link in a service description doesn’t mean the entire path from your device to the destination website is private. Local Wi-Fi, public networks before the entry point, and connectivity from the exit to the destination can all affect performance. A stable segment can’t fix a weak local signal, destination throttling, or an account-region mismatch.

Entry region, exit region, and content region

The entry point is the server address your client connects to; the exit is where a destination website sees the request coming from. They may differ, so interpret region labels in subscription entries alongside the client’s details. Content availability may also depend on account information, payment region, previous sessions, and platform rules. To access content for a particular region, check the exit and account requirements first rather than assuming a route label is enough. See the streaming access guide for more on these limitations.

The term “native IP” also needs a clear definition. Address registration, geolocation databases, network ownership, and a platform’s fraud checks are separate things. A region shown in one database doesn’t prove that a platform will recognize the address as local. Choose a route based on whether it works for your task, not because one label supposedly guarantees access. See the nodes page for VPNXB regions and entry points; check the client for the route type.

To troubleshoot route topology, compare different entry points that use the same exit, if available. If the destination and exit are broadly the same but performance differs noticeably by entry, focus on the access and relay path. If several entry points slow down for the same destination, look more closely at the exit or destination service. Don’t infer internal topology from a name when the subscription doesn’t provide comparable options. Recording your network type, time of day, and route name is more useful than labeling an unverified node as dedicated or direct.

VPNXB covers 100+ countries and offers 180+ routes. Coverage indicates a choice of regions; it doesn’t mean every region uses the same topology or suits the same tasks. Choose a route for the destination region first, then compare reachability and sustained performance. Once you find a stable option that meets your needs, there’s no need to keep switching regions. Frequent changes to the exit can trigger app reauthentication and make it harder to identify the cause of a problem.

Packet Loss, Jitter, and Peak-Time Congestion

Similar Stalls Can Have Different Causes

Packet loss means data doesn’t arrive as expected; jitter means arrival times vary; congestion occurs when more data enters a part of the network than it can currently handle. Congestion can cause queuing and packet loss, while wireless interference or device issues can also cause packet loss. These issues are related but not interchangeable. Brief web stalls, video buffering, and choppy voice calls can all involve them. To narrow down the cause, note which tasks are affected, whether other apps slow down at the same time, and whether switching access networks helps.

With excessive buffering, downloads may still show high throughput while interactive requests wait in a queue. Downloads can seem fine even as web pages and voice calls become sluggish. Increasing send rates won’t necessarily help; adding more concurrent tasks can make queuing worse. Pause uploads, syncing, and other sustained tasks first, then see whether interactions improve. After that, consider queue management on your access device or a different route. Network quality isn’t just about how much data it can move, but also how quickly it handles small requests.

Compare the Full Path During Peak-Time Slowdowns

During busy periods, local access, carrier peering, proxy entry, relays, and exits can all compete for shared resources. A slowdown at a particular time doesn’t prove the problem is on the service’s end. If all routes and ordinary local apps are affected, start by checking your access network. If local access is fine but a particular type of exit is slow, compare other regions or route types. Track the same destination at different times to help distinguish an occasional fault from a recurring time-of-day bottleneck.

Avoid creating extra load during comparisons. Downloading large files over several routes at once competes for local bandwidth and may overload the remote exit with the test itself. Instead, run the same task on each route in turn. Check whether transfers repeatedly drop to zero, interactions become sluggish, or reconnects increase. If only one destination remains slow, also consider maintenance, content-source issues, or account status. A route problem needs repeatable network evidence—not just a generic error from an app.

Why Network Tests Can Mislead

Ping and traceroute can offer clues, but they don’t fully represent every app’s traffic. Some network devices give probes a lower priority or don’t respond to them at all. A silent intermediate hop may still forward later traffic; packet loss shown at an intermediate hop when the final destination is fine doesn’t prove that hop is the bottleneck. Conversely, a clean probe with a slow app may mean the app uses a different transport, rule, or destination address.

Most users don’t need to change a long list of system network settings to troubleshoot. First check your local connection, pause heavy traffic, update the subscription, choose another route for the same purpose, and retry the same action in the same app. If you need to dig deeper, check the client’s connection errors, destination domain, and matched rule. Before sharing logs, remove account identifiers, subscription links, and authentication details. Keep only the relevant error category and a description of what happened so troubleshooting doesn’t expose your credentials.

Higher throughput with less responsive controls isn’t an overall improvement. Consider sustained transfers and interactive response together. When the upstream connection is busy, pause competing tasks before judging a protocol or route.

An MTU mismatch along the route can also cause small requests to work while larger transfers fail. Encapsulation adds overhead, and some access networks support smaller effective packet sizes. If large files stall or certain page resources repeatedly fail only on a particular network, check encapsulation and path compatibility as possible causes. Other issues can produce the same symptoms, so don’t apply a fixed MTU value without evidence. Keep the defaults, test another route, and consult the client’s documentation before making a change.

When contacting support, include the app feature, local network, time of day, route name, error message, and comparisons you’ve already tried. Open a ticket from the user dashboard. Don’t just say “the speed is bad,” and don’t submit your entire browsing history. A concise, reproducible description helps distinguish route, client, and destination-service issues, avoids unnecessary follow-up, and gives support a clear way to verify any changes.

Mobile Battery Life and Platform Differences

Battery Use Comes from Processing and Network Activity

On mobile devices, battery use isn’t determined by encryption alone. Sustained transfers keep the wireless connection active; frequent reconnects repeat handshakes and DNS lookups; frequent keep-alives and background probes can also wake the device. Weak signals add to the communication workload. That’s why the same protocol can use different amounts of power on stable Wi-Fi and mobile data. When checking battery use, consider the screen, app, signal, and traffic volume together. A warm device alone doesn’t prove the proxy protocol is at fault.

QUIC-based connections may reduce reconnection overhead in some situations, but sustained transmission, packet-loss recovery, and implementation still affect battery use. TCP connections can also reduce repeated work through session reuse. There’s no fixed battery-use ranking that applies to every network. Instead, compare the same app task and see whether a route repeatedly reconnects, the device heats up unusually, or network activity drops after you stop. Don’t compare idle background use with sustained video playback.

System Traffic Capture Determines Which Apps Use the Proxy

On desktop systems, system proxy settings generally work only if an app respects them. Some apps open connections directly and may bypass those settings. TUN or a similar virtual network interface captures traffic at a lower level, but also involves permissions, routing, DNS, and interaction with other network software. Mobile systems typically use a network extension or VPN interface to capture traffic; background policies and system permissions still affect whether it keeps running. A client showing as started doesn’t mean every platform captures traffic the same way.

VPNXB supports Windows / macOS / iOS / Android / Linux. The protocols and modes available depend on the client and subscription you receive after signing in. Download clients from the client page in the user dashboard; don’t replace them with installers from untrusted sources. For macOS installation and permissions, see How to Use a VPN on Mac: A Complete Beginner’s Guide. This page explains how permissions affect connections.

Network Changes, Sleep, and Background Recovery

After a device sleeps, the local network or remote server may have already closed the existing connection. When the device wakes, the client may need to restore its interface, resolve domains again, or reconnect; the app may also retry on its own. If the problem occurs only after waking, first check whether reconnecting restores service. Then look for stale proxy settings, DNS cache, or leftover interface routes. Don’t immediately change accounts or reinstall everything: connection recovery and an expired subscription require different fixes.

Android background policies can vary with system settings. Excessive background restrictions may prevent the client from maintaining connections. iOS network extensions are also managed by the system, so keeping an app open on screen isn’t a universal fix. Follow the client and operating system’s permission guidance, confirm the required access is granted, and note what happens when the screen turns off. Adjust battery settings only for options you’ve confirmed are disrupting the connection.

VPNXB allows unlimited simultaneous devices, but that doesn’t give each device the same network conditions. If desktop connections are stable but mobile ones aren’t, compare access networks and traffic-capture modes. If all devices have the same problem with a destination, check the exit or destination service. Bandwidth-heavy tasks running at the same time also compete for resources on your home network. Device limits and local network capacity are different things; unlimited devices doesn’t mean unlimited local bandwidth.

For everyday mobile use, make changes sparingly and keep them easy to undo. Use a trusted subscription, avoid frequent probes you don’t need, and don’t run multiple apps that compete for the same network interface. If disconnections happen occasionally, note whether they coincide with locking the screen, switching networks, or losing signal. Then decide whether to check background settings or try another route. Connecting the issue to a system event is more effective than constantly changing protocols, and can prevent unnecessary background activity.

Choose a Protocol and Route for Your Use Case

Web Browsing and AI Tools: Check the Full Request

Web browsing and AI tools don’t all make requests in the same way. A web page may load many separate resources; an AI conversation may keep a response connection open for longer; and file uploads add upstream load. Before choosing a route, make sure you can sign in, submit a request, and receive the complete response—not just open the homepage. If a response stops partway through, check for a reconnect, network change, or account or service error. Don’t attribute every issue to the protocol name.

For AI tools, keeping the exit consistent can sometimes matter more than repeatedly seeking the lowest latency. Changing regions mid-session may trigger another verification or end the existing connection. Choose a route that meets the platform’s rules and your access needs, then check whether longer responses complete without interruption. Select a protocol based on how it performs on your access network; don’t tie a protocol name to a particular tool by default. For more on app-level limitations, see the AI connectivity guide. Account, platform, and network requirements should be assessed separately.

Video, Live Streams, and Transfers: Different Kinds of Continuity

On-demand video buffering can absorb some jitter. Live streams and real-time interactions have less room to hide fluctuations with a long buffer. For video, check content region, account access, and resolution before assessing sustained playback. For live streams, also note whether interruptions repeatedly occur at critical moments. A low latency reading doesn’t guarantee smooth playback, and a high download peak doesn’t guarantee an uninterrupted live stream. For more on peak-time performance and live viewing, see How to Choose a VPN Route for Live Sports.

Large file transfers can reveal sustained throughput and device strain, but they shouldn’t be the only basis for choosing a route. A route may download smoothly yet slow down web browsing during uploads because of upstream queuing. A protocol may transfer quickly but keep a mobile device hot, making it a poor everyday default. It’s more practical to keep separate options for everyday interactive use and sustained transfers than to chase one winner for every situation. Switch when your task changes rather than repeatedly testing during normal use.

Make Your Final Choice with an Easy Way Back

Start with the default option in your subscription. Complete a real task in the app you want to use, then try another route for the same purpose on the same access network. Compare protocols only after confirming that the route makes a difference. Change one thing at a time and keep the original option. If a new setting doesn’t clearly help, restore the default instead of accumulating changes whose purpose you’ve forgotten. Don’t invent transport combinations that aren’t in your subscription; the client and server need matching configurations for a meaningful comparison.

When something fails, troubleshoot by layer. If the app can’t complete a task, check your account and the destination service. If the proxy won’t connect, check the subscription, entry point, and local network. If sustained transfers are affected, check competing tasks, packet loss, and device resource use. When an option fails, compare it with a similar option rather than changing the region, protocol, and mode all at once. Include only necessary details in a support ticket; don’t upload your full subscription link. For common account and data-usage questions, see VPN FAQs for Beginners.

Choose a plan that fits how you use the service. VPNXB 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 for the remaining days. Data add-ons are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they’re valid until used and never expire. Protocol tests and sustained downloads also use data, so consider your main tasks before choosing a plan. See the plans page for full billing details; there’s no need to move to a higher tier just to test protocols.

The best setup is the one that gets the job done. A working connection, access to the features you need, a suitable sustained experience, and acceptable device use matter more than an undefined protocol ranking.

VPNXB offers a 60-day money-back guarantee and accepts Alipay / WeChat Pay / USDT. You can create an account without an email address using a username and password. See the refund policy for details. These service terms are separate from protocol capabilities: a refund policy isn’t a performance test, and coverage doesn’t guarantee access to every destination. Once you’ve chosen a setup, keep a stable option and troubleshooting notes. If network conditions change, you can check the connection, route, and app layers one at a time instead of guessing at every setting again.