V2Ray Protocols and Core Technology Guide

01 / SELECTION MODEL

Separate the protocol, transport, security layer and core

The “protocol type” in a client is only the first decision

Graphical clients usually list VMess, VLESS, Trojan and Shadowsocks as node types, but a connection is never determined by that field alone. The complete path can be divided into at least four layers: the application protocol handles authentication and request formatting; the transport determines how data is carried over channels such as TCP, WebSocket and gRPC; the security layer handles encryption and peer verification; and the core parses the configuration and establishes the connection. REALITY is closer to a security and handshake capability than to a standalone application protocol equivalent to VLESS. Treating all these concepts as one name often leads to the mistaken conclusion that a connection should work simply because the protocol was chosen correctly.

Consider a common VLESS setup. A node may include VLESS, TCP, REALITY, XTLS Vision, a server name and a public key at the same time. VLESS defines the authentication and request format, TCP identifies the underlying transport, REALITY handles the handshake and identity verification, and Vision affects stream processing. After importing a share link, the client writes these pieces into one outbound configuration. Missing key fields, changed spelling or fields placed where the current core does not recognize them can all make the actual behavior differ from the node name.

Start with the server-side configuration

A protocol cannot be switched unilaterally based on client preference. The client node must match the server in protocol, port, authentication details, transport and security parameters. When a subscription provides an existing configuration, confirm that the client can recognize it completely instead of manually changing VLESS to VMess or rebuilding a node with only the server address and port. Similar protocol names do not make them interchangeable, and an identical UUID cannot replace the remaining parameters. Every option in the node editor is essentially a mapping of part of the server configuration.

If you control both sides, choose in this order: confirm the supported core range, select the application protocol, choose the security layer and transport, then consider client import and maintenance. For most new configurations, VLESS provides a lightweight protocol layer that works well with security capabilities such as TLS or REALITY. VMess has a more established protocol design and remains common in legacy configurations. Trojan combines password authentication with TLS, while Shadowsocks has a compact structure and broad client coverage. There is no universal ranking independent of network conditions, server implementation and maintenance goals.

Judge compatibility by field completeness, not the name alone

To determine whether a client supports a node, check at least the protocol, address, port, user identifier, transport, security method, server name, fingerprint, path or service name and other fields. A node appearing in the client list does not mean every field was received correctly. Subscription converters, older subscription templates and cross-core imports may discard unknown extensions, leaving a node that looks complete but has silently fallen back to defaults. In that situation, open the node editor and compare each field with the original link or server documentation. Also check the client log for unknown fields, handshake failures or configuration parsing errors.

The basic rule for choosing a protocol is not to chase a name, but to ensure that the complete parameter set passes consistently between the server, subscription, client and core. Establish this layered model first; only then do comparisons of speed, resource use or battery life become meaningful. If the basic import workflow is not complete, use the quick configuration guide to establish a working connection, then return here to compare combinations.

02 / VMESS & VLESS

How VMess and VLESS differ by design

VMess background and configuration characteristics

VMess is a representative protocol from the early Project V ecosystem. It organizes user identifiers, authentication details and protocol-layer encryption within its own format, and has long been used by many V2Ray configurations and subscription formats. Common node fields include the server address, port, user UUID, alterId, transport and security settings. Newer configurations generally no longer rely on a high alterId, but older subscriptions and tutorials may still include the field. After importing a node, use the values supplied by the server; do not rewrite them merely because a field looks outdated.

VMess’s main strengths are its mature ecosystem and legacy compatibility. Many subscription generators, panel formats and clients already recognize its core fields reliably, making older configurations easier to migrate. The trade-off is a protocol layer that handles more work, with field meanings that can easily blur into the transport and security layers. On resource-constrained devices, these differences rarely determine the experience by themselves, but under many concurrent connections, frequent wake-ups or long-running sessions, additional processing may still appear in CPU time and battery use.

VLESS delegates security to the surrounding layers

VLESS is designed to keep the protocol layer simple. It authenticates with a user identifier, but does not duplicate full data encryption within VLESS itself; instead, it relies on external security layers such as TLS or REALITY to form a complete connection. This separation makes responsibilities clearer and leaves room for composable extensions in the Xray ecosystem. After selecting VLESS in a client, still verify security, flow, transport and serverName. Address, port and UUID alone are usually not enough to reproduce the original node.

“VLESS is lighter” should not be read as “it is always faster.” Total connection time includes DNS resolution, TCP establishment, the security handshake, authentication, the first request and sustained transfer. Reducing protocol-layer processing affects only part of that path. When network round-trip time is high, handshake count and connection reuse matter more than a small amount of local computation. For large transfers, congestion control, link quality and the server’s egress are more important. When a phone frequently creates many short connections, handshakes and application wake-ups become important again. Performance must therefore be judged as a complete combination, not by comparing the four words VLESS and VMess.

Do not skip checking Vision, TLS and REALITY

Some VLESS configurations include a flow field, such as Vision used with a specific TCP and security combination. This is not a decorative label; it is part of negotiation and data processing on both sides. After importing a subscription, a blank or truncated flow value, or a combination unsupported by the current core, can cause the connection to fail after the handshake. In TLS setups, check the server name, the domain covered by the certificate and the application-layer protocol options. REALITY setups also add parameters such as the public key, short ID, server name and client fingerprint; their details are covered in Chapter 3.

“Skip certificate verification” in a configuration editor is a diagnostic option, not a suitable long-term fix. Certificate errors usually point to the device clock, server name, certificate deployment or subscription fields. Disabling verification hides the root cause and can make the setup fail again after moving to another device or updating the subscription. A safer order is to check the system time, verify the server name in the node, then confirm that the server port actually provides the expected TLS configuration.

Where the practical choice lies

If an existing VMess configuration is stable and imports completely across all your devices, there is no need to rebuild it immediately just because the name is newer. For a new deployment using the Xray ecosystem and combinations such as REALITY or Vision, VLESS is usually the more natural fit. When broad compatibility between V2Fly and Xray matters, prioritize basic fields understood by both and avoid treating core-specific extensions as universal configuration. For subscription maintainers, clearly outputting protocol, transport and security fields is more valuable than simply labeling something a “VLESS node.”

In v2rayN, use the node editor to inspect the complete combination. On Android, when using v2rayNG, expand the transport and security options as well instead of relying only on the name in the node list. v2flyNG is primarily oriented toward the V2Fly core and suits configurations that V2Fly can recognize. Installation links and supported platforms for all three clients are listed on the download page.

03 / TROJAN, SHADOWSOCKS & REALITY

The roles of Trojan, Shadowsocks and REALITY

Trojan is a protocol; correct TLS parameters are fundamental

Trojan uses password authentication and builds the connection on TLS. A client node typically needs the server address, port, password, server name and certificate-verification options. Its configuration may look simpler than a VLESS setup with many extensions, but TLS parameters remain central to a successful connection. The server address can be a domain or IP, while the server name is generally used for name matching during the TLS handshake; they may be the same or different. If a subscription converter keeps only the address and drops the server name, certificate-name mismatches may result.

Trojan suits scenarios that need a mature TLS combination with relatively direct configuration semantics. Its performance is affected by TLS handshakes, connection reuse and the underlying transport; fewer visible fields do not automatically eliminate every overhead. In long-lived connections, the initial handshake cost is spread across later data. With many short connections, handshake frequency matters more. If the client log shows a TLS error, check the name, time and server configuration before repeatedly changing the local proxy mode.

Shadowsocks stays simple through explicit encryption methods

The core fields of a Shadowsocks node are usually the server, port, password and encryption method. Its protocol structure is relatively compact, and implementations exist across many platforms and cores, so it is often used when broad basic compatibility and lower configuration complexity matter. The encryption method must be supported by both sides and match exactly. A method appearing in the client dropdown does not mean the server uses it; a subscription converter that rewrites the method name can also cause authentication failure.

Different encryption methods place different demands on processor capabilities and implementation quality. Modern devices generally have strong support for symmetric encryption, but low-power devices, older processors and high-concurrency workloads can still show differences. Evaluate CPU use, temperature and stability under sustained throughput instead of relying on one web-page load. If the server or client log reports an unsupported method, restore the original subscription value and confirm that the current core includes the required implementation.

Shadowsocks’s simplicity also means that some advanced behavior is handled by external layers or client policies. Split tunneling, DNS, the system proxy and application interception are not functions of the protocol itself, so changes in these settings should not be attributed to the Shadowsocks node. When the same node behaves differently in two clients, the usual causes are routing rules, the DNS query path or the way the system is intercepted—not a change in the node protocol.

REALITY is not a fifth standalone proxy protocol

REALITY often appears alongside VLESS, but it handles the security handshake and peer verification; it does not replace VLESS’s proxy request format. To create this type of node, clients usually start with VLESS, set the security method to REALITY, then enter the public key, short ID, server name, fingerprint and flow. Even when a subscription interface abbreviates it to a “REALITY node,” understand it as four separate parts: VLESS, transport, security layer and flow control.

The public key lets the client verify the server identity, the short ID is constrained by the server configuration, the server name participates in the handshake parameters, and the client fingerprint describes handshake characteristics. These fields cannot be substituted for one another. In particular, do not apply ordinary TLS certificate fields directly to REALITY or infer the public key or short ID from the displayed node name. When the server configuration changes, update the subscription as well; manually editing several devices makes it easy for some of them to retain old values.

REALITY extensions are mainly tied to Xray core capabilities. With a client using the V2Fly core, “supports VLESS” does not imply support for the same set of REALITY extensions. Basic protocol compatibility and extension compatibility must be assessed separately. If a subscription serves different cores, create separate groups by core or at least use clear node names to show the requirement, rather than discovering only after import that fields were ignored.

When choosing among the three, first ask what role the option plays in the connection stack, then ask whether the client and core support every required field. This order is more reliable than judging by the node name. For a focused review of missing fields, empty values or failed updates after import, continue with Common questions and Troubleshooting failed subscription updates.

04 / PERFORMANCE & POWER

Connection speed, resource use and mobile battery life

Separate connection setup, first byte, throughput and stability

“Speed” covers at least four different metrics. Connection setup time runs from the start of a connection until the protocol and security handshakes finish. Time to first byte is the wait after sending a request before the first useful data arrives. Sustained throughput is the effective rate during a longer transfer. Stability asks whether the connection survives network changes, idle periods and sustained load. A protocol that performs one less step during setup is not necessarily faster over a long transfer, and similar throughput does not mean identical short-connection responsiveness.

Public-network paths, server load, DNS resolution, TCP congestion control and application caching often matter more than protocol-layer differences. For a meaningful comparison, hold the server, egress, client, routing rules and test time constant while changing only one protocol combination. Run several rounds and record the median behavior; this reflects normal performance better than selecting a single fastest result. Disable background synchronization and system updates during testing so unrelated traffic does not distort the result.

Protocol and transport jointly determine overhead

VMess performs more work at the protocol layer, VLESS keeps that layer lighter, Trojan relies on TLS, and Shadowsocks’s processing profile depends on the selected encryption method. These are only part of the computational cost. WebSocket adds framing and header processing, gRPC relies on HTTP/2 connection management, and a direct TCP combination reduces intermediate encapsulation. Different implementations also vary in buffer handling, connection reuse and concurrent scheduling, changing actual resource use.

Memory use is usually influenced more by connection count, DNS cache size, routing-rule scale, log level and the graphical client interface. Comparing the memory value of one idle node says little about protocol cost. A better method is to create the same number of connections, run the same task for the same duration and observe the core process during its stable range. Verbose logging also adds disk writes and text formatting overhead; restore the normal level after troubleshooting.

CPU use must be considered alongside the device hardware. Desktop processors usually handle everyday connections easily, while low-power devices may show significant load under high throughput, complex encryption, dense rules or many concurrent connections. If CPU use rises linearly with throughput, compare the encryption and transport combinations first. If it remains high while idle, investigate reconnect loops, subscription update jobs, abnormal DNS requests or log rotation instead of immediately changing protocols.

Mobile battery drain is driven mainly by wake-ups and network activity

Battery behavior on mobile devices cannot be ranked by encryption algorithm alone. Keep-alives, frequent reconnects, switching between Wi-Fi and cellular links, background application wake-ups, DNS queries and many short connections repeatedly activate the radio and processor. A slightly lighter combination that disconnects and reconnects often may consume more power than a slightly heavier but stable one. Stability, keep-alive intervals and application traffic patterns are therefore usually as important as the protocol itself.

For battery testing, use the same device, similar signal strength and the same application tasks, covering both continuous foreground use and background standby. System battery statistics are useful for trends, not for treating a small short-term change as a conclusion. If v2rayNG or v2flyNG uses significant battery in the background, first check for repeated reconnects, overly frequent automatic subscription updates, routing that sends all application traffic through the proxy, and system behavior that repeatedly stops and restarts the connection service.

For messaging, web browsing and light synchronization, a stable connection and sensible routing usually matter more than peak throughput. For sustained downloads or video streaming, the server’s egress and link quality carry more weight. For many developer-tool requests, connection reuse and DNS behavior deserve closer attention. Define the task first; otherwise protocol performance comparisons become a number contest detached from real use.

Overall, VLESS’s simplified protocol layer can reduce some processing, Shadowsocks is also relatively compact, VMess emphasizes established compatibility, and Trojan’s behavior is closely tied to TLS connection management. None of these broad tendencies outweighs transport, implementation or network conditions. For most users, a node with complete fields, a stable connection and a clearly identified core is usually a better choice than chasing theoretical overhead based on the protocol name alone.

05 / CORE FAMILY

The V2Fly and Xray core families

Shared configuration conventions do not mean identical functionality

V2Fly and Xray both inherit configuration conventions from the Project V ecosystem, with common structures such as inbounds, outbounds, routing, dns and log. Many basic VMess, VLESS, Shadowsocks, Trojan and routing configurations are conceptually similar, which is why users often see matching JSON hierarchies and client fields. Similar structures make migration easier, but do not imply that every extension can be exchanged directly. Each core line maintains its own features, fields and implementations, so confirm the supported range for the target core.

Graphical clients sit above the core. v2rayN handles node management, subscriptions, routing templates, the system proxy and core startup; on desktop, it usually converts user choices into a core configuration. v2rayNG provides a similar management layer on Android and primarily matches Xray core capabilities, while v2flyNG targets the V2Fly core. An option in the client interface means the client can represent that field, but whether it takes effect still depends on the current core and the complete field combination.

Keep Xray extensions separate from fields common to V2Fly

REALITY, specific flow values and some extension combinations are more closely tied to Xray capabilities. If a subscription containing these fields is imported into a client that runs the V2Fly core, the fields may be unrecognized, ignored or cause startup failure. The reverse migration also requires care: a configuration accepted by Xray is not necessarily written in the common form recommended for both cores. When building a cross-core subscription, clearly separate basic protocol nodes from nodes that require a specific core.

Compatibility can be assessed at three levels. First is syntax: can the JSON be parsed, and are the field types correct? Second is structure: are the fields located where the target core expects them? Third is semantics: does the protocol, transport and security combination have an implementation? A format check proves only the first level, not that the node can connect. Log messages such as unknown field, failed to build config and unsupported security point respectively to structural or semantic problems.

A minimal routing structure clarifies configuration boundaries

The example below shows only a generic routing structure. It sends private addresses to an outbound named direct, while other traffic is handled by later rules and the default outbound. The snippet contains no node credentials and is intended to illustrate the relationship between routing, rule and outboundTag. Real clients usually generate a more complete configuration; export a backup before editing manually.

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

outboundTag must point to an outbound tag that actually exists in the configuration. If a client template names the direct outbound differently, copying this rule alone creates a reference to nowhere. domainStrategy controls how the routing stage handles domain and IP matching. It is related to DNS configuration but does not replace the system or core’s complete DNS decisions. When a graphical client offers preset routing, understand its effect first, then decide whether to edit custom JSON.

Validate each function when migrating cores

Migration is not finished when an executable is replaced and the process starts. First list the protocols, transports, security methods, flow, routing rules, DNS policy and local inbounds used by the current nodes, then verify each item in the target core. Next, use a node with the simplest fields to test the basic connection, followed by extension nodes and split routing. This isolates basic runtime, protocol-extension and routing problems instead of producing a mixture of errors after importing everything at once.

Configuration files should not be repeatedly overwritten in both directions between different clients. v2rayN, v2rayNG and v2flyNG generate configurations from their own interface models, so extra fields, tag names and default inbounds may differ. A subscription link is suited to carrying node information, a client backup to restoring settings in the same type of client, and complete core JSON to cases where the field semantics are understood precisely. These serve different purposes; mixing them blurs the client-generation and core-execution layers.

When the desktop setup needs to cover Windows, macOS and Linux, v2rayN is the site’s recommended client. On Android, choose v2rayNG when the configuration is primarily Xray-based, or v2flyNG when the V2Fly core is required. Package types and system architecture details are collected on the client download page; this chapter focuses only on core and configuration compatibility.

06 / SUBSCRIPTION COMPATIBILITY

Subscription formats and field compatibility

A subscription is a configuration container, not a new proxy protocol

A subscription link delivers node information in bulk; the nodes inside still use protocols such as VMess, VLESS, Trojan or Shadowsocks. Common forms include a base64-encoded collection of share links, native configurations recognized by clients, and individual share links. base64 is only a text encoding; it adds no protocol capability and cannot repair missing fields. After fetching a subscription, the client must identify the container format, parse each node and then convert it into the current core’s configuration.

Share links usually put the protocol type in the URI scheme, then express authentication, transport and security details through the authority and query parameters. Basic fields transfer easily between clients, while extensions depend on the link specification and parser implementation. Items such as the REALITY public key, short ID, fingerprint, flow and gRPC service name may be ignored if the subscription generator uses non-standard parameter names. A node appearing in the list proves only that the outer layer parsed successfully; it does not prove that every query parameter entered the configuration.

Native JSON and share links serve different purposes

Native JSON can express complete inbound, outbound, DNS, routing and logging configuration, making it suitable for precise control of one core instance. It is not equivalent to a graphical client’s node database. When full JSON is imported into a graphical client, some clients run it as a custom configuration, some extract only outbound nodes, and some interface settings are not written back to the original file. Before importing, check whether the entry point is labeled for a “node,” “subscription” or “custom configuration.”

Share links are better for carrying individual nodes and work well with QR codes, clipboards and subscription aggregation, but complex routing and DNS policies generally do not belong in a single node link. Let the subscription handle nodes and the client handle local routing. If the same split-routing behavior is needed on several devices, maintain node subscriptions and routing templates separately, using the format appropriate to each client rather than making one overly complex subscription carry every setting.

A failed update and an unusable node after update are different problems

A failed update means the client did not retrieve or parse the subscription. Common clues include an unreachable link, an incorrect device clock, an unexpected response format, a certificate error or a local network egress problem. If the update succeeds but nodes are unusable, investigate field completeness, core support and server status instead. The two problems appear in different logs and require different sequences. Confirm the subscription request first, check the number of parsed nodes next, and only then test an individual connection.

Automatic update intervals should not be set too short. Frequent fetching increases background wake-ups and may repeatedly overwrite the local list while the server is generating temporary content. Set the interval according to how often nodes change and keep a client backup before major changes. Group names, enabled states, ordering and local notes may belong to the client itself; whether they survive a subscription update depends on the implementation. Do not store important explanations only in node names that may be overwritten.

When managing multiple subscriptions, grouping by source or core requirement is easier to troubleshoot than putting every node in one list. Separate basic-compatible, Xray-extension and V2Fly nodes, then reduce list noise with include or exclude keywords. For grouping methods, see Subscription groups and server keyword filtering. For format differences, continue with base64, native JSON and share links compared.

If a subscription contains extensions that v2rayN recognizes but another client does not, do not force the original subscription to serve as a universal format. Producing a clear, complete subscription for the target client—or choosing a basic combination supported by both—usually costs less to maintain. For the roles of inbounds, outbounds and routing in configuration JSON, read A section-by-section guide to configuration files.

07 / CLIENT WORKFLOW

Choose and verify protocols in the client

Establish a baseline configuration with v2rayN on desktop

Use v2rayN first on desktop. After installation, import the subscription and run one update; do not edit node fields immediately. Choose a node with a clear source, open its editor and record the protocol, address, port, user identifier, transport, security method, server name, flow and extension parameters. Save and connect, then use the client log to confirm that the configuration was generated, the core started and the outbound was established. This creates a baseline configuration for later performance tests and protocol migrations.

Once the node connects, configure the system proxy and routing mode. The system proxy determines whether applications that support it hand requests to the client; the routing mode determines whether traffic entering the core is proxied, sent direct or blocked. Neither is a protocol field. Changing VMess to VLESS does not automatically fix a disabled system proxy, and editing routing rules does not add a REALITY public key. Keeping the layers separate during troubleshooting prevents ineffective changes.

When v2rayN offers several desktop installation forms, choose the appropriate interface version according to the download-page instructions; the node and core selection principles remain the same. System-proxy entry points and permission behavior differ across Windows, macOS and Linux, but the outbound configuration generated by the client follows the same layered model. For LAN sharing, configure the listen address, firewall and port separately; see A guide to allowing LAN connections for the relevant boundaries.

Choose the Android client by core direction

For Xray extension nodes, v2rayNG generally matches the field model better; when the V2Fly core is required, use v2flyNG. After importing a subscription, inspect the node details, especially the VLESS security method, flow, server name, public key and short ID. Mobile interfaces have limited space, so some fields may be under advanced or transport settings. Their absence from the list view does not mean the fields are unavailable.

After the connection is established, the system displays the status of the local connection service. If an app has no traffic, first confirm that the app is included in the current per-app rule, then check routing and DNS. If the connection service repeatedly exits, inspect configuration parsing and core startup messages in the client log. If it fails only after a network change, disconnect and reconnect manually for comparison to determine whether the cause is the link transition, a background restriction or a node handshake problem. Change only one item at a time during protocol migration so the results remain comparable.

Manual nodes are useful for testing, not as a replacement for long-term subscriptions

Creating a node manually is useful for confirming that a set of parameters works. Start with the protocol, then enter the server, port, authentication details, transport and security layer in order. Save it and immediately reopen the editor for a second check. Some clients write defaults into empty fields; reviewing the result can reveal whether those defaults differ from the server requirements. Once testing succeeds, if the node is maintained by a subscription, correct the subscription output rather than keeping manual copies on every device.

When a subscription node is edited locally, the next update may overwrite the change or create a duplicate. For temporary troubleshooting, copy the node to a local group and edit the copy while preserving the original. After identifying the issue, apply the correct fields to the subscription source or server configuration, then delete the temporary copy. This keeps the source, diagnostic and final configurations distinct, so it remains clear weeks later which entry is the current standard.

Read logs by stage

During configuration parsing, look for field types, unknown fields and outbound-build errors. During core startup, check port conflicts, permissions and local listeners. During connection establishment, check DNS resolution, TCP setup, the security handshake and authentication. During routing, check the outbound tag ultimately selected for the request. The last line in a log is not necessarily the root cause; read forward from the beginning of the same connection attempt. Restore the normal log level after diagnosis to avoid recording large amounts of irrelevant data.

For a first setup, follow the V2Ray setup guide to import a subscription, connect a node and verify the result. This checklist is useful when a node will not connect, when migrating between clients or when changing protocols. If the error remains difficult to classify, continue in the Common questions page under installation, configuration and troubleshooting.

08 / SCENARIO GUIDE

Build a selection decision by usage scenario

Stable existing setup: keep it, then build a parallel alternative

If a VMess, Trojan or Shadowsocks node has been stable for a long time, the safest approach is to keep it while testing a new combination separately. Give the new node a distinct name and group so subscription updates do not mix it up with the old one. Test short web connections, sustained transfers, recovery after standby and network changes—not just one successful connection. After a period of comparison, decide whether to make the new node the default.

This approach is especially useful when moving from VMess to VLESS or from a standard TLS combination to REALITY. Migration touches the server, subscription and client, so a staged switch preserves a fallback path. If different clients are used across several devices, validate the setup first in the client that exposes the most complete fields, then test subscription parsing elsewhere. Resolve any missing extension fields before the formal switch.

New Xray setup: prioritize complete combination support

When building a new configuration with Xray capabilities on both sides, VLESS is a candidate for the protocol layer. Choose TLS or REALITY according to the server design and confirm whether a specific flow is required. The basis should not be popularity, but whether the server can maintain it correctly, the subscription can output every field and the client can parse it reliably. With v2rayN on desktop and v2rayNG on Android, the field models are usually easier to keep aligned, but each field still needs verification.

If the same subscription must also serve clients running the V2Fly core, prepare basic-compatible nodes or place core-specific nodes in clearly labeled groups. Do not mistake “VLESS is recognized” for “every VLESS extension combination can run.” Cross-core compatibility depends on narrowing the configuration to the shared field set, not on hoping that clients will ignore unknown fields.

Low-power and mobile use: prioritize connection stability

On mobile, prioritize nodes that reconnect rarely, expose clear fields and update subscriptions reliably. VLESS and Shadowsocks are relatively lightweight at the protocol level, but battery use is also affected by security handshakes, signal quality, routing and application traffic. During testing, observe whether the connection recovers after background standby, whether network changes trigger repeated reconnects and whether the connection service remains active in system battery statistics. If the cause is a background restriction or changing signal, switching protocols usually will not solve it directly.

Automatic update frequency, log level and the scope of the global proxy also affect battery life. When nodes change infrequently, there is no need for frequent updates. Turn off verbose logging after troubleshooting, and send only necessary traffic through the proxy to reduce needless connection activity. Choose between v2rayNG and v2flyNG first according to the node’s core requirement, and only then compare interface preferences.

Multiple clients and team configurations: choose the smallest explainable set

When distributing configurations across multiple devices, desktop systems and Android clients, prioritize combinations with clear field definitions and confirmed support in every target core. Label subscription groups with the protocol, core requirement and purpose; this is easier to maintain than vague names such as “Fast” or “Backup.” Let each platform’s client template manage routing and DNS policy, while the node subscription carries only outbound information to reduce cross-platform conversion complexity.

Configuration documentation should record the protocol, transport, security layer, core requirement and key extension fields without copying complete credentials. Record which fields changed and keep the old node until verification is complete. That way, even if a client changes its parser, structural differences can be located instead of forcing everyone to guess what a node means again.

Use the decision tree to roll back when problems appear

First determine whether the subscription content was retrieved successfully; if not, check the link, device time and response format. Second, determine whether the node fields are complete; if not, inspect subscription generation and conversion. Third, determine whether the core can build the configuration; if not, address unknown fields, incorrect types or unsupported combinations. Fourth, determine whether the security handshake completed; if not, verify the server name, public key, short ID, password and device time. Fifth, determine whether the request was routed correctly; if the connection succeeds but the app does not work, check the system proxy, per-app rules, DNS and outbound tags.

Change only one setting in the relevant layer at each step, and keep the logs and original configuration for comparison. Changing the protocol, transport, security layer and routing all at once makes even a successful result difficult to reproduce. If the issue began after a subscription update, copy the old node for comparison. If it began after changing cores, use the simplest node to verify that the core runs. If it occurs only on one platform, compare the fields generated by the client and the way the system is intercepted rather than immediately blaming the server.

After choosing a setup, visit the v2rayN, v2rayNG and v2flyNG download page to select the package for your platform, then use the configuration guide to establish a connection. For subscription, core startup, system-proxy or routing issues, use this chapter’s decision tree together with the troubleshooting categories to locate the problem layer by layer; this is usually more effective than repeatedly switching node types.