VPN Protocols and Server Routes

Connection Layers and How to Diagnose Them

Access Network, Transport, Exit and Destination

When you open a webpage, the request does not jump straight from your client to the destination site. Your device first connects through Wi-Fi or Ethernet to your ISP, then reaches the entry point for your subscribed route. The route carries the request to an exit, which connects to the destination service. DNS resolution also plays a part by determining which address the request looks for. Client rules decide whether a request uses the subscribed route. Breaking down these steps helps explain why a client can show as connected while a particular app still cannot load.

Protocols mainly describe how the client and server authenticate, encapsulate and transmit data. Route topology describes how entry points, exits and intermediate links are arranged. The same protocol can run over networks of very different quality, and a single region can have different entry points and paths. So saying “this protocol is faster” leaves out crucial context: which network, which exit, which destination and which device? Conclusions made without those details are not a reliable basis for choosing routes over time.

It is also important to distinguish a proxy connection from an app’s own secure connection. Sending a request through an exit does not remove the destination app’s responsibility for authentication and encryption. Browsers still need to check site certificates, and apps still need to manage account sessions. A change in exit region may also trigger security checks from the destination service. If you are asked to sign in again or see a region warning, check the app’s policies and the network path separately; do not assume the subscription protocol has failed.

Latency, Throughput and Time to First Response Are Different Metrics

Latency is the time data takes to make a round trip. Throughput measures how much data can be transferred continuously. Time to first response includes waits for DNS resolution, connection setup, authentication and destination-server processing. A route that downloads quickly may not open a complex page any faster; an exit with a short round-trip time may still struggle to sustain transfers when its shared link is congested. Browsing, video and interactive tools respond differently to these factors. Before choosing a route, identify which kind of delay is actually causing trouble.

Connection setup involves more than the protocol handshake. A cold start may require resolving the entry hostname, establishing the underlying transport, validating a certificate, completing proxy authentication and then establishing the app connection. When a client reuses an existing connection, some of this cost is amortized. That is why the first request after switching routes should not be treated the same as ongoing use. To compare protocol overhead, keep the destination, access network and client settings consistent, and observe both the first page load and later requests.

Set Up Comparisons You Can Repeat

The most useful record is not simply “fast” or “slow,” but a set of conditions you can reproduce. Note the platform, access method, route name, protocol, destination and whether the issue occurs during connection setup or data transfer. Do not change the exit, protocol and client mode at the same time. Even if things start working, you will not know which change helped. Keep everything else fixed, change one factor, then repeat the same task. That gives you a meaningful comparison.

A connected icon in the client only means it considers the connection established; it does not verify the app. Conversely, a website loading does not prove that every app uses the same path. Browser extensions, in-app proxies, system proxies and virtual network adapters may each handle different traffic. First confirm which component is handling the request, then assess the exit and protocol. This is essential context for every comparison on this page.

A useful order of checks: Is the access network working? → Is the client handling the request? → Are the entry point and protocol available? → Can the exit reach the destination? Do not jump from one page error to a protocol ranking.

Stream Protocol Design Trade-offs

Shadowsocks and VMess: Check the Full Configuration

Shadowsocks is a relatively lightweight encrypted proxy protocol. Common implementations handle both stream connections and datagram forwarding. It focuses on proxy transport rather than putting every network function into the protocol itself. Its security properties and resource use depend on the encryption method, client implementation and transport settings. Compare the full options in your subscription rather than generalizing from a particular older implementation to every Shadowsocks connection. The name alone cannot tell you whether it suits a given access network.

VMess incorporates authentication and encryption into its protocol design and is commonly used with proxy cores that support rule-based routing. Its performance also depends on the underlying transport: direct transport, additional encapsulation and multiplexing settings can all change handshake and resource costs. Some authentication flows depend on the device clock. If the system time is significantly off, a seemingly correct configuration may fail authentication. In that case, check time synchronization and subscription integrity before repeatedly changing encryption parameters.

Neither protocol can be judged by labels like “lightweight” or “feature-rich.” A lightweight design does not guarantee higher throughput on a congested link, and more features do not necessarily mean higher battery use during everyday browsing. The device’s encryption support, whether it keeps idle connections alive and whether detailed logging is enabled can all affect resource use. For most users, the supported configuration provided by the subscription is a safer choice than manually combining parameters from different sources.

Trojan and VLESS: Separate Authentication from Transport Security

Trojan is commonly deployed over TLS, which protects the connection carrying proxy authentication and data. The client needs to validate the server certificate and hostname correctly; a certificate error is not a decorative warning to ignore. The first connection typically involves establishing the underlying connection and TLS. Session reuse and keeping existing connections alive can affect the wait for later requests. Trojan suits scenarios that need mature client support and a clear certificate-validation process, but it still depends on route quality.

VLESS separates authentication from transport protection. The protocol itself does not encrypt content, so it needs to be paired with an appropriate secure transport layer. This distinction matters: a streamlined protocol does not mean every deployment has the same security properties, nor does it automatically mean the connection is plaintext. Check the transport and security settings specified by the subscription, along with server identity verification. Do not disable verification to make an error disappear or apply parameters from another node to the current route.

Additional encapsulation is generally useful for adapting to deployment and network conditions, not for getting higher speeds for free. It can add overhead for headers, buffering, parsing and connection management, while improving compatibility on specific paths. Multiplexing can reduce the cost of repeatedly establishing connections, but it may also make requests share queueing delays and the impact of a transport failure. Treat these features as tools for particular conditions, not performance switches to turn on by default.

What Connection Overhead Means for Your Choice

For short webpage requests, compare cold starts with requests made after a connection is reused. For sustained file transfers, watch for steady throughput and client load. Encapsulation that is negligible on a desktop may have a different impact on a resource-constrained mobile device. There is no universal ranking of overhead across platforms; compare complete configurations under the same conditions. Check the user panel for the protocol options currently available on VPNEG routes. This chapter explains protocol concepts; it does not mean every route supports every combination.

QUIC Protocols and Datagram Paths

What Hysteria2 and TUIC Are Designed to Do

Hysteria2 and TUIC both build proxy transport on QUIC. QUIC runs over UDP, but that does not mean it simply sends data without checking whether it arrives. Reliable streams still use acknowledgements, retransmission, flow control and congestion control, and establish secure connections with TLS. Understanding this distinction helps avoid reading “uses UDP” as “unaffected by packet loss” or assuming it is automatically suited to every wireless network.

QUIC can carry multiple independent streams on one connection, reducing waits between streams caused by transport-level ordering. However, shared network capacity and congestion control still affect overall throughput, and lost data within a reliable stream still needs to be recovered. QUIC addresses head-of-line blocking at a specific layer; it does not eliminate queues or retransmission. If the path from the exit to the destination is congested, using QUIC from the client to the entry point cannot make the destination server process requests faster.

Hysteria2 is designed for proxy transport and includes congestion-control and bandwidth-related settings. Performance depends on whether the server policy and parameters fit the actual path. Setting a very high bandwidth hint cannot create access capacity; it may instead make sending behavior mismatch the bottleneck. Most users should stick with the subscription configuration rather than increasing generic parameters found online. Before adjusting anything, establish whether the client or server controls the setting and whether the current implementation supports it.

TUIC also uses QUIC to carry proxy traffic. Its stream forwarding and datagram handling depend on the client implementation and configuration. Sharing some underlying technology with Hysteria2 does not make their authentication, congestion strategies, connection management or datagram forwarding identical. No speed conclusion follows from the protocol names alone. To compare them, use the same exit, access network and task, then check connection success and performance over sustained use.

UDP Reachability and Network Switching

Some access networks handle UDP differently from TCP. They may have short-lived mappings, traffic shaping, variable path quality or unreachable datagrams. If ordinary webpages work but a QUIC route cannot connect, consider the underlying UDP path before suspecting the destination app. You can compare it with another transport option available in your subscription. If the alternative works, that shows the paths behave differently; it does not prove one protocol is more reliable on every network.

QUIC supports connection migration, but whether a specific proxy implementation enables it—and whether the connection survives an address change—depends on the server, client and access network. Switching from Wi-Fi to a mobile network can change path quality, addresses and mappings. Even if the underlying connection survives, the app’s own session may not. Check whether new requests work after the switch rather than relying only on whether the client still shows the connection as active.

Throughput Is Not the Only Measure of Resource Use

QUIC’s encryption, datagram handling and connection-state management often run in user space. CPU and memory use depend on the core implementation, system interfaces and workload. Higher throughput may require more processing, or it may finish a transfer sooner and reduce active time. When evaluating a mobile device, also watch heat, background activity and task completion. One smooth download does not prove the same configuration will save battery all day.

Hysteria2 and TUIC are transport options, not guarantees against packet loss. Confirm that the UDP path works before considering congestion control, connection reuse and device overhead.

Direct, Relayed and Dedicated Routes

The Network Path Behind a Route Name

A direct route usually means the client connects through its access network to an overseas service entry point without an additional provider-arranged relay in front. The structure is relatively straightforward, but the actual path is still determined by ISP routing; a nearby location does not necessarily mean fewer network detours. Entry-point reachability and international egress can vary considerably between access providers. So a direct route working differently at home and at the office is not a contradiction, nor does it necessarily mean the client settings changed.

A relayed route adds a forwarding step between the route’s entry point and final exit. The idea is often to connect the client to a more suitable entry point, then use a provider-arranged path to reach the exit. An extra hop adds processing and propagation costs, but avoiding a poor public route can still improve end-to-end performance. Conversely, a congested relay entry or weak intermediate link can become a new bottleneck. More hops do not automatically mean a worse experience.

An IEPL dedicated route uses a dedicated link for a specific part of the transport path, typically to provide more control over routing and link quality. The client-to-entry and exit-to-destination legs often still use other networks. A dedicated-route label does not mean the entire path is exclusive, nor does it increase the destination service’s capacity. To judge whether it suits your network, observe performance during peak hours and sustained interactive use rather than treating the name as an end-to-end quality guarantee.

The Exit Region Is Not the Entry Location

Locations shown in the client—such as Hong Kong, Tokyo or Frankfurt—usually identify the exit region. They do not describe the full entry and intermediate path. An app’s view of your region may also depend on IP geolocation databases, account region and service policies. If the route name and a website’s location check disagree, first confirm that the request actually used that exit, then consider differences in location databases. Do not infer the exit location from page language, currency or search results alone.

The outbound and return paths may also differ. Data sent from the client to the entry point and data returned by the server do not necessarily use the same ISP interconnection points. Normal downloads but slow uploads, or occasional pauses during interaction, may point to a bottleneck affecting one direction. Most clients cannot show the provider’s complete internal path. You can hold the task constant and compare entry points or route types, recording what happens clearly rather than drawing conclusions from incomplete traceroute output.

VPNEG offers international routes and routes to mainland China. Examples include Hong Kong IEPL, Singapore relay, direct routes to Tokyo, a Los Angeles relay, a direct route to Frankfurt and an exit in Shanghai for routes to mainland China. These illustrate different directions and route types, not a performance ranking. For current regions and route categories, see Servers and Routes. Availability is shown in the user panel. Coverage includes 120+ countries / 180+ routes, but scale alone cannot replace testing on your access network.

Choose a Topology That Fits Your Destination

For services in mainland China, first decide whether you need an exit in mainland China. For international services, consider the destination region and entry-point quality. Do not choose a nearby exit at the expense of the service’s regional requirements, or stick to a particular region if the route is persistently congested. Where possible, compare route types that meet the region requirements, then keep the options that work well on your access network. Region, topology and protocol are separate factors; check each one independently.

A dedicated, relayed or direct route cannot guarantee that a destination platform will accept a particular exit. Streaming services and AI tools may make additional checks based on accounts, payment regions, IP reputation or business policies. Smooth data transfer and platform permission are separate issues. If ordinary webpages work but a specific service flags your region or account, keep the notice and check the service’s rules. Repeatedly changing topology will not fix an app policy issue.

Packet Loss and Peak-Hour Congestion

Where Packet Loss Happens

Packet loss can occur at many points, including the wireless access link, home router, ISP interconnection, service entry point or exit. Weak wireless signals, interference and busy devices can cause retransmissions on the access side; routers may also drop packets when queues fill up. Apps only show a stalled request or slow transfer—they do not identify where the loss happened. Start troubleshooting with the parts of your local setup you can control, then compare routes and exits.

Reliable transports need to recover lost data, adding wait time and potentially triggering congestion-window adjustments. Interactive requests may pause occasionally, while sustained downloads may fluctuate. The content can arrive intact and the experience can still suffer. Datagram-based apps may tolerate some loss and continue, resulting in choppy audio or visual changes. Apps use different recovery strategies, so the result from one webpage cannot tell you how every service will behave.

Not every lost packet means the physical link is poor. Some devices give probe packets a lower response priority, and an intermediate router not replying does not mean it failed to forward application traffic. If requests continue to succeed, a probe timeout alone is not proof of a fault. Compare probes with real usage: whether apps also pause, whether multiple destinations are affected and whether switching access networks helps are more informative than an isolated result from one hop.

Congestion, Bufferbloat and Shared Resources

During peak hours, the same access link, interconnection point or exit may carry more concurrent traffic. If incoming data exceeds processing capacity for long enough, queueing delays grow. Large buffers can hold more data temporarily, but they can also leave interactive requests waiting in line. That is a common source of bufferbloat. Downloads may keep running while webpage clicks and remote controls feel sluggish—not because a protocol setting suddenly stopped working, but because queueing delays are hurting responsiveness.

Home networks share capacity too. Cloud backups, system updates and uploads from other devices compete with your current app. If the upstream link is saturated, acknowledgements and interactive requests can suffer, making downloads seem slower too. First pause background transfers you can identify while keeping everything else the same. If performance improves, consider scheduling sync tasks or checking your router’s queue management instead of blaming the international route straight away.

Congestion control in a protocol uses network feedback to regulate sending; it is not permission to seize bandwidth without limit. Overly aggressive settings can increase queues, retransmissions and resource use, making the network harder for other apps to use. During peak-hour fluctuations, compare entry points, route types and exit paths first, then consider parameters supported by the service. Increasing every buffer and bandwidth setting usually does not locate the bottleneck and may hide the original problem.

Compare by Symptom

If local websites are also slow on the same device, check Wi-Fi signal, the router and your access network first. If local sites work but every subscribed route has problems, check how the client handles traffic, subscription status and conflicts with other network tools. If only one exit is affected, compare other routes in the same region. If only one destination is affected, check its status and the interconnection between the exit and destination. Following this order helps avoid pointless protocol switching.

For a peak-hour comparison, keep the task as consistent as possible. Video quality may adjust automatically, webpages may load from cache and download sources may change delivery servers—all of which can make a route switch seem more effective than it was. Note the first response from the same page, whether repeated actions in the same app pause, and whether a short pause clears on its own. Do not saturate the link just to test it; the test itself can cause congestion and affect other devices.

Compare peak-hour stability using the same task under similar conditions. A protocol cannot fix a busy destination server or deliver more data at once than the access network can handle. A route type can only affect the part of the path it actually carries.

When reporting a problem, replace “it’s bad at night” with the destination, route name, access method and when the pause occurs. Say whether you paused background transfers. Remove account details and subscription contents from any error messages before sharing them. These notes help distinguish general congestion, a route-specific issue and a device problem. They are more useful than repeated speed-test screenshots without context.

Device Resources and Mobile Battery Use

Battery Drain Comes from Ongoing Activity, Not Just Encryption

Mobile battery use depends on wireless communication, CPU, screen and background activity. A proxy client processes encryption, routing rules, connection maintenance and data forwarding, while apps can keep generating traffic through refreshes and sync. Comparing battery levels before and after a session can easily confuse usage time or signal changes with protocol impact. A better comparison keeps the task, access method and background apps similar, then checks heat, system battery-use breakdowns and connection recovery—not just the slope of the battery graph.

With a weak signal, the wireless module may retry more often or stay active longer, increasing battery use for reasons unrelated to protocol processing. Frequent small requests, keepalives and background notifications can also extend network activity. Conversely, a protocol with slightly higher processing overhead may complete a task more smoothly and return to idle sooner, so total battery use may not be higher. You cannot rank protocols by battery efficiency without considering signal conditions and app behavior.

CPU use also depends on the encryption implementation, hardware, data copying and system network interfaces. Desktops usually have more resources than mobile devices, so the same transport configuration can result in different temperatures and CPU use. Detailed logging, complex routing rules or multiple network tools running in parallel can add more work. Start with a supported default configuration, turn off extra debugging features and then decide whether a different protocol or traffic-handling mode is worth testing.

System Proxies and Virtual Network Adapters

A system proxy is used by apps that support it; not every program follows the system setting. A virtual network adapter handles traffic at the network layer and may cover more connections, while also needing to manage routes, DNS and packet forwarding. It should not be treated as “the faster mode,” and a system proxy is not automatically more battery-efficient. Choose based on whether the target apps use the system proxy and what the client supports on your platform. Avoid having multiple tools handle the same requests.

Desktop environments may also use browser proxy extensions, command-line environment variables and app-specific proxy settings. If a browser works but the command line does not, they may be using different traffic-handling methods. On Linux in particular, distinguish desktop settings from the environment of terminal processes; similar differences can occur on other platforms. First identify which process made the request and what settings it inherited. Do not change global routing to work around a configuration problem in one app.

Background Restrictions and Battery Optimization

Mobile operating systems may restrict app activity when the screen is locked or an app is in the background. If a connection only drops after the screen locks, check the system’s background management for the client before changing every route. Battery-management menus vary between Android devices, so check the instructions for your current system. On iOS, check the VPN configuration and network extension status. For troubleshooting, change only settings relevant to the issue rather than disabling battery management for every app.

Client keepalive settings should suit how the access network handles connection mappings. Frequent keepalives can keep the wireless connection active longer, while intervals that are too long may let an idle connection expire. The right value depends on the implementation and network; there is no one-size-fits-all setting. Keep the subscription and client defaults unless you can reliably reproduce idle disconnections. Before making a change, note the original value. If it does not help, restore it so you can keep a useful baseline.

VPNEG supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices. Each device still has its own access network and system constraints. You can choose a suitable route for each device; they do not all need to use the same protocol. Find the client downloads in the user panel. For first-time iPhone setup, see the iOS Setup Guide.

Choose a Protocol for Your Use Case

Web Browsing and AI Tools: Prioritize Responsive, Reliable Connections

Browsing involves DNS lookups, connections to multiple resources and script requests, so the experience is often affected by the first response and occasional pauses. When choosing a route, compare response consistency among exits that meet the destination’s region requirements, then check that the client is routing traffic correctly. A fast download of one large file does not mean a complex webpage will load quickly. For everyday reading and research, reliable connection reuse and fewer interaction stalls usually matter more than peak throughput.

AI tools often stream generated text over a persistent connection, so it is worth checking both how quickly the response starts and whether it stays connected. If the page loads but generation does not continue, check the app session, browser extensions and destination service status before comparing exit routes. Repeatedly switching regions may trigger account checks and will not reliably fix an app issue. Protocols are only one part of transport; regional policies, account access and platform load need to be checked separately. For details on this use case, see ChatGPT Access Guide.

For these interactive tasks, start with a supported configuration that connects reliably on your current network, then decide whether to test a QUIC option. If UDP works consistently, Hysteria2 or TUIC can be useful comparisons. If the path has trouble connecting, a working stream transport is more valuable. Keep the exit direction and task similar during comparisons. Do not also change browsers, clear all caches and switch protocols at once, or you will not know what helped.

Video, Files and Remote Work: Different Bottlenecks Matter

Video depends more on sustained transfer capacity and consistency. Players buffer and adjust quality automatically, so a brief smooth session does not prove a route will work well long-term, and a drop in video quality is not automatically a protocol fault. Check the platform’s region and account rules first, then watch for repeated buffering during extended playback. For video services in mainland China, choose a return route with the appropriate exit direction rather than picking an international route based only on geographic distance. Actual availability still depends on platform policies and results when you connect.

For file transfers, distinguish upload, download and source-side limits. Cloud storage may limit speed based on account, file or delivery server, and the destination server may have limited upload capacity. If the same file is still slow after changing exits while other destinations work, the source is a more likely cause. Large-file tests also use subscription traffic, so avoid repeatedly downloading entire files to compare protocols. A short, necessary transfer is usually enough to spot obvious pauses.

Remote work combines meetings, documents, code downloads and interactive tasks, each with different needs. Voice calls are sensitive to jitter and packet loss, remote terminals depend on responsive input, and file sync needs sustained throughput. Choose a route that remains consistent during the task, and test it before important work. Company apps may require an organization-approved network method. Follow your organization’s rules if there is a conflict; do not move work traffic onto an unauthorized path.

Choose a Plan Based on Usage, Not Protocol Name

Protocols add encapsulation and connection-management overhead, but everyday traffic differences are more often driven by video quality, file sync, software updates and time spent online. A protocol being described as lightweight does not mean a smaller plan will be enough. VPNEG 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 based on the remaining days. Check your usage records in the panel and consider the tasks you actually use.

If you use the service intermittently, compare the rules for data packs and monthly plans. Data packs cost ¥158/300GB, ¥358/1000GB and ¥658/3000GB. They remain available until used and never expire. This pricing model fits different usage patterns; it does not provide a transport channel reserved for a particular protocol. See Plans and Pricing for details, and the Data Pack vs. Monthly Plan Guide for help estimating usage. Do not confuse billing options with route topology.

A sensible order is: destination region → routes available on your current network → protocol suited to your device → plan that fits your usage. VPNEG offers a 14-day refund policy; this is not a guarantee of access to any particular destination platform.

Keep recommendations tied to their conditions: a configuration suits a particular device and access network, not every device forever. Recheck it if your network, client settings or tasks change. Keeping a few familiar routes and a backup direction is more practical for ongoing use than chasing protocol rankings.

Connection Verification and Troubleshooting Notes

Start with a Repeatable Baseline

Before testing, confirm that your regular access network works, pause any large background transfers you can identify and keep your current client configuration. Get your subscription through the user panel. Do not use publicly shared links or give your personal subscription to unfamiliar tools for conversion. VPNEG does not require an email address; a username and password are enough to create an account. Subscription and client downloads are available in the panel. For the steps to import a subscription, return to the Quick Start Guide. Do not mix configurations from multiple sources while troubleshooting.

To establish a baseline, note the route name, protocol, access method, destination app and traffic-handling mode, then repeat the action that causes the issue. First check whether the client can establish a connection, then whether it handles the destination request, and finally how the app responds. DNS and connection state may still be recovering just after a device starts, wakes or switches networks; include that context in your notes. Do not treat a brief recovery failure as the same symptom as a persistent fault.

To check your exit, use the Network Check page on this site and compare the result with the route currently selected in your client. Exit addresses are network information; do not post them publicly without a good reason. Geolocation results can also differ between databases. A browser check only describes the browser’s requests; it does not prove that every background app is using the route. If a separate app still has trouble, check its proxy support and routing-rule matches rather than repeatedly refreshing the check page.

Handle DNS, Certificates and App Errors Separately

If DNS resolution fails, first distinguish between an entry hostname that cannot be resolved and a destination hostname that cannot be resolved. The former may prevent the proxy connection from being established; the latter can occur after the connection is working normally. Clients may resolve names locally or remotely according to their rules, and the results can differ. One failed domain does not prove the entire DNS path is broken. Do not copy DNS settings from online at random; check your existing rules and system settings, and whether another app is overriding DNS behavior.

If you see a certificate or authentication error, save the exact message and check the device clock, subscription integrity and client support for the configuration. Do not bypass certificate checks to force a connection; doing so changes how the server’s identity is verified. Authentication failures may also be caused by subscription status or missing parameters. Check the panel and reimport a supported configuration. Redact hostnames, account identifiers and subscription contents before sharing an error message.

Treat a destination app’s region, permission, expired-session or too-many-requests notice as an app-level issue. First check whether other destinations work, then read the service’s own message and policies. If page content loads but account features are restricted, verify network reachability and account access separately. Repeated route changes, resubmissions and sign-ins can add noise to troubleshooting. Keeping the original error text is more useful than describing every issue as a “dead node.”

Share Only Relevant Logs and Support Details

Client logs can show connection setup, rule matches and error stages, but not all logs are safe to share publicly. Full logs may include visited domains, device paths, account identifiers or subscription parameters. Find the entries around the time of the issue and remove sensitive details first. Never upload your full subscription or publish a client-exported configuration as plain text. VPNEG’s anonymous no-logs policy is a service privacy commitment; it does not mean your device cannot create local diagnostic records.

For a useful report, include the platform and access method, selected route and protocol, affected destination, exact error, whether the issue occurs on another access network or exit, and what you have already changed. Say whether the change helped and keep the original settings so you can revert. There is no need to share account passwords or payment details unrelated to troubleshooting. For further help, submit a ticket through the user panel. You can also find common explanations in the FAQ.

Knowing when to stop matters too. Once you have a configuration that works consistently and can be reproduced, there is no need to keep changing every setting. If a change does not clearly help, restore the baseline. If the problem affects only one destination, check that service before changing the whole system.

The goal is not to name a protocol that wins forever. It is to find a connection setup you can explain and verify. Check the entry and exit, transport protocol, device traffic handling and app rules separately to know where to make changes. When network conditions change, repeat the checks in the same order and build on what worked instead of guessing from scratch.