Protocols · Transport · Security · Cores

V2Ray Protocols & CoresA Client Selection Guide

Choose a protocol based on node settings, then check core support, subscription format and routing behavior.

This page is a technical reference to the compatibility details behind configuration fields. For your first installation and connection, start with the Getting Started guide. Return to the relevant section for questions about protocols, security layers or core selection. For desktop, start with v2rayN; find installation options on the client downloads page.

VMess
VLESS
Trojan
Shadowsocks
REALITY

Reading order: identify the configuration layers, then compare protocols and runtime requirements.

If you already have a working node, keep the provider's settings. A protocol name is not a speed rating, and switching cores does not convert configuration fields.

Configuration Layers and VMess: Separate Protocol, Transport and Encryption

When reading a node name, first break the setup into layers. The proxy protocol defines how identity and destination information are conveyed. The transport determines how that data travels. The security layer handles authentication and encryption for the relevant connection. The client translates interface fields into a core configuration. A protocol can use different transports, so two nodes labeled VMess may not share all settings. The address, port, user ID, transport and security parameters together define a connection; a missing value can cause failure at any stage.

VMess: Background and Current Use

VMess is an early proxy protocol from the Project V ecosystem. It combines user authentication with proxy data transfer and evolved to use authenticated encryption. It defines how client and server recognize an agreed identity, protect protocol data and express proxy requests; it does not dictate every aspect of the underlying transport. Existing subscriptions may still include VMess nodes. Before using one, confirm that its settings are complete and the server still provides that endpoint. There is no need to replace a working configuration just because the protocol is older.

When editing a VMess node in v2rayN, check the server address, port and user ID first, then review the encryption option, transport and TLS settings. The user ID is usually a UUID, but that does not mean any string of the same length will work. “Auto” in the interface generally lets the core choose an encryption method it supports; it does not fix incorrect server-side settings. After importing a share link, open the editor and check the key fields, especially for nodes converted from an older format.

Protocol Encryption vs. Outer TLS

VMess's own authenticated encryption and outer TLS are separate. The former is handled by the proxy protocol; the latter protects the relevant outer connection and may involve certificate and server-name checks. Enabling one does not mean the other should be enabled or disabled. For a node configured with WebSocket and TLS, distinguish the connection address, request Host, path and server name. These values may match, but they can also serve different purposes: locating the endpoint, routing the request and verifying identity. Do not set them all to the same value just to make the interface look tidy.

Older references often mention an extra ID, legacy authentication or other historical fields. For these configurations, ask for a current working share link or subscription instead of copying values from an old screenshot. Modern implementations vary in which legacy mechanisms they accept; an input field in the client does not guarantee that the core supports every historical value. An incorrect device clock can also affect time-dependent authentication and TLS certificate validity checks. If authentication fails, sync the system clock first, then compare the user ID and original node settings.

Configuration layer	Common fields	What to check
Proxy protocol	Type, user ID, password	Must match the server's identity settings
Transport	Network, path, Host	Must match how the endpoint handles traffic
Security layer	TLS, server name	Must match the server's security settings
Runtime	Core, logs, configuration generation	Must support all three layers above

Pinpoint errors by configuration layer

For connection timeouts, start by checking the address, port and transport endpoint. For certificate errors, check the security layer and device clock. If the connection opens and then immediately drops, review identity settings, the path and server logs. This order is not a one-to-one map of errors to causes; it helps avoid changing several variables at once. If the original node works, duplicate it for testing and change only one field at a time, with a clear reason. For the full click-by-click process, see the subscription import guide. Don't use your original subscription group as a scratchpad for trial and error.

VLESS and REALITY: Check the Protocol and Security Layer Separately

VLESS is designed to keep the proxy protocol itself lean and leave data protection to the chosen outer mechanism. It still requires authentication, but it is not simply “VMess with a shorter name.” Changing a VMess node's protocol type to VLESS and keeping the rest of its fields will not work: the two protocols handle requests differently, and the server must provide a matching endpoint. VLESS is often paired with security options such as TLS or REALITY. The node's complete settings determine the transport and whether flow control is used.

VLESS User ID, Encryption and Flow Control

When editing a VLESS node, enter the address, port and user ID first, then check the transport, security type and flow control. The encryption field is often set to none; this applies to the VLESS layer and does not mean the entire connection is unencrypted. If the node specifies outer TLS or REALITY, configure that security layer in full. Don't enable an unconfigured encryption option just because you see this value, or disable outer protection based on it. Adding extra layers at random does not make a setup compatible with the server.

Flow control is part of a specific supported configuration, not a boost switch to turn on at will. For example, if a node specifies a Vision flow control value, the client, core and server must all support that combination, and the transport must match. Don't copy a flow control option from a screenshot of a different node if yours doesn't specify one. If configuration generation fails or the connection drops after the handshake, check whether a subscription converter omitted the flow control setting or applied it to an unsupported transport combination. Then decide whether to request a fresh configuration from the provider.

REALITY Is Not a Standalone Proxy Protocol

REALITY is a security mechanism in the Xray ecosystem. It is usually selected as the security type in a client, not entered as a proxy protocol alongside VLESS. A common setup uses VLESS as the protocol and REALITY as the security layer. REALITY uses a verification model different from deploying a certificate for your own domain; the client needs the server's matching public key and other agreed settings. Changing a TLS node to REALITY, or deleting the public key and selecting TLS instead, will not create a working connection. The server must be configured for the chosen option.

Common REALITY client fields include the server name, public key, short ID and fingerprint. Choose a server name from the values allowed by the provider. The public key must match the server's key, and the short ID must be entered exactly as provided—don't add zeros or concatenate values. Some configurations allow an empty short ID, but that depends on the server. The fingerprint affects the client's handshake characteristics and must be supported by the core. If an import preserves the public key but drops the server name or short ID, the connection may still fail. A recognized link does not prove that all its settings were imported.

Check whether the combination is supported by the client

On desktop, use v2rayN to check which core is assigned to the node; don't rely on the presence of Xray in the installation folder. On Android, for a REALITY node, check that the Xray core included with v2rayNG supports the node's requirements. Don't hand the same configuration to v2flyNG, which uses V2Fly, and assume the result will be equivalent. The client's available options, link parser and runtime core are three separate parts of the process. Missing fields at any stage can mean a successful import but a failed connection.

Keep deployment requirements in mind when choosing a setup. If you have complete VLESS and REALITY settings and your client supports every field, use the configuration provided. If the node specifies ordinary TLS, treat it as a TLS node. REALITY is not a universal upgrade for every connection and does not guarantee lower latency. For a fair comparison, control the server location, route, test destination and network conditions. For more on the relationship between these projects, see Xray vs. V2Fly: Core Differences. Establish compatibility before comparing performance.

Trojan and Shadowsocks: TLS Requirements and Encryption Methods

Trojan and Shadowsocks reflect different design priorities. Classic Trojan places authentication and proxy requests inside a TLS connection, relying on a valid security handshake and certificate verification. Shadowsocks focuses on lightweight encrypted proxy traffic, using shared credentials and an agreed encryption method. Neither can be fully configured from a server address alone. First confirm which endpoint the server provides, then check that the client supports the specified method and extensions. Similar-looking password fields do not make protocols interchangeable.

Trojan: Get TLS Verification Right First

When editing a Trojan node, check the address, port, password and server name in order. The connection address locates the endpoint; the server name is generally used for the TLS handshake and certificate identity check. They don't always have to match. If the provider specifies a server name, keep it even when the address is an IP. The password is an identity credential for the proxy layer, not a website login. Avoid leading or trailing spaces, line breaks and characters changed by an input method. A password field displaying the expected number of characters does not prove that its contents match the original.

For certificate errors, check the device clock, server name and server-side certificate configuration first. Don't use “allow insecure” as a general fix: skipping certificate verification weakens confirmation of the connection's identity. If the node was designed to use a trusted certificate, fix the name or certificate issue. If it uses a custom trust model, follow the provider's explicit instructions. Change verification settings only temporarily to isolate a problem in a controlled test, then restore them and document the actual cause.

Shadowsocks: Match the Method Exactly

The key Shadowsocks settings are the address, port, encryption method and credentials. Modern configurations often use authenticated encryption, but each method has specific requirements for keys, implementations and data framing. Don't replace the method name with “auto encryption” or switch to another method based on device performance. Newer Shadowsocks 2022 methods differ from legacy methods in how keys are represented and handled; both the client and core must support the required format. If an import tool re-encodes the password as an ordinary passphrase, it may change the original meaning.

There is more than one format for a ss:// share link. Some encode the method and credentials; others use a different URI structure or include extension parameters. The parser must understand both the outer link and its internal fields. If a node depends on extensions, basic Shadowsocks support in the client does not prove that the full set of extensions will work. Confirm with the provider which extensions are required and under what conditions, then check support in the current core. Don't install unrelated components on a hunch.

Item	Trojan	Shadowsocks
Identity settings	Password	Method and corresponding credentials or key
Key security checks	TLS server name and certificate verification	Encryption method and key format
Common compatibility limits	Transport extensions and TLS options	Method version and extension support
UDP behavior	Depends on implementation and server capabilities	Depends on method, implementation and deployment

“Lightweight” does not mean faster in every situation

Shadowsocks' lightweight design doesn't mean it uses less battery on every phone or network, and Trojan's use of TLS doesn't mean every request requires a full handshake. Connection reuse, session resumption, hardware acceleration, server load and application request patterns all affect the result. With many short-lived connections, setup costs are worth watching. For long transfers, throughput, packet loss and sustained encryption overhead matter more. Test on the same device and network; a protocol label is no substitute for measurement.

If you already have ordinary Trojan settings and certificate verification works, keep them. A modern Shadowsocks method is a lightweight proxy option when the client supports it fully. For voice, gaming or other UDP-dependent apps, check UDP support across the server, intermediate endpoints and client traffic handling. TCP support alone does not guarantee that every app will work. If web browsing works but a particular app fails, first check whether its traffic enters the proxy and whether the protocol can carry that traffic. Then decide whether to change node type.

Xray and V2Fly: Distinguish the Client Interface from the Runtime Core

Project V is an important source of related proxy tools and configuration ideas. V2Fly continues community maintenance of the V2Ray ecosystem, while Xray has developed as an independent core branch based on the same technical foundations. They share a history but have their own protocol extensions, transport capabilities and configuration changes. They are not the same program under different names, and feature lists from one point in time do not predict every later implementation. To assess compatibility, check whether the core actually running recognizes the fields, supports the combination and accepts the generated configuration.

How the Three Clients Differ

v2rayN is a desktop GUI client for managing nodes, updating subscriptions, configuring routing and launching cores. The Desktop and WPF editions for Windows mainly differ in interface technology and interaction, not in proxy protocol standards. macOS and Linux users should also choose the right architecture and package format from the relevant v2rayN download options, rather than looking for a different client name. The interface applies settings to the runtime configuration; the core it launches handles the network connection. Troubleshooting requires checking both.

On Android, v2rayNG primarily uses the Xray core, while v2flyNG offers a V2Fly-based option. Similar interfaces don't mean they support every share link, flow control value and security mechanism equally. For REALITY and other Xray-specific features, first choose a client that can represent the required settings. If your node uses only basic features supported by both, decide based on actual compatibility rather than similar-looking letters in the client names.

Configuration Compatibility Is More Than Copying Fields

Shared configuration structures and protocol names make some migrations possible, but field meanings, defaults and supported combinations can differ. Removed legacy fields, changes to experimental features, or updates to DNS and routing structures can stop seemingly identical JSON from starting in another core. GUI clients usually generate their own runtime configuration, and custom settings may not go through the same field conversion. Before switching, determine whether you're using standard node mode or a fully custom configuration; their settings sources and override order are not interchangeable.

In v2rayN, check the node's protocol and core assignment options first, then use the runtime logs to confirm which program actually started. Menu labels may vary between interface versions. Look for core settings, protocol-specific core options or related controls in the node editor; don't assume one global dropdown changes every node. If the logs show an unknown field or unsupported security type, check the core selection and source of the field. If the configuration passes but the connection fails, check server settings. Don't treat both errors as network problems.

Keep a Record When Updating or Rolling Back

Before updating, note the working nodes, routing mode, DNS settings and core assignments so you don't change the subscription and traffic handling at the same time. After updating, test the same node against the same destination before trying new features. A client update may include a core change, or it may only adjust the interface and configuration generation. Adding a core file elsewhere on the system does not prove the client will use it. To roll back, use an installation method with a clear source and compatibility notes, and restore the matching settings. Mixing files from multiple directories makes runtime behavior hard to trace.

Open source means the implementation and maintenance process can be studied; it does not mean every third-party configuration has been reviewed or that a particular core always uses fewer resources. This site provides download links and configuration guidance for three clients, not a separate core download section. For installation options, see the client downloads page. If the client exits before reaching its main screen, follow the startup crash troubleshooting guide and check the runtime requirements. Don't keep changing node protocols before the client has even started.

Subscription Formats and Imports: Check Addresses, Content and Missing Fields

A subscription is a way to retrieve multiple node configurations, not a proxy protocol. A subscription URL may return multiple share links, encoded text or a client-specific structure. The client must fetch the content, parse its outer format and convert each node into an internal model. If the URL opens in a browser, that only suggests the fetch may be working. Import success, complete field retention and successful connections must be checked separately. Keeping these stages distinct helps avoid changing protocols blindly.

Subscription URLs vs. Individual Share Links

An individual share link usually starts with a protocol-specific URI prefix and contains one node's address, identity and optional parameters. A subscription URL is usually a web address with access credentials that returns a set of nodes when the client requests it. Use each in the right place. Pasting a single link into a subscription group's URL field may cause updates to fail; using a subscription URL as an ordinary server address won't create a proxy connection. Before you start, check the link format and choose either “Import share links from clipboard” or the subscription group settings.

In v2rayN, open the subscription group settings, add a group and a note, then paste the full address into “Optional address (URL).” Enable updates if needed, then update the group. The example https://example.com/sub?token=xxxx only shows where the field is; it does not provide a node. When copying your own URL, keep the query parameters and everything after the question mark. Don't include line breaks or trailing punctuation added by a chat app. Subscription URLs grant access and should not appear in public screenshots, pasted logs or untrusted conversion services.

Successful Decoding Does Not Guarantee Every Field Was Preserved

Common VMess share formats may use encoded data, while VLESS, Trojan and Shadowsocks links often express their settings in a URI. Share formats don't always use consistent names for paths, server names, fingerprints or flow control, and extensions are particularly easy to lose during conversion. After importing, open a node in the editor and compare its protocol, transport, security type and identity fields with the original settings. If the name, address and port are present but the REALITY public key or WebSocket path is missing, the import is still incomplete.

Some subscription responses are designed for other configuration systems and use different node fields and rule structures. Changing a file extension won't turn one into a native subscription for your client, and not every client converts formats automatically. Ask the provider for a format compatible with v2rayN or the relevant Android client. If conversion is necessary, check which fields the converter understands, what structure it outputs and whether credentials leave your device. Review every converted node, especially its security layer and transport extensions. Matching node counts alone is not enough.

Managing Updated Nodes and Manual Changes

Subscription updates may rebuild the node list. Whether manual changes to names, paths or core assignments are preserved depends on how the client manages them. For temporary comparisons, duplicate a node in a separate group and note the changes. Don't use a subscription group as a long-term store for manual configurations. After an update, confirm the selected node still exists and check whether filters have hidden it. An empty list doesn't necessarily mean the server has no nodes; the response format, access, filters or parsing may be the cause.

Set automatic update intervals based on the provider's limits and how often you use the subscription. Frequent fetching won't improve node latency and may increase background wake-ups, failed requests and server load. When an update fails, read the logs to determine whether the problem is connectivity, access or format. Hide the full URL, user ID and password before sharing logs. For subscription and node basics, see 10 Common Beginner Questions Answered. For the actual steps, use the import section of the Getting Started guide.

Performance and Mobile Battery Use: Compare the Full Connection Lifecycle

Protocol performance has no fixed ranking outside a specific environment. A request may involve DNS lookup, a connection to the proxy endpoint, an outer security handshake, proxy authentication and forwarding to the destination before sustained data transfer begins. Different tests cover different parts of this process. A TCP port test shows whether the endpoint accepts connections, not whether identity settings and destination access work. A real connection test more closely reflects an actual request, but still depends on the test destination. Identify what a test measures before deciding whether one protocol is faster.

First Request, Sustained Throughput and Resource Use

The first request is more sensitive to DNS, connection round trips and security handshakes. Sustained downloads depend more on bandwidth, packet loss, congestion control, server load and encryption performance. A quick latency test on one node doesn't prove that large downloads will be faster. Hardware acceleration may reduce the cost of some encryption operations; the same configuration can behave differently under heavy load or power-saving modes. Choose encryption methods to match the server's requirements, not to chase theoretical throughput by changing fields.

Connection reuse can reduce the cost of repeatedly establishing connections, but it also places multiple requests on a shared channel, so the effects on failures and congestion vary by implementation. Reuse, transport protocols and application connection pools may overlap; a reuse toggle in the interface is not a universal speed boost. Keep the default or provider recommendation when the connection is stable. If a particular app misbehaves, test that option on its own. Change one setting at a time and observe small requests, long-lived connections and concurrent requests—not just repeated latency tests.

Background Activity Also Affects Phone Battery Life

On Android, encryption is only one part of battery use. A persistent VPN service, wireless wake-ups, keepalives, DNS requests, background sync and repeated reconnects can all affect battery life. With a weak signal or frequent switching between Wi-Fi and mobile networks, radio use may matter more than protocol differences. A node that repeatedly disconnects and reconnects may use more power overall, even if each encryption operation is lightweight. When comparing v2rayNG and v2flyNG, use equivalent settings fully supported by both, or you may be measuring a compatibility issue instead.

First check whether background battery restrictions are repeatedly suspending the VPN service, then review reconnect frequency in the client logs. For apps that need a persistent connection, allow the necessary background activity in system settings if appropriate, bearing in mind that this changes overall power use. Don't run multiple VPN-capable apps and mistake them competing for control for protocol-related battery drain. If the connection drops only when the screen locks, investigate background policies, network switching and keepalive behavior before changing the node's security mechanism.

Metric	What it indicates	What it cannot prove
Port connection time	Connection conditions to the endpoint	The full proxy route works
Real connection latency	One proxied request to a specific destination	All apps will have the same speed
Sustained throughput	Transfer performance over a specific period	The first request will always be faster
Background battery use	Power use under the overall runtime conditions	That the protocol name alone determines it

Set Up a Repeatable Comparison

Use the same device, network and approximate time of day, and choose the same test destination. Record the node, core, traffic handling method and routing mode. First confirm that test requests actually use the node, then compare the first load, repeat visits and sustained transfers. For mobile battery tests, keep screen-on time, signal quality and background tasks similar; a brief change in the battery percentage is not enough to establish a difference. Don't invent a universal improvement figure or attribute results from servers in different regions directly to protocol design.

For reliable everyday use, first choose a configuration with full compatibility, few reconnects and normal app behavior. Then compare response times that you can actually notice. For an explanation of different speed-test options in the client, see How to Test Node Latency. Use test results to compare working configurations—not to bypass authentication, ignore certificate errors or hide missing fields. Fix those issues before comparing performance.

Routing and DNS: Confirm Traffic Uses the Selected Node

A working protocol establishes one proxy connection; routing determines which requests use it. A system proxy provides an entry point for apps that follow system proxy settings, but it does not force every app to use it. TUN captures more traffic through a virtual network interface but requires the right permissions, routing and DNS setup. If a real connection test succeeds but an app still connects directly, the issue may be traffic capture or routing rules, not the protocol. Before troubleshooting, confirm the traffic handling method in use and whether the target app supports it.

Rule Order and Matching Data

Routing rules are generally evaluated in a defined order, and an earlier match can affect later decisions. Domain rules need domain information; IP rules use the destination address or lookup result. geosite and geoip are common references to classification data, not proxy protocols. Built-in client templates may use different data files and default outbound tags. When copying a rule, confirm that the referenced data exists and the tag is valid. Matching template names do not guarantee identical rules across cores or client-generated configurations.

To customize routing, first copy your current routing setup, then add the smallest rule needed. Be clear whether the target is a domain, subnet or application type; don't use a broad rule that masks existing settings. If a rule doesn't match, check whether the app passes a domain or IP to the proxy, then review rule order and outbound tags. In some cases, sniffing can provide additional destination information, but it cannot recover a domain for every protocol and request or replace a sound DNS and traffic handling setup. Verify the actual route in the logs after making a change.

DNS Settings and Where Resolution Happens

DNS maps names to addresses, but an app may resolve a name locally or send the lookup through the proxy. System proxy settings, TUN and app-specific DNS can change that path. Changing system DNS may not affect lookups performed inside the client; changing client DNS may not capture encrypted lookups made by an app. Distinguish resolution of the server address from resolution of the destination site. If the former fails, the proxy endpoint is unreachable; if the latter fails, the node may connect while some domains remain inaccessible.

When choosing a DNS strategy, first identify which layer needs a domain name and which needs an IP address. Keeping the domain name for remote resolution may avoid some local lookup differences, but local IP-based rules may not be able to make the same decisions. Local resolution can provide an address for matching, but the local result may differ from what the remote server sees. Neither approach suits every deployment. Start with a complete setup provided by the client, then make targeted changes based on logs. Don't combine half-steps from unrelated tutorials into a new DNS flow.

The following Xray-style routing snippet illustrates the relationship between fields for direct connections to private addresses. It is not a complete configuration. Merge it into the existing routing section and confirm that the existing outbound is actually tagged direct and the classification data is available. A GUI client may regenerate its runtime configuration; most users should express the same intent through the routing settings.

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

Troubleshoot Along the Observable Path

Test the node connection first, then check system proxy or TUN status, verify the target app, and finally review routing and DNS. For problems accessing LAN devices, check private-address rules, virtual interface routes and local name resolution. If only one domain fails, compare its resolution result and matching rules. Don't repeatedly clear every rule to judge protocol performance; that changes too many conditions at once. Before sharing logs, hide internal network addresses and access credentials, keeping only the error type and field names needed for diagnosis.

Desktop and Android use different traffic handling mechanisms; a system proxy toggle on one platform is not equivalent to VPN permissions on the other. Router or bypass-gateway deployments also involve gateway, return path and DNS forwarding relationships, and need their own design rather than a desktop template. For background, see Router and Bypass Gateway Deployment Overview. For your first connection, follow the mode selection steps in Getting Started, then return to this chapter to refine the rules.

Choosing and Verifying a Setup: From Complete Settings to Repeatable Connections

Choose based on the working nodes and device you have, not a protocol ranking. If you have a working subscription, start with a client that can parse and run it completely. For a self-hosted or custom deployment, compare maintenance requirements, security mechanisms and app needs. Use v2rayN to manage desktop nodes; on Android, choose between v2rayNG and v2flyNG based on core support. The package architecture determines whether the software can install and run; the protocol type affects connection behavior. They are not interchangeable considerations.

Choosing for Everyday Desktop and Mobile Use

For everyday desktop use, prioritize reliable sources for settings, clear routing and readable logs. If your VMess, Trojan or Shadowsocks node works, there's no need to reconfigure it just to use a different protocol name. For a VLESS and REALITY setup, check Xray support and every security field before testing. If you use one subscription on multiple devices, verify the parsed settings on each device. Success on desktop does not prove that Android retained every extension. Check each device's clock, permissions and traffic handling separately too.

When a mobile device frequently switches networks, first observe reconnect recovery and background service stability; check throughput and heat during sustained transfers. For voice or other UDP-dependent apps, verify the complete path: client traffic handling, protocol support, server forwarding and destination access. A successful web page load does not test all of these conditions. If two nodes use different regions or routes, the results primarily reflect those deployment differences, not any single protocol—VLESS, Trojan or Shadowsocks.

Read Errors by Stage Instead of Changing Settings at Random

Stage one is startup. If the client won't open, check system requirements, permissions and package architecture. If the core won't start, review configuration parsing errors and missing capabilities. Stage two is the connection to the endpoint: check the address, port, DNS resolution and transport. Stage three is the security handshake and authentication: check the clock, server name, certificate, user ID, password or REALITY settings. Stage four is destination access and routing. Identifying the stage first helps avoid fixing the wrong layer.

For example, “connection timed out” means a step did not complete in time; it does not prove the password is wrong. “Unknown field” points more toward configuration or core compatibility, so changing DNS is not the first step. “Certificate name mismatch” calls for checking the server name and certificate setup, not changing the encryption method. Log wording varies by implementation; read the surrounding context to see whether the error came from fetching a subscription, starting the core or making a proxy request. The same word “failed” at different stages does not necessarily mean the same problem.

Run a Repeatable Connection Test

Confirm that the subscription updated successfully with no missing fields, then start the selected node and check that the core logs show no configuration errors. Test a specific destination and verify that the request uses the expected outbound. Keep the node unchanged while testing the target app and reconnection after locking the screen. For comparisons, duplicate the configuration and change one justified setting at a time. Don't update the subscription, switch cores, enable TUN and replace DNS all at once. Even if the result improves, you won't know why or be able to reproduce it on another device.

Long-term maintenance is about avoiding differences you can't trace. Label groups by purpose, keep subscription-generated nodes separate from manual test nodes, and spot-check security fields and the active core after updates. When asking for help, include the client name, platform, failure stage and relevant redacted logs; never share subscription URLs or credentials. If the provider changes the server protocol or security settings, request a complete updated configuration instead of guessing new fields on an old node. Stable setups come from understanding each change, not accumulating options.

The final choice comes down to three conditions: the server provides the protocol combination, the client and core fully support its required fields, and the target app works on your actual network. Once those conditions are met, compare response time, sustained transfer performance and background battery use. For installers and package formats, return to the client downloads page. For setup instructions, go back to Getting Started. Consult this page's contents for individual topics. A protocol is one configuration requirement, not a substitute for measurement or troubleshooting.