Connection path layers
“Which protocol should I choose?” is rarely the first question to answer. A browser request passes through the local app and system network settings to the client, then travels over the local access network to the route’s entry point. Finally, the exit node connects to the destination service. Any part of this path can affect your experience. Protocol names describe only one part of it; they cannot replace an assessment of the full route.
What the app, client and exit node each do
The app determines which domain to access, whether to reuse a connection and how to handle request timeouts. The client determines which requests go through the proxy, where domains are resolved and how to connect to the entry point. The exit node determines the network origin seen by the destination service. If a website loads but one app does not work, first check whether that app is routed through the client rather than assuming the exit node is down.
System proxy settings and virtual network adapter mode are not the same thing. System proxy settings mainly affect apps that follow them. A virtual network adapter can cover more system traffic, but routes, DNS resolution and loops need to be handled correctly. Some apps use their own network stack, so a successful browser test does not prove that every app on the device follows the same path.
Where a domain is resolved can affect which destination address is selected. DNS resolution may happen locally or be handled remotely, and results can also be affected by caching and a provider’s content delivery strategy. When troubleshooting, note the domain, app and connection mode. Saving only the address returned by a single lookup can lead you to mistake a change in the content delivery node for a change in route performance.
Keep protocols, transports and network topology distinct
A proxy protocol handles authentication, request encapsulation and forwarding semantics. The underlying transport carries data to the other end, while network topology describes the path the data actually takes. Names such as Shadowsocks and VLESS do not tell you whether a route is relayed, let alone the quality of the exit node’s upstream network. The same protocol can perform very differently on different routes.
It also helps to distinguish the encryption layer from the transport layer. Some protocols include their own encryption design; others rely on a secure transport. Seeing TLS in the interface does not eliminate every risk to app data. HTTPS within the app, account permissions and device security still matter. VPNMT describes its security using the phrase “military-grade encryption”; when choosing a setup, still check the client’s actual security settings.
Fast connection setup and fast sustained transfers are different measures. Setup time depends on DNS resolution, handshakes, authentication and connection reuse. Sustained transfers also depend on congestion control, loss recovery, route capacity and the receiving device’s processing ability. A short webpage load leans more on the first set of factors; a large file transfer depends more on the second. One download cannot represent every use case.
Turn experience issues into testable questions
Describe what happens in concrete terms, such as “the page takes a long time to load the first time,” “the connection does not recover after switching networks,” or “video starts buffering after playing for a while.” These symptoms point to connection setup, session recovery or sustained throughput. “The node is bad” does not identify where the failure occurs, making it easy to keep switching protocols while the same local network issue remains.
Keep the app, destination and connection mode the same, and change only one protocol or route factor at a time. Changing the exit region, switching client mode and clearing the cache before comparing changes several variables at once. Even if things improve, you will not know why—and the result will not help you diagnose the next issue.
Trade-offs in common protocols
Shadowsocks, VMess, Trojan and VLESS often appear in the same client list, but they are not a simple speed ranking. Whether a protocol suits your setup depends on the client implementation, transport combination, authentication method and network conditions. The overview below explains each protocol’s design focus; it does not rank performance independently of implementation or treat newer names as a reason to switch.
Shadowsocks and VMess: consider the full implementation
Shadowsocks uses a relatively lightweight proxy wrapper to forward traffic. Its performance depends on the encryption implementation, processor capability and underlying TCP or UDP path. A streamlined wrapper can reduce processing overhead, but it does not guarantee faster long-distance transfers. If the exit route itself is congested, reducing local processing is unlikely to fix the main bottleneck.
To check Shadowsocks compatibility, confirm that the encryption method in your subscription is supported by the client and that UDP forwarding is enabled correctly. Do not manually copy settings just because the protocol name matches. Importing a subscription preserves a complete set of settings; removing fields you do not understand can break the connection or cause some apps, such as voice apps, to fail while webpages still work.
VMess provides authentication and request encapsulation, and can be paired with different transports. It is common in existing deployments and client ecosystems; do not assume it must be replaced just because another protocol is more streamlined. Check that client and server settings match, and keep the device clock accurate. Authentication failures and route congestion are different issues and should not be treated in the wrong order.
Trojan and VLESS: secure transport matters
Trojan typically places proxy sessions inside TLS-protected connections. When troubleshooting a failed connection, distinguish between DNS resolution, reaching the server, certificate verification and proxy authentication. The certificate’s domain, the system trust chain and the device clock can all affect the result. Disabling certificate verification may temporarily hide an error, but weakens identity checks and should not be a routine fix.
VLESS favors streamlined authentication and proxy encapsulation. The protocol itself is not a complete encrypted tunnel, so it must be understood alongside the security transport actually in use. When you see VLESS, also check its transport, security settings and client support. A streamlined wrapper can reduce some protocol overhead, but total connection costs still include setting up and maintaining the outer transport.
Both Trojan and VLESS can improve responses to repeated requests through connection reuse. They may also need to reconnect if an intermediate device closes an idle connection. “The first request after opening an app is slow, but later ones are faster” does not necessarily mean the protocol is inefficient; it may simply take time to establish the secure connection. Compare repeated visits with visits after a period of inactivity to identify where the delay occurs.
| Protocol | What to check | Common misconception |
|---|---|---|
| Shadowsocks | Encryption method, UDP support and implementation efficiency | A streamlined wrapper makes every route fast |
| VMess | Authentication settings, system clock and transport combination | Authentication failure means exit congestion |
| Trojan | TLS verification, domain and authentication details | Skipping verification fixes the network |
| VLESS | Secure transport, client compatibility and matching settings | The protocol name tells you how it is encrypted |
Resource use depends on the combination, not just the protocol
Local resource use typically includes encryption and decryption, data copying, connection maintenance, log writing and rule matching. A complex interface, continuously updating logs or frequently refreshed rules can also make a client seem resource-intensive. For a fair protocol comparison, use the same client, similar rules and the same task; otherwise, you may mainly be measuring differences in software features.
For a stable existing connection, keep the complete subscription and default security settings. If you need to switch protocols, first confirm that the target client supports it, then compare routes of the same region and type. Do not bulk-edit a subscription based on a single claim in an online article. If the server does not support those settings, even reasonable local parameters cannot establish a compatible session.
QUIC protocols on unreliable networks
Hysteria2 and TUIC are both related to QUIC. QUIC builds reliable transport over UDP and combines it with secure handshakes, flow control and loss recovery. UDP is the underlying transport; it does not mean app data can simply be discarded, nor does it make a protocol suitable for every network. First confirm that the UDP path is available, then consider any benefits on unreliable networks.
Multiplexing and connection recovery: what they can and cannot do
When multiple logical requests share one ordered byte stream over TCP, lost data near the beginning can hold up the delivery of later data. QUIC’s independent streams can reduce this kind of cross-stream blocking. However, each stream still has to recover lost data, and the underlying route gains no extra capacity. QUIC changes some waiting mechanisms; it does not make packet loss disappear.
QUIC supports connection migration, but whether a mobile device can resume smoothly after switching networks also depends on the protocol implementation, server policy and intermediate networks. A capability built into the underlying protocol does not mean every client has implemented it. After a switch, watch to see whether the session recovers before deciding whether to reconnect manually.
Secure session reuse or resumption can reduce some of the delay from reconnecting, but it generally depends on cached data, valid session state and server configuration. Do not compare a first connection with one made after prior visits as if they were equivalent. A protocol may seem faster during repeated refreshes because it reuses session state; that does not prove it will perform better after the device sleeps or changes networks.
Comparing Hysteria2 and TUIC
Hysteria2 is designed with transport performance over challenging paths, including high latency and packet loss, in mind. Different congestion-control modes and bandwidth settings affect how it sends data. If the client offers manual bandwidth settings, follow the server’s guidance. Raising the value does not increase actual capacity; an overly aggressive estimate can create queues, packet loss and competition with other apps.
TUIC also carries proxy traffic over QUIC. Its actual performance depends on how the client implements connection management, congestion control and UDP forwarding. Two protocols both labeled QUIC in the interface do not necessarily use the same handling strategies. Compare stability and recovery for your task rather than relying on their shared underlying protocol name.
These protocols may rely more on devices processing packets promptly. Their theoretical transport advantages may not materialize on devices under heavy processor load, with restricted background activity or with strict power-saving policies. If a mobile device heats up, drains its battery or becomes intermittent after being connected for a while, check the client’s background status and system resource use rather than continually increasing the sending rate.
Treat blocked UDP and poor UDP quality as separate issues
Some access networks handle UDP differently from TCP. UDP may be unreachable, mappings may expire quickly, or packet sizes may not fit the path. If no QUIC-based route can connect but a TCP-based route works on the same device, continue using the working transport and check the client’s message on the same network. Repeatedly changing the exit region may not help.
Path MTU describes the largest packet size a route can carry reliably. Additional encapsulation overhead may mean that packet sizes that previously worked need adjusting. A typical symptom is that a connection starts and small requests work, but large responses stall. Do not copy someone else’s MTU value blindly. Prefer the client’s automatic handling or the provider’s guidance, and keep the original setting so you can revert.
If UDP connects but performance fluctuates, compare it with a TCP-based route at the same time and check whether other devices are uploading heavily. Queued traffic can affect both transports, so fluctuations on QUIC alone do not prove the protocol is unsuitable. The right choice is the better combination for this network and device—not a universal protocol winner.
Direct, relayed and dedicated routes
Network topology describes how traffic is organized between the access point and the exit, making it a closer reflection of the actual path than the protocol name. Direct, relayed and IEPL dedicated routes each suit different conditions, but their labels cannot tell you everything about local access, entry capacity, the exit’s upstream network or the destination service. When choosing, ask both “Where does traffic enter?” and “Where does it exit?” rather than looking only at the exit country.
A direct route does not always mean a shorter path in practice
A direct route usually means the client connects to the proxy entry point over the public internet, with a relatively straightforward path and fewer forwarding stages to troubleshoot. It can work well when the local carrier has good connectivity to the entry point. But public routing depends on policies between networks, so a shorter geographic distance does not necessarily mean fewer hops in practice.
The same exit region can use different entry networks. A change of entry point affects the local carrier’s international route; a change of exit affects the server’s connection to the destination website. If a page loads slowly, first identify whether the problem is between the client and the entry point or between the exit and the destination. Switching exits behind the same entry point may not improve congestion in the first part of the route.
Direct routes suit situations where the path is already smooth and you want fewer dependencies. They also make a useful baseline for troubleshooting. They are not inherently more data-intensive or more power-efficient than relayed routes; those outcomes depend on protocol overhead, retransmissions and device implementation. Equating fewer stages with better performance or lower cost ignores actual network quality.
Relaying changes the route and adds stages to monitor
A relay sends traffic through an additional entry or forwarding node to reach the final exit. Its value comes from using better network connectivity, not simply adding another server. If the local connection to the relay entry is smooth and the route from the relay to the exit is more stable, the overall experience may improve. If an additional stage is congested, the relay may introduce more waiting.
When choosing a relay, consider whether the entry and exit both suit your task. Destination services generally care about the exit location, while the entry determines how the client connects. The region shown in a client often refers more closely to the exit than to the full route. Dashboard labels can help with route selection, but a region name alone is not proof of the complete network topology.
A relay issue may allow the client to connect to the entry but prevent access to the destination. Compare other exits using the same entry and note the stage where the error occurs. If all destinations are affected, check for a shared point of failure. If only one website is affected, look at the route from the exit to that service or changes in the service’s own policies.
Assess dedicated routes across the full end-to-end path
An IEPL dedicated line generally describes a dedicated connection arrangement for carrying traffic across regions. It can reduce reliance on some public interconnection routes. However, the connection from a user’s device to the entry point, such as a home network, and the final leg from the exit to the destination service may still use the public internet. An IEPL label does not mean the entire end-to-end path is dedicated, nor does it guarantee freedom from congestion at all times.
If you need reliable access to AI tools, video or remote work during peak hours, compare the actual performance of dedicated routes with other route types. Keep the exit region and client consistent where possible, and check whether loading, recovery and sustained transfers improve. If your local Wi-Fi signal is already unstable, switching route types first may not give you a clear result.
| Type | Potential benefit | What to check |
|---|---|---|
| Direct | Clearer path with fewer forwarding dependencies | Public interconnection and actual routing |
| Relayed | Uses a more suitable entry point and forwarding path | Entry, relay segment and exit status |
| IEPL dedicated line | Optimizes some cross-region transport | Local access, exit upstream and destination service |
VPNMT offers routes in 100+ countries and 230+ routes. See the Servers page for specific regions and types. This coverage indicates the range of available paths; it does not mean every region offers every topology at the same time or guarantee that a particular route will work for a specific website. Always test it in the app you intend to use.
Packet loss and peak-time congestion
Slow network performance can come from limited capacity, wireless interference, retransmissions, DNS delays or the destination service itself. Peak hours describe when an issue occurs, not its cause. Understanding the relationship between queues, packet loss and latency can help you decide whether to change routes, adjust your local network or wait for the destination service to recover, rather than blaming every slowdown on the protocol.
Why queues affect interactive apps first
When more data reaches a network stage than it can send promptly, a queue builds up. The device may still transfer data at a high rate, but new requests have to wait behind data already in the queue. Downloads can appear normal while webpage clicks, voice calls or remote controls feel sluggish. This shows why throughput and response time are not interchangeable.
Home network uploads are especially easy to overlook. Cloud backups, photo syncing or continuous uploads from other devices can queue acknowledgements and interactive requests. Pause nonessential heavy transfers, then repeat the same task. If performance improves, addressing local network contention is more targeted than repeatedly switching remote protocols.
Long queues can also make an app assume a connection has stopped responding and trigger retries. Those retries add more network load and more waiting. Running several speed tests, repeatedly refreshing pages or reconnecting often can all distort your observations. Stop extra tests first, keep the task simple and see whether the same symptom still occurs.
Packet loss has different causes and effects
Packets may be dropped because of congestion, poor wireless quality, a device that cannot process them quickly enough or packet sizes that do not fit the path. Reliable transports must recover missing data, causing extra delay. Real-time apps may tolerate some loss in exchange for lower latency, with reduced audio quality or visual glitches. The same packet loss can affect different apps in different ways.
Jitter is variation in latency over time. Average response time may look acceptable, but inconsistent delays can make it harder to maintain a smooth video call. On-demand video has a buffer that may temporarily hide fluctuations; interactive tasks generally cannot rely on large buffers. When choosing a route, observe stability throughout the task rather than recording only the fastest response.
Diagnostic probes are not exactly the same as application traffic. Some network devices prioritize probe responses differently, so an intermediate node that does not respond does not prove that application data is being dropped there. Consider destination access, client errors and end-to-end performance together. Do not assume that an abnormal line in a route report identifies the fault.
Distinguish shared bottlenecks from route-specific issues
If every route on the same device slows down at the same time, first check local access, router load and background tasks. If other devices work normally, focus on the local client, conflicting system proxy settings or resource use. If different devices and routes all have trouble with just one website, investigate the destination service or its content delivery path.
If only one entry point or route type gets noticeably worse at busy times, switching to a different entry or topology is more informative. Changing protocols while still using the same congested segment may make no difference. Conversely, improvement after a protocol change does not prove the old protocol was at fault: the new option may also have changed the entry point. Continue checking with one variable at a time.
When documenting an issue, note the destination, app, access network, when it started and whether an alternative route works. You do not need to rate routes by feel or use a single peak result to represent a whole day. Clear reproduction steps help narrow down the issue more than a speed-test screenshot without context.
Multiple devices and mobile battery life
The same subscription can behave differently across devices because of system access methods, processors, background policies and client implementations. Protocol encapsulation is only one part of resource use. On mobile devices, also account for the screen, wireless activity and background keep-alive. Do not attribute all battery drain shown for a client in system settings to encryption alone.
Balancing background connections and frequent reconnects
Keeping a session alive may require periodic communication to prevent an intermediate network from closing the connection. Disconnecting frequently may mean repeating DNS lookups, handshakes and authentication. Which approach uses less power depends on how often you access the network and how the system schedules tasks. More frequent keep-alives do not guarantee greater stability, and fully restricting background activity may not save power if the connection keeps dropping and reconnecting.
After sending data, a mobile device’s wireless radio may stay active for a while; scattered background requests can also keep waking it. Message syncing, cloud tasks and app updates can all contribute. To assess battery use, compare similar tasks on the same access network rather than comparing long video playback directly with short periods of standby.
Power-saving modes may restrict background networking, causing disconnections when the screen locks and recovery when it is unlocked. First check whether the system restricts the client’s background activity, then see if the issue occurs only on a particular access network. Do not start by replacing the entire subscription; switching protocols usually cannot fix a process that the system is actively pausing.
What to check on desktop and mobile
On Windows and macOS, check whether other proxy tools, virtual network adapters or security software are also changing routes. Enabling the system proxy does not mean every app follows it; when using a virtual network adapter, also avoid routing loops. If a browser works but a development tool does not, first check the tool’s own proxy settings and whether environment variables override the system settings.
On iOS and Android, pay closer attention to the network extension or system VPN connection and how background restrictions affect sessions. Clients may differ in rule parsing, DNS handling and recovery after a network change. A connection icon in the system only shows that the access component is active; it does not prove that every app is using the expected exit.
On Linux, desktop proxy settings, command-line environment variables and system routes may each take effect independently. A successful terminal request does not prove a graphical app works, and vice versa. If the system uses containers or separate network namespaces, also check whether their traffic follows the host’s connection path. Troubleshoot the traffic route, not just whether the process is running.
| Platform | Check first | Commonly overlooked boundary |
|---|---|---|
| Windows / macOS | Proxy conflicts, routes and resource use | App-specific proxy settings |
| iOS / Android | Background policies, network changes and session recovery | A connection icon does not mean every app is covered |
| Linux | Environment variables, routing and DNS path | Terminal, desktop and container paths can differ |
Compare resource use with realistic tasks
To compare CPU and memory use, let the client finish updating the subscription and loading rules before running the same task. A brief startup spike does not represent sustained resource use. Keep the log level consistent too. If you temporarily enabled verbose logging for diagnosis, restore your usual settings when finished to avoid ongoing writes that affect resource use and your observations.
VPNMT supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices. Device count and resource use are separate things: multiple devices used at once still consume traffic and share your home network capacity. Unlimited devices does not mean each device gets a separate traffic allowance; the allowance depends on your plan.
For a new device, get the client and subscription from the dashboard download page; you must be logged in and meet the plan requirements. For Windows instructions, see the Windows setup guide. Do not share sensitive configurations exported from other devices with anyone who does not need them.
Choose a setup by use case
The goal is to find a combination that reliably completes your task, not to try every protocol. Start by identifying what the task needs: web interactions depend on the first response, long-lived connections on recovery, video on sustained delivery, and real-time calls on low jitter. Then check the region, route type and client compatibility before comparing other protocols. This makes it easier to narrow down your options.
AI tools, browsing and development
AI tools such as ChatGPT may involve account sign-in, static pages and requests that stream responses over time. A page loading does not guarantee a stable generation process; an interrupted response does not necessarily mean the route disconnected. The cause could be the service’s load, account status or an app timeout. Distinguish a sign-in failure from a rejected request or interrupted transfer before troubleshooting.
For ongoing conversations, prioritize an exit you have tested and found stable, and avoid frequently changing your connection source mid-task. Compare protocols in a separate test rather than switching routes repeatedly during an important session. Account permissions, regional policies and service availability are set by the destination platform; a network connection does not override its terms of use.
Development tools often have their own proxy settings. Repository access, dependency downloads and terminal requests may not use the same path as your browser. If a download fails, check whether the tool goes through the client, whether the repository address resolves, and whether a certificate error comes from the local environment. Testing the specific tool is more reliable than assuming the whole development environment works because the browser does.
Streaming, live video and real-time calls
Streaming requires an exit that meets the service’s region and account requirements, as well as a route that can deliver content consistently. Catalogs, licensing and platform detection policies can change, so do not label a route as permanently unlocking a particular catalog. First confirm that the content plays, then observe playback. If only a specific title fails, check content access before switching protocols.
On-demand video usually has a buffer that can absorb brief fluctuations; live streams use different buffering strategies and may expose congestion more quickly at critical moments. Test in the actual app before watching rather than merely opening its home page. For details on regional availability and playback conditions, see our Streaming coverage and Netflix regional catalog guide. Keep region selection separate from transport stability.
Calls, voice chat and remote control depend more on consistent responses. Background file transfers can affect them first, even when overall throughput remains high. Pause competing traffic, then compare routes that are more stable. If you want to switch protocols, first confirm the client supports the UDP forwarding your app needs, then test audio, video and reconnection outside an important call.
Assess plan data and protocol efficiency separately
Choose a plan based on your actual usage, not on an assumption that a protocol will save a fixed amount of data. Encapsulation, encryption, retransmissions and the content itself all affect traffic; video quality and background syncing are often more significant. Do not treat data from a local speed test as typical daily usage or estimate long-term needs from one short session.
VPNMT monthly plans: ¥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, and do not expire. Billing terms differ, so check the Plans page before choosing.
If your usage is irregular, first understand the difference between monthly resets and non-expiring data. If you use the service regularly, focus on whether the selected data allowance suits your everyday tasks. Switching routes does not add data, and protocol names do not change plan terms. Payment methods: Alipay / WeChat Pay / USDT. VPNMT offers a 60-day money-back guarantee; see the Refund Policy for details.
Connection testing and troubleshooting notes
The goal of troubleshooting is not to collect as many screenshots as possible, but to narrow the fault down to an explainable part of the connection. Record the working setup before each change and test the same task afterward. If a change does not help, revert it promptly. This prevents security settings from being left in an altered state and stops successive experiments from making a previously working route impossible to restore.
Verify the connection first, then investigate issues
Once the client shows a connection status, test it in the app you actually need. Confirm that the app uses the expected proxy mode, then consider the exit location and destination access together. Exit lookup results can be cached or imprecise, so a city name alone does not prove that a route is faulty. Focus on whether the request follows the expected path and completes the task.
Check DNS resolution separately. The system, browser and client can all cache results, and some apps have their own secure DNS settings. If a change to routing rules still sends you along the old path, reconnect through the app’s normal process and then check for cache effects. Do not blindly disable security features just to make a symptom disappear; first identify which component handles DNS.
For more detail, see our IP and DNS leak test guide to check the exit, DNS resolution and per-app routing together. Verify these before assessing protocol performance. If one app connects directly while another uses the proxy, the results are not comparable and cannot tell you how well the route works.
Troubleshoot based on where the error occurs
If a connection cannot be established, first check whether the subscription is valid, whether the selected option is still available and whether the device clock is correct. Then identify whether the error is a DNS failure, connection timeout, certificate verification error or authentication failure. The first group points more toward the network path; the latter is more likely to involve settings or identity. Do not make reinstalling the client your answer to every error.
If the client connects but you cannot access a destination, try other destinations to see whether only one site is affected, then check whether the rules route the destination as expected. If small requests work but large responses stall, look at packet size compatibility and loss recovery. If only UDP apps fail, check UDP forwarding and the access network rather than changing every transport setting at once.
If an issue appears only after you have been connected for a while, note whether it coincides with the screen locking, a network change, system sleep or a background task starting. Before reconnecting, check the client’s message rather than immediately clearing the logs. A brief record can help determine whether the system paused the session, the route changed or the destination closed the connection. Restore your usual log level when troubleshooting is done.
| Symptom | Check first | Compare next |
|---|---|---|
| Connection fails to establish | Error stage, subscription and device clock | Other working transports on the same network |
| Some apps fail | App proxy settings and routing rules | How the same destination works in other apps |
| Large responses stall | Loss recovery and path MTU | An alternative route to the same destination |
| Disconnects when the screen locks | Background policy and session recovery | Whether it recurs with the app in the foreground |
Share redacted information that reproduces the issue
When asking for help, include the platform, protocol and route type shown in the client, access network, destination app, exact error message and comparisons you have already tried. “It worked after switching to a different entry point” is more useful than “I tried lots of nodes” because it identifies the variable that changed. If the issue is intermittent, also note what you did just before it happened so the same path can be tested.
Logs, screenshots and configurations may contain subscription URLs, authentication details or session identifiers. Check and redact them before sharing. Do not post a complete configuration publicly or enter a real subscription URL into a search box or public forum. Troubleshooting usually requires only the error stage and relevant setting names—not information that could grant access to your account or subscription.
For further help, sign in and submit redacted notes through the dashboard support ticket page. Keep a verified working combination of route and client settings, and treat other combinations as alternatives. Reliably completing your task matters more than chasing a protocol name. If conditions change, repeat the checks on this page in the same order.