V2Ray Protocol and Core Selection Guide

A node in a client is usually a combination of several parameter layers, not a single protocol. For example, a typical VLESS node may use TCP for the underlying connection, TLS or REALITY for security, and WebSocket, gRPC, HTTP Upgrade, or XHTTP for transport. Node lists often show only the region, protocol abbreviation, and route label, while the full parameters remain in the subscription. So VLESS and VLESS + TCP + REALITY are not the same level of description, and two nodes labeled VMess do not necessarily share identical connection characteristics.

Use this order: confirm the core first, then identify the application-layer protocol, transport method, security layer, and finally connection parameters such as the address, port, user ID, and server name. The core determines whether the client can recognize a feature; the protocol defines authentication and data framing; the transport carries the data; the security layer handles encrypted handshakes and server identity; and the specific parameters determine whether the service can be reached. A mismatch at any layer can appear as a timeout, handshake failure, startup error, or missing fields after import.

Five common terms, five different layers

VMess, VLESS, Trojan, and Shadowsocks usually appear as a node’s main protocol. REALITY is closer to a transport-security capability provided by Xray and is commonly combined with VLESS, TCP, and flow-control settings. Treating REALITY as a peer protocol to VLESS can hide important selection criteria. A client may recognize VLESS without supporting the REALITY parameters in a subscription. Conversely, a node named REALITY still requires checking its main protocol, transport, server name, and other fields.

Rule out incompatibility before comparing performance

Availability comes first. If a subscription depends on Xray extensions while the client is running V2Fly, comparing latency or throughput is pointless. Confirm that the core can read the configuration completely, then use a real connection test to judge route quality. Latency measures one test from the local device to the server; it is not download speed. Results can vary widely with the network path, server load, and transport combination. A protocol name can suggest technical characteristics, but it cannot replace testing the actual route.

The second principle is to avoid unnecessary layers. When two nodes offer similar route quality, prefer the combination the client supports natively, with fewer parameters and no extra conversion. Each additional transport layer adds headers, state management, and troubleshooting points, though the impact depends on packet size, connection count, and device performance. Fewer layers do not guarantee higher speed, and more fields do not automatically mean more capability. Choose the shortest path that matches the current core, device, and server configuration.

The third principle is to keep a fallback. If a subscription offers VLESS, Trojan, VMess, or Shadowsocks nodes, start with the type that best matches the current core and retain a simpler node for comparison. When a connection fails, cross-test nodes in the same region and route but with different protocols to separate route, protocol-parameter, and client-core issues. For a refresher on importing, updating, and switching nodes, return to the v2rayN configuration tutorial; to choose another installer, open the Download Center and select your platform.

The differences between protocols begin with their design goals. VMess is one of the core protocols developed in the earlier Project V ecosystem, combining user authentication, time validation, data encryption, and transport coordination in one structure. Its strengths are a mature ecosystem, broad coverage in older subscriptions, and solid baseline support in both V2Fly and Xray. In return, the protocol handles more responsibilities internally, so configuration must keep the user ID, encryption method, clock accuracy, and client-server parameters aligned. A stable VMess node does not need to be migrated simply because a newer protocol name appears. For new configurations, decide based on server capabilities and the client core.

VMess: a complete mechanism with broad legacy compatibility

VMess authenticates with a user ID and includes time-related validation. If a device clock is significantly off, connections may fail, so time synchronization belongs on the basic checklist when troubleshooting VMess. VMess has also used different encryption and compatibility configurations over time, and subscription parsers usually convert common fields into the client’s internal format. It suits environments that must work with existing servers, subscriptions, or multiple Project V cores. Its limitation is not simply “lower speed”: its processing chain is more complete than VLESS and may involve more computation and framing. On most modern desktop devices, the practical difference is usually smaller than the variation caused by the route.

VLESS: leaving encryption to the security layer

VLESS is designed to be lighter. The main protocol handles identity and data forwarding rather than duplicating a content-encryption mechanism internally. In practice, it is commonly paired with TLS or REALITY. This separation keeps responsibilities clear: VLESS manages connection identity, the security layer handles handshakes and encryption, and the transport carries the data. It also makes a complete combination essential. An address, port, and user ID alone may not be enough; missing server names, flow settings, transport types, paths, public keys, or short IDs can prevent a connection.

VLESS is often associated with the Xray ecosystem, but basic VLESS support is not limited to one client. The important question is which extensions are present. If a node includes REALITY, Vision flow control, or newer transport fields, use an Xray core that explicitly supports them. A standard VLESS + TLS combination generally has broader compatibility. Do not stop at the word VLESS: open the node details and check values such as flow, security, network, and serverName.

Trojan: built around a TLS connection

Trojan relies on TLS for its connection structure and uses a password for authentication. Its configuration is straightforward, with common fields including the server address, port, password, server name, and certificate-related options. Because TLS is essential to the combination, an incorrect server name, inaccurate device clock, or changed server certificate configuration can directly affect the handshake. If the client offers an “allow insecure” option, do not treat it as a routine fix. First verify the server name and server-provided parameters, and keep the authentication chain aligned with the server.

Trojan’s operating cost mainly comes from standard TLS processing and the network path, not from complex internal protocol encryption. It fits servers configured specifically for Trojan, complete subscription fields, and clients with stable core support. VLESS + TLS may also use TLS, but its authentication structure and field semantics differ; changing only the protocol name in a dropdown does not convert one into the other. Migration requires the server to provide the corresponding entry point and the client to import the complete parameters again.

Shadowsocks: a streamlined structure with strict cipher matching

Shadowsocks, often shortened to SS, focuses on a compact encrypted-proxy design. Its core settings are usually the server, port, password, and encryption method. The field list is short, but the encryption method must match exactly; a mismatch prevents connection. Modern implementations may support different sets of encryption methods, so an older client recognizing an SS link does not guarantee that it can run the specified method. If import succeeds but startup fails, check the core log for an unsupported cipher or method, then decide whether to update the client, switch cores, or use another node from the subscription.

These four protocols have no fixed ranking outside their environment. When an existing VMess service is stable, compatibility itself is valuable. If a subscription provides complete VLESS + REALITY parameters and the client uses Xray, test that combination first. Trojan suits servers configured for its structure, while Shadowsocks is a compact option with clear fields and broad implementations. The real criteria are what the server provides, what the current core can implement completely, route stability, and the device’s connection and battery budget.

Once the main protocol is identified, examine transport and security. Many connection failures come not from the protocol itself but from an incorrectly imported path, service name, server name, fingerprint, or flow setting. In a client, “transport protocol” usually refers to carriers such as TCP, WebSocket, gRPC, HTTP Upgrade, and XHTTP; transport security commonly means TLS or REALITY. These fields can be combined, but not every combination is valid. Each one must match the entry point exposed by the server.

TCP and additional transport layers

A direct TCP connection is easiest to understand: the main protocol runs directly over TCP, usually with few extra fields. Fewer fields shorten troubleshooting, but actual performance still depends on network quality, congestion control, and server configuration. WebSocket adds an HTTP upgrade step and uses parameters such as a path; a one-character path difference can cause failure. gRPC commonly requires a service name and may use long-lived, multiplexed connections, so the service name, mode, and TLS settings must match on both sides. HTTP Upgrade likewise depends on upgrade-request parameters. XHTTP is a newer transport capability; confirm that both the current Xray core and subscription parser recognize its fields before using it.

Do not assume a transport is slower simply because it adds more framing. With short connections, small packets, and frequent requests, handshake count and connection reuse can magnify the difference. For sustained high-volume transfers, bandwidth, packet loss, and congestion usually matter more. Multiplexing is not always better either: it can carry several logical connections over fewer underlying connections, but blocking on an unstable connection may affect multiple requests at once. When the defaults work, keep them first and adjust only after reviewing logs and real application behavior.

What TLS needs

A TLS combination usually requires at least a server name. The connection address may be a domain or network address, but the server name used during the handshake must match the server-provided value. The client fingerprint describes handshake characteristics and should follow the subscription value or a compatible default; do not switch it randomly without understanding the server configuration. ALPN and allowInsecure also have specific meanings: ALPN participates in application-protocol negotiation, while skipping certificate checks changes identity verification and is not a suitable long-term response to ordinary network failures.

REALITY is a security combination, not a drop-in replacement

REALITY is usually implemented by the Xray core and appears together with VLESS, TCP, Vision, and related capabilities. Common client fields include the server name, public key, short ID, fingerprint, and flow. The public key comes from the server configuration, the short ID must be one the server allows, and the server name must satisfy the server’s settings. An empty field, a value truncated by a subscription converter, or an extra character introduced during copying can cause a handshake failure. When a REALITY node cannot connect, expand its details and verify these values before checking core logs; do not blindly switch among TCP, WebSocket, and TLS.

Check combination fields in a share link

Common share links put the protocol at the start of the URI, main parameters in the host section, and transport and security fields in query parameters. Subscription tools may differ in field names, capitalization, and encoding. After import, verify the values on the client’s node-editing screen instead of checking only whether the node appears in the list. The example below shows structure only and contains no connection details; its values illustrate how the fields relate:

vless://[email protected]:443?type=tcp&security=reality&flow=xtls-rprx-vision&sni=example.invalid&fp=chrome&pbk=PUBLIC_KEY&sid=SHORT_ID#VLESS-REALITY

In this structure, vless is the main protocol, type=tcp specifies the transport, security=reality selects the security layer, and flow defines flow control. sni, fp, pbk, and sid correspond to the server name, fingerprint, public key, and short ID. Keeping only the address, port, and user ID produces a node that looks complete but cannot complete the handshake. If these fields disappear after conversion, re-import the original subscription or use a format that preserves them.

Check a combination in three steps. First, see whether the core can load the configuration; an unknown-field error at startup usually indicates a core or format compatibility issue. Second, check whether a network connection can be established; an immediate timeout points to the address, port, or local network. Third, inspect handshake logs; errors involving the server name, public key, authentication, or service name require checking the security and transport fields one by one. This layered approach is faster than repeatedly changing node names and shows whether to update the client, switch cores, or obtain the subscription again.

Evaluate protocol performance across connection setup time, sustained throughput, CPU use, memory use, connection stability, and device wakeups. The latency shown by a client usually covers one test and cannot represent large-file download speed or predict battery use. The same VLESS node may perform very differently on a wired desktop connection and a mobile network. Different transports, routes, and server loads can also create larger variations than the protocol itself.

What happens during connection setup

A new connection may involve DNS resolution, TCP establishment, a security handshake, protocol authentication, and an application request. TLS or REALITY adds handshake steps, while connection reuse and session resumption can reduce repeated costs. WebSocket and gRPC add their own setup sequences. When many small requests open in a short period, setup overhead is easier to notice; during sustained transfers, the route, congestion, and packet-loss recovery matter more. At minimum, test first-open speed, repeat-visit speed, and sustained-transfer performance separately.

VMess has a more complete internal processing path and theoretically requires more computation than lightweight VLESS. VLESS keeps the main protocol simpler by moving security responsibilities outward. Trojan concentrates its cost in TLS and forwarding, while Shadowsocks varies with the chosen encryption method and implementation. These differences are easier to observe on low-power devices, with many concurrent connections, or during intensive small-packet traffic. On modern desktop processors and ordinary web browsing, route quality usually remains the dominant factor. A difference of a few milliseconds in one test is not a reliable permanent protocol ranking.

Memory and CPU use depend on the connection model

Memory use does not come from the protocol alone. The client interface, core process, rule sets, DNS cache, routing data, and connection state all consume memory. On desktop systems, v2rayN’s interface and core processes usually perform separate roles; on Android, v2rayNG and v2flyNG also work with system networking services. Enabling TUN, loading large routing data, or maintaining many connections may change usage more than switching protocols. For a fair comparison, keep routing and DNS settings identical and test different protocol nodes on the same route.

CPU use depends on encryption, handshakes, data copying, compression, log level, and connection count. Excessively verbose logging can consume additional resources through continuous writes. A brief CPU increase during a speed test is normal. Pay attention instead to sustained idle usage, continued activity after the app stops making requests, and repeated retries in the core log. When retries continue, battery and CPU drain usually indicate a configuration error or unreachable network rather than protocol inefficiency.

Mobile battery use is driven by wakeups and reconnects

Mobile battery use is often oversimplified as “one protocol is more efficient.” More influential factors include network switching, background keepalives, connection stability, DNS request volume, TUN scope, routing complexity, and retry behavior. A stable long-lived connection often uses fewer resources than repeated timeout-and-reconnect cycles. When a device switches from Wi-Fi to mobile data, existing connections may need to be rebuilt. If the handshake fails and retries rapidly, the system stays awake and battery drain accelerates.

To control battery use in v2rayNG or v2flyNG, start with a stable node and reduce unnecessary full-device capture and frequent speed tests. If only certain apps need the connection, narrow the scope with the client’s per-app or routing controls. When all traffic must enter TUN, check DNS and routing to avoid forwarding loops. At the node level, prefer a combination with stable handshakes and low packet loss over the lowest latency. When protocols offer no required functional difference, stability matters more than small theoretical framing differences.

Use a three-stage judgment: first remove clearly unreachable nodes with a latency test, then check first connection and sustained transfer in real apps, and finally observe idle reconnects and resource use. On desktop, inspect v2rayN logs for connection-failure frequency; on mobile, focus on whether the connection recovers after a network switch and whether timeouts continue. The site’s node selection guide explains latency, multipliers, regions, and protocols in more detail and works well alongside this chapter.

V2Fly and Xray both belong to the Project V technical ecosystem and handle many of the same foundational protocols and routing concepts, but they are not the same program under interchangeable names. Each maintains its own features, configuration fields, and extensions. For VMess, standard VLESS, Trojan, Shadowsocks, routing rules, and DNS, their configuration concepts overlap substantially. For REALITY, Vision, specific transports, and newer extension fields, rely on each core’s actual implementation.

Shared foundations and similar configuration models

Both cores use a configuration model centered on inbounds, outbounds, routing, and DNS. An inbound describes how local applications hand traffic to the core; an outbound describes how the core connects to a target or remote service; routing rules choose the outbound; and DNS controls resolution policy. Clients usually generate the complete configuration from nodes and interface settings, so most users do not need to write everything by hand. These shared concepts help identify whether a problem lies in the node protocol, routing, DNS, or the client’s configuration-generation layer when switching clients or cores.

Identical field names do not mean every value can be copied directly. A field may be an extension in one core, unsupported or ignored in another, or represented differently. A common example is a subscription containing an Xray-specific feature while a converter outputs only generic V2Ray fields. The node imports successfully but loses flow, the REALITY public key, or newer transport parameters. The name and address remain visible, but the fields that determine the handshake are incomplete.

Xray’s feature focus

Xray follows a clear feature path around VLESS extensions, REALITY, Vision, and several transport capabilities. When these terms appear in a subscription, using an Xray core directly reduces intermediate conversion. v2rayN and v2rayNG commonly carry these nodes: v2rayN targets Windows, macOS, and Linux desktops, while v2rayNG targets Android. A client name is not the same as its core name; confirm the actual core in settings, logs, or the about screen.

Using Xray does not mean every node should be changed to VLESS. It can handle multiple protocols, so retaining VMess, Trojan, or Shadowsocks nodes for compatibility and comparison is perfectly reasonable. Core selection chooses a set of capabilities; protocol selection chooses a specific server entry point. They are related but not identical. If the server provides only VMess, an Xray client should still connect using VMess parameters; changing it locally cannot turn it into VLESS.

V2Fly’s feature focus

V2Fly continues Project V’s open configuration model and evolves independently across VMess, basic VLESS support, Trojan, Shadowsocks, routing, and DNS. v2flyNG is an Android alternative built around the V2Fly core, suited to subscriptions made mostly of common protocols when you specifically want the V2Fly implementation. If a subscription clearly includes parameters implemented only on the Xray side, v2flyNG may not load them completely. Use v2rayNG instead, or choose a compatible node supplied by the server.

What to save before switching cores

Before switching cores, record the current client, node name, main protocol, transport, security type, routing mode, and DNS settings. If the client can export configuration, save a copy for comparison and do not immediately overwrite the original subscription after switching. Import a small number of nodes first, confirm basic connectivity, then restore routing and advanced settings such as TUN. This separates core compatibility issues from advanced-setting issues. If every node fails to start, check configuration-loading logs; if only REALITY nodes fail, inspect extension fields; if nodes connect but some domains fail, check DNS and routing.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.invalid"],
        "outboundTag": "direct"
      }
    ]
  }
}

The snippet above shows a routing structure that both core families can understand: when a domain matches a specified rule, traffic is sent to the outbound named direct. It is not a complete configuration; the client still needs to generate the inbound, remote outbound, DNS, and other sections. When editing manually, outboundTag must match an existing outbound tag. Graphical clients usually handle this association automatically. If you are only selecting a protocol and importing a subscription, do not paste this snippet directly into the client.

Core updates mainly provide protocol fixes, compatibility improvements, and runtime enhancements. “Latest” does not mean every old configuration must be rebuilt. After updating a client, keep the original configuration and test it first. Modify nodes only when logs show that an old field is no longer valid or the server has changed its entry point. For installer and client matching, use the Download Center, which lists fixed entry points for v2rayN, v2rayNG, and v2flyNG across four platforms.

A subscription delivers a set of node parameters to the client. It may contain several share links, a structured configuration, or a server-specific format. During import, the client downloads the text, parses each record, and converts it into an internal node model. Compatibility can fail at any stage: the address may be unreachable, encoding may be invalid, a share link may omit fields, the parser may not recognize a new parameter, or the internal model may lack a matching field. “Subscription update succeeded” only means the request completed; it does not prove that every node was parsed completely.

Share links are suited to individual nodes

VMess, VLESS, Trojan, and Shadowsocks all have common share-link formats. A link usually encodes authentication, server, port, transport, and security parameters in one line. This makes copying and importing easy, but protocol extensions add fields and parsers may adopt new fields at different speeds. In a VLESS + REALITY combination, the public key, short ID, fingerprint, server name, and flow must all be preserved. If a converter understands only early VLESS fields, the imported result may degrade into an ordinary node without the required security parameters.

VMess share data often uses encoded JSON and may include the address, port, user ID, network type, host, path, and TLS settings. Generators do not always handle abbreviations and defaults identically. Trojan and Shadowsocks links are more direct, but passwords, encryption methods, and server names still require correct encoding. Special characters in a link must be URI-encoded. Omitting trailing query parameters or copying a line break into a field can also cause parsing errors.

A full configuration and a client subscription serve different purposes

A complete core configuration usually includes global inbounds, outbounds, routing, DNS, and logging, and is intended to drive the core directly. A client subscription mainly describes remote nodes; the client combines them with local system-proxy, TUN, port, and routing settings to generate the final configuration. Importing a full configuration as an ordinary node subscription may not preserve its global rules, while using a node share link as a full configuration leaves out local inbounds and routing. Confirm the file’s purpose rather than relying on its extension.

v2rayN subscription groups are useful for managing multiple remote nodes, and the node editor can verify protocol, transport, and security fields after import. v2rayNG and v2flyNG can also import subscriptions, but they follow different core paths. A generic VMess or Shadowsocks node usually migrates easily; a VLESS node with Xray extensions should be verified first in v2rayNG. Do not delete key fields just to make a subscription “importable everywhere”—broader compatibility is meaningless if the node loses its correct configuration.

What subscription conversion can change

Subscription converters are often used to standardize names, filter nodes, or output another client format. Conversion may rewrite node names, remove unknown query parameters, map transport names, set a default fingerprint, or omit empty values. These changes may not matter for common protocols, but deleting an extension field changes the connection semantics. When using converted output, compare one node with the original parameters, focusing on protocol, network, security, flow, serverName, publicKey, shortId, path, and serviceName.

A safe order for updating subscriptions

Before updating, record the currently working nodes and routing mode. After updating, review additions, removals, and protocol changes before overwriting manual settings in bulk. Choose one clearly structured node to test core startup, then test a real connection, and only afterward restore automatic selection, load balancing, or TUN. If the new subscription breaks every node, compare it with the old group. Problems during download point to the address; problems during parsing point to the format; problems during the handshake point to protocol parameters.

A subscription address is a configuration credential. Keep it on controlled devices and in trusted clients; do not paste it into public pages or screenshots. When moving to another device, add the original subscription again in the new client, then verify the group and routing instead of relying on a single-node text copied multiple times. For parsing errors, see V2Ray runtime log guide and distinguish stages using rejected, timeout, DNS, and field errors.

Protocol selection ultimately happens in the client interface. This site covers three clients: use v2rayN on desktop, v2rayNG on Android by default, and v2flyNG when you need the V2Fly core. All three manage nodes graphically, but their field layouts and visible options differ. After importing a subscription, first confirm that the current core can load the node, then decide whether manual editing is needed. Manual edits are for correcting known fields, not guessing information the server never supplied.

v2rayN: the main desktop entry point

v2rayN supports Windows, macOS, and Linux and is suited to multiple subscriptions, desktop system proxy, TUN, routing, and different cores. After choosing Edit for a node, you can usually inspect its address, port, user ID or password, transport protocol, transport security, and server name. A VLESS node using REALITY also requires checking flow, public key, short ID, and fingerprint. Interface versions may group fields differently, but their meaning does not change with their position.

v2rayN is the desktop first choice because it brings node management, core execution, and system-proxy controls into one interface and supports the protocols covered here. After selecting a node, run a real connection test before enabling the system proxy or TUN. If the node test fails, do not keep changing proxy modes: the system proxy only determines how application traffic enters the client and cannot repair remote handshake parameters. If logs show configuration-loading failure, check the protocol and core first. If the connection is established but apps still cannot access the network, check the system proxy, routing, and DNS.

v2rayNG: the Xray choice on Android

v2rayNG suits Android configurations that need Xray protocol extensions. After importing a subscription, open the node details and verify protocol, transport, TLS or REALITY fields. When connecting, the client uses the system network interface to capture the selected traffic. If only certain apps need the connection, use per-app settings to limit the scope. With full-device capture, pay attention to DNS, routing, and battery use. Test REALITY and Vision combinations in v2rayNG first, provided the subscription fields are complete.

Mobile networks frequently change addresses and links, so a node that works on Wi-Fi but briefly disconnects after a handoff is not necessarily incompatible. Stop and reconnect first, then check whether the log shows a new session. If timeouts continue, try a stable node from the same subscription. Do not run frequent speed tests continuously in the background; they actively create connections and consume resources. Keeping one stable node and one backup using a different protocol makes the failure scope easier to identify.

v2flyNG: the V2Fly core alternative

v2flyNG works much like other Android graphical clients, but it uses the V2Fly core. When a subscription mainly contains VMess, standard VLESS, Trojan, or Shadowsocks, it can verify behavior under the V2Fly implementation. A node with REALITY, Vision, or another Xray extension may import successfully but fail at runtime. That is a capability boundary, not a reason to delete fields. Switch to v2rayNG or choose a common-protocol node supplied by the subscription.

How to read interface fields consistently

The address and port identify the connection target. The user ID authenticates VMess or VLESS. Passwords are common with Trojan and Shadowsocks. The encryption method is mainly used by Shadowsocks. The transport type selects carriers such as TCP, WebSocket, and gRPC. Host, path, and serviceName belong to the relevant transport. security selects TLS or REALITY; serverName is used during the security handshake; flow appears in certain VLESS combinations. When translations differ between clients, match fields by function rather than screen position.

Change one field at a time and duplicate the node as a backup before editing. If you change the address, transport, and security layer together, a failed test cannot show which change caused the problem. Subscription nodes are normally maintained by the server and manual edits may be overwritten at the next update. For a persistent local adjustment, duplicate the node and mark it with a new name. Leave the original subscription node untouched for future comparison.

After choosing a client, follow the main steps in the tutorial to import a subscription, choose a node, start the connection, and verify it. To confirm the installer for your system and processor, open the V2Ray client download page. The download FAQ at the bottom covers installer selection, system requirements, and upgrades; this page focuses on protocol and core decisions.

After separating the layers, selection becomes a fixed process: identify the device and client, confirm the core, inspect the protocol combinations actually provided by the subscription, remove nodes with missing fields or unsupported capabilities, and test the remaining nodes for stability. Newer is not automatically better, and fewer fields are not automatically preferable. The best node must satisfy five conditions: the server provides it, the client parses it completely, the core can run it, the route is stable, and resource use fits the device.

Everyday desktop use

On Windows, macOS, or Linux, start with v2rayN. If the subscription provides complete VLESS + REALITY fields, test it first with the Xray core; if existing VMess, Trojan, or Shadowsocks nodes have been stable, keep them. Desktop systems generally have more CPU and memory, so minor computational differences between protocols should not be the first concern. Prioritize connection stability, route quality, application compatibility, and routing needs. When TUN must capture all traffic, also check permissions, DNS, and routing instead of attributing TUN problems to the remote protocol.

Everyday Android use

When an Android subscription includes REALITY, Vision, or other Xray extensions, choose v2rayNG. If it mainly contains common VMess, Trojan, Shadowsocks, or standard VLESS and you want the V2Fly core, choose v2flyNG. On mobile, prioritize stable connections and predictable reconnect behavior. A lowest-latency node that disconnects often may deliver worse battery life and user experience than a slightly slower but stable node. Keep two nodes using different protocols for quick cross-testing after network changes.

Migrating an old configuration to a new client

During migration, re-import the original subscription instead of copying nodes field by field. After import, check the node count, protocol, transport, and security fields, then test one standard node and one node with extensions. Once remote connectivity is confirmed, migrate routing, DNS, system proxy, and TUN settings. If the old client used V2Fly and the new one uses Xray, common protocols usually migrate easily, but still check default values. In the opposite direction, rule out REALITY, Vision, and newer transport capabilities first.

Do not think of protocol migration as changing a type inside the client. Changing a VMess dropdown to VLESS does not create a corresponding server entry point; changing TLS to REALITY also leaves out the server’s public key and short ID. A genuine migration requires the server to provide a new node or update the subscription. The client’s job is to receive the complete parameters, select the matching core, and verify the connection.

Choose the troubleshooting path from the logs

If the configuration will not start, first suspect field structure, core support, and local ports. If the connection fails immediately, check the address, port, authentication values, and security fields. For long timeouts, check reachability, server status, and the route. If only certain domains fail, inspect DNS and routing. If the browser works but other apps do not, check system-proxy scope or TUN. If mobile connectivity breaks after a network switch, reconnect first and then see whether failures continue.

A five-minute selection checklist

1. Choose the client: use v2rayN on desktop; on Android, choose v2rayNG or v2flyNG based on whether you need Xray or V2Fly.
2. Open node details: record the main protocol, transport, security layer, and key extension fields.
3. Rule out capability conflicts: route REALITY, Vision, and newer transport fields to an Xray core that explicitly supports them.
4. Test a real connection: verify that the configuration loads, then check the handshake and finally test real apps and sustained transfers.
5. Watch device costs: on mobile, monitor reconnects, battery use, and network changes; on desktop, check routing, DNS, and TUN.
6. Keep a fallback node: retain at least one verified, connectable node with clear parameters and a different protocol.

For more detail, read the node selection guide for latency and region decisions, the domain, ip, and geosite rules guide for routing syntax, and the runtime error guide for failures. If these concepts are new, start with Ten V2Ray questions for beginners, then return here to review the relevant sections.

Protocol selection does not require configuring every advanced option at once. Establish a stable connection with the original subscription parameters, then add the system proxy, routing, DNS, and TUN one at a time. Verify after each change and roll back the latest change when something breaks. This keeps the remote protocol, client core, and local network settings separate instead of stacking variables. To get an installer again, open the Download Center; to repeat the process from import through verification, return to the configuration tutorial.