V2Ray Protocol, Core and Client Selection Guide

01 / DECISION MODEL

Build a protocol selection model first

Protocol, transport, security layer and client are different layers

When you see a node configuration, break it into four layers. The first is the proxy protocol, such as VMess, VLESS, Trojan or Shadowsocks. It defines how the client authenticates, structures connections and how the server identifies requests. The second is the transport, such as TCP, WebSocket or gRPC, which determines how data is carried over the network connection. The third is the security layer, such as TLS or REALITY, which handles handshake identity, the encrypted channel or specific connection verification. The fourth is the client and core: v2rayN, v2rayNG and v2flyNG provide the interface, while V2Fly or Xray actually parse the configuration and establish the connection.

These four layers can be combined, but they are not interchangeable. VLESS is a protocol, while REALITY is a security solution implemented in the Xray ecosystem and paired with specific transport patterns, so “VLESS” and “REALITY” are not two completely parallel choices. Likewise, WebSocket is not a proxy protocol, and TLS is not a node type. A common “VLESS + TCP + REALITY” subscription entry is actually a three-layer combination. When an imported configuration contains many fields, checking them by layer is more reliable than guessing parameters one by one.

Start selection with compatibility

The first selection criterion is not theoretical speed, but whether the server and the client core support the same option. If the server only provides VMess, discussing VLESS's overhead advantages has no practical value. If a subscription includes REALITY parameters, confirm that the core used by the current client can recognize those fields. Once compatibility is established, compare the network environment, device resources, connection count and maintenance effort. Only then consider peak throughput, because most everyday differences come from route quality, handshake retries, DNS resolution and transport settings—not the protocol name itself.

A reliable check goes in this order: identify the link scheme, confirm the client core, inspect the transport and security fields, then verify the address, port and authentication details. Do not identify a protocol solely by the node's display name. That name is a label written by the subscription provider and can contain any text; the actual parser is determined by the link scheme and fields such as protocol, network and security.

Stability is the result of the entire chain

The same protocol can behave very differently under different configurations. Direct TCP is usually simple, with little extra processing. WebSocket works well with common web-service deployment patterns but adds framing overhead. gRPC is built on HTTP/2 and offers stronger connection management, while also introducing more complex parameter relationships. For TLS, the certificate name, system time and SNI must match; otherwise the handshake will fail even when the protocol itself is configured correctly. REALITY likewise requires the client and server to agree on fields such as the short ID, public key and server name.

When choosing, record the complete “protocol + transport + security layer + core” combination rather than a single abbreviation. Troubleshoot in the same order. If import succeeds but the connection fails, first confirm that the client recognized the protocol, then check that all transport fields are present, and finally review the security parameters. If everything matches, inspect DNS, the system proxy and local ports. For specific symptoms, continue with the Troubleshooting checklist.

02 / VMESS

VMess: comprehensive authentication and broad compatibility

Design background and protocol role

VMess is a representative protocol from the early Project V ecosystem. Its design incorporates user identity, request information and time-based authentication, with the client and server identifying users through values such as a UUID. Its defining feature is not “one fixed encryption algorithm,” but a complete mechanism covering authentication, request framing and connection negotiation. Because it appeared early, VMess is recognized by many V2Ray configurations, subscription generators and graphical clients, giving it broad historical compatibility.

A VMess configuration typically includes the server address, port, user UUID, alterId, transport and security layer. In current configurations, alterId is commonly zero, although older subscriptions may still include other values. Do not change this field during import: the server and client settings must match. The encryption option is often auto, with the core determining its behavior from the configuration. If the subscription updates normally but every VMess node fails to connect, check the system time first, because clock skew can directly affect authentication.

VMess advantages and trade-offs

VMess benefits from mature documentation, broad configuration-tool support and generally good handling by both V2Fly and Xray. When you need to move between clients, the server still uses a traditional V2Ray configuration, or the subscription format has been running reliably, continuing with VMess is often easier than changing protocols. It can also be combined with transports such as TCP and WebSocket, with TLS layered on top. For maintainers, a stable existing deployment does not need to be migrated merely because a newer protocol is available.

The main trade-off is a relatively complex processing path, with more authentication and framing steps than lighter designs. On desktops with ample computing power, the difference is usually hard to notice. On low-power devices, under many concurrent connections or in frequently awakened mobile environments, the extra processing is more visible. Actual battery use and speed are still dominated by network quality. Repeated failures and retries often consume more resources than a single protocol calculation, so a configuration that completes the handshake reliably matters more than its theoretical overhead.

How to verify common fields

First check that the address and port were imported completely, then confirm that the UUID is unchanged. A UUID should use the standard hyphenated form and contain no extra spaces. Next inspect the transport layer: with WebSocket, the client path and Host must match the server; with TLS, the SNI or serverName should match a name covered by the certificate. The remark shown in the client does not affect the connection and can be edited freely, but do not delete other fields just to make the configuration “look cleaner.”

{
  "protocol": "vmess",
  "settings": {
    "vnext": [
      {
        "address": "server.example.com",
        "port": 443,
        "users": [
          {
            "id": "11111111-2222-4333-8444-555555555555",
            "alterId": 0,
            "security": "auto"
          }
        ]
      }
    ]
  }
}

The snippet above shows only the core layers of a VMess outbound. A complete configuration also needs inbound, transport and routing sections. When entering values manually, interface labels may differ from JSON names: for example, “User ID” corresponds to id, while “Alter ID” corresponds to alterId. Matching the meaning is enough; the interface wording does not need to match the underlying field name exactly.

When to keep VMess

When the server is stable, the subscription is used across several devices, and clients include both V2Fly and Xray cores, VMess is a conservative compatibility choice. This is especially true for traditional WebSocket + TLS deployments where the goal is to minimize migration variables. If creating a new configuration and both the client and server clearly support VLESS, you can compare authentication overhead and security-layer options—but that does not make VMess obsolete.

When troubleshooting VMess, first distinguish an import failure from a handshake failure. Import failures usually involve link encoding, subscription content or client parsing. Handshake failures are more often related to the system time, UUID, transport path, TLS name or port. Do not keep changing every parameter while switching between these two stages. Change one item at a time and record the result before and after each change so the actual failure point can be identified.

03 / VLESS + REALITY

VLESS and REALITY: a lightweight protocol and security-layer combination

Why VLESS uses a lighter design

VLESS separates protocol authentication from transport security more explicitly. It uses a UUID to identify the user, but does not handle encryption inside the protocol in the same way as VMess; instead, channel security is delegated to outer layers such as TLS or REALITY. This layering keeps the protocol itself simpler and lets the core combine features according to the transport and security layer. Remember that a lighter protocol does not mean the security layer can be omitted. Whether TLS or REALITY is needed depends on the complete deployment.

A VLESS node in a client commonly includes the address, port, UUID, flow control, transport network, security type, server name and fingerprint. These fields have combination constraints. For example, some flow-control values work only with specific transports and security layers, while REALITY additionally requires values such as a public key, short ID and serverName. If a subscription omits one of them, the client may still create the node but fail during the handshake. Import success therefore cannot be judged simply by whether a node appears in the list.

REALITY's role and parameter relationships

REALITY is not an independent proxy protocol. It is a security and handshake mechanism in the Xray ecosystem, commonly combined with VLESS. The client must use an Xray core capable of parsing the relevant fields. In the configuration, publicKey is used for client-side verification, shortId matches the server setting, serverName helps select the handshake target, and fingerprint describes the client's handshake fingerprint policy. These fields are not interchangeable aliases; each must correspond to the server configuration.

The most common REALITY configuration problem is that a field is present but contains the wrong value. Examples include putting the server address in serverName, treating the node UUID as the public key, or dropping characters when copying the short ID. Another possibility is that the subscription includes the parameters but an old core ignores fields it does not recognize. The interface may appear to import the node successfully even though the actual configuration is incomplete. In that case, confirm the current core type and import again; do not repeatedly toggle the system proxy on the original node.

Keep performance expectations specific

VLESS has a relatively light protocol-processing path, giving it a reasonable theoretical advantage for high throughput, many concurrent connections or low-power devices. But observed speed depends on several factors: round-trip latency affects handshake time, packet loss affects retransmission, server CPU and bandwidth affect sustained transfer, transport determines framing overhead, and DNS affects the first request. If the route itself is unstable, switching between VMess and VLESS may not produce a consistent visible improvement.

REALITY uses more handshake parameters, so initial setup is more likely to fail from a missing field than ordinary VLESS + TLS. Once configured correctly, it usually needs little day-to-day adjustment. Maintenance should focus on core support and complete subscription fields. If an old node still works after a client upgrade, there is no need to recreate it. If it suddenly fails after a subscription update, compare serverName, public key, short ID and flow-control fields before and after the update; this is usually more effective than reinstalling the client.

When this combination makes sense

For a new node where the server explicitly provides VLESS + REALITY, this combination has a clear support path when using v2rayN on desktop or v2rayNG with an Xray core on Android. If Android uses v2flyNG, first confirm that the protocol and security layer in the subscription fall within V2Fly's support range; similar names do not guarantee compatibility. When one subscription must be shared across different cores, ordinary VLESS + TLS or a mature VMess combination may be easier to keep consistent.

The final test is not whether it is “more advanced,” but whether the server, core and subscription can express the same parameter set reliably. After choosing, perform three checks: the client displays all security fields, the connection log contains no unknown configuration items, and the connection recovers after repeated disconnects and reconnects. Only then make the node a regular configuration.

04 / TROJAN + SHADOWSOCKS

Trojan and Shadowsocks: two different simplified approaches

Trojan's design approach

Trojan authenticates users with a password and relies on TLS to establish a secure connection. Its configuration is relatively direct: the server address, port, password, SNI, certificate verification and transport settings make up the main parts. Unlike VMess's time-based authentication, Trojan depends more heavily on a correctly configured TLS layer. Unlike VLESS, it generally uses a password rather than a UUID. If the client shows both “Password” and “User ID,” confirm the current node type so the credentials are not entered in the wrong field.

Trojan connection problems often center on TLS. Clock skew, an SNI that does not match the certificate name, a wrong port or an invalid certificate chain can terminate the connection before the proxy request begins. The allowInsecure setting controls certificate verification and should not be treated as a universal fix. With a normal certificate setup, strict verification should remain enabled. Change it only for short-term diagnosis when you clearly understand the server's certificate arrangement, then restore the intended setting.

Shadowsocks core structure

Shadowsocks, often shortened to SS, uses the server, port, password and encryption method as its core configuration. It does not use the UUID model found in VMess or VLESS; the server and client must select exactly the same encryption method. With few configuration fields and a direct processing path, SS usually has a low management cost on resource-constrained devices and in simple connection scenarios. Its boundaries are also clearer: for complex transport combinations, confirm that the core and server provide support through an additional mechanism rather than copying fields from another protocol into SS.

Do not guess the encryption method from its name. Use the value provided by the subscription unchanged in the client. If the method is blank after import or replaced with an unfamiliar value, the client core may not support it or the subscription converter may have dropped the field. Check the client log for “unknown method” or a similar parsing message before deciding whether to change the core or have the subscription output a compatible format. Changing the password repeatedly will not fix an encryption-method mismatch.

Understanding speed and resource use

SS usually has a shorter processing path, making it suitable when you want simpler configuration and lower computational overhead. Trojan requires a TLS handshake, which adds a cost to the first connection, although connection reuse and persistence can reduce repeated handshakes. If an application frequently creates short-lived connections, DNS, TLS session resumption and transport reuse can strongly affect the experience. For sustained transfers, route bandwidth and server load are usually more important.

Do not judge a protocol by the speed of opening one webpage. A more reliable test keeps the same server, time window and application while observing the initial connection, sustained transfer, idle recovery and reconnection after a network change. Repeat the test several times and include failed retries in the results. An occasional higher peak does not mean a protocol is more stable on mobile networks or weak signals.

How to choose between them

When the server provides a standard Trojan configuration, the certificate and domain relationship is clear, and the client core offers full support, Trojan suits users who want a straightforward TLS model. When the server provides SS, device resources are limited, and the goal is fewer fields and maintenance steps, SS is more direct. Neither is simply a “lighter replacement” for VMess or VLESS, because their authentication models and security boundaries differ. Migration requires the server to provide the corresponding protocol; changing the type in a client menu is not enough.

If one subscription offers several protocols, keep one verified stable node as a baseline before testing a new combination. The baseline helps distinguish a local network problem from a configuration problem. If every node fails, check the system proxy, DNS and network connection first. Only when one protocol type fails should you return to that protocol's authentication and security fields.

05 / PERFORMANCE

Connection speed, resource use and mobile battery life

Break speed into four stages

“Speed” includes at least resolution, handshake, time to first byte and sustained transfer. DNS resolution determines when the client obtains the target address; the protocol and security-layer handshake determine when the connection becomes usable; time to first byte reflects the application request and remote response; sustained transfer is closest to what is usually called bandwidth. VMess, VLESS, Trojan and SS differ in protocol processing, but slow DNS or severe packet loss can outweigh those differences.

During testing, keep the node address, transport and security layer fixed and change only one variable. Comparing VMess + WebSocket + TLS directly with VLESS + TCP + REALITY changes the protocol, transport and security layer at once, so the result cannot be attributed to any one factor. A better method is to use comparable combinations provided by the server and repeat tests on the same network. Record connection success and recovery, not just peak throughput.

Where CPU and memory overhead comes from

CPU use mainly comes from encryption, protocol framing, TLS handshakes, data copying, compression and extra transport processing. Memory use depends on the number of connections, buffers, routing rules, DNS cache and log level. A lightweight protocol does not guarantee a lightweight client: the graphical interface, core process, rule sets and TUN mode may be the main sources of overhead. On desktop systems, v2rayN usually manages the core as a separate process; combine related processes when reviewing resource use.

Log verbosity also affects overhead. You can temporarily increase detail while troubleshooting, but restore the normal level afterward to avoid excessive disk writes. More routing rules increase matching work and memory use, although well-organized rules are rarely the primary bottleneck. Focus instead on duplicate rules, oversized domain lists, repeated DNS failures and continuous connection retries.

What mainly determines mobile battery use

When using v2rayNG or v2flyNG on Android, battery use is not determined by the protocol alone. Persistent background connections, switching between Wi-Fi and cellular networks, the system terminating background processes, frequent DNS requests, failed reconnects and many concurrent connections all affect battery life. A theoretically lighter configuration that disconnects often may consume more power than a slightly more complex but stable one, because every reconnect repeats DNS resolution, the handshake and application recovery.

When checking battery use, first ensure that the client has the system permissions needed to keep running, and add it to an appropriate battery-optimization exception list if required by the device. Then watch for repeated connection events while idle. If the connection repeatedly drops when the screen is off, investigate background restrictions before changing protocols. For Android VpnService permission, battery-optimization exceptions and per-app proxying, see v2rayNG Android usage tips.

TUN mode changes the resource baseline

After enabling TUN mode on desktop, the client usually handles more traffic than in ordinary system-proxy mode. The core takes over more connections and may perform additional DNS and routing decisions. Comparing protocol overhead between ordinary system-proxy and TUN modes therefore has no direct meaning. Fix the proxy mode first, then compare protocols. If resources rise sharply after enabling TUN, check the routing scope, DNS settings and possible traffic loops.

v2rayN TUN mode suits applications that do not follow system-proxy settings, but it should not be the first fix for a failed connection. If a node cannot connect through the ordinary system proxy, switching to TUN usually adds variables rather than solving the problem. First use the client's built-in test, then enable the system proxy and verify a browser, and only afterward decide whether TUN is needed for the application.

Create repeatable test records

For each candidate combination, record the protocol, transport, security layer, core, proxy mode and test network. Change one item at a time and observe the initial connection, ten minutes of continuous use, idle recovery and network switching. If a combination has a slightly higher peak but more reconnect failures, prefer the one with stable success. Everyday experience is determined by availability most of the time, not by a single best result.

When resources are abnormal, reduce variables in order: disable verbose logs, restore simple routing, exit TUN, keep one node and observe the core process. If usage returns to normal, re-enable features one at a time. This separates protocol, rule and proxy-mode overhead instead of blaming every issue on the node type.

06 / CORE FAMILY

V2Fly and Xray core families and configuration compatibility

Shared origins and different directions of development

V2Fly and Xray both continue the configuration ideas of the Project V ecosystem, so their common inbound, outbound, routing, DNS and transport structures are often similar. They are not graphical clients; they are core programs that parse configuration and handle connections. v2rayN is a desktop graphical client that can manage the relevant cores. v2rayNG mainly uses the Xray core, while v2flyNG targets the V2Fly core. Choosing a client therefore also means choosing its default core capabilities.

Their shared foundation lets many VMess, Shadowsocks, Trojan, ordinary VLESS and common routing rules use similar representations, but “similar” does not mean every field is compatible in both directions. Xray adds its own features around VLESS, XTLS and REALITY, while V2Fly continues along the original configuration model. A configuration accepted by one core may contain extension fields the other core does not fully understand.

Evaluate feature differences at the field level

When checking compatibility, do not ask only whether VLESS is supported. Also inspect the security layer, flow control, transport and extension parameters. Ordinary VLESS + TLS has different core requirements from VLESS + REALITY; even with TCP transport, enabling a specific flow-control mode can change the support boundary. A subscription name may say only VLESS, while the parameters that determine core selection are hidden in the query string or underlying JSON.

When Xray-specific fields are passed to V2Fly, common outcomes include being ignored during import, an unknown-field error at startup, or a node that saves successfully but cannot connect. Reverse migration can also encounter different defaults or field names. The safest approach is not to delete the item that caused the error blindly, but to confirm what function it serves. If it is a required security-layer parameter, removing it may leave a configuration that starts but does not provide an equivalent connection.

Configuration migration checklist

Before switching from one core to another, export or record the current node type, transport, security layer and routing settings. Next, check whether the configuration contains extension fields unknown to the target core. Then import just one node into the target client and confirm that the core starts. Check DNS and routing logs to verify that requests use the intended outbound. Only after that should you migrate the full subscription. Moving every node at once makes the source of errors difficult to identify.

If only the graphical interface was upgraded and the core family did not change, rewriting the configuration is usually unnecessary. If ordinary VMess nodes work after a core switch but REALITY nodes fail, narrow the check to Xray extensions and security fields rather than reinstalling network drivers. If every node fails to start, first verify that the client calls the core file correctly, that the local listening port is free and that the configuration syntax passes.

Routing and DNS have compatibility boundaries too

A working proxy protocol does not mean the entire configuration is compatible. Domain categories in routing rules, rule-set references, DNS query policies and outbound tags may also differ. If the node test succeeds but some websites behave unexpectedly after migration, check for routing rules that reference missing tags, a DNS outbound pointing to the wrong object and changes in rule order. Core configurations are generally matched in order, so a broad rule near the top can override a specific rule later.

A simplified configuration is an effective way to verify compatibility. Keep one local inbound, one proxy outbound and minimal DNS settings, confirm the basic connection, and only then add split routing. Do not enable complex rules, TUN and multiple fallback outbounds in the same minimal test. Confirm connectivity after each added feature so the layer causing the difference is clear.

How to choose the default core

If the subscription mainly contains VMess, ordinary VLESS, Trojan or SS, and an existing V2Fly configuration is stable, you can keep the current core. If the subscription clearly includes REALITY, specific flow control or Xray extension fields, use the Xray support path. On desktop, start with v2rayN and select the core according to the node requirements. On Android, choose between v2rayNG and v2flyNG based on the subscription's capabilities.

Core selection is not irreversible, but every switch should have a clear reason. Changing cores simply because one name is more familiar adds configuration differences. For a more detailed comparison, read How do the Xray and V2Fly cores differ?, which breaks down protocol support, performance and configuration migration boundaries.

07 / SUBSCRIPTION

Subscription formats, share links and client compatibility

A subscription is a configuration container, not a protocol

A subscription link provides one or more node configurations to the client; it does not determine whether a node uses VMess, VLESS, Trojan or SS. After updating a subscription, the client downloads text or structured data, then converts its share links, fields and remarks into internal configurations. “Subscription update succeeded” therefore means only that the content was retrieved. It does not mean every node was parsed completely or can connect.

Common share links use different schemes to identify protocols, such as vmess://, vless://, trojan:// and ss://. VMess share content often carries encoded JSON; VLESS and Trojan commonly use URI user information and query parameters for transport, security and additional fields; SS links contain the encryption method, password, address and port. The client must recognize both the scheme and the parameter version used in the link.

Why the same subscription shows different node counts in different clients

Different node counts usually have four causes. First, a client does not support a protocol or extension field in the subscription and skips that entry. Second, part of the subscription contains malformed links. Third, the client has deduplication, filtering or keyword exclusions enabled. Fourth, the subscription converter outputs different content for different client types. Compare the distribution of protocol types first instead of comparing only the total count.

If v2rayNG shows REALITY nodes but v2flyNG does not, check the core support boundary first. If both are missing the same group of VMess nodes, subscription encoding or link integrity is more likely at fault. If desktop v2rayN imports only some nodes, look in the update log for messages such as “skipped,” “unknown scheme” or “field parsing failed.” Do not restore missing nodes by copying their names manually; the name does not contain the actual configuration.

Hidden problems caused by URI encoding

Special characters in passwords, remarks, paths and query parameters must be encoded according to URI rules. If a subscription converter encodes a value twice, the client displays extra percent-encoded sequences; if it does not encode it at all, characters such as #, ? and / may be interpreted as part of the link structure. Trojan and SS passwords deserve particular attention. If the imported password is noticeably longer, return to the original subscription and inspect it rather than guessing characters in the client.

The fragment after the # at the end of a link is usually the node remark and does not participate in authentication. Garbled remarks usually do not prevent a connection, but they may indicate a problem in the subscription encoding pipeline. If the remark and key parameters are both abnormal, fetch the complete subscription again. When copying a link, avoid editors that automatically wrap lines or replace characters, and do not copy only the visible truncated text.

Safe steps after a subscription update

Before updating, keep one node that has already been verified and do not delete the old configuration immediately. After the update, check the node types and count, then run the client's built-in test on one new node. Once it passes, enable the system proxy and verify real access, and only then update routing or TUN settings. This separates subscription parsing, node connectivity and system interception into three stages. If any stage fails, you can return to the last working state.

If an update overwrites the original node, check whether the client can preserve local edits, merge by remark or create a separate subscription group. Manual changes to subscription nodes are usually overwritten at the next update; lasting fixes belong in the subscription source. For temporary testing, copy a node into an independent configuration and give it a clear remark so it is not confused with automatically updated entries.

Match the client to the subscription type

For Windows, macOS and Linux desktops, start with v2rayN for centralized subscription management, core switching and log inspection. On Android, choose v2rayNG when the subscription relies on Xray extensions, or v2flyNG when V2Fly core compatibility is required. Choose the installation package by platform and architecture on the Get a client page; do not infer the package type from a share-link name.

A subscription link is a configuration entry point and should not be displayed in full on public pages or screenshots. During troubleshooting, record the protocol type, error message and non-sensitive fields, but keep authentication data private. When explaining an issue to someone else, “protocol + transport + security layer + core + failure stage” is usually enough to point the investigation in the right direction.

08 / SCENARIO GUIDE

Choose the protocol, core and client for the use case

Everyday desktop use: minimize maintenance variables first

On Windows, macOS and Linux desktops, start with v2rayN. First choose from the protocols already provided by the subscription rather than changing the server's node type. Next check for REALITY or specific Xray extensions; if present, use the corresponding Xray support path. Complete a single-node connectivity check in ordinary system-proxy mode. Evaluate TUN only when an application ignores the system proxy or unified traffic interception is genuinely needed.

For protocols, keep a stable existing VMess + TLS configuration if it already works. When a new configuration explicitly provides VLESS + REALITY, import all fields and verify the core. For Trojan, focus on TLS and SNI; for SS, ensure the encryption method matches. Desktop hardware usually handles these protocols comfortably, so prioritize compatibility, recovery and maintenance cost over small theoretical overhead differences.

Long-running Android background use: control reconnects first

If an Android subscription includes Xray capabilities such as VLESS + REALITY, start with v2rayNG. If the configuration is explicitly built around the V2Fly core, choose v2flyNG. After import, grant VpnService connection permission, then configure the battery-optimization exception according to the device's background-management settings. Watch whether the connection stays alive with the screen off. If the log repeatedly shows disconnects and new handshakes, address background restrictions first.

On mobile, prioritize stable connections and idle recovery. SS is simpler to configure and VLESS itself is lightweight, but any protocol that repeatedly fails and retries will consume more battery. Test the same node for at least half a day and observe idle periods, network switching and app wake-ups rather than relying on a short speed test. Per-app proxying can reduce the number of connections that need proxying and lower unrelated traffic processing.

Sharing one subscription across devices: use the common capability set

When one subscription must work on desktop and Android, use the protocol combinations supported by every target client as the baseline. VMess, Trojan, SS and ordinary VLESS often have broad client coverage, but transport and security fields still matter. If the subscription includes REALITY, let capable clients use those nodes while keeping a fallback node with broader compatibility. Do not force different security combinations into the same link merely to standardize their names.

For a shared subscription, keep fields consistent and groups clear. Add explicit remarks based on protocol or core requirements, such as “VLESS-REALITY-Xray” or “VMess-TLS-Common,” but use remarks only for identification, not as a substitute for actual parameters. After every update, test one node on each device type to ensure the conversion did not remove query parameters.

Low-resource and high-concurrency scenarios: test the full chain first

On resource-constrained devices, you can start by comparing direct-processing options such as SS and VLESS, but only after confirming server support and a complete security layer. For high concurrency, also consider connection reuse, transport, core buffers and server limits. Lightweight framing reduces only part of the overhead and cannot compensate for packet loss, server load or incorrect DNS policy.

Record CPU, memory, connection success rate and sustained throughput during testing. If lower protocol overhead improves CPU use but increases failures, the overall result may still be worse. Choose a configuration that remains stable under the target load and keep a rollback option. When changing the transport, core or security layer, change one item at a time so the result has a clear cause.

Final verification checklist

After choosing, verify eight items in order: the protocol name matches the server; the client core supports every field; the address and port are complete; authentication data contains no spaces or truncation; the transport and path match; TLS or REALITY parameters are complete; the client's single-node test passes; and real access works after the system proxy or VpnService takes over. If any item fails, stop at that stage instead of adding routing or TUN.

After the connection succeeds, observe disconnect/reconnect behavior, idle recovery and network switching. Once it has run reliably for a while, save a written record of the working combination, including the protocol, transport, security layer, core and client. When problems occur later, use this record as the baseline and compare only the fields that changed. This is easier to diagnose than reimporting the entire subscription.

One-page selection summary

For a mature existing configuration where cross-core compatibility matters, keep VMess initially. For a new configuration with complete VLESS + REALITY parameters from the Xray ecosystem, use a core and client that support the combination. If you want a clear TLS authentication model and the certificate configuration is complete, choose Trojan. If the goal is simplicity, the server explicitly provides SS and the encryption method is compatible, use Shadowsocks. There is no universal protocol ranking outside its use case.

Use v2rayN on desktop, and choose v2rayNG or v2flyNG on Android according to the core requirements. After selecting a configuration, return to the Quick Start Guide and follow the steps for subscription import, proxy activation and connectivity verification. If the client crashes on startup, a port is occupied or certificate handshakes still fail, consult Troubleshooting and the TLS certificate error checklist.