Routes & protocols

A subscription isn’t a live connection

A subscription link gives your client access to available nodes and their settings; it doesn’t carry your everyday web or video traffic. After updating a subscription, the client typically saves node names, server addresses, protocol settings, and rules locally. When you connect, it builds a route according to the selected mode. So a successful subscription update doesn’t mean every route will connect, and a working route doesn’t guarantee that a particular app is ready to use. Troubleshooting is more effective when you identify the failing step than when you repeatedly re-import the subscription.

A node is a connection endpoint you can select in your client; a route describes the network path your traffic takes. They don’t always correspond one-to-one. Nodes with similar names may use different entry or exit points, and a single region may offer several transport options. Compare the region, topology label, and client support rather than relying on the city in a node name. Available options depend on your account panel and current subscription. The server locations page explains regions and route types, but doesn’t replace the list in your client.

What happens during a connection

When an app makes a request, the client first checks whether its rules apply. It then resolves the destination name or delegates resolution to a remote server before connecting to the selected entry point. After the entry point validates the settings, traffic follows the service route to an exit point, which connects to the destination website. A delay at any step can leave a page waiting to load. Seeing the client open only confirms that the program is running; it doesn’t prove system traffic is passing through it. Likewise, opening a page in a browser doesn’t mean every app uses the same route.

Distinguish a cold connection from an established one. A cold connection may involve name resolution, a transport handshake, security negotiation, and authentication. Once connected, later requests may reuse the existing channel and complete sooner. If a page loads slowly the first time after switching nodes but is fine afterward, that alone doesn’t point to an ongoing bandwidth problem. Conversely, a fast connection followed by repeated download stalls calls for checking congestion, packet loss, the destination’s response, and device load—not just whether the handshake succeeded.

Latency, throughput, and task completion time

Latency is the time data takes to make a round trip; throughput is how much data is transferred over a period. They measure different things. Interactive apps make frequent short requests, so they’re more sensitive to latency and jitter. Continuous video downloads depend more on sustained throughput and buffer capacity. A route test may only measure the connection from your client to an entry point or test address, while an app’s traffic also passes through an exit point and on to its destination. A low test result and a sluggish app can coexist because they measure different parts of the route.

For a fair comparison, keep the app, destination region, local network, and client mode the same so that only the protocol or route changes. If you also change networks, nodes, and cache state, it’s hard to tell what improved. Distinguish cached pages from first visits, and video preloading from real-time interaction. Note whether content appears promptly, transfers stall, or the app recovers after you switch away. There’s no need to reduce the whole experience to a precise-looking score with an unclear scope.

The protocol descriptions here explain technical principles; they don’t mean every node in your subscription supports every protocol or feature. Protocol support, client implementation, and server configuration must all be compatible—a matching name isn’t enough. If a term is unfamiliar, see the VPN glossary for beginners, then use the comparisons below to check compatibility. This helps turn “it won’t connect” into a problem you can verify instead of a reason to keep changing settings at random.

Shadowsocks: implementation and transport both matter

Shadowsocks is a family of encrypted proxy protocols commonly used to forward app requests through a remote server. Its data path is relatively straightforward, but implementation, encryption method, and extensions affect compatibility and resource use. Any claim that it’s lightweight needs to specify the client and configuration; one client’s performance doesn’t represent every implementation. For everyday browsing and general app use, there may be no noticeable benefit to switching from a stable setup just to try a newer protocol.

For real-time voice or other datagram-based apps, check that the client handles the relevant traffic and the server supports the required forwarding. If a webpage loads, that only confirms the transport path used by that page. A feature may fail because of system proxy coverage, an app bypassing the proxy, or routing rules—not because of the encryption algorithm. After importing a subscription, keep the provider’s settings unless there’s a clear reason to change them. Randomly copying encryption settings from online sources can leave the client and server unable to agree.

VMess: consider authentication and transport separately

VMess provides authentication and data protection for proxy connections, and deployments can pair it with different transport layers. So a comparison isn’t complete without specifying the outer transport: additional encapsulation, security negotiation, and connection reuse can all affect initial connections and long-lived sessions. Nodes labeled VMess can perform quite differently over different network paths and transports. Focus on whether the client fully recognizes the subscription settings, not on whether the protocol name sounds familiar.

Some implementations are sensitive to device clock settings and configuration compatibility during authentication. If authentication fails, first check that your system date and time are set to update automatically. Then refresh the subscription and see whether the client reports unsupported settings. Don’t assume a single failure means the exit route is at fault. If the logs explicitly point to a protocol or authentication error, switching to another region on the same path may not help. Restore a compatible configuration before comparing network routes so a settings issue doesn’t skew every test.

Trojan and VLESS: don’t overlook the security layer

Trojan typically uses TLS to establish a secure channel for proxy requests. The connection depends not only on the remote server being reachable, but also on certificates, the server name, and verification settings. A certificate check failure is different from a general timeout: check the system clock, subscription settings, and client support for the former; investigate the network path for the latter. Disabling certificate verification to make a connection work changes its security boundaries. It isn’t a routine troubleshooting step and shouldn’t be saved as a permanent setting.

VLESS keeps the protocol itself relatively minimal, but doesn’t encrypt data on its own. Security depends on the outer secure transport and correct configuration. A “lightweight” label doesn’t mean every combination will use less battery or run faster; connection maintenance, encapsulation, and client processing still have a cost. Compare a complete setup—VLESS plus a specific secure transport and carrier. Without those details, you can’t assess resource use or make a reliable judgment about connection privacy.

These protocols don’t have a universal speed ranking independent of context. Handshakes affect connection setup; congestion control and routing affect sustained transfers; implementation and hardware acceleration affect resource use. Most users should prioritize a combination that the client supports natively, with complete subscription settings, and that works reliably for their apps. Change protocols to address a specific, clear problem—such as noticeably slow cold connections or a datagram feature that doesn’t work—so the results can be repeated and compared.

What QUIC changes

QUIC builds connections over UDP, combining security negotiation and stream management at the transport layer. Compared with putting all logical requests on one ordered byte stream, it can reduce the way packet loss in one stream holds up other streams. But less cross-stream waiting doesn’t make packet loss free: lost data may still need to be recovered, congestion control still limits sending, and access networks still have capacity limits. A protocol can change how a route is used, but it can’t create network capacity that isn’t there.

Hysteria2 and TUIC both use QUIC for proxy transport, but their protocol designs, forwarding, congestion-control choices, and implementation details differ. A shared underlying transport doesn’t make their client settings interchangeable, nor can a test on one network be applied directly to another. Before choosing, confirm that your client explicitly supports the protocol and use the complete settings supplied by your subscription. Then evaluate connection setup, sustained transfers, and recovery separately.

Hysteria2: sending strategies must suit the route

Hysteria2 implementations can use different sending and congestion-control strategies, and some configurations also take bandwidth hints into account. A hint isn’t a plan guarantee, and a higher setting doesn’t automatically mean faster speeds. If the sending rate exceeds what the route can handle, queues grow, interactive latency can worsen, and packet loss or retransmissions may increase. Keep the settings provided by your subscription. Adjust them in a recoverable local configuration only when you understand what they do and have evidence to compare.

On routes with variable latency or some packet loss, this type of transport may be worth trying—but watch for effects on other apps. A higher download speed doesn’t mean the overall experience improved if web input and voice calls start lagging. Test with a familiar webpage or meeting app running alongside the transfer to see how they respond together. If they interfere with each other, reduce background transfer intensity or choose a route better suited to interactive use instead of chasing a higher reading.

TUIC: stream management and recovery depend on implementation

TUIC carries proxy traffic over QUIC; results depend on the implementation’s stream management, datagram forwarding, and congestion control. With multiple apps in use, independent streams can reduce some transport-level blocking, but apps still compete for shared network queues, device processing, and exit bandwidth. Multiplexing doesn’t provide separate bandwidth or dedicated resources to each app. If meeting stability matters, test during a meeting rather than relying on a single download test.

Recovery after a network switch also depends on changes to the system network interface, address updates, and the client’s reconnection strategy. QUIC has mechanisms that support connection migration, but not every client, proxy implementation, or deployment keeps app sessions alive when the network changes. One successful switch doesn’t prove every session will stay connected. Check separately whether the client reconnects, the page continues loading, and the app needs to start a new session. Transport recovery and app recovery aren’t the same thing.

Public Wi-Fi, business networks, and routers may handle UDP differently or close idle sessions quickly. A connection may work at first and then fail after being idle, or downloads may work while a particular real-time feature doesn’t. Note when the failure occurs and whether reconnecting fixes it, then compare another transport. Avoid repeatedly shortening the keepalive interval: it can use more battery without overcoming a restriction imposed by the access network.

When comparing these protocols, test tasks you actually do and assess cold starts, sustained transfers, interactive use alongside other traffic, and recovery after idle time separately. If UDP isn’t suitable for your current network, choosing a compatible node that uses another transport is a sensible trade-off, not a sign of outdated technology. Choose protocols for your environment. Making one protocol the only answer for every device and network adds maintenance overhead and leaves you without an easy-to-test alternative when something breaks.

Consider first connections and long-running sessions separately

A first connection may involve name resolution, a handshake, certificate processing, and authentication. Long-running use draws more on encryption, data forwarding, rule matching, and connection maintenance. A few quick page visits may make handshake delays more noticeable; sustained downloads amplify differences in processor load, network activity, and heat. “Starts quickly” and “uses fewer resources over time” aren’t the same conclusion. Specify the kind of task before comparing, and don’t judge by processor or memory readings right after launch.

Whether encryption can use device hardware affects protocol overhead, but the protocol name alone won’t tell you. The client implementation, system network extensions, logging detail, and traffic capture mode all contribute to resource use. If your device heats up after connecting, pause large downloads and turn off unnecessary verbose logging. Check whether the device cools down while idle before deciding whether the transport or a background task is responsible. Switching protocols might change the load temporarily while leaving the actual background workload untouched.

Wireless activity matters

A mobile device’s battery use depends on more than processor load. Frequent small exchanges, keepalives, and background app sync keep the wireless connection active for longer. A connection can keep waking the system even when total traffic is low. Conversely, a concentrated transfer can sometimes finish sooner, but that doesn’t mean it saves power on every device. Battery life also depends on screen brightness, signal quality, system scheduling, and temperature. Compare under similar conditions for meaningful results.

Keepalives maintain network session state. Intervals that are too short increase background activity, while intervals that are too long may let access devices close an idle session. The right setting depends on the network and client; there’s no one-size-fits-all value. Start with the client defaults and subscription recommendations. Consult the client documentation if you repeatedly see a session fail after idle time and recover when you actively use the connection. Don’t change keepalives, routing, and name resolution all at once, or you won’t know what made a difference.

How system traffic handling affects usability

A system proxy usually affects only apps that follow that setting. Tunnel mode may cover a wider range of traffic, while also requiring the client to handle routing, name resolution, and more packets. These modes have different capabilities and costs; their names alone don’t establish which is better. If a browser works but another app doesn’t, first check whether the client is handling that app’s traffic instead of adding protocol complexity. Before changing modes, quit other tools that may also manage system networking to reduce route conflicts.

VPNMove supports Windows / macOS / iOS / Android / Linux, with no device limit. Find the client link in the account panel and see the Guides for setup instructions. Platform support doesn’t mean every platform exposes the same advanced settings, or that one local configuration can be copied directly across all systems. Use the import method supported by your platform to avoid leaving out required fields when transferring settings manually.

To compare battery use, check the system battery report for activity from both the client and the apps you’re using, then observe them under similar conditions. The system may attribute some network activity to the app or count background time under the client, so don’t simply add the figures or use them to calculate exact efficiency. If high usage continues after you stop the app, check for logging loops, repeated reconnections, and background sync. If it happens mainly in weak-signal areas, the access conditions may matter more than the protocol.

For everyday use, keep a configuration you’ve confirmed works and make a targeted change only when a clear symptom appears. On mobile, avoid leaving frequent speed tests or high-rate automatic probes running: they also create connections, use data, and wake the device. You can keep alternate nodes in different regions or using different transports without running tests on them continuously. The goal of resource management is to get real tasks done, not to keep the client display updating numbers.

Direct routes: simple paths, variable performance

A direct route typically connects from your local network to a remote service entry point without an additional relay arranged by the provider. It removes one part of the route, but the actual path across networks still depends on carrier routing, peering, and time-of-day load. A nearby location on a map may have poor peering, while a more distant exit may have a better route. Direct describes the topology; it doesn’t guarantee low latency or high throughput.

When the route from your local network to the destination entry point is already good, a direct connection can be easy to maintain. If the path becomes congested during busy periods, changing the encryption protocol alone is unlikely to fix it. Compare routes over the same access network and at similar times rather than comparing an off-peak result on a weekday with a busy-period result on another route. Also check whether the destination service itself is slow before attributing every delay to the cross-region connection.

Relayed routes: an extra step can improve peering

A relay adds a forwarding point between your local network and the remote exit. Traffic first reaches a suitable entry location, then follows the next leg to the exit. This can improve poor peering, but adds forwarding, queueing, and maintenance. Stability depends on the entry point, the route from relay to exit, and the load on each part at the time. An extra hop doesn’t automatically make a route slower, and a “relay” label doesn’t guarantee good performance during busy periods.

The region shown in a client usually refers to the exit location, while the server you connect to directly may be at a different entry point. Entry and exit points do different jobs: the entry affects access and handshakes, while the exit determines the region seen by the destination service and the rest of the route. Be clear about what you want to improve—local access, how the destination identifies your region, or the response from the exit to the destination. If you change only the entry but keep the same exit, the destination will usually identify the same region.

IEPL dedicated lines: understand the whole path

IEPL describes a route that uses dedicated cross-region transport resources for part of the path. You still need to reach an entry point over your local network, and the exit still needs to connect to the destination service. A dedicated line can’t eliminate home Wi-Fi interference, device load, destination congestion, or app account restrictions. Its value is best understood in terms of consistency and control over part of the route—not as a guarantee that every app will work without delays at all times.

VPNMove covers 90+ countries and 220+ routes. Coverage describes the range of available regions and routes; it doesn’t mean every region offers the same route types, protocols, or app support. On the server list, first choose a region that suits the destination service, then compare the available topologies. If the destination doesn’t require a specific region, prioritize a route with reliable real-world response and simple upkeep rather than picking the most distant location or the one with the most labels.

Streaming region detection also depends on the exit IP address, the platform’s checks, your account region, and content licensing. Two routes exiting in the same country may still get different responses, and a dedicated-line label doesn’t change platform rules. For more, read Netflix libraries by region and how to assess routes and Disney+ regional differences and stability comparison. Check network connectivity and content availability separately; one successful playback session isn’t proof that a route will work everywhere over time.

Choose a route in this order: destination region, fit with your access network, sustained performance, and backup option. Once the main route works for your needs, keep a backup with a different topology or region to help isolate local failures. A backup may not help if both routes share the same unstable local network, or if they share an exit affected by the same destination-service issue. A backup is useful because it gives you a different set of conditions to test—not simply another name in the list.

Packet loss can have several causes

Packets may fail to arrive as expected because of wireless interference, an overloaded access-device queue, carrier peering congestion, or a slow response from the destination. Each cause calls for a different fix. If the wireless signal is unstable, improving local access may help more than changing the remote region. If the route is congested, trying a different transport path is more relevant. Protocol recovery mechanisms can reduce some effects, but recovery takes time and resources; they can’t make persistent packet loss cost-free.

Jitter is variation in response time. The average may look acceptable, but occasional long pauses can disrupt voice calls, remote desktops, and interactive work. Video buffering can absorb some variation, so smooth playback doesn’t prove that a meeting will be smooth. Test the task itself: for meetings, check for choppy audio or frozen video; for remote control, watch for uneven input response; for web browsing, look for repeated stalls on key requests rather than just whether the page eventually opens.

Peak-hour queues versus insufficient bandwidth

A common peak-hour problem is several users or tasks competing for shared resources, leaving data waiting in a queue. Interactive responses can slow considerably even when the connection hasn’t dropped. Large uploads on your home network or an overloaded router can cause similar symptoms, so a problem at night doesn’t automatically mean remote congestion. Pause local backups, sync, and downloads to see whether interactions improve. Then compare with another access network to narrow down the cause.

When sustained transfers fill a queue, new short requests can get stuck behind them, so “good speed but sluggish controls” can happen at the same time. First reduce unnecessary parallel tasks, limit background transfers if needed, and then compare routes. Increasing concurrent connections repeatedly may not improve useful throughput; it can increase competition, device load, and pressure on the destination service. Testing how real tasks complete is more useful than running several speed tests at once.

Measurement tools have limitations

Common network probes may not be handled like business traffic. Routers can deprioritize probe responses or fail to respond to certain probe types. A nonresponsive intermediate hop in a route trace doesn’t mean later traffic can’t get through. Conversely, a responding test endpoint doesn’t prove that web pages, security negotiation, or app authentication will succeed. Compare probe results with client logs and real app behavior. A single red warning isn’t enough to declare a route unavailable.

It helps to note whether the problem follows a time-of-day pattern. If the same route works off-peak but consistently worsens during busy periods while other routes improve, congestion is a more plausible explanation. If it fails at any time and the logs stop at the same authentication step, check configuration and compatibility instead. Record the access network, client mode, route name, and target app. Don’t jump to a conclusion or present a suspected route issue as confirmed.

Distinguish transport-level head-of-line blocking from competition for network capacity. Moving traffic to a different transport can change packet-loss recovery, but it may still share the same congested path. If every protocol stalls in a similar way on the same access network, investigate local access and routing first. If only one transport fails, focus on how the network handles it and whether the client supports it. This layered comparison avoids wasting time on unrelated settings.

Also consider the destination service. If one website is slow while other tasks work, the problem may be the site itself, peering between the exit and that site, or your account status. On the same node, try another service you use regularly; then try a suitable region for the same destination. See whether the problem follows the destination or the route. Keep the conclusion specific: “this destination performs poorly on this route right now” is more useful than saying the whole network is unstable.

Web browsing, AI tools, and online work

Web browsing and online documents make many short requests, so what matters is how quickly content appears, input responds, and updates load. Prioritize a reliable handshake, successful name resolution, and a suitable destination region—not just sustained download speed. With AI tools, also check service-region support, account status, and platform rules. If the page loads but a task won’t submit, the problem may be beyond basic connectivity. Keeping the exit region consistent during a session can help avoid repeated verification and unnecessary state changes.

If ChatGPT won’t open, first distinguish a name-resolution failure from a page resource, login, or conversation request failure. Different stages involve different service endpoints, so changing protocols won’t always help. Confirm that the client is handling the relevant requests, then compare suitable regions and routes. If only account actions fail, check the platform’s message. Rule-based mode can keep unrelated traffic outside the proxy, but the rules must cover the actual requests; the site’s main domain alone may not tell you where every resource goes.

Meetings and remote collaboration

Meetings depend more on jitter and recovery than on peak download speed. Test voice, video, and screen sharing on the network you’ll use for meetings, and check whether background transfers compete for queue space. If the app needs datagram traffic, make sure both the client mode and node support the required forwarding. Some apps fall back to another transport when communication is restricted. They may still connect but take longer to respond. Joining a meeting is only the first check—also see whether interaction remains smooth.

Hotel and other temporary networks on a trip may handle traffic differently from your usual home connection. Keeping a compatible transport as a fallback is safer than changing advanced settings right before a meeting. If the current network doesn’t suit UDP-based nodes, try another transport and pause background downloads. For planning mobile work and short-term data use, see the business travel guide to short-term data and work networks. Choose a protocol to support uninterrupted work, not because its name sounds newer.

Streaming video and large file transfers

Video streaming needs a steady data supply, but playback also depends on regional catalogs, account entitlements, device capabilities, and platform scheduling. Confirm the content region and playback rights before diagnosing a transfer bottleneck. A higher throughput won’t change licensing if the catalog is wrong. If the content is available but keeps buffering, compare exit locations, peak-hour routes, and background tasks. Hysteria2 or TUIC may be worth trying when they suit the route, but another stable, compatible protocol is a good choice if local UDP conditions aren’t suitable.

Large file transfers can occupy a route for a long time, so check whether other apps remain responsive while the transfer runs. A setup that finishes in a reasonable time without disrupting interactive tasks is more useful than one that only wins on peak speed. For long downloads, also consider device heat, client stability, and your data allowance. “Data packages never expire” describes the validity period of the data, not a guarantee of bandwidth or sustained performance. Those are separate considerations.

Choose a plan separately from a protocol. VPNMove 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 packages are ¥158/300GB, ¥358/1000GB, and ¥658/3000GB; they remain available until used and never expire. See the full plan details to compare your usage and frequency. Don’t infer protocol priority or route performance from prices when those details aren’t listed.

The decision can be simple: choose the destination region, use a complete configuration supported by your client, test a real task, and keep a backup route that differs from your main one. If your current setup is stable, there’s no need to switch protocols just for the sake of switching. If a problem is clear, change only the layer related to it. This reduces maintenance and gives you a reliable baseline for future troubleshooting. Choose based on how the setup works for your task and environment, not how often a protocol name appears in online discussions.

Start from a setup you can verify

Before troubleshooting, save your current working local configuration or note the selected mode. Turn off automatic switching and background speed tests. Confirm that your device’s regular connection can reach everyday services, then check your account, subscription, and client. If the subscription list is empty or an update fails, resolve that first instead of changing transport settings. For the full process of retrieving, importing, and updating a subscription, see the beginner’s guide to subscription links. For quick setup, follow the Guides.

Check the system date and time, confirm the client is enabled correctly, and look for other tools that may also manage network traffic. Then update the subscription. Don’t post your subscription link in public discussions: it may contain information that grants access to account resources. Don’t paste the full configuration into a support ticket either. When describing an error, include only the necessary error category and context; remove access credentials, the full subscription URL, and personal work data. Protecting this information doesn’t hinder troubleshooting and helps prevent additional account risks.

Troubleshoot based on where the error occurs

If the client reports unsupported settings, authentication failure, or a certificate problem, first check client compatibility, the system clock, and whether the subscription is up to date. Don’t bypass errors by turning off verification, and don’t change the server name or encryption settings at random. For a connection timeout, compare another node and transport; if only a UDP-based connection fails, try another access network. After each change, repeat the same task and undo changes that didn’t help so the configuration stays understandable.

If the client says it’s connected but an app still fails, check whether the app’s requests are going through the client and where its rules send them. Browsers and other apps may use different proxy mechanisms, and the system proxy setting may not cover all traffic. Start with a webpage you know works, then check login, resource loading, and app requests for the target service. Only compare exit regions and protocols after confirming traffic is taking the intended route. Otherwise, switching nodes repeatedly may not help.

Run a small, controlled comparison

Start by changing nodes on the same device, then try the same node on another access network. Change clients or devices only if needed. If the issue follows a node, focus on its route and exit; if it follows the local network, check Wi-Fi, the router, and access policies; if only one device is affected, review system permissions, background management, and configuration. You don’t need complex tools, but you do need to change only a few conditions at a time and record whether the problem disappeared, improved partly, or stayed the same.

Check name resolution separately. The client may resolve names locally, remotely, or according to rules, and each mode creates destination addresses differently. If you see a name-resolution error, don’t change the node, resolution mode, and traffic handling mode all at once. First confirm whether it occurred while retrieving the subscription or accessing the destination. Then check the client’s diagnostics and logs. If changing access networks fixes it, note that for support rather than immediately sending all resolution requests to an unfamiliar public service.

For further help, describe steps others can repeat in a support ticket in the account panel. This is more useful than simply saying “it’s slow.” Note whether the initial page load is slow, a sustained download stalls, a connection fails after idle time, or it won’t recover after a network switch. Include sanitized error text if available. VPNMove doesn’t require an email address; you can create an account with a username and password. Handle account and subscription tasks in the panel, and don’t enter existing account details on unfamiliar pages.

After troubleshooting, restore the normal log level, turn off probes enabled temporarily for diagnosis, and keep the verified main and backup settings. If a conclusion applies only to a particular access network or task, state that scope rather than turning a local result into a universal protocol ranking. When the same symptom appears again, start with your existing comparisons to avoid repeating tests. A technical guide isn’t about accumulating settings; it’s about making every change answer a specific question.

For pricing, billing, and service terms, see the plans, FAQ, and Terms of Service. VPNMove offers a 60-day no-questions-asked refund and accepts Alipay / WeChat Pay / USDT. Refund terms and technical troubleshooting are separate matters; there’s no need to make exaggerated performance claims to justify a choice. Understand your environment, test real tasks, and decide whether to continue based on what you actually need.