V2Ray protocols and core technology guide

1. Build a protocol selection framework first

Protocols, transport, and security are separate layers

Client node names often combine terms such as VLESS, TCP, WebSocket, TLS, and REALITY, which can make them seem like competing protocols. In practice, these terms usually belong to different layers. VMess, VLESS, Trojan, and Shadowsocks mainly define how the client and server identify users, encapsulate data, and establish proxy sessions. TCP, WebSocket, and gRPC describe how data is carried. TLS and REALITY handle connection security and handshake characteristics. A complete node is usually a combination of several layers, not a choice of one name from a single list.

For example, “VLESS + TCP + REALITY” means VLESS is used at the application layer, TCP carries the traffic, and REALITY-related handshake parameters handle the security layer. “VMess + WebSocket + TLS” is another combination. Compare nodes layer by layer: first check whether the client core supports the protocol, then verify that the transport and security methods can be enabled together, and finally confirm fields such as the address, port, user ID, server name, and public key. Looking only at the first word in a node name cannot tell you whether the full configuration fits the device.

Compatibility comes before theoretical performance

The first rule of protocol selection is not to find the fastest option in the abstract, but to ensure that the server, subscription converter, client core, and graphical interface can represent the same configuration completely. Even a streamlined combination can fail if the client ignores one critical field, resulting in a failed handshake, no traffic after connection, or a node that loses data during import. Confirm the protocol support matrix first, then compare speed, throughput, and resource use.

For desktop systems, v2rayN is the first choice because it provides relatively complete graphical configuration on Windows, macOS, and Linux, and can handle common Xray protocol fields. On Android, v2rayNG uses the Xray core and suits configurations that require VLESS, REALITY, and similar capabilities. v2flyNG uses the v2fly core and is better suited to environments centered on VMess, Shadowsocks, and V2Fly-compatible configurations. The two Android clients look similar, but their underlying protocol capabilities should not be assumed to be identical.

Protocol names do not determine node quality

Real-world connection quality also depends on server load, route quality, outbound bandwidth, distance, DNS resolution, the system network stack, and server-side parameters. Two nodes using the same protocol can perform very differently, while nodes using different protocols can produce opposite results because of their routes. A protocol defines encapsulation and capability boundaries; it does not directly represent a node’s bandwidth, stability, or availability.

A sensible workflow is to filter out combinations that cannot be imported completely, then compare real connection latency, page response, and sustained download performance on the same device and network within a similar time window. ICMP Ping, TCP real-connection latency, and download speed tests measure different stages of the path and cannot simply be ranked by the smallest number. For the differences between these tests, continue with Ping, real connection latency, and download speed tests.

2. VMess and VLESS: from full sessions to streamlined authentication

VMess background and session characteristics

VMess is one of the representative protocols from the early Project V ecosystem. It incorporates user identification, time-based validation, session establishment, and data encapsulation into its protocol design, allowing clients and servers to authenticate and communicate through a consistent structure. In early V2Ray configurations, VMess handled many responsibilities, so it remains common in older subscriptions, long-maintained servers, and the V2Fly ecosystem. Its main advantage is broad historical compatibility: many subscription generators and graphical clients can recognize its basic fields.

A VMess configuration typically includes the server address, port, user ID, encryption or security fields, transport method, and outer options such as TLS. The user ID must match the server, and the device clock should be correct because clock skew can affect authentication. When troubleshooting a failed VMess connection, check more than the address and port: verify the device time, user ID, transport path, Host field, TLS server name, and subscription validity. Re-running a speed test without checking these fields usually cannot identify a configuration-layer error.

Because VMess handles more session logic internally, its protocol processing is somewhat more complex than VLESS. On ordinary desktop devices, however, this difference is usually smaller than fluctuations caused by network quality. Only on low-power Android devices, with many concurrent connections, or during sustained high-volume transfers is the extra encapsulation more likely to appear in CPU wakeups, memory allocation, and battery use. Even then, transport choice and application behavior may have a larger effect than the protocol itself.

Why VLESS uses a streamlined design

VLESS focuses on reducing the encryption and state responsibilities handled inside the protocol, leaving more of the security work to outer mechanisms such as TLS and REALITY. It retains the user ID and essential proxy-session fields without duplicating a complete data-encryption layer. This shortens the processing path and clarifies the roles of the security and transport layers. VLESS should not be interpreted as automatically secure without an appropriate security configuration: the security of a node depends on the complete combination, not the VLESS name alone.

This layered design also explains why VLESS nodes commonly appear with TLS or REALITY. During import, the client must retain the complete combination of fields, including the server name, fingerprint option, public key, short ID, and flow-control parameters. Some fields are valid only with specific transport, security, and core implementations; copying them into another combination can prevent the handshake from completing. Flow-control fields are not universal speed switches and should be enabled only when the server and client use the same mode.

From a user’s perspective, VLESS is valuable not because it has fewer interface options, but because its responsibilities are clearer and it combines more cleanly with modern transport and security mechanisms. For a new configuration, if the server explicitly provides VLESS and the current client can recognize every field, it is usually worth testing first. If an existing VMess node is stable and its subscription updates normally, there is no need to migrate merely because the protocol name is older. A complete, stable configuration is more reliable than a newer combination with missing fields.

Compatibility and migration boundaries

VMess and VLESS are not interchangeable formats that can be converted by changing a node type dropdown. The server must be configured with the corresponding inbound protocol, and the client’s user ID, transport, and security layers must match it. Changing the protocol prefix in a VMess share link to VLESS, or simply switching the protocol type in a graphical interface, does not automatically create a usable node. Migration must be completed through both the server configuration and the subscription content.

The subscription conversion stage can also map old fields to new ones. For example, security fields, camouflage types, or path expressions in historical VMess data may use different names across subscription formats. After import, open the node editor and check each field rather than merely confirming that the node appears in the list. A visible node only proves that the parser recognized the basic record; it does not mean every advanced field was retained.

3. The boundaries between Trojan, Shadowsocks, and REALITY

Trojan: simple authentication, but dependent on complete TLS configuration

Trojan uses a straightforward password-based authentication structure and normally runs over a TLS connection. It delegates secure transport to a mature TLS implementation while handling proxy requests and identity verification itself. Its node fields may look shorter than a complex VMess combination, but whether the connection succeeds still depends on the address, port, password, server name, certificate settings, and transport options. A correct password cannot prevent a connection from stopping during the TLS handshake if the server name is wrong.

Trojan is a good fit when the server has been configured with TLS correctly and the client can pass the server name accurately. Its basic model is easy to understand, and it is widely represented in subscription formats. Keep in mind that implementations may add transports such as WebSocket or gRPC, so a Trojan node is not always just “address, port, and password.” The path, service name, Host, and ALPN fields can all become compatibility requirements. If an imported node exists but cannot connect, compare it field by field with the original subscription.

Trojan’s protocol encapsulation is relatively direct, but the initial TLS handshake still incurs computation and round-trip costs. Once a long-lived connection is established, those costs are spread across subsequent traffic; when short connections are created repeatedly, the number of handshakes has a greater effect on response time and battery use. A single speed test therefore cannot prove that Trojan is faster than VMess or VLESS. Connection reuse and frequent network changes can alter the result as well.

Shadowsocks: lightweight forwarding and method compatibility

Shadowsocks, often abbreviated as SS, is designed for lightweight forwarding. Its core configuration usually consists of a server, port, password, and encryption method. Compared with nodes containing many layered fields, it is easier for different clients and subscription formats to represent, and it suits devices with limited resources. However, fewer fields does not mean compatibility can be ignored: the client and server must support the same encryption method, and older and newer implementations may cover different method lists.

If the encryption method is replaced, left blank, or shown as unsupported after import, re-running a speed test will not normally fix the node. Check whether the current core implements that method and confirm that the subscription converter did not rewrite its name into a different spelling. Plugin-based extensions add more parameters, and those configurations cannot be reduced to the basic SS fields. v2rayN, v2rayNG, and v2flyNG can all handle common SS nodes, but the available methods and extensions still depend on the core running with the client.

SS usually has low protocol-processing overhead and suits everyday use with a modest number of connections and a clear configuration. Actual throughput still depends on the route, encryption method, device processor, and server load. On low-end Android devices, choosing a method supported natively by the core and appropriate for the hardware may matter more than changing the node name. Do not change the encryption method casually in the client; it is part of the agreement with the server.

REALITY is a security-layer combination, not a standalone proxy protocol

REALITY often appears together with VLESS, so it is easy to mistake it for a protocol parallel to VMess or Trojan. More precisely, it handles specific handshake and security-layer logic, while VLESS and similar protocols still manage the proxy session. A REALITY node typically also requires a server name, public key, short ID, fingerprint, and sometimes flow-control parameters. These fields work as a combination; omitting one can prevent the client from completing the handshake.

REALITY-related capabilities are primarily provided by the Xray core, so v2rayNG and v2rayN configurations running with Xray are better suited to these nodes. v2flyNG, which uses the v2fly core, should not be assumed to support the same fields. Even when a subscription parser can read the node title, it may discard fields the core does not recognize when saving the node. Check whether the node editor provides the corresponding security method and parameters instead of merely looking for the word “REALITY” in the list.

The server name and target address must not be confused. The node address determines where the client establishes the network connection, while the server name participates in the handshake; they may appear as separate fields. A public key is not a user ID, and a short ID is not an extra part of the port. Preserve field positions when copying a configuration rather than combining them into the address or remark. The fingerprint must use a value supported by the server configuration; the client default is not interchangeable across all nodes.

4. Comparing connection speed, throughput, and resource use

Connection speed has several stages

The perceived “loading speed” usually includes DNS resolution, network round trips to the server, TCP connection setup, security handshake, protocol authentication, the server’s connection to the target, and time to first byte. VMess, VLESS, Trojan, and SS processing accounts for only one part of this chain. When a node is far away or the route is congested, saving a small amount of encapsulation work will not significantly change overall response time. When route conditions are similar, handshake behavior and connection reuse are more likely to show a difference.

A client latency test may not cover every stage. A normal Ping may measure only the network round trip to an address; real connection latency usually establishes a proxy connection; and download testing is also affected by outbound bandwidth, the test target, and sustained transfer capacity. It is therefore not contradictory to see low Ping with ordinary page response, or higher real-connection latency with stable downloads. Choose metrics by purpose: browsing favors initial connection and response time, sustained transfers favor stable throughput, and real-time applications care more about jitter and packet loss.

Control variables when comparing protocols. Use the same client, device, network, approximate region, and server load, and run multiple tests within a short period to reduce random variation. If two nodes change protocol, server region, and transport at the same time, the result cannot be attributed to the protocol. Selection does not require laboratory precision, but it should avoid mistaking route differences for an inherent advantage of VLESS or Trojan.

Transport encapsulation may affect throughput more than the application protocol

Direct TCP transport is usually straightforward. WebSocket adds frame encapsulation and depends on an HTTP upgrade flow. gRPC is built on HTTP/2 and has its own stream and connection-management behavior. Transport methods make different trade-offs in server deployment, connection reuse, header overhead, and compatibility with intermediate network devices. For sustained large-file transfers, a small amount of header overhead is rarely the only bottleneck; for many short requests, handshake and reuse strategies may matter more.

Transport also affects memory and CPU load. As the number of connections grows, each connection consumes buffers, protocol state, and encryption context. WebSocket and gRPC are not necessarily slower, but their implementation paths are longer than simple TCP and depend more on the quality of the client and server implementations. On resource-constrained devices, removing unnecessary layers is often the easier way to achieve stable performance.

UDP workloads need separate evaluation. Some protocol and transport combinations can forward UDP, but the traffic may be handled as native datagrams or carried through another connection. Games, voice calls, and DNS queries are sensitive to packet loss, jitter, and head-of-line blocking, so TCP download speed alone cannot predict UDP performance. Enabling TUN mode also changes how system traffic enters the client, adding routing rules, DNS policy, and core processing to the measurement.

Evaluate resource use over a stable interval, not at startup

When a core starts, it reads the configuration, creates routing rules, and initializes DNS, logging, and connection-management modules. Brief CPU usage at this point is not representative. A more useful method is to observe a stable interval with the same configuration and similar application activity, recording idle, web browsing, and sustained transfer states separately. Memory use should likewise distinguish resident memory, connection buffers, and system cache; a single snapshot says little about protocol efficiency.

Log level affects resource use. Detailed logs help diagnose handshakes, DNS, and routing during troubleshooting, but keeping them enabled permanently creates more writing and formatting work. For everyday use, choose a restrained level such as warning or error, raise it temporarily when investigating, and restore it after the issue is confirmed. With a large node list, batch testing and subscription updates also create short-lived peaks, which differ from the stable usage of the active connection protocol.

5. Android battery use and background connections

Battery drain comes from sustained wakeups, not just encryption

When v2rayNG or v2flyNG runs on Android, battery use comes from several sources: the core processes data, a virtual network interface forwards traffic, the app maintains a foreground service, the system switches networks, DNS queries run, logs are written, and background requests from other apps wake the processor and wireless hardware. Protocol encryption is only one factor. Even when a node shows as connected, battery behavior is very different with no application traffic than during continuous video, file synchronization, or heavy notifications.

Cellular and wireless LAN connections also have different power characteristics. With a weak signal, the wireless module may transmit at higher power and repeatedly rebuild connections as network conditions change. Frequent handshakes become more costly in this situation. While moving between locations, address changes, sleep-and-wake cycles, and broken connections can all cause the client to rebuild its channel. A protocol combination that is stable on a fixed wireless network may not use the same amount of power during frequent network changes.

Long-lived connections usually reduce repeated handshakes, but they rely on heartbeats or system keepalive mechanisms. Heartbeats that are too frequent increase wakeups; intervals that are too long may let network devices remove the connection, triggering a reconnect. Most users do not need to adjust low-level heartbeat settings manually. A more practical approach is to choose a stable node, avoid frequent switching, skip background batch tests, and let the client use the core- and system-recommended connection defaults.

Relative battery impact of protocols and transports

Under comparable route conditions, combinations with shorter processing paths and fewer reconnects generally help control battery use. VLESS delegates security to outer mechanisms, and SS also has a lightweight basic structure, but total battery drain still depends on TLS or REALITY handshakes, transport encapsulation, application connection count, and network stability. VMess having more complete session processing does not mean it will clearly use more power on every device. If a VMess node is stable while a lighter protocol keeps reconnecting, VMess may actually use less battery.

WebSocket and gRPC each add protocol processing and connection management. On modern devices, the difference under normal traffic may be small; on low-performance devices, with many concurrent short connections, or during long background sessions, the extra encapsulation is more likely to become noticeable. TUN mode also sends more system traffic through the client, including requests from apps that would not normally use a manual proxy port. If battery use rises after enabling TUN, first check whether background apps are continuously connecting before blaming the protocol.

DNS configuration matters as well. Failed resolution, unreachable results, or rules that trigger duplicate queries can cause the client and applications to retry repeatedly. The client may appear constantly active even though DNS or routing rules are the real cause. During troubleshooting, temporarily simplify complex rules, use a stable node, and check which apps continuously generate traffic in the system battery view. Do not draw conclusions from the client’s percentage alone, because the system may attribute more forwarding activity to the virtual network service.

Build a repeatable battery comparison

When comparing v2rayNG with v2flyNG, or comparing two protocols, keep screen brightness, network type, background apps, and test duration as consistent as possible. Begin with a stable charge state, disable batch updates and speed tests, and observe standby, light browsing, and sustained transfer separately. Battery percentage changes over only a few minutes are imprecise, so combine the system battery curve with foreground activity and device temperature.

If a node frequently disconnects after the screen locks, first check Android’s background-run restrictions, foreground service status, and network changes. Then inspect the client log for repeated connection timeouts, DNS errors, or handshake failures. If failures cluster after network recovery, the issue may be connection rebuilding; if they continue on a fixed network, verify the node fields and server availability. General troubleshooting steps are available in Frequently Asked Questions.

Everyday optimization starts by reducing wasted work: update subscriptions only when needed instead of running continuous tests; group or filter an oversized node list; restore the normal log level after troubleshooting; enable TUN only when full-device routing is actually required; and choose nodes with few reconnects and stable real-connection results. A protocol name is not a battery switch; a stable route and reasonable traffic volume usually matter more.

6. V2Fly and Xray core families and configuration compatibility

The Project V ecosystem and its two core directions

Project V is an open-source ecosystem built from proxy protocols, core programs, configuration systems, and client tools. The term V2Ray sometimes refers to the broader technology ecosystem and sometimes to a specific core implementation, so compatibility discussions should clarify whether they concern a protocol, configuration format, or concrete core. V2Fly continues V2Ray’s community-maintained direction with an emphasis on established protocols and configuration ecosystems. Xray extends a similar configuration model with additional capabilities, including VLESS and REALITY.

The two share a common history and many similar concepts, but they should not be treated as identical programs with different names. Their basic structures for inbounds, outbounds, routing, DNS, and logging overlap substantially, while specific protocol fields, transport options, security settings, and defaults may differ. A configuration being parseable by another core does not mean every item behaves the same way. Conversely, a parse failure does not always mean the entire configuration system is incompatible; it may contain fields specific to the other core.

Graphical clients add another layer of mapping. v2rayN converts interface settings, subscriptions, and system-proxy actions into core configuration; v2rayNG is primarily based on Xray capabilities; v2flyNG corresponds to the v2fly core. Users see nodes and switches in the interface, but actual connection behavior is determined by the generated configuration and underlying core together. During troubleshooting, distinguish among “the subscription did not parse the field,” “the interface provides no option,” and “the core does not support the capability.”

Shared configuration structure and core-specific fields

Both core families typically use JSON configurations organized around logging, inbounds, outbounds, DNS, and routing. The minimal example below creates a local SOCKS inbound and accesses the network directly through a freedom outbound. It is intended to verify the configuration structure, listening port, and core startup process. It contains no remote node and should not replace a client-generated daily configuration.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    }
  ]
}

After installing Xray correctly and saving the content above as config.json, run the following command in a terminal to check whether the configuration starts. If the port is already in use, close the conflicting program or change the listening port first. Normal graphical-client use usually does not require running this command manually.

xray run -config config.json
curl --proxy socks5h://127.0.0.1:10808 https://example.com/

A real VLESS, VMess, Trojan, or SS outbound also adds a server list, user ID, password, encryption method, and flow settings. REALITY-related fields are extensions that require particular care; handing an Xray configuration containing them to an unsupported core may produce an unknown-field error at startup, or an upper-level conversion tool may remove them in advance. For cross-core configurations, do not check only JSON syntax; verify the meaning of each protocol field.

Configuration compatibility is not subscription compatibility

Core configuration files and subscription files solve different problems. A core configuration describes how the program listens, routes, and connects; a subscription mainly carries node records, which the client then turns into a complete core configuration. A client may support a share-link format without allowing import of a complete core JSON file. It may also allow a core configuration import without converting every field into editable nodes. Therefore, “Xray can run it” does not imply that “any subscription client can import it.”

v2rayN is suited to desktop node management, subscription updates, route selection, and system-proxy switching. v2rayNG is better suited to using Xray-related protocols on Android. v2flyNG is an alternative along the V2Fly path. The three clients can sync common configurations through a subscription link or single-node share data, but complex routing, DNS rules, core-specific fields, and client interface preferences usually cannot be exchanged completely. For device-to-device syncing methods, see Subscription links, configuration exports, and QR-code sharing.

Troubleshooting order for core differences

First record the node’s original protocol and every security and transport field. Next confirm which core family the current client is actually using. Then open the node editor and check whether each field exists. Finally inspect the runtime log to determine whether the error occurs during parsing, startup, handshake, or transport. If an imported field has no corresponding control at all, it is usually a client or core capability boundary, not a latency problem. Use a client that supports the configuration rather than guessing and deleting critical fields.

7. Subscription formats, share links, and field compatibility

A subscription is a node container, not a universal configuration standard

A “subscription link” is an entry point for a client to retrieve a set of node data, but the returned content can use different structures. Common cases include multiple share links, encoded text, structured node lists, and client-specific formats. The client must first identify the outer format, then parse each node record, and finally map its fields into a core configuration. Incompatibility at any layer can cause update failures, unexpected node counts, or lost advanced parameters.

VMess share data often contains many structured fields. VLESS, Trojan, and SS are commonly represented as URIs, with query parameters expressing transport and security options. Recognizing a URI does not mean the current client supports every parameter name. REALITY public keys, short IDs, fingerprints, and flow control, along with gRPC service names, WebSocket paths, and Host fields, are especially likely to be lost in older parsers or format conversions.

A node remark is normally display-only and does not participate in the connection. Changing it does not change the protocol, although rules that group nodes automatically by remark may be affected. By contrast, the address, port, user ID, password, encryption method, server name, and security parameters are connection fields and must not be removed just to make the interface look cleaner. When an import behaves unexpectedly, keep the original subscription for comparison and avoid changing several fields at once; otherwise it is difficult to identify which change caused the result.

Successful import and successful connection are separate checks

Nodes appearing after a subscription update only means that the client completed basic parsing. Next verify the node type, confirm that the transport and security methods match, and check that critical fields contain values before running a real connection test. If no nodes import at all, first check whether the subscription address is reachable, whether the response is empty, and whether the wrong subscription type was selected. If only one protocol family is missing, a format or core-capability issue is more likely.

When nodes exist but all connections fail, first look for shared fields such as the same server name, transport method, or core-specific configuration. If only individual nodes fail, check their addresses, ports, and user information. Blaming the subscription address for every failure can hide node-level errors. Conversely, switching nodes repeatedly will not help when the subscription update itself reports an error, because the process has not yet reached the node-connection stage.

Subscription updates also involve overwrite rules. Some clients replace old nodes by subscription group, so manual edits may be restored on the next update. Other scenarios retain local nodes and add new records, creating duplicates. If custom parameters must be kept long term, first understand the client’s update behavior, then decide whether to maintain a separate manual node or modify the subscription source. See the Getting Started guide for the basic v2rayN subscription import steps.

Cross-client syncing means accepting the capability intersection

When syncing from v2rayN to v2rayNG, common node protocols and basic fields can usually stay consistent through the same subscription. Desktop system-proxy settings, route groups, process matching, and interface preferences will not automatically appear on Android. The reverse is also true: Android app-level selections and background-service settings are not part of a node subscription. Subscriptions are suited to maintaining server connection information, not backing up every device setting.

The difference between v2rayNG and v2flyNG mainly comes from their core capabilities. A subscription containing REALITY may be fully recognized by v2rayNG but cannot produce an equivalent configuration in v2flyNG. Do not try to downgrade REALITY fields into ordinary TLS; the two are not interchangeable switches. A better approach is to provide node types supported by each core, or choose an Android client that matches the subscription’s capabilities.

QR-code sharing is usually a visual encoding of a single-node URI, limited by the record length and the client’s parsing capabilities. It is suitable for temporarily passing a small number of nodes, not for replacing long-term subscription updates. A configuration export may include more complete routing and DNS information, but proprietary structures are more likely to be incompatible across clients. Choose the method based on the goal: use a subscription to sync nodes, a QR code to share one node temporarily, and a client-supported export when advanced settings must be preserved; then review each field on the target device.

8. Choose protocols and clients by use case

Everyday desktop use: choose the client first, then a complete node

Use v2rayN first on Windows, macOS, and Linux desktops. It is suited to managing subscriptions, switching the system proxy, editing nodes, and viewing connection logs. If a subscription provides VLESS, VMess, Trojan, and SS, first remove nodes with missing fields or unsupported core capabilities, then run real-connection and actual browsing tests on the rest. For new configurations, VLESS with a clearly defined security layer is worth testing first; stable VMess or Trojan nodes can continue to be used.

Desktop processors and memory are usually sufficient, so small processing differences between protocols are rarely the main issue. Pay more attention to connection stability, server load, transport, and routing. When process-level routing or full-device takeover is needed, TUN mode changes the traffic entry point. Record the current system-proxy and routing settings before enabling it step by step. If only some apps misbehave after TUN is enabled, check DNS and routing before changing protocols.

For large downloads or sustained transfers, choose a node with stable throughput and low jitter rather than chasing the lowest single-test latency. Office browsing and interactive applications care more about initial response, so compare real-connection latency and actual page loading. Nodes using the same protocol still need separate testing because server region and route differences are usually larger than encapsulation differences.

Everyday Android connections: prioritize background stability and core matching

Use v2rayNG on Android when VLESS, REALITY, or other Xray capabilities are required. When the configuration mainly uses VMess, SS, or other V2Fly-compatible protocols, v2flyNG is an option. On devices with limited resources or long background sessions, prioritize combinations with few reconnects, simple fields, and native core support. A theoretically lightweight protocol that repeatedly fails its handshake will not save battery.

When mobile networks change frequently, check whether the node reconnects normally after the network returns. If a particular node works only on wireless LAN or continually fails after switching to cellular data, check address resolution, transport, and server reachability separately. Do not change the protocol, security layer, and DNS settings at the same time. Change one variable per test and record the error stage in the log.

When the device heats up or loses substantial battery during standby, pause batch tests and frequent subscription updates, check background traffic, and then compare protocols. TUN expands the traffic scope and may send more app requests through the core. If only a few apps need connections, use the narrowest app scope supported by the client to reduce unnecessary forwarding at the source.

Older subscriptions and long-term configurations: prioritize stability and migrate as a complete set

Older subscriptions commonly contain VMess and SS. If a node still imports completely and maintains a stable connection, continuing to use it is usually more reliable than manually converting it to VLESS. A protocol migration must be completed across the server, subscription, and client; changing only the local node type is not enough. When planning a migration, retain the original node for comparison, import the new nodes provided by the server, test them separately, and then adjust groups.

If a subscription converter outputs only basic fields, complex WebSocket, gRPC, TLS, or REALITY parameters may be lost. Reduce intermediate conversion steps and let a client that supports the target format read the subscription directly. Organize node remarks, group names, and sorting afterward; keep connection fields unchanged. For further troubleshooting of failed subscription updates, see the FAQ category guide.

Low-resource devices and high-concurrency scenarios

On low-resource Android devices, start by testing SS, VLESS, or an existing stable protocol with a straightforward structure and mature core support, but do not prescribe one answer independently of server conditions. Reduce the total node count, disable continuously verbose logging, and avoid batch tests during large transfers. If memory use rises sharply with connection count, check whether the app is creating many short connections and whether TUN is capturing unnecessary background traffic.

In high-concurrency scenarios, connection reuse, server file descriptors, buffers, and routing-rule complexity may matter more than protocol encapsulation. WebSocket, gRPC, and ordinary TCP manage connections differently and should be tested alongside the server deployment. Results from one user browsing normally cannot be generalized to many concurrent connections. For long-running devices, stable usage, error rate, and reconnect count are more valuable to record than a momentary peak speed.

Final decision table and validation loop

After choosing, establish a simple validation loop: record the client and core family, save the node’s protocol, transport, and security method; run multiple real-connection tests; use real applications to verify response and sustained transfer; observe logs and resource use over a stable interval; and only then decide whether to make it the default node. When problems arise, roll back the most recent change instead of replacing the protocol, client, and network environment simultaneously.

If several nodes perform similarly, choose the one with clearer configuration, reliable subscription updates, and complete support in the current client. No protocol is consistently superior on every platform, network, or server setup. The goal of protocol selection is to reduce compatibility risk and make connection behavior explainable and reproducible, not to chase theoretical rankings detached from the environment.