VMess, VLESS, Trojan, SS and REALITY Selection Guide

1. A protocol selection framework: separate the configuration layers first

A protocol name is not a complete connection profile

VMess, VLESS, Trojan or Shadowsocks in a client list primarily identify application-layer proxy protocols. A real connection also includes an address and port, user credentials, a transport method, a security layer, a domain name and optional path information. Comparing protocol names alone cannot tell you whether two profiles are interchangeable or predict connection speed. VLESS, for example, can run over plain TCP or be combined with TLS, WebSocket, gRPC or REALITY. These combinations differ in handshake flow, certificate requirements, data framing and client support.

Break a profile into four layers when choosing a setup. The first is the protocol and authentication, such as a VLESS UUID, a Trojan password, or the Shadowsocks encryption method and password. The second is the transport carrying the data, such as TCP, WebSocket or gRPC. The third is security and identity verification, such as standard TLS or REALITY. The fourth is the client and core: v2rayN, v2rayNG or v2flyNG converts interface fields into a configuration readable by Xray or V2Fly. A mismatch at any layer may appear as an immediate disconnect, a handshake timeout or missing fields after import.

Start with the existing profile, not personal preference

Client users typically receive a share link or subscription with fixed parameters. The right approach is not to pick a newer-looking protocol first and rewrite the profile, but to confirm the protocol and transport combination supplied by the server, then choose a client and core that can identify it completely. If the server uses VMess, import it as VMess. If it uses VLESS with REALITY, the client must support VLESS and preserve REALITY fields such as the public key, short ID, fingerprint and server name. Changing a client dropdown alone cannot add capabilities to the server.

If you control both server and client, rank the options by compatibility, configuration complexity, device performance and maintenance cost. For use across several clients, prefer combinations that every platform can parse reliably. If you need Xray-specific capabilities, confirm that every device runs a compatible Xray core. On low-powered devices, avoid unnecessary layers of encapsulation. Here, “simpler” means fewer fields, fewer link layers and clearer troubleshooting boundaries; it does not mean one protocol is always faster on every network.

2. The design trade-offs of VMess, VLESS, Trojan and Shadowsocks

VMess: complete authentication structure and time synchronization requirements

VMess originated in the early Project V protocol family, aiming to handle user identification, request transport and data protection within one protocol. Its configuration usually uses a UUID as the user identifier and includes additional handshake fields. VMess has broad historical compatibility across the V2Fly and Xray families, so many older subscriptions and existing deployments still use it. When preserving an established profile, waiting for a server-side change or supporting multiple already-tested devices, continuing with VMess is usually safer than migrating solely for a newer protocol name.

VMess authentication requires the client and server clocks to remain within a reasonable offset. Incorrect device time, time zone or automatic synchronization can cause authentication to fail even when the address and port are correct. During troubleshooting, restore automatic system time first, then check the UUID, the legacy alterId compatibility field and transport parameters. Modern profiles generally do not rely on the old alterId design, but it may still appear in imported legacy subscriptions. A client displaying a field does not mean the server still uses the same legacy behavior; migration should follow the server’s current configuration.

VLESS: a leaner protocol that delegates capability to the surrounding layers

VLESS is a major protocol in the Xray ecosystem. Its design minimizes the encryption responsibilities handled by the protocol itself, delegating transport security to TLS, REALITY or another explicit security layer. VLESS uses a UUID and related information for user identification, but it should not be treated as a self-contained solution that provides every security function on its own. A deployment must be described together with its transport and security layer, such as VLESS over TCP with TLS or VLESS over TCP with REALITY.

This separation of responsibilities makes VLESS easier to combine with Xray features such as flow control and avoids some duplicated processing. The trade-off is that the options have clear dependencies: if the server has no flow configured, the client cannot invent one; REALITY requires a public key, short ID and server name; standard TLS requires the domain to match the certificate identity. VLESS is valuable for Xray feature combinations and clear protocol layering, not because selecting VLESS automatically improves every link.

Trojan: password authentication over standard TLS

Trojan usually uses a password as the user credential and relies on TLS to establish a secure connection. Its conceptual model is straightforward: the client connects to a TLS service, then submits authentication and target information at the protocol layer. The key is not the password field alone; the domain, server name, certificate validation and port must form a consistent identity relationship. Replacing the address with another host while retaining the original server name, or disabling required security options, can break the original verification logic.

Trojan is supported across several core ecosystems and suits setups built around standard TLS with a relatively clear parameter structure. It is not synonymous with any TLS service, and an ordinary HTTPS address cannot be used as a Trojan node. After import, confirm that the security setting remains TLS, SNI is present and the password was not truncated. If a subscription converter keeps only the address, port and password while dropping transport fields, the resulting entry cannot represent the original profile even if it appears in the list.

Shadowsocks: lightweight structure and encryption-method consistency

Shadowsocks, often shortened to SS, centers on the server, port, encryption method and password. Compared with VLESS or VMess profiles involving more layers, a basic Shadowsocks entry has fewer fields and is easier to understand. Performance depends on the chosen encryption method, implementation, processor instruction support and link quality. Newer AEAD methods provide clear confidentiality and integrity semantics, but the client and server must use exactly the same method name and password.

The Shadowsocks ecosystem includes various extensions and plugin combinations. Basic SS support does not imply support for a particular extension, and a successful subscription import does not prove that extension fields were preserved. With v2rayN or an Android client, check the encryption method, plugin parameters and additional transport settings in the entry editor. If the goal is to move a profile between the three clients, basic fields are usually easier to keep consistent; entries using specific plugins should be verified on each platform. Record protocol compatibility and extension compatibility separately.

3. Transports, TLS and REALITY: combinations and field boundaries

How TCP, WebSocket and gRPC carry data

The transport determines how protocol data is placed inside the underlying connection. TCP generally adds less encapsulation and has a more concentrated set of parameters. WebSocket carries bidirectional data over an HTTP upgrade flow, commonly using a path and Host. gRPC follows HTTP/2 semantics and commonly uses a service name and multiplexing-related settings. These are not speed modes that can be switched based on client preference; the server must listen on the same transport with matching parameters. Changing a WebSocket entry to TCP generally does not produce an equivalent profile.

Transport affects performance through handshake count, framing overhead, connection reuse and the behavior of intermediate network devices. Connection setup costs are more noticeable with many short-lived connections; for sustained high-volume traffic, link quality, congestion control and server load often matter more. A WebSocket path must match character for character, and a gRPC service name cannot be omitted. Host, SNI and the address may look similar in a client, but they serve different roles: the address locates the server, Host belongs to the application-layer request, and SNI supplies the server name during the TLS handshake.

Standard TLS: certificate identity and server name

TLS provides an encrypted channel and server identity verification for upper-layer protocols. The server name in the configuration generally needs to match a name verifiable against the certificate, while the connection address may be a domain or, in specific setups, another address. With certificate validation enabled, the client checks the certificate’s validity period, trust chain and name match. When a certificate error occurs, first check system time, SNI, domain spelling and the server certificate configuration. Disabling verification should not be a routine fix because it changes the identity checks required by the original profile.

ALPN negotiates the upper-layer protocol during the TLS handshake, such as HTTP/2 or HTTP/1.1. Whether it must be entered manually depends on the transport combination and server settings. Preserve the supplied ALPN value when the subscription includes one; when no value is explicitly required, do not add one merely to have more parameters. A client allowing multiple selections does not mean the server accepts every combination. Similarly, the fingerprint describes the TLS client-handshake characteristics. It is an implementation detail and must be compatible with the selected core and server design.

REALITY: the Xray security layer and its required parameters

REALITY is a security-layer capability in the Xray family, typically combined with VLESS and similar configurations. It is not a standalone proxy protocol, so a client entry may still show VLESS as the protocol while REALITY is selected as the security option. Common parameters include the server name, public key, short ID and client fingerprint; some combinations also use flow. The public key lets the client verify the REALITY server identity, the short ID is matched against the server configuration, and the server name participates in the handshake semantics. Omitting any of these during subscription conversion can prevent the handshake from completing.

The public key and UUID serve different purposes. The UUID authenticates a VLESS user, while the REALITY public key verifies the security-layer identity; they cannot be substituted for one another. A short ID is generally a hexadecimal string in a defined format, with length and allowed values determined by the server. Preserve it exactly; do not add zeros or change its case. The server name is not a display label and must match the server configuration. When editing a REALITY entry in v2rayN, check protocol, address, port, user ID, security, SNI, publicKey, shortId, fingerprint and flow in that order.

{
  "protocol": "vless",
  "address": "server.example.com",
  "port": 443,
  "id": "00000000-0000-4000-8000-000000000001",
  "network": "tcp",
  "security": "reality",
  "serverName": "www.example.com",
  "publicKey": "Replace this example public key with the value provided by the server",
  "shortId": "1a2b3c4d",
  "fingerprint": "chrome",
  "flow": "xtls-rprx-vision"
}

The snippet above illustrates the relationship between fields; it is not a node that can connect as-is. Actual values must come from the corresponding server configuration. A client interface may use different field labels or place these values under “Transport Settings,” “TLS Settings” or “REALITY Settings,” but their meanings remain the same. Share links may also use abbreviations, such as pbk for the public key, sid for the short ID and fp for the fingerprint. When comparing manually, map the fields first, then check for omissions.

4. Connection speed, resource use and mobile battery life

Protocol overhead is only part of total latency

Perceived connection speed reflects DNS resolution, network round-trip time, the handshake, server load, line congestion, transport framing and local processing. The protocol affects only part of that equation. If two profiles use different protocols but also differ in server location, egress load or link quality, speed-test results cannot prove which protocol is better. A reliable comparison keeps the server, port path, test time, target resource and client version as consistent as possible, then repeatedly observes connection setup time, sustained transfer and failed retries.

Basic TCP transport usually adds less application-layer framing, but it does not guarantee the lowest latency in every environment. WebSocket and gRPC add their own protocol processing and change connection reuse and intermediate-link behavior. TLS and REALITY both involve handshakes and cryptographic computation, which modern desktop processors usually complete quickly. On low-power mobile devices, frequent disconnects and reconnects can consume more battery than maintaining a stable connection. Reducing futile retries, keeping system time correct and avoiding incorrect DNS resolution often matter more than debating the cost of a single encryption operation.

CPU, memory and connection count

Resource use cannot be ranked by protocol name alone. The core maintains connection state, routing rules, DNS caches, logs and, optionally, a TUN network stack; the client interface also handles subscription updates, list rendering and statistics. Many concurrent connections, complex regular expressions, overly verbose logging and frequent health checks all increase CPU wakeups and memory use. A basic Shadowsocks profile usually has fewer fields and an easier-to-follow processing path; VLESS with a simple transport can also keep overhead low. Multiple transport layers and complex routing require more state management.

When monitoring desktop resource use, distinguish the v2rayN GUI process from the Core process. Growth in interface memory does not necessarily indicate a problem with the protocol core, and the reverse is also true. Disable automatic updates and extra checks temporarily, then retest with the same profile to see whether background tasks are involved. Keep only necessary logging during normal use, increase verbosity temporarily for troubleshooting, then restore it. Continuously recording full access logs adds disk writes and processing overhead and makes the actual error lines harder to find.

Battery considerations on Android

On Android, v2rayNG or v2flyNG generally uses the system VPN interface to handle traffic. Battery use comes not only from encryption but also from maintaining the network, total app traffic, Wi-Fi or mobile-network transitions, DNS requests and background wakeups. If the connection is repeatedly rebuilt with the screen off, first check the system’s background restrictions, network switching and automatic subscription-update frequency. Replacing the protocol while keeping an unstable link usually does not solve the battery drain caused by reconnects.

The scope of TUN or VPN interception also affects processing volume. When all app traffic enters the client, the core must handle more connections. Reducing unnecessary background traffic according to device capabilities and actual needs lowers the workload. Very large routing rule sets or many rules requiring DNS resolution also add decision cost, though they are usually not the first bottleneck at ordinary scale. A more effective troubleshooting order is: confirm connection stability, look for retry loops, check logging, automatic updates, DNS and routing, and only then compare protocol combinations.

Protocol selection should prioritize stability, compatibility and maintenance cost, with performance data used as supporting evidence under controlled conditions. If an existing VMess profile has remained stable, migrating to VLESS is not urgent. If REALITY or a specific Xray flow is required, include core upgrades and full-device compatibility checks in the migration plan. For unusual resource use, troubleshoot using the categories in the Help Center; do not change the protocol, DNS, routing and system proxy at the same time, or the comparison baseline will be lost.

5. The V2Fly and Xray core families

Shared origins, independent development

V2Fly and Xray both inherit configuration concepts and multi-protocol proxy capabilities from the Project V ecosystem, so similar ideas appear in VMess, some VLESS configurations, Shadowsocks, routing rules and outbound structures. They later developed as independently maintained projects, and their features, field meanings and implementation details do not always stay in sync. A shared origin explains why many basic configuration structures look alike, but it does not mean every extension is interchangeable between the two cores.

Xray has focused more heavily on capabilities such as REALITY and XTLS Vision, with corresponding fields established in the Xray client ecosystem. V2Fly follows its own release, protocol-implementation and feature roadmap. For most users, the key point is that basic VMess, Shadowsocks or standard transport profiles may migrate well across cores, while profiles using Xray-specific security layers, flow or extension fields should explicitly use Xray Core. A configuration being parseable only means its syntax may be accepted; it does not guarantee identical runtime behavior.

The roles of the three clients

v2rayN is this site’s primary desktop client, supporting Windows, macOS and Linux with graphical controls for server lists, subscription groups, routing, the system proxy and Core type management. For VLESS profiles using REALITY, select an Xray Core with that capability in v2rayN and confirm that all security fields remain after import. When the desktop needs to manage multiple subscription groups, detailed routing and the system proxy, v2rayN’s centralized settings make it the better primary management client.

v2rayNG is an Android client following the Xray capability path and works well with desktop v2rayN for sharing Xray profiles such as VLESS and REALITY. v2flyNG is centered on the V2Fly core family and suits VMess, Shadowsocks and other compatible profiles supported by that core. Their names are similar, but similar interface fields do not prove identical functionality. When a server entry depends on Xray-specific fields, prefer v2rayNG. When V2Fly behavior is required or an existing V2Fly baseline is available, choose v2flyNG.

Three levels of configuration compatibility

Evaluate compatibility at three levels: syntax, functionality and behavior. Syntax compatibility means that JSON fields or a share link can be recognized. Functional compatibility means that the core actually implements the protocol, transport and security layer. Behavioral compatibility means that the same profile produces the expected results for DNS, routing, connection reuse and error handling. Many migration failures occur when the first level is mistaken for the third—for example, an import tool generates an entry successfully but drops unsupported fields that only become visible at connection time.

Configuration migration also requires attention to outbound tags, routing references and DNS structure. A usable protocol node does not mean the original routing rules can be copied directly. The outboundTag in a rule must point to an outbound tag that actually exists; DNS query policy and domain-resolution mode can also affect routing decisions. With a graphical client, prefer creating or importing through the client so it generates a structure matching the current Core. Export the configuration for read-only comparison only when you need to locate a specific field.

xray run -test -config ./config.json

The test command above asks the installed Xray Core to check configuration syntax; it does not replace a real connection test. Success means the configuration passes basic parsing, not that the address is reachable, credentials are correct or the security-layer handshake will succeed. v2rayN users can usually inspect the Core startup result directly in the log. Manual commands are better for locating unknown fields, JSON structure errors or tag-reference problems. Test with a temporary copy generated by the client to avoid modifying the active configuration file.

6. Subscription formats, share links and field compatibility

A subscription is a configuration container, not a protocol

A subscription URL returns a set of nodes or client configurations; the subscription itself is not a proxy protocol such as VMess or VLESS. One subscription can contain multiple protocol types or use a structure recognized by a particular client. “Subscription updated successfully” only means that the client completed the request and basic parsing. You still need to check the entry count, protocol types, names, transport methods and security fields. If the list is empty, distinguish an unreachable URL, an empty response, an unsupported format and an incorrect group filter.

Common share links begin with a protocol scheme, such as vmess://, vless://, trojan:// or ss://. Each scheme organizes parameters differently. VLESS and Trojan links can usually carry transport, security-layer, SNI and fingerprint details in query parameters. Legacy VMess formats often encode a set of JSON fields inside the link, while Shadowsocks links focus on the encryption method, password, address and port and may include plugin parameters. Any truncation, escaping change or missing data during QR recognition can cause fields to be lost.

Generic subscriptions and client-specific formats

A so-called generic subscription is usually a set of multiline share links or encoded links. Its strengths are a clear structure and easy transfer between clients; its limitation is that it cannot fully express complex routing, DNS or client-specific policies. A client-specific configuration can include groups, rules and interface options, but migration to another client often preserves only the node itself. Choose the format based on the sharing goal: synchronize server entries only, or migrate routing and DNS policies as well?

For v2rayN, v2rayNG and v2flyNG, the safest cross-device approach is for the subscription to provide node fields supported by every client, while routing is maintained locally on each device. Desktop system-proxy modes, Android system VPN interception and app-level split routing differ, so forcing a complete client configuration into one subscription easily creates semantic mismatches. The node subscription should handle the address, protocol and transport; the device should handle proxy interception, DNS and routing. This separation is easier to troubleshoot.

Benefits and information loss in subscription conversion

Subscription conversion can reorganize one container format into another and may also rename, filter or group entries. It is lossless only when the target format can express the source fields. A VLESS REALITY entry must preserve security, SNI, publicKey, shortId, fingerprint and flow; WebSocket must preserve path and Host; gRPC must preserve serviceName. If the target template has no corresponding fields, the tool may silently ignore them instead of reporting an error.

When validating a converted result, do not compare only node names. Select at least one entry from each protocol type at random, open the editor and check the protocol, address, port, authentication fields, transport, security layer and extension parameters one by one, then test the connection. Put the original and converted subscriptions in different groups to avoid same-name collisions. Switch to the daily-use group only after every protocol type works correctly. If VLESS imports but REALITY fails after conversion, check the additional security-layer parameters first rather than repeatedly refreshing the subscription.

Updates, overwrites and local edits

Subscription nodes are usually managed by remote content. If you edit a subscription entry directly in the client, the next update may restore the subscription’s original value. Put custom settings that must persist in a separate local entry or in client-supported override rules. Copying an entry and changing its name before editing preserves a comparison baseline. Adjusting the system proxy, routing mode or active group is usually local client state and does not require changing node protocol fields.

When a subscription update fails, first check that the URL is complete and the relevant group is enabled, then inspect the client log for an HTTP status, parsing error or certificate error. Do not paste a subscription URL into the address field for manually adding a server, and do not assume that a single share link can be scheduled for updates. See the subscription import steps in Getting Started for the complete workflow; for empty lists and group selection, continue to the Help Center.

7. Applying protocol choices in v2rayN, v2rayNG and v2flyNG

v2rayN: check the Core first, then the node editor

v2rayN is the primary desktop choice. After importing a node, confirm the Core type in Settings, then open the server editor and verify its fields. For VMess, check the user ID, transport and security settings. For VLESS, also check encryption, flow and the REALITY or TLS panel. For Trojan, check the password, TLS and server name. For Shadowsocks, check the encryption method and password. The name in the client list is only for identification and does not participate in authentication, so a normal display name does not prove that the profile is complete.

Before enabling the connection, keep node settings separate from system proxy settings. Selecting an active server determines which outbound profile the Core uses. The system proxy determines whether applications that support it hand requests to the client, while routing rules determine whether traffic uses the proxy outbound, direct outbound or another configured exit. These are consecutive but distinct steps. If a node test fails, inspect protocol logs first; if the node is connected but an application is not intercepted, check the system proxy; inspect routing only when specific domains or paths behave unexpectedly.

v2rayNG: verify every parameter in the share link

When importing a VLESS REALITY link into v2rayNG, open the configuration details and confirm that the security type, SNI, public key, short ID, fingerprint and flow are all present. If a field is empty after QR recognition or clipboard import, compare it with the original share content instead of copying it from another node. Each node’s public key and short ID are bound to its server; similar-looking values cannot be mixed. For VMess, pay extra attention to device time and transport parameters; for Shadowsocks, focus on the encryption method.

The Android connection button starts system VPN interception; it does not change the node protocol. If no application has network access after connecting, first check whether the Core started, whether the configuration parsed and whether the handshake completed in the log. If only certain applications behave differently, check system restrictions and app-level routing. Switching among many protocol entries interleaves log output, so during troubleshooting fix one verified node, clear or note the current log time, then perform one deliberate connection attempt.

v2flyNG: choose entries within the V2Fly capability range

v2flyNG suits Android users who need a V2Fly core client. Before importing, determine whether the profile depends on an Xray-specific feature. Basic VMess, supported Shadowsocks and transports implemented by V2Fly can be checked against the actual profile. A VLESS entry using REALITY or a specific Xray flow should not be assumed compatible merely because its protocol name is visible. If one subscription mixes several entry types, create separate groups and use only verified compatible nodes in v2flyNG.

When comparing the two Android clients, use the same basic compatible profile and keep DNS, routing and network conditions similar. If fields are missing after import on one side, record the result as format or feature incompatibility rather than simply blaming the network. The goal of client selection is to match core capabilities, not to force every device to use the same app. Prefer v2rayNG for Xray profiles and v2flyNG for V2Fly profiles; this clear division is easier to maintain than repeated conversion.

Use logs to locate the configuration layer

Log errors can usually be classified by stage. Configuration parsing reports unknown fields, malformed data or missing outbound tags. DNS and connection stages report resolution failures, refused connections or timeouts. TLS and REALITY stages report certificate-name, key or handshake problems. Protocol authentication errors relate to UUIDs, passwords or server-side user configuration. Identify the failed stage first, then return to its fields; this is more efficient than changing settings at random.

Change only one variable at a time during troubleshooting. Keep the protocol and transport unchanged while correcting SNI, for example, then check the public key in a separate test. Do not change the Core, node, DNS and routing mode together, or you will not know what fixed the issue—or what expanded the failure. When reporting a problem, record the client name, Core family, protocol, transport, security layer, failure stage and key error category, while hiding credentials.

If the required client is not installed, use the client page to choose a package for Windows, macOS, Android or Linux. Prefer v2rayN on desktop; on Android, choose v2rayNG or v2flyNG according to the Xray or V2Fly core requirement. Subscription import, the system proxy and connection verification after installation are covered in Getting Started; this chapter only maps protocol choices to client settings.

8. Choosing by use case, migrating and rolling back

When an existing profile is stable, keep the protocol and minimize changes

There is no need to migrate a stable VMess, Trojan or Shadowsocks profile solely because the protocol name has changed. Record the current client, Core, transport, security layer, DNS and routing baseline first, then define the specific problem migration should solve. If the goal is only to change devices, import the same profile on the new device and verify its fields. If the goal is REALITY or Vision, treat it as a joint server-and-client change: create a separate test entry instead of overwriting the original node.

A stable profile provides a valuable comparison baseline. If a new entry fails, switch back to the old one to confirm that the local network, system proxy and client still work. If the old entry also fails, the problem may not be the new protocol. During migration, keep the original subscription group, the recorded Core settings and the key-field checklist. Once the new profile has been verified on every target device, phase out the old entry gradually.

Multi-platform desktop use: center management on v2rayN and shared capabilities

When Windows, macOS and Linux desktops need a consistent workflow, use v2rayN to manage subscriptions and routing. Choose a Core and transport combination that runs reliably across all three desktop environments before considering platform differences. Basic VLESS with a standard security layer, existing VMess, Trojan or basic Shadowsocks should all be verified field by field against the server parameters. With REALITY, ensure that each platform’s v2rayN invokes a compatible Xray Core and preserves every required field.

Cross-platform synchronization does not mean copying the entire client directory. System proxy implementation, certificate storage, network interfaces and startup behavior differ by platform and should be configured separately. Let the subscription synchronize nodes, create readable routing rule sets for each use case, and keep system-level settings local. For Linux desktop installation and autostart, see the technical note v2rayN Linux desktop installation; verify protocol fields using the layered method on this page.

Sharing between Android and desktop: identify the common core capability first

When desktop v2rayN and Android v2rayNG share a profile, their common Xray capabilities are usually the clearest fit, especially for VLESS REALITY. If Android uses v2flyNG, choose protocols and transports explicitly supported by V2Fly and do not bring Xray-specific parameters into the shared profile. One subscription can contain multiple node types, but use names or groups to label core requirements, such as “Xray profiles” and “V2Fly-compatible profiles,” rather than choosing by protocol name alone.

Mobile devices require closer attention to connection stability and background behavior. If a profile works on desktop but fails on Android, compare the imported fields first, then check system VPN startup and the device network instead of immediately blaming the server. If Android connects but uses excessive battery, check reconnects, network switching, automatic updates and logging in the order described earlier rather than replacing the encryption protocol first. Cross-device selection should aim for consistent parameters, a matching core and clear troubleshooting boundaries.

Complex subscriptions: validate samples by protocol

When a subscription contains VMess, VLESS, Trojan and Shadowsocks, do not test only the first item. Group entries by protocol and choose one complete profile from each; then group them by transport and cover TCP, WebSocket or whatever other transports the subscription actually provides; finally check TLS and REALITY separately. This reveals whether a failure comes from one node, one protocol class, one transport or the subscription format itself. Record the results in groups or names instead of relying on short-term memory.

If only REALITY entries fail within one protocol, check the Xray Core and REALITY parameters. If every WebSocket entry fails while TCP works, compare the path, Host and TLS. If every protocol fails to parse, return to the subscription response and format layer. Classifying the issue by layer reduces unrelated changes. For broader differences between protocols and clients, read How to choose between v2rayN, v2rayNG and v2flyNG.

Migration checklist and rollback conditions

A production migration can be divided into preparation, parallel validation, cutover and observation. During preparation, record the old profile and do not delete a working group. During parallel validation, add the new entry and test parsing, handshakes, sustained connections and common applications under the same network conditions. During cutover, change only the active node and leave DNS and routing unchanged. During observation, apply new routing or system settings gradually. Each stage has a clear rollback point, so an anomaly can be handled by restoring the old active node instead of rebuilding the entire configuration.

Rollback conditions include: the target client cannot preserve required fields, the Core lacks a required capability, subscription updates repeatedly overwrite local fixes, the mobile client reconnects constantly, or any critical device in a multi-platform setup cannot run reliably. Rolling back does not judge one protocol as better; it means the current combination has not met compatibility requirements. Keep the old setup, fix the server, subscription format or client settings separately, and begin the next validation round.

After deciding on the protocol, go to Getting Started to import the subscription, choose a node, enable the system proxy and verify the connection. For connection failures, empty lists or ineffective routing, use the Help Center to find the path for the relevant failure stage. For more advanced split-routing rules in mainland China and outside China, see Practical v2rayN split routing for mainland China and outside China, and maintain node protocols separately from routing policies.