V2Ray Protocol and Core Selection Guide

01 / MODEL

Before choosing a protocol: separate protocol, transport, and security layers

A single node entry in a client is actually made up of multiple layers of parameters

In client interfaces, “protocol” is often used as a broad category, but a working connection depends on more than the protocol name. Take a common VLESS node: VLESS defines how the client and server exchange identity information and forward data; fields such as TCP, WebSocket, and gRPC describe how data is carried underneath; TLS or REALITY handles the handshake and security layer; XTLS Vision may participate in data processing as a flow-control mode. The address, port, user ID, and server name are connection parameters. A mismatch at any layer can appear as a timeout, handshake failure, or no usable traffic after connection.

That is why “VLESS” and “VLESS + TCP + REALITY + Vision” should not be treated as equally precise names. The former identifies only the protocol framework; the latter is close to a complete combination. The type label shown after a subscription import usually highlights only the easiest part to recognize. Open the node editor to check the full parameter set. This matters especially when moving from a text subscription to another client: the same displayed name does not mean every extended field was retained.

Four decision criteria are more reliable than a fixed ranking

First, check server compatibility. A client cannot unilaterally turn VMess into VLESS, and selecting REALITY alone will not give a standard TLS node the same capability. Protocol, transport, and security parameters must match the server configuration field by field. Second, check core support. v2rayN handles common desktop configurations, v2rayNG primarily uses the Xray core, and v2flyNG targets the V2Fly core. The same base node may have different support across these clients, especially when REALITY, Vision, or transport-specific extensions are involved.

Third, consider the device environment. Desktop devices usually have more processor time and memory available, so compatibility, routing, and ease of maintenance can take priority. Android devices also require attention to background operation, Wi-Fi changes, repeated handshakes, and reconnects that consume power. Fourth, consider the configuration source. If a node comes from a subscription, prefer types the subscription explicitly provides and the client fully recognizes. Do not manually guess missing parameters just to pursue a particular name.

Confirm completeness before discussing performance

Connection speed starts with correct parameters. Address resolution, reachable ports, accurate system time, matching user IDs, and the same transport path affect first-connection success more directly than the protocol name. If an import is missing the server name, WebSocket path, REALITY public key, or short ID, simply switching node types usually will not help. Check the node details or subscription source instead of guessing field by field in the client.

A practical order is: first confirm that the client recognizes the node type; then verify the address, port, and identity fields; next check the transport and its related parameters; finally inspect the security layer and flow control. Only then compare connection setup time, sustained throughput, memory use, and battery impact. This order separates configuration errors from protocol trade-offs and prevents a failed handshake from being mistaken for evidence that a protocol is inherently slow.

02 / VMESS

VMess: compatibility for legacy configurations and parameter boundaries

Design background and current role

VMess was one of the earlier widely adopted protocols in the Project V ecosystem. It organizes user identity, authentication data, and data-transfer rules within a unified protocol structure, and uses a time-based authentication process between client and server. This means VMess is more than a simple “address plus password” combination, and explains why clock drift can affect connectivity. Many older server deployments, subscription converters, and client configurations are based on VMess, so it still has practical value for legacy-node compatibility.

The main reason to choose VMess is usually not to minimize processing steps, but that an existing configuration is stable and its subscription fields are fully parsed by the client. If the server provides only VMess, the client should use the same protocol. Changing the node type to VLESS while keeping the original UUID does not create an equivalent connection because the two protocols use different authentication and data structures. Migration requires changes on both the server and client; changing only the local label is not enough.

alterId, encryption options, and recognizing legacy configurations

Older documentation often includes alterId. It belongs to the earlier VMess configuration model and is usually set to zero in modern configurations. When importing a legacy subscription, follow the server’s actual configuration if the client still displays this field; do not change it to another number based on the age of a tutorial. Different clients may hide options that are no longer common or fill in defaults during import. These interface differences do not mean the protocol content has changed.

A VMess node may also show security or an “encryption method.” This field describes processing at the VMess data layer and is not the same option as outer TLS. Whether outer TLS is enabled is controlled by the transport security fields. A common mistake is to see a value in security and assume TLS is configured too. In reality, they belong to different layers. Check them separately during troubleshooting; one does not replace the other.

{
  "protocol": "vmess",
  "settings": {
    "vnext": [{
      "address": "example.com",
      "port": 443,
      "users": [{
        "id": "11111111-1111-4111-8111-111111111111",
        "alterId": 0,
        "security": "auto"
      }]
    }]
  }
}

The snippet above shows only the core layers of a VMess outbound. A real connection still requires transport and security settings that match the server. The example address and user ID only illustrate field structure and cannot be used as a node. When entering a configuration manually, place each value from the node details in its corresponding field instead of copying the example.

Understanding transport combinations and performance

VMess can be combined with transports such as TCP and WebSocket, and can also use TLS. The differences between combinations are often larger than the differences caused by VMess itself. Direct TCP has a relatively short encapsulation path; WebSocket adds frame processing and depends on matching fields such as the path and Host; TLS adds handshake and encryption work. When asking whether “VMess is fast,” specify whether both sides use the same transport, security layer, server, and network conditions.

In terms of resource use, VMess usually involves more authentication and data-processing steps than the more streamlined VLESS, but on modern desktop hardware this difference may not be the main bottleneck. Noticeable latency more often comes from DNS resolution, server distance, wireless jitter, repeated connection setup, and transport retries. During extended mobile use, check the client logs for periodic disconnects and reconnects; repeated handshakes increase both waiting time and battery consumption.

When to keep VMess and when to migrate

If a VMess node has complete parameters, remains stable, updates normally through its subscription, and the current client accurately recognizes its transport settings, continuing to use it is reasonable. Protocol selection does not require migration whenever a new name appears. Conversely, if you are creating a new server and both the client and core clearly support VLESS and the required security combination, you can evaluate a more streamlined protocol framework. Keep the original node as a reference, add and validate the new configuration first, then remove the old one to preserve a working baseline while parameters are being checked.

When moving VMess nodes between v2rayN, v2rayNG, and v2flyNG, the basic fields are usually broadly compatible, but some transport extensions still depend on the core. After import, check at least the protocol, address, port, UUID, transport, TLS switch, server name, and path. If a subscription provides only a vmess:// entry, the client will usually decode it. If it appears as a blank node or the fields are misaligned, first check whether the subscription content is complete instead of guessing missing values.

03 / VLESS · REALITY

VLESS, REALITY, and XTLS Vision: what each layer does

VLESS is a lightweight protocol framework

VLESS is designed to minimize the work handled by the protocol itself. It uses a user ID for identity matching, but does not duplicate a complete encryption mechanism within the VLESS data layer; security is delegated to outer solutions such as TLS and REALITY. This separation makes the protocol structure clearer and reduces some redundant processing. However, “VLESS is lighter” does not mean every VLESS combination is automatically faster. Total overhead still depends on the transport, security handshake, flow control, server implementation, and network path.

Common VLESS fields in a client editor include the address, port, UUID, encryption value, transport, security type, and flow control. Some interfaces require the encryption field to be none; this is part of the protocol structure and does not mean the connection has no security layer. If the node also uses TLS or REALITY, security processing is handled outside VLESS. To understand the security combination, inspect the “transport security” option or its equivalent rather than looking only at VLESS’s encryption field.

REALITY is a security handshake solution, not another name for VLESS

REALITY is often provided together with VLESS, so many clients display the combination as one name. Strictly speaking, VLESS handles the application protocol while REALITY provides security and handshake capabilities. A REALITY configuration usually includes the server name, public key, short ID, and client fingerprint; these values must match as a set. An address, port, and UUID alone are not enough to establish a complete connection. If a subscription converter drops any extended field, the client may display VLESS yet fail during the handshake.

The public key is an important field used by the client for verification and handshake participation. The short ID matches the server configuration, while the server name contributes to the handshake semantics. The client’s fingerprint option describes the preset used for the handshake behavior. Interface labels may vary slightly between versions, such as “Public Key,” “public key,” or an abbreviated name, but the function remains the same. When migrating a node, map fields by meaning rather than copying them by screen position.

XTLS Vision is a flow-control and data-processing mode

XTLS Vision commonly appears in VLESS + REALITY combinations. It is not a new identity protocol or an add-on form of the server address, but a flow-control choice. One goal of Vision is to reduce redundant processing in specific scenarios and use a more suitable data path for traffic that already has security semantics. The client and server must both support and configure it consistently; selecting Vision only on the client can cause connection problems if the server has not enabled it.

A common interface value is xtls-rprx-vision. Use the node details as the source of truth. Leaving it blank and entering this value are not interchangeable performance modes; flow is part of the server configuration. Some subscription formats carry the flow parameter directly, while older conversion workflows may drop it. If the REALITY public key and short ID are present but traffic still does not pass, check flow next rather than repeatedly changing the server name.

Why these combinations often respond well

The VLESS framework is streamlined, REALITY removes part of the process of preparing a conventional TLS certificate configuration, and Vision optimizes the data path. Together, less redundant encapsulation and suitable flow control may reduce processing overhead. Actual results still depend on round-trip latency, server load, congestion, DNS resolution, and device performance. Protocols determine only part of the outcome; one speed test cannot establish a universal rule.

On mobile devices, the benefit often appears as a more stable long-running connection with less repeated computation. If the network frequently switches between Wi-Fi and mobile data, every protocol must reconnect; background policies and network quality may affect battery life more than protocol differences. For a deeper look at handshakes and data paths, read the technical guide to REALITY and XTLS Vision. Before configuring it, confirm that the chosen client and core support all required fields; v2rayNG is generally better suited to Xray-related extensions.

04 / TROJAN · SS

Trojan and Shadowsocks: simple structures, different trade-offs

Trojan: a clear authentication and TLS combination

Trojan typically uses a password as the identity credential and runs with TLS. Its configuration is relatively straightforward: the client connects to a specified address and port, authenticates with the password, and relies on TLS for the security layer. Node details commonly also include the server name and certificate-verification options. The server name must match the server’s certificate configuration; it cannot be inferred from the address field alone.

Trojan’s strength is an easy-to-understand parameter structure, and many clients reliably parse standard share links. It is not simply “a password and port,” because the TLS handshake, server name, and transport must still match. If WebSocket or gRPC is used, related fields such as the path and service name also affect the connection. During troubleshooting, separate the TLS handshake stage from Trojan authentication: check system time, server name, and security settings for the former, and the password and server-side protocol configuration for the latter.

Shadowsocks: a streamlined encrypted forwarding structure

Shadowsocks is often abbreviated as SS. Its core parameters usually include the server address, port, encryption method, and password, making it shorter than VMess or a VLESS combination with multiple extension layers. The compact configuration is convenient for manual entry and cross-client transfer. However, the encryption method must be supported by both client and server, and its name must match exactly. Replacing it with a similar-looking method will not automatically negotiate a working value.

Different cores may support different sets of Shadowsocks encryption methods. Newer methods require corresponding core capabilities; an older client may read an ss:// link but still report that the method is unsupported when connecting. In that situation, verify the client core before changing the password. v2rayN is suited to managing different protocols on desktop, while v2rayNG and v2flyNG are each constrained by the capabilities of their respective cores. Include the actual encryption method in your compatibility check when choosing a client.

{
  "protocol": "shadowsocks",
  "settings": {
    "servers": [{
      "address": "example.com",
      "port": 8388,
      "method": "aes-128-gcm",
      "password": "your-password"
    }]
  }
}

This snippet shows the relationship between standard outbound fields. Replace the address, port, method, and password with the real values supplied by the server. The encryption method is not a local preference and cannot be changed unilaterally to reduce resource use. If the method is blank after import, recheck the share link or subscription conversion result.

Performance cannot be judged from the number of fields alone

Fewer Shadowsocks parameters do not mean it is faster than Trojan under every network condition. Trojan usually pays the cost of a TLS handshake, but for a long-lived connection that cost is amortized over subsequent traffic. Shadowsocks overhead depends on the selected encryption method, hardware acceleration, packet size, and core implementation. With many short-lived connections, connection reuse and client behavior may dominate the experience; during sustained downloads, server bandwidth and link quality are often more important.

On mobile devices, continuous encryption and frequent reconnects both affect battery life. Modern processors handle common cryptographic operations well, so the algorithm name alone is a poor predictor of power use. A more useful approach is to keep the network, server region, and approximate workload consistent, then record connection stability, wake-ups, and client background status over a meaningful period. A few seconds of speed testing cannot determine long-term battery performance.

Use cases and selection criteria

If node details provide standard Trojan parameters and the client correctly recognizes the TLS fields, keeping Trojan is the safest choice. If a node provides Shadowsocks, focus on whether its encryption method is supported by the current core. Neither needs to be converted simply to make every node use the same type. When a subscription contains multiple protocols, keep the different types and manage them per node; system proxy and routing rules do not require every outbound to use the same protocol.

From a maintenance perspective, fewer parameters make manual checking easier, but they do not eliminate future updates. If the server address, password, certificate name, or encryption method changes, the old node will still stop working. With subscriptions, use the client’s update function to receive changes instead of maintaining multiple manual copies. For subscription entry points on desktop and Android, see How to import V2Ray subscription links.

05 / PERFORMANCE

Comparing connection speed, resource use, and mobile battery life

Break “speed” into four observable stages

“Speed” in a protocol comparison includes at least four different metrics. First is connection setup time, from the client’s initial request to handshake completion. Second is time to first byte, the wait after a request is sent until the first useful data arrives. Third is sustained throughput, the stable rate over a longer transfer. Fourth are jitter and reconnects, which determine how smoothly pages load, media plays, and background tasks run. A combination that connects slightly more slowly does not necessarily have lower sustained throughput; conversely, a fast first connection does not guarantee better stability on a weak network.

For a meaningful comparison, keep the server, network, destination, routing rules, and test period consistent. If two nodes are in different regions, the observed difference mainly reflects the network path rather than the protocol. Warm up each connection first to reduce the influence of DNS resolution and first-connection caching. A client’s “latency test” may measure only TCP setup or a specific probe address and may not complete a real protocol handshake. To determine whether a node works, use a real connection test and access an actual destination afterward.

Protocol processing is rarely the only bottleneck

VMess has its own authentication and data-processing flow; VLESS delegates more security work to outer layers; Trojan commonly includes TLS; Shadowsocks overhead depends on its encryption method; and VLESS + REALITY + Vision combines handshake and flow-control work. Theoretical processing steps help explain differences, but in ordinary client use, network round trips, server capacity, packet loss, and congestion often account for more. Protocol-level differences are easier to observe only when the server and network path are otherwise comparable.

Transport choice also changes the result. TCP combinations usually take a direct path; WebSocket adds frame encapsulation; gRPC uses HTTP/2 semantics and may use multiplexing. More multiplexing is not always better: excessive aggregation can let jitter on one underlying connection affect multiple requests. Adjust concurrency, connection reuse, or mux options conservatively, changing one item at a time and keeping the defaults as a baseline.

Memory, CPU, and background wake-ups

Resource use comes from the client interface, core, rule set, number of connections, and log level. The protocol is only one part. Large routing rules, continuous verbose logging, and many concurrent connections often increase memory and CPU use more noticeably than an individual protocol field. Desktop v2rayN also manages the system proxy, tray state, and configuration list; Android clients take over traffic through system network interfaces and are affected by background policies. When comparing resources, ensure both tests use the same rules and log level.

Log verbosity is especially likely to distort long-term observations. Detailed logs are valuable for troubleshooting, but after the issue is identified you can return to the normal level to reduce continuous writing and formatting overhead. A large node list usually does not consume substantial CPU continuously, but running full tests frequently creates many connections at once. On mobile devices, avoid setting automatic test intervals too short; testing the current candidates on demand produces more interpretable results.

Mobile battery life depends on stability and reconnect frequency

Mobile power use cannot be ranked in a fixed order such as VMess, VLESS, then Trojan. Wireless wake-ups, screen time, signal strength, background keep-alive, connection count, and retry policy all affect the result. A theoretically lightweight node that reconnects every few dozen seconds may consume more power than one that maintains a stable long-lived connection. Choose a stable path first, then compare protocol-processing differences.

When comparing nodes in v2rayNG or v2flyNG, keep the routing mode and app scope the same, disable unnecessary continuous testing, and observe system battery statistics during a normal usage cycle. Do not switch networks repeatedly or run large system updates at the same time. If the system consistently reclaims the connection after the device sleeps, check the client’s background-execution settings; this is a device scheduling issue that changing protocols may not solve.

06 / CORES

V2Fly and Xray: core families, feature coverage, and configuration compatibility

The client interface and proxy core are separate components

v2rayN, v2rayNG, and v2flyNG all provide graphical interfaces, but the core usually handles protocol parsing, connection setup, and routing. The interface manages subscriptions, node editing, the system proxy, logs, and startup controls; the core reads the configuration and executes the network logic. Once this separation is clear, many compatibility issues are easier to locate: an interface displaying a field only means the data was saved; whether the core can execute it depends on feature support.

v2rayN is the primary desktop choice for Windows, macOS, and Linux, and can manage multiple node types and routing configurations. v2rayNG is a common Android client that primarily uses the Xray core. v2flyNG also targets Android but follows the V2Fly core route, making it a suitable choice when that core’s compatibility range is required. Installation links for all three clients are available in the Download Center. Choose by platform and node type rather than by similar-looking names.

V2Fly continues the Project V configuration model

V2Fly maintains core capabilities related to V2Ray, with configuration structures built around familiar layers such as inbounds, outbounds, routing, and dns. VMess, Shadowsocks, Trojan, and their supported transports can be organized within that model. For users with existing V2Fly configurations, dependencies on its specific behavior, or a preference for the same core family, v2flyNG provides a direct Android graphical interface.

“Similar configuration structure” does not mean every extension field is interchangeable. Some fields may exist only in a particular core, while fields with the same name may accept different values. Before copying a complete JSON configuration from one core to another, check protocol and transport support, then review routing rules and DNS structure. Basic outbounds are usually easier to migrate; experimental features, specialized flow control, and extended transports require field-by-field validation.

Xray extends capabilities such as VLESS, REALITY, and Vision

Xray shares deep structural ties with the V2Ray configuration model, so many basic configurations look similar. Xray provides capabilities around VLESS, XTLS Vision, and REALITY, which is why these nodes are generally better suited to v2rayNG or a desktop environment using a compatible core. If node details explicitly include a REALITY public key, short ID, and Vision flow control, first confirm that the core actually used by the client supports them; merely confirming that the interface offers a VLESS type is not enough.

Core selection can also affect which fields survive share-link parsing. A client may recognize URI parameters during import but still convert or validate them when starting the core. If logs report an unknown field, invalid value, or unsupported flow control, the issue is usually feature coverage rather than address reachability. Revisit the node-type and core match instead of deleting random fields to force the configuration through; the removed field may be essential to the connection.

Which configurations usually transfer easily, and which require caution

Addresses, ports, basic user IDs, standard VMess fields, some common transports, and basic routing rules are generally easier to map between similar configuration models. DNS and routing also share core concepts. REALITY, XTLS Vision, transport-specific extensions, protocol-specific settings, and fields newly added by a particular core require separate verification. A client-generated complete configuration may also contain local listen ports, log paths, and platform-specific settings that should not be copied unchanged across devices.

The safer migration method is to use node-sharing information as the input and let the target client generate its own local configuration. This avoids carrying over the source client’s local ports, cache paths, and platform options. Then migrate routing rules and validate each item. If you must work with JSON, start with the smallest outbound containing only the required transport fields, confirm the connection, and then add DNS, routing, and advanced options. Test after each layer so any failure can be tied to the most recent change.

v2ray test -c config.json
xray run -test -c config.json

The commands above check configuration syntax when the relevant core executable is correctly installed and available in the current command environment. Passing the syntax test only means the configuration can be parsed; it does not prove that the server is reachable. Users of graphical clients can usually inspect the startup log directly without leaving the client.

07 / SUBSCRIPTION

Subscriptions, share links, and client compatibility: how fields move between tools

A subscription link is an entry point to a configuration set, not a protocol

A subscription link usually returns a set of nodes, which the client then parses into local configurations. It may contain VMess, VLESS, Trojan, Shadowsocks, or other types, and may return multiple share links encoded with Base64. The subscription address itself says nothing about which protocol the nodes inside use; only after updating and parsing can you see their actual types. Pasting a subscription address directly into a single-node editor usually will not produce a valid result.

In v2rayN, save the address through the subscription group or subscription management entry, then run an update. v2rayNG and v2flyNG provide corresponding subscription settings and update actions. After updating, confirm the number and types of nodes before testing one. If the list is empty, check that the address is complete, the network request succeeded, and the response uses a format supported by the client. For the full procedure, see How to import subscriptions in v2rayN and v2rayNG.

What information common URI formats carry

A typical vmess:// link encodes a JSON object containing fields such as the address, port, UUID, transport, Host, path, and TLS settings. Different generators have used slightly different field names, so older links should be checked manually after import into a newer client. vless://, trojan://, and some ss:// links are closer to standard URIs: identity data appears in the user-info section, the address and port appear in the host section, and additional parameters are placed in the query string.

URI parameter names have specific meanings. For example, security may indicate TLS or REALITY, type may specify the transport, flow identifies flow control, and sni or an equivalent parameter specifies the server name. pbk and sid are commonly used for the REALITY public key and short ID. The client must recognize these parameters and map them correctly to the core configuration. A long share link is not necessarily complete; if the generator omitted a required field, no amount of extra length can restore it.

Base64 is an encoding format, not a protocol

Many subscriptions encode multiple share links as one block of Base64 text for transport. After decoding, the result is still a set of vmess://, vless://, trojan://, or ss:// entries. Base64 does not encrypt node content or determine client compatibility. Compatibility depends on the decoded protocol links, their extended parameters, and the target client’s parsing capabilities.

If one client imports successfully while another produces an empty list, do not assume the subscription has expired. Check in order whether the target client supports the returned types, recognizes the protocols inside, and supports the extended parameters carried by the links. v2flyNG and v2rayNG follow different core paths, so nodes containing REALITY or Vision deserve particular attention. If a subscription contains several node types and only some import, the cause is usually a difference in protocol or parameter support rather than a failed subscription request.

The boundaries of subscription updates, deduplication, and local edits

A subscription update may overwrite nodes managed by that subscription. If you edit a subscription node directly in the client, those changes may disappear after the next update. For local experiments that must be kept, duplicate the node as an independent entry and rename it so it is not confused with the subscription item. Identical names do not necessarily indicate duplicates; compare the address, port, protocol, identity fields, transport, and security parameters before deleting anything.

If a node stops connecting immediately after a subscription update, first check whether its parameters changed, then inspect local proxy settings. The server may have changed its address, port, or security fields, and the client may display different results after a parser change. Keeping an independent copy from before the update helps identify which layer changed. If every subscription node times out, follow the node timeout troubleshooting order to check system time, local ports, node parameters, and subscription status.

08 / DECISION

Choose by use case and migrate safely

Stable existing nodes: compatibility comes before chasing names

If an existing VMess, Trojan, or Shadowsocks node is stable, its subscription updates normally, and the client fully recognizes its parameters, there is no need to migrate merely because a newer protocol name appears. Server capabilities constrain protocol selection first; local preference comes second. A stable connection represents a verified combination of server configuration, network path, and client. Those conditions are more valuable than theoretical comparisons.

When changing clients, choose v2rayN first on desktop platforms. On Android, prefer v2rayNG for configurations with Xray extensions, and choose v2flyNG when the V2Fly core path is required. Before migrating, record the protocol, transport, security, server name, path, flow, and identity fields in the original client. After importing through a share link or subscription, compare each item. Matching only the name and address is not enough; a missing extension field can cause handshake failure.

New configurations: choose the core before the combination

When creating a new node, start by working backward from the target devices and clients to determine core capabilities. If both desktop and Android must use the configuration and it involves REALITY and Vision, confirm that both platforms have a suitable Xray environment before adopting VLESS + REALITY + Vision. If consistency with the V2Fly configuration model is the priority, choose protocols and transports within V2Fly’s supported range. Selecting the core first prevents discovering after deployment that one platform cannot parse a required field.

If you need a compact configuration that is easy to enter manually, and the server and client support the same encryption method, Shadowsocks is a clear option. If you already use a standard TLS setup and want password authentication with an easy-to-follow TLS hierarchy, Trojan is straightforward to understand and maintain. VMess is better suited to carrying existing configurations and supporting legacy subscriptions. No combination has an absolute ranking outside its environment; evaluate compatibility, maintenance, stability, and resource use together on one checklist.

Weak networks and mobile devices: minimize reconnects first

When the network is unstable, a reliable server and suitable transport matter more than minimizing theoretical encapsulation. Watch logs for connection resets, handshake timeouts, and repeated resolution. If a node disconnects frequently, first determine whether the cause is Wi-Fi signal, server load, transport settings, or protocol parameters. Switching protocols directly may also switch the server and path, making the comparison inconclusive.

On Android devices, reduce continuous batch testing and overly frequent subscription updates, keep routing rules at a reasonable size, and allow the system to run the client in the background as needed. VLESS + REALITY + Vision may provide an efficient processing path when fully supported and correctly matched, but a stable Trojan or Shadowsocks node may still perform better on the actual device. Judge by stability, battery use, and real connection results over a complete usage cycle.

Multi-device sync: use the subscription as the source and client settings as the local layer

When using desktop and Android devices together, use the node subscription as the shared source while keeping the system proxy, app scope, routing mode, and local listen ports managed separately on each device. Do not copy a complete client configuration file because it contains platform-specific fields. After updating the subscription, check node types and extended parameters on both devices. If a node type appears on only one, inspect that device’s parser and core support instead of immediately deleting subscription content.

Routing rules should not be confused with protocol selection. The same VLESS or VMess outbound can be referenced by different rules, and changing the routing mode does not change the node protocol. When some websites work and others do not, first determine whether the request matched the intended route, then inspect the node. Return to protocol and connection parameters only if all requests fail. Keeping the two layers separate avoids unproductive changes.

Migration workflow: add, compare, validate, then clean up

A safe migration has four steps. First, keep the old node and add the target protocol without overwriting the working entry. Second, compare the address, port, identity, transport, security, and flow fields one by one, confirming that the server supports the same configuration. Third, run a real connection test, inspect the logs, and access an actual destination to verify both connection setup and system-proxy behavior. Fourth, after a period of stable use, remove the old configuration if it is no longer needed.

If the new configuration fails, roll back to the most recent working state and troubleshoot by layer. For authentication errors, check the UUID or password; for handshake errors, check system time, server name, public key, and short ID; for timeouts, check the address, port, and transport; for unknown fields at startup, check core compatibility. Do not change the protocol, transport, routing, and DNS all at once, or the logs will be unable to identify the cause. For a detailed first-connection verification process, see the complete v2rayNG first-connection workflow.