VPN Protocol and Route Guide

Keep protocols, transports and routes separate

The protocol name in a subscription tells you how the client and proxy server organize data; it does not describe the full path that data takes. A request also involves local access, DNS resolution, a connection to the entry point, server forwarding and the destination's response. A smooth route won't make a busy destination load quickly, and a lightweight protocol won't ensure a stable connection if the exit is congested. Start by separating these layers.

App-level proxying and system-wide traffic routing are also different. A system proxy usually affects only apps that follow the proxy settings. A virtual network interface routes matching traffic through the client for the system to process. If an app isn't using the proxy, that doesn't automatically mean the protocol has failed. Check how the client handles traffic, whether the rules match and whether DNS resolution is consistent with the routing decision.

Time to first response is not the same as sustained transfer

Connection setup time measures how long it takes to start exchanging useful data after a request. DNS resolution, transport handshakes, authentication and security negotiation may all contribute. When an existing connection can be reused, later requests skip some or all of that work. So a page opening slowly the first time and quickly the next doesn't mean the route suddenly improved. Caching and session reuse can have a similar effect; compare under similar conditions.

Sustained transfer is about delivering data after a connection is established. Large downloads depend mainly on available throughput, interactive pages reveal brief stalls and queueing more readily, and video calls are particularly sensitive to interruptions. A route that handles downloads well may still struggle with calls; a quick response from one webpage doesn't guarantee a long-lived connection will stay up. Evaluate the actual task instead of reducing every experience to a single speed label.

Latency is the time for a round trip; jitter is variation in that time; packet loss means data doesn't arrive as expected. They affect one another but are not interchangeable. A high-latency but steady route may work well for reading and file sync, while a lower-average-latency route with frequent spikes can make calls choppy. Plenty of bandwidth won't prevent queueing either, especially when uploads saturate your local connection and interactive requests have to wait.

Limits of qualitative comparisons

Protocol resource use depends on the encryption implementation, number of connections, data copying, logging level and device hardware. The same protocol can have different processing costs across client cores and operating systems. Hardware acceleration, complex rules and DNS sniffing all affect the results. Tests run in different environments can't establish that one protocol is always faster or more energy-efficient.

Connection reuse can reduce the cost of setting up connections repeatedly, but it can also make more requests share one underlying channel. If that channel is blocked, the impact may be wider. Implementations handle reuse, flow control and recovery differently, so don't assume a setting should always be enabled. Establish a working baseline with the client's default settings, then change one thing to address a specific issue. That's easier to assess than enabling every optimization at once.

This page covers general protocol design; it does not promise that every feature is available on every VPNGS route. Check the subscription details in your account panel and your client's compatibility to see whether a transport, authentication or reuse feature is supported. If an import fails, don't edit protocol fields by hand: similar-looking configurations can differ substantially in parameter meanings, certificate validation and datagram support.

A useful comparison order: confirm traffic passes through the client, keep the destination and route fixed, then check first response, sustained transfer and recovery after disconnection. Change one variable at a time and note which part of the connection changes.

You can record results in a simple table using the same network, destination and entry point. Note whether a connection is established, whether the page responds consistently and whether switching networks restores service. Don't count changes in login state or destination-side errors as network failures. Identify which layer is at fault before comparing protocols or routes; otherwise, repeated switching may produce differences you can't reproduce.

Shadowsocks: straightforward data encapsulation

Shadowsocks is an encrypted proxy protocol. Common implementations encapsulate the destination address and application data before forwarding them to a server. Its design is relatively straightforward, but that doesn't mean it always uses the fewest resources. Performance still depends on the cipher, implementation, device acceleration and network quality. When assessing security, look at the specific method in use—not just the protocol name.

Modern implementations typically use authenticated encryption, which lets the recipient detect modified data. The client must support the encryption method specified in the subscription; an older implementation won't become compatible with a newer one just by changing a name. In most cases, keep the parameters supplied by the account panel. If the client reports an unsupported method after import, check its compatibility rather than swapping in a more familiar-looking option.

Check stream-based traffic and datagram forwarding separately. A browser opening a webpage shows only that the relevant requests succeeded; it doesn't prove that calls, games or other datagram-dependent apps will work. Client traffic routing, server support and the network in between can all affect datagrams. If only some apps have trouble, first identify how they send traffic, then check that the subscription and client support it.

VMess: authentication and encapsulation

VMess includes authentication and data encapsulation for proxy sessions. Clients commonly pair it with different underlying transports, so two subscriptions labeled VMess may use different handshake flows. A security layer on the transport, an additional carrier layer or connection reuse can all change setup costs. Comparing protocol names alone misses important factors that affect the experience.

System time is one of the first things to check when troubleshooting VMess. Some authentication processes rely on time checks, so an incorrect device clock can cause a connection to be rejected even when the credentials are correct. Don't troubleshoot by repeatedly changing authentication fields. Enable automatic time sync in the operating system and check the client logs for authentication errors. Reconnect after correcting the clock, then check for any remaining server or network issues.

Extra encapsulation can help with compatibility or deployment, but it also adds protocol layers. Each layer may introduce buffering, flow control or handshake behavior; more layers don't automatically mean more features. For most users, importing the complete configuration from the account panel is safer than assembling one by hand. Advanced users should record both the proxy protocol and its transport to avoid attributing transport differences to VMess itself.

Compatibility and how to evaluate it

When device compatibility is good and route quality is comparable, check how real apps perform before worrying about small overhead differences. File sync depends on sustained throughput, web apps on responsiveness and reuse, and long work sessions on recovery after disconnection. If you change the protocol, region and route type at the same time, the result only shows that the overall connection changed—not that one protocol made the difference.

When troubleshooting, confirm that the subscription has fully refreshed in the client and read the error details—not just the node name. If no nodes can connect, start with the local network, client permissions and traffic-routing mode. If only one entry point fails, check that entry point and its parameters. Narrowing down the scope helps avoid concluding that a protocol is unsuitable for your device because of a temporary issue in one region.

Neither protocol determines the business attributes of the final exit or whether a destination will allow access. Region detection, account permissions and terms of service are separate issues. If a webpage returns a clear service-related message, changing the encryption method usually won't help. Check the platform's regional requirements and your account status, and treat network connectivity and service eligibility as separate questions.

Trojan: proxy traffic over a TLS connection

Trojan typically uses TLS to establish an encrypted connection, then handles proxy authentication and data forwarding inside it. Keep transport security separate from proxy authentication: the certificate helps the client verify the server and protect data in transit, while the proxy credentials determine whether the service can be used. Correct credentials don't make a failed certificate check safe; these protections address different issues and can't replace one another.

Certificate validation can depend on the hostname, trust chain and validity period. If the client reports an error, first check the system clock, server name in the subscription and network environment. Don't routinely skip validation as a workaround; doing so weakens verification of the server you're connecting to. If the account panel supplied the configuration and the error persists after an update, submit a support ticket with the error type so the server team can check the certificate and deployment.

TLS handshakes involve round trips, but their cost isn't fixed. Session resumption, existing connection reuse, client implementation and the network in between all affect first response. A fast request may have reused existing state; a slow first connection after switching networks may need to negotiate again. Don't judge Trojan by a single page load—compare new connections with requests made over an existing session.

VLESS: a lightweight protocol isn't encryption by itself

The basic VLESS protocol focuses on authentication and forwarding; it doesn't provide content encryption in the traditional sense. It is typically paired with a suitable secure transport. Seeing VLESS in a subscription doesn't tell you how the complete setup is protected, so check the transport and security parameters too. Calling it “more secure because it's lighter” or “unusable because it isn't encrypted” overlooks the complete configuration.

Different secure transport combinations require different client support, and their parameters don't all mean the same thing. You don't need to memorize every field, but remember that a subscription is a set of interdependent settings. Copying only the address and credentials while missing the server name or another required parameter can break the connection. Using the import option provided by the account panel helps avoid inconsistencies from manual entry.

A compact VLESS protocol header doesn't mean the full path has no overhead. Security negotiation, transport encapsulation and network round trips still apply. On a lightly loaded device, header differences may be hard to notice; with complex rules or many concurrent connections, other processing costs may matter more. Ask whether the complete setup works for your use case—not whether “lightweight” translates into a fixed speed gain.

Check security settings alongside real-world performance

With these combinations, it's also worth checking where DNS resolution happens. A client may resolve the entry-point hostname first, then use rules to determine how to resolve the destination hostname. Entry-point resolution failure, destination resolution failure and certificate name mismatch are different problems. If the logs only say the handshake failed, use the surrounding entries to identify the layer where it stopped; don't keep changing system DNS or proxy mode without evidence.

If the connection is established but stalls occasionally, check route queueing, transport flow control and destination response. A valid certificate shows that the secure connection passed validation; it doesn't guarantee speed. Likewise, connecting after disabling validation doesn't prove the route is fixed. Assess connection correctness and performance separately so that weakening verification doesn't hide a configuration issue.

Military-grade encryption is part of this service's security description. For any specific connection, start with a correctly imported configuration, keep identity verification enabled and manage subscription credentials carefully. Security claims are no substitute for checking your settings.

For extended work sessions, Trojan and VLESS with a suitable secure transport are both options, provided your current client fully supports them and the route is stable. Once you choose a setup, keep the exit region and commonly used rules consistent to avoid needless switching. To see the entry points and route types available in each region, visit the server routes page. Route categories reveal more about the actual path than a protocol name alone.

If an issue occurs in only one client, keep a working configuration for comparison, then check which transports the client supports and how it handles certificates. A link that imports on one device isn't necessarily compatible with every device. Different parsers may display the same subscription differently or support different features; judge by the connection result and specific log messages.

First, understand UDP and QUIC

UDP carries datagrams; unlike TCP, it doesn't guarantee delivery of an ordered, reliable byte stream. Protocols built on UDP can add their own reliability, congestion control and encryption. QUIC combines these capabilities and can organize multiple streams within a connection. So “uses UDP” doesn't mean application data is lost at random or that there's no flow control—the key is how the protocol above UDP uses it.

Hysteria2 and TUIC both use QUIC-related capabilities, but their design goals, authentication flows and forwarding behavior differ. They aren't interchangeable names. The client must explicitly support the protocol and configuration format. A subscription displaying the protocol name doesn't guarantee that the client core fully supports it. If a connection fails, check how the configuration was parsed and whether the core supports it, not just whether the node appears in the list.

Congestion control can't eliminate congestion

Hysteria2 includes congestion-control options designed for proxy traffic. Some modes use bandwidth-related settings to influence sending behavior. Bigger values aren't always better, and setting an exaggerated limit by guesswork can cause queueing, retransmissions or competition with other apps if the settings don't fit the actual link. For everyday use, stick with the adaptive settings provided by the subscription and client.

TUIC also uses QUIC to handle proxy sessions. Its performance depends on how the implementation handles congestion control, datagrams and connection management. It offers another transport option, but can't eliminate local Wi-Fi interference or an overloaded destination. A smooth download doesn't mean the protocol “overcomes all packet loss”; persistent congestion still needs to be addressed by reducing competing traffic or changing the actual route.

Multiplexing can reduce some forms of waiting between streams, but lost data still takes time to recover. A stream may have to wait for its own missing data, and all streams share the capacity of the underlying link. An app that puts important operations into a single long-lived connection may benefit differently from a multi-connection download. Evaluate the app's actual behavior; don't equate a transport feature with a guaranteed improvement.

Mobile networks and middleboxes

Some networks handle UDP less reliably than TCP. You might be able to reach an entry point and open webpages occasionally, yet still have trouble with sustained transfers. Connection state timeouts, network changes or packet-size issues can also play a part. Under the same route conditions, compare with a known-good TCP-based configuration to see whether the difference is at the transport layer before assuming the client is installed incorrectly.

QUIC has mechanisms for handling address changes, but results still depend on whether the proxy client uses them correctly, whether the server supports them and whether the app can tolerate interruptions. Recovery after a Wi-Fi or mobile-network switch doesn't mean every app session will continue uninterrupted. File uploads may need app-level resume support, video calls may have to reconnect, and web apps may re-establish long-lived connections. Test these behaviors separately.

A mismatch between packet size and path capacity may show up only during larger transfers. Small requests may work while larger content stalls or repeatedly recovers. Don't blindly adjust related parameters as a first optimization. Rule out local network and route issues, then use the diagnostics supported by your client. Without clear evidence, keeping the defaults is usually safer than changing several low-level values at once.

QUIC-based protocols are a route option, not a speed guarantee. Whether they suit your environment depends on UDP compatibility, the client implementation and current congestion.

Battery life and processing overhead also matter. User-space transport handling, encryption, acknowledgements and retransmissions can increase device workload, while connection reuse may reduce some repeated costs. The result depends on the device and traffic pattern. For extended mobile use, consider recovery after disconnection, background stability and heat—not just a single desktop download.

A practical approach is to keep one proven standard route as your baseline and test Hysteria2 or TUIC as alternatives. You can switch back to the baseline in a difficult network environment to confirm whether your apps recover. Don't change congestion settings, packet size and routing rules all at once; even if performance improves briefly, you won't know which change helped.

The route matters more than its label

A direct route usually means the client connects straight to an overseas entry point, skipping an explicit relay. The actual network still passes through carriers and multiple routing segments. One fewer service-layer hop doesn't guarantee a shorter physical distance or less queueing. Carrier peering, regional egress and the return path from the destination can all affect performance. The benefit of a direct route is a more straightforward route structure—not inherently the lowest latency.

A relayed route typically sends traffic to an entry point first, then forwards it along a path selected by the service to reach the exit. An entry point close to you may make local access more stable, but additional forwarding adds processing and path costs. A relay helps only if it avoids a problematic peering segment. Neither “one extra hop” nor “a closer entry point” is enough to judge the entire route.

IEPL describes a type of network transit, not a proxy protocol. It can form part of a route and reduce uncertainty on some public peering segments, but local access to the entry point and routing from the exit to the destination still need to work. A dedicated-line label doesn't mean the entire end-to-end connection is exclusively yours, or that wireless access, server processing and the destination app can't become bottlenecks.

Route illustration: local access → service entry point → transit path → exit and destination. The diagram does not represent actual physical distance.

Check entry and exit regions separately

Users often care about the exit region because the destination sees the exit address as the source of a request. The entry region determines where the client connects first; the two may differ. A subscription name can help identify a route, but it isn't a complete description of the path. If a destination shows a different region than expected, check that the rules selected the right exit, then consider whether the platform's own IP geolocation data may differ.

The return path matters too. Requests and responses may take different routes, so a smooth outbound path doesn't guarantee stable interactions. Traceroutes provide only a partial view; intermediate devices often don't respond or may limit probes. An unusual-looking hop doesn't prove that the end-to-end service route is broken. Interpret route information alongside the destination connection and actual app behavior.

When comparing routes at peak times, keep local access as consistent as possible. A download running over Wi-Fi at home may be competing for bandwidth; if it stops after you switch routes, the improvement may have nothing to do with the route. Pause background sync, check your Wi-Fi signal and then test alternatives. If possible, compare different access methods on the same device, but note the change in access rather than treating the results as the same route under identical conditions.

A route label doesn't grant access to a service

Labels such as “native IP” describe address attributes; they don't prove that a particular platform will allow access. A platform may consider account region, payment details, activity history and address reputation. It can still display a region or account notice even when the network connection works. Choose a route for network stability and regional consistency, then follow the platform's rules for account eligibility. An address label isn't permission to use a service.

Cities in a route list are useful clues for choosing a route, not proof of physical data center distance. Carrier policies can affect routing, and an exit that looks close on a map may still take a detour. For work, prioritize a path that performs steadily for interactive tasks; for downloads, a longer route may be fine if sustained transfer is smooth. Choosing by use case is more useful than ranking by map distance.

VPNGS covers 90+ countries with 180+ routes. See the servers page for available regions and route types; the options in your account panel are the ones available to connect to. Coverage gives you choices, but not every region suits every task. If your use case depends on a consistent exit, keep a short list of suitable options rather than switching regions frequently.

Find where the competition is happening

Peak-hour slowdowns often reflect higher demand for shared resources. Congestion could occur on your home connection, at carrier peering, at a service entry point or exit, or at the destination. Different bottlenecks can feel similar, so “it's slow at night” doesn't identify the cause. Check whether other sites and devices on the same network are also affected, then compare routes to help separate local access problems from issues farther along the path.

Local uploads are easy to overlook. Cloud sync, photo backups and video uploads can saturate your connection, making web requests and voice traffic wait in a queue. Download speeds may look fine while interactive apps feel sluggish. If pausing competing tasks immediately helps, address local bandwidth use before changing proxy protocols. Router queue management may help too, depending on your hardware.

Wi-Fi can also be affected by interference, shared airtime and retransmissions. Being close to the router doesn't guarantee a clear wireless environment; nearby networks and devices compete for airtime. If a wired or alternative connection works normally, check the Wi-Fi layer first. Proxy logs may show timeouts, but they can't prove that those timeouts happened on a cross-region link. Don't skip local comparisons.

How packet loss and queueing affect apps

Reliable transports recover lost data, but recovery takes time; an app may show a pause rather than an error. Persistent queueing also increases round-trip time, slowing acknowledgements and congestion control. Video calls may first sound choppy, webpages may hang while loading and downloads may fluctuate. These differences reflect what each task needs; they don't necessarily mean the apps are using different faulty routes.

Lost probe packets and lost application data aren't the same thing. Network equipment may deprioritize diagnostic requests while forwarding normal traffic. Conversely, stable probe results don't rule out application-layer problems: they don't fully test destination processing, long-connection timeouts or support for a particular transport. Use probes as clues, not as a substitute for observing real tasks over time.

Retries can make an issue disappear temporarily, but they can also add to congestion. Automatic page refreshes, repeated client reconnections and background sync can compete for the same resources. During an outage, pause unrelated traffic and keep only the app you're testing active, then restore background tasks one at a time. This reduces interference and helps show whether combined traffic caused the stalls or the route is unstable even under light load.

Narrow down the variables by the scope of the issue

If all exits fail but changing local access fixes the problem, start with the current connection and the client's network permissions. If only one region fails while others work, check that region's route and the destination service. If route types in the same region differ noticeably, temporarily use the steadier one. State the conditions for each comparison; changing the protocol, entry point and exit at once can't establish a single cause.

If only one app fails, start with the error type. DNS failure, connection timeout, certificate error and account rejection are different issues. If the app returns a clear permissions message, network transfer may already be working; another speed test is unlikely to help. If a page loads but an upload stalls, check long-lived connections, competing uploads and network changes instead of only testing whether the homepage opens.

Understand what automatic speed tests and route selection measure. The test destination may not be the service you want to use, and the fastest test route may not suit a call or a large download. Frequent automatic switching can also change your exit identity and interrupt sessions. For ongoing work, keep a route that you've tested with the actual app and switch to a backup only when there's a clear issue.

For a support ticket, include the client and operating system, connection method, entry-point name, error type, steps to reproduce and what changed when you switched routes or connections. Don't post subscription links, passwords or authentication details publicly.

After making a change, retest the same task instead of relying on the client's connection status. “Connected” means the tunnel was established; it doesn't guarantee the destination app worked throughout. Repeat the same meeting, editing or upload task and check whether the interruption is gone before keeping the setting. If you need help, use the account panel support ticket form and describe what you can reproduce rather than just saying “it's slow.”

Client cores and system-wide traffic routing

The client interface handles imports and controls; its core actually processes protocols and traffic. Seeing a configuration in the interface doesn't mean the core supports every field. If a node type doesn't work, check the client's documentation and error logs, then confirm the subscription has fully updated. Don't infer capabilities from an app's name or download installers from unknown sources. Use the client downloads page in the account panel for official downloads.

System proxy and virtual network interface modes have different permission requirements. The former may depend on apps following proxy settings; the latter usually requires system network authorization and routing control. If a browser works but other software doesn't, check whether that software uses the proxy. Broader traffic routing can also conflict with other network tools, so keep your original settings and check local network access and commonly used apps after making changes.

Domain and IP rules, as well as sniffing, use processing resources. The size of the ruleset, how it's updated and logging intensity affect startup and runtime costs, but deleting all rules isn't a sensible way to make a client lighter. Rules also determine what connects directly and what uses the proxy. Use a suitable configuration and remove tools you know are duplicating network functions instead of deleting routing rules you don't understand.

Mobile battery use has several causes

On mobile devices, battery use isn't just about encryption. Continuous transfers keep the wireless radio active, background keepalives can wake the device frequently, and reconnects and retries extend active time. An unstable route may mean more repeated work. A slightly more resource-intensive setup with a stable connection may be better for long sessions than a lightweight one that keeps disconnecting. Protocol header size alone can't predict battery life.

Encryption and user-space networking costs depend on the hardware and operating system. Hardware acceleration can reduce the load from some algorithms, while other combinations may rely more heavily on the general-purpose processor. Screen brightness, background tasks and wireless signal can also mask protocol differences. Compare similar usage and check the system's battery stats; don't rank protocols based on one instance of heat.

Background restrictions can affect recovery. To save power, an operating system may limit app activity; after the client is paused, a network change or long idle period may require the session to reconnect. Follow the guidance for your client and system before changing background settings. On Android, see the Android setup and verification guide: grant the necessary permissions first, then check whether background interruptions are actually occurring.

Choosing a setup for extended use

On desktop, compare client resource use under a real workload rather than while idle. An idle connection and continuous sync put different demands on the client; many small requests may also behave differently from one large file. If the whole system slows down, check other processes, disk activity and background updates too. Don't attribute all system resource contention to the proxy client.

On macOS, consider network extension permissions, coexistence with system services and chip compatibility based on the client's support. Before switching clients, confirm that the extension is authorized and no older tool is still routing traffic. For more guidance, see the Mac client compatibility guide. Platform compatibility and protocol performance are related, but they shouldn't be treated as the same issue.

VPNGS supports Windows / macOS / iOS / Android / Linux, with unlimited simultaneous devices. You don't need to use the same protocol or traffic-routing mode on every device. You might prioritize reliable work sessions on desktop and recovery and battery life on mobile, while keeping your rules clear. Maintain a working baseline on each device so you can tell a device-specific issue from a route-wide one.

Work and AI tools: prioritize continuity

For remote work, sustained interactions matter more than short bursts of peak download speed. Calls, remote desktops and collaborative editing are sensitive to jitter and interruptions. Keep a route you've tested with your actual tasks, then compare protocol options. If your usual network handles UDP poorly, keep a verified TCP-based setup as a fallback. If the current route struggles under congestion, try another transport or route type rather than changing everything at once.

For video calls, confirm that datagram traffic is handled as expected; opening a browser homepage isn't a complete test. Check joining a call, voice, screen sharing and recovery after a network change. Also rule out upload queues caused by background sync. For a closer look at different tasks, see how to choose routes for remote work. Evaluate performance by what you do, not by protocol name.

AI tools may stream responses over a persistent connection. A page can finish loading while a response still stops midway because of a long-lived connection issue, a network change or the app's own state. Keep the exit region and session environment consistent, and avoid switching routes automatically in the middle of a conversation. The platform's region, account and payment requirements are separate; a working network doesn't mean every platform requirement is met.

When using ChatGPT, Claude or Gemini, check that the login page and core features work, then observe how longer tasks respond. If the platform clearly reports an account or region issue, follow its guidance instead of changing protocols. See the guide to stable ChatGPT access for more on consistent exits and extended use. The same route-selection principles apply to other tools with ongoing interactions.

Streaming and downloads: prioritize sustained throughput

Streaming needs consistent delivery and enough buffer. Check startup time separately from uninterrupted playback. Content catalogs, account permissions and how a platform identifies your exit may all affect availability; a region label can't guarantee a particular catalog. Try playing something before deciding whether buffering is a problem. The protocol itself doesn't determine platform access. See the streaming routes page for more.

Large downloads and cloud sync depend on sustained transfer, but leave enough capacity for interactive tasks. Giving all available bandwidth to a download can disrupt calls and browsing on the same device, even when the route is fine. If sync runs continuously, adjust its concurrency or transfer limits in the app, then check whether work improves. When local traffic competition is the cause, there's no need to keep searching the proxy protocol layer for a fix.

Build a short, maintainable list of route options

A reproducible order is to choose an exit region first, then a route type, and finally compare protocols supported by your client. Keep one verified setup and test one alternative on the same connection and destination. Note whether the problem occurs during setup, sustained transfer or after a network change. If switching makes no difference, go back to the destination app and local environment instead of adding endless alternatives.

Keep plan selection separate from protocol selection. Monthly plans: ¥9.9/month for 60GB, ¥18/month for 250GB and ¥28/month for 500GB. Data resets monthly from the activation date; mid-cycle upgrades are prorated by the remaining days. Data packs: ¥158 for 300GB, ¥358 for 1000GB and ¥658 for 3000GB. They last until used and never expire. See the plans page for all options. Data allowance is not a measure of protocol performance.

You can open an account without an email address; just choose a username and password. Pay with Alipay / WeChat Pay / USDT, with a 14-day money-back guarantee. To get started, follow the quick start guide to import the client configuration and check the connection, then come back here to troubleshoot specific issues. New users don't need to understand every protocol setting before connecting.

The best setup is the one that fits your current task: a compatible client, complete settings, a suitable exit and a stable route. The protocol name is only one part of the picture and doesn't prove that a connection is reliable.

For long-term use, avoid changes without a clear reason. When network conditions change, retest your existing setup before replacing the entry point, route or protocol one at a time. If the destination changes how it behaves, check its service rules and your account status first. A known-good baseline, a clearly scoped issue and a record of changes are more useful than a long list of untested nodes. Use this page as a reference; the account panel shows the configurations currently available to you.