V2Ray Protocol Guide and Client Selection

Build a decision framework

Separate proxy protocols, transport methods and security layers

A client node is really a combination of layers

When you view a node in v2rayN, v2rayNG or v2flyNG, the interface often puts the protocol, address, port, transport method and security settings into one editing form. Together they define a connection, but each serves a different purpose. VMess, VLESS, Trojan and Shadowsocks mainly describe how the client authenticates, packages application traffic and how the server identifies the connection. Transport options such as TCP, WebSocket and gRPC determine how that data is carried. TLS and REALITY operate at the security and handshake layers. Treating all these names as interchangeable “protocol models” leads to misleading comparisons. For example, VLESS can be combined with TCP, gRPC and other transports, along with different security settings. REALITY is usually not a standalone proxy protocol that works by entering an address alone; it is a security-layer solution used together with inbound and outbound structures such as VLESS.

Read a configuration from the outside in. Start with the server address and port: “where does the connection go?” Next check the transport method: “how does the data get there?” Then review the security layer and handshake parameters: “how is the protected session established?” Finally check the user ID, password or encryption method: “how does the server identify and process this user’s data?” After importing a subscription, the client usually fills in these fields automatically, so they rarely need manual editing. Understanding the layers still helps identify incomplete imports, incorrect protocol choices and mismatched parameters.

The same name does not mean the same combination

Two nodes both labeled VLESS may behave very differently. One might use plain TCP with TLS, while another uses gRPC with REALITY; their handshake steps, connection reuse, certificate requirements and supported cores are different. Conversely, VMess and VLESS have different authentication structures but may use the same underlying TCP or WebSocket transport, making some network behavior quite similar. When comparing speed, looking only at the protocol name often attributes differences in line quality, server load, transport encapsulation and security layers to the protocol itself.

Choosing a protocol does not mean turning on every available option. Each additional encapsulation layer usually adds headers, buffers and state management; removing a layer may sacrifice the handshake capability or compatibility required by the deployment. The right approach is to start with the combinations enabled by the server, then select one the client core can parse completely and the device can handle comfortably. The protocol field in the client must match the server. A VMess node cannot be made into VLESS simply by renaming it, and enabling REALITY while keeping the original TLS parameters is not enough.

Latency, bandwidth and stability are different metrics

A client’s latency test usually measures the time needed to establish a particular probe connection; it does not equal sustained download speed. Bandwidth depends on the server’s egress capacity, network path, congestion control and device performance. Stability requires observing packet loss, reconnections and major speed fluctuations over time. A protocol saving a few milliseconds in one latency test does not prove it is better for long-lived connections, video traffic or many concurrent requests. Choose only after verifying the configuration, then compare on the same device, network and route at a similar time to avoid mistaking environmental changes for protocol differences.

Throughout this guide, “proxy protocol,” “transport method,” “security layer” and “core” refer to four different responsibilities. Once this separation is clear, the dense list of client options becomes a traceable connection chain. When you encounter a new term, first ask which layer it belongs to, what it replaces and what it depends on—not whether it is faster than another name.

Protocol background and boundaries

Design trade-offs among VMess, VLESS, Trojan, Shadowsocks and REALITY

VMess: a complete authentication model with broad legacy compatibility

VMess was one of the earlier protocols in the Project V ecosystem to establish a complete client-server workflow. It uses a user identifier and time-related information for authentication, while encapsulating data at the protocol layer. Its strengths include extensive historical documentation and broad support across the V2Fly and Xray families. Many older subscriptions and existing deployments still rely on VMess. In environments that must retain an existing server and support several older clients, VMess’s compatibility value often outweighs the appeal of minimal encapsulation.

That complete structure also means the client must handle more protocol logic. Authentication may fail when the system clock is significantly inaccurate. When using a transport such as WebSocket, the path, Host and security-layer parameters must also agree. VMess is not a universal format that automatically adapts after import; missing transport fields can still cause a connection failure. For a new deployment without legacy-client requirements, VLESS’s simpler structure is often evaluated as well, but existing VMess nodes do not need to be migrated automatically. Whether a stable configuration should change depends on actual load, maintenance cost and client coverage.

VLESS: separating authentication from encryption

VLESS separates user authentication from transport security. Rather than repeating a separate content-encryption scheme at the protocol layer, it delegates security to outer layers such as TLS and REALITY. This makes the forwarding chain easier to understand and allows the Xray ecosystem to combine different flow-control and security options. VLESS commonly uses a UUID-style user identifier, but the identifier alone does not form a complete node. The transport, security layer, server name and any flow-control option must each match the server configuration.

Separating these responsibilities reduces duplicate processing and lets each layer evolve independently. The trade-off is greater dependence on configuration accuracy. A client interface may offer VLESS as a choice without supporting every extension field carried by a subscription. When a node includes REALITY, a public key, a short ID or a specific flow-control setting, prefer an Xray-family core that can interpret all of those fields. Deleting unfamiliar parameters usually does not create a “compatibility mode”; it breaks the handshake instead.

Trojan: a simple structure centered on password authentication

Trojan authenticates users with a password and is commonly paired with TLS. Its parameter model is relatively straightforward: server, port, password, server name and certificate-related settings make up the main fields. This structure is easy to follow when deploying TLS clearly or moving between clients that support Trojan. It still depends on a valid server certificate, domain and system time. A certificate-name mismatch, incorrect SNI or inaccurate system clock can terminate the TLS handshake before proxy authentication begins.

Trojan and VLESS are not simply a matter of speed. They may use similar network paths and both may run over TLS. The real differences more often come from authentication structure, composable extensions, server implementation and client core. If a provider already supplies a stable Trojan node and the client imports it completely, there is usually no reason to switch protocols merely because the name is different. A protocol cannot be converted by the client alone; changing to another type requires a matching server configuration.

Shadowsocks: lightweight encrypted proxying

Shadowsocks, often abbreviated as SS, uses the server address, port, password and encryption method as its primary parameters. Its structure is lightweight and implementations are widely available, making it suitable for short configuration chains, resource-constrained devices and traditional compatibility needs. The important point is not simply that it is “lightweight,” but that both sides support exactly the same encryption method. Legacy methods and modern AEAD methods differ in compatibility and implementation requirements. An option appearing in the client’s drop-down list does not mean the server uses it.

A Shadowsocks share link usually carries the core parameters, while plugins or additional transport details may use different extension formats. If a subscription converter keeps only the address, port and password, those extra parameters may be lost. After importing, verify the encryption method and plugin fields rather than assuming the configuration is complete because the node name appears. As with VMess and VLESS, performance remains governed by the network path and server implementation; a lightweight protocol structure does not guarantee higher throughput in every environment.

REALITY: a secure handshake solution, not a standalone node type

REALITY is used mainly by the Xray ecosystem to address secure-handshake and identity-validation concerns. In practice, it is commonly configured together with VLESS, so a client list may highlight REALITY even though the underlying proxy protocol still needs to be confirmed separately. Typical parameters include the server name, public key, short ID and optional fingerprint. These are companion values generated by the server and provided to the client. A missing character in the public key or short ID, or an inconsistent server name, can cause the handshake to fail immediately.

REALITY is designed for a specific handshake and deployment model, not as a replacement for every TLS setup. It requires a compatible Xray core and complete subscription fields; a V2Fly core does not gain the same capability automatically just because REALITY appears in the node name. Before choosing it, check which core the client actually uses and whether the subscription includes every parameter. For a deeper look at handshake overhead and the XTLS Vision forwarding path, read the REALITY and XTLS Vision technical guide.

Performance analysis

Comparing connection speed, throughput and forwarding paths

Handshake overhead affects initial connections, not sustained speed alone

When opening a new webpage, the device may first resolve the domain, establish a TCP or other transport connection to the server, complete the security handshake and authenticate through the proxy before sending the actual request. The protocol and security layer affect only parts of this chain. VMess processes its own authentication and encapsulation; VLESS has a simpler protocol structure, but TLS or REALITY still requires its corresponding handshake; Trojan usually relies on TLS; Shadowsocks establishes its data-processing state according to the selected encryption method. Differences in initial connection time are often measured in milliseconds, while route latency becomes more significant as network distance grows.

During sustained transfer, the key questions are how many times each data block is copied, encrypted, encapsulated and buffered. The core implementation, operating-system network stack and transport combination all contribute. Some flow-control options aim to reduce repeated encryption or copying under specific conditions, but they work only when the client, server and outer layers all match. Selecting a flow-control name on the client while the server lacks the same capability normally causes a connection failure; it does not automatically fall back to a plain connection.

The transport method often changes behavior more than the proxy protocol name

Plain TCP has a short encapsulation chain and suits configurations seeking direct forwarding. WebSocket adds frames and path fields; its advantage is compatibility with an appropriate web-service deployment, while the extra encapsulation and intermediary layers can affect throughput and latency. gRPC is built on HTTP/2 and provides stream and connection management, which can organize long-lived connections well on a suitable server, but it requires the correct service name and HTTP/2 support. When comparing nodes, a TCP node and a WebSocket node cannot be compared as though their results were caused by VLESS alone, even if both are labeled VLESS.

Connection reuse also requires careful interpretation. Reuse lets multiple logical requests share fewer underlying connections and can reduce repeated handshakes. If the underlying connection becomes congested or loses packets, several requests may be affected together. Browsers and modern applications already use connection pools or HTTP/2, so adding proxy-layer reuse does not necessarily help continuously. Start with the defaults, test reuse only when many short-lived connections make handshake costs significant, and observe initial page loads, sustained downloads and concurrent tasks separately instead of relying on one latency figure.

Build a repeatable comparison method

A useful test controls its variables. Compare multiple nodes on the same device and network at roughly the same time. To compare protocols, use nodes with the same server location, similar load and the same transport where possible. For each option, observe the initial page load, sustained transfer and recovery after a network change. Latency tests can eliminate unreachable nodes or those with excessive round-trip times, but real applications should make the final call. If results vary widely, repeat the test and check the time of day. Do not change Mux, routing, DNS and protocol settings together, or you will not know which change mattered.

Desktop v2rayN environments typically have more CPU and memory available and can handle more complex rules and concurrency. Android v2rayNG and v2flyNG are also affected by battery policies, background restrictions and network changes. Desktop test results cannot be copied directly to mobile devices. If overall speed drops, check the node, route and local settings in that order; see the layered V2Ray slow-speed troubleshooting checklist for the relevant steps. First determine whether the issue concerns connection setup, sustained throughput or route selection, then decide whether to change the protocol combination.

Device load

Resource use, mobile power consumption and background connections

CPU load comes from the entire data path

The protocol itself accounts for only part of resource use. Encryption algorithms, security handshakes, transport encapsulation, DNS lookups, routing-rule matching, connection logs and the graphical interface all consume CPU and memory. Shadowsocks is often considered lightweight because of its simple structure, but its actual load still depends on the encryption method and whether the implementation uses the device’s hardware capabilities. After reducing duplicate protocol-layer processing, VLESS still requires computation for the outer TLS, REALITY or transport layers. VMess adds another layer of protocol logic, but that does not mean it creates a noticeable bottleneck on modern desktop hardware. Differences are more likely to appear under high throughput, on low-power devices or with many concurrent connections.

Memory use is closely tied to the number of connections, buffer sizes, routing-rule scale and log level. A configuration with many domain rules and multiple outbounds generally needs more memory than a direct single-node setup. Detailed logging records more connection events and may increase write activity. After troubleshooting, restore the log level to what daily use requires instead of retaining excessively detailed records. Separate the client window’s usage from the core process’s usage: v2rayN’s graphical interface and proxy core have different responsibilities. Even after the interface is minimized to the tray, the core may continue processing system-proxy traffic.

Mobile power use is driven mainly by wakeups and network conditions

Power consumption on Android is not determined by whether traffic is encrypted. Maintaining long-lived connections keeps the network hardware active periodically, while frequent short-lived connections increase handshakes and wakeups. Weak signal can also make the wireless module transmit at higher power. Switching between Wi-Fi and mobile data may invalidate old connections and require new ones, adding further cost. If the system restricts v2rayNG or v2flyNG in the background, connections may pause; reopening the app can trigger a burst of reconnects, causing both instability and a short-lived resource spike.

Assess the power impact of a protocol choice under the same traffic volume. Lightweight encapsulation may reduce some computation, but repeated reconnects caused by an unstable node quickly offset those savings through additional network wakeups. A stable long-lived connection is often more efficient than a theoretically simpler setup that disconnects frequently. Connection reuse can sometimes reduce the number of underlying connections, but if a shared connection recovers poorly after a mobile-network change, multiple requests may retry together. On mobile, keep rule sets moderate, use a transport explicitly supported by the server and adjust one setting at a time only after stable operation.

Judge v2rayNG and v2flyNG resource differences together with core capabilities

v2rayNG uses the Xray core and suits subscriptions containing VLESS, REALITY or Xray extensions. v2flyNG uses the v2fly core and is better suited to environments centered on VMess, Shadowsocks and other V2Fly-compatible configurations. Neither should be judged solely by installer size or one background-usage reading. If v2flyNG cannot parse the REALITY fields required by a node, lower idle usage does not matter because the connection cannot be established. Conversely, when a subscription contains only basic VMess, advanced extension support does not automatically improve speed.

When observing mobile resource use, cover at least four states: screen on, screen off, network switching and sustained transfer. System battery statistics are useful for longer-term trends, not conclusions drawn from a few minutes. Also distinguish proxy traffic from traffic generated by the application itself: video playback, cloud synchronization and large updates naturally use substantial bandwidth, while the client only forwards that data. If standby drain is abnormal, first check for apps making continuous requests, nodes repeatedly reconnecting and subscriptions updating too frequently, then investigate the protocol and core.

Order of adjustments for reducing resource use

First disable unnecessary detailed logs and repeated speed tests. Then remove dead nodes, overly frequent subscription updates and oversized routing rules. Next check for frequent reconnections. Compare transport and protocol combinations only afterward. Change one setting at a time and observe for long enough. If memory is higher only while the device is idle, with no system memory pressure and a stable connection, do not repeatedly restart the core just to improve the number. Modern systems use available memory for caching; persistent growth, lag, unusual heat and connection loops matter more.

Core families

V2Fly and Xray: relationship, capability boundaries and configuration compatibility

A shared origin does not mean synchronized features

V2Fly and Xray both continue the Project V ecosystem’s configuration model and multi-protocol forwarding approach, so many fundamentals are shared: inbounds receive local or external connections, outbounds send traffic to its destination, and routing selects an outbound based on domains, addresses, ports and other conditions. Common structures such as VMess, Shadowsocks, SOCKS and HTTP are understood similarly in both families. When moving from one core to the other, users usually do not need to relearn the inbound–routing–outbound framework.

However, they are now independently evolving core families. Feature release timing, field names, defaults and extension protocols are not guaranteed to match. The Xray side commonly includes combinations such as VLESS, REALITY and XTLS Vision, while V2Fly maintains protocol, transport and configuration capabilities along its own path. Similar-looking JSON does not prove that every field is interchangeable. A client displaying a node does not mean the selected core can start it; some clients preserve unknown fields and report unsupported features or parse errors only when the core launches.

How three clients map to their cores

v2rayN is a desktop client for Windows, macOS and Linux. It manages subscriptions, the system proxy, routing and core processes, making it the preferred starting point for desktop use. It can organize configurations around different core capabilities, but node availability still depends on the packaged and selected core. v2rayNG is an Android client primarily based on the Xray core and suits VLESS, REALITY and related Xray configurations. v2flyNG targets the v2fly core and is an alternative when Android users need V2Fly capabilities.

A graphical client is not the protocol itself. The client converts subscriptions or form data into core configuration, starts the process and controls the local network entry point; the core actually parses the protocol and forwards data. When the same node works in one client but not another, compare the core families and configuration fields first rather than only the interface names. If both use the same family, then check the import process, supported fields in that version and system network permissions.

Configuration compatibility has three layers: syntax, fields and behavior

The first layer is syntax compatibility: whether the JSON can be parsed. A syntactically valid file only shows that its brackets, quotes and data types are basically correct. The second is field compatibility: whether the core recognizes the protocol name and specific keys and values. The third is behavioral compatibility: whether identically named fields share the same defaults, edge cases and combination limits across implementations. Checking only the first layer is not enough for migration. The safest approach is to let the target client generate configuration from the subscription again rather than copying the old core’s complete runtime configuration.

The following snippet shows the basic layering of a VLESS outbound for illustration only. The example address and user ID are for documentation and cannot be used to connect. A real node must include the transport and security settings required by the server.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "11111111-1111-1111-1111-111111111111",
                "encryption": "none"
              }
            ]
          }
        ]
      }
    }
  ]
}

Here, protocol identifies only the outbound protocol; it does not replace the transport or security layer. Importing a REALITY node may also add the server name, public key, short ID, fingerprint and flow-control settings. If the target core does not support these fields, do not delete them to force startup. Use a client with a compatible Xray core, or ask the server for a compatible node. For a comparison of desktop client variants, continue with the differences between the v2rayN desktop and WPF editions.

Data exchange

Subscription formats, share links and configuration-field compatibility

A subscription is a node list, not a universal protocol standard

A client subscription usually retrieves a node list from one address. The response may contain encoded, line-separated share links or a structured configuration format. Subscriptions solve batch distribution and updates; they do not eliminate feature differences between cores. One subscription can contain VMess, VLESS, Trojan and Shadowsocks nodes at the same time, and the client identifies and converts each one into its own data model. Unsupported protocols may be skipped, while partially recognized nodes may keep their names but lose extension fields.

Therefore, “subscription updated successfully” only means the client retrieved and processed the response; it does not mean every listed node works with the current core. After updating, check whether the node count is reasonable, protocol types are shown and key parameters are present. If the subscription originally included REALITY nodes but v2flyNG lacks the required capability, this is a core limitation that repeated updates cannot fix. If v2rayNG recognizes the same subscription, that further points to a difference in core capabilities or the conversion layer.

What a share link can carry depends on the protocol and its extensions

Common links begin with a protocol scheme such as vmess://, vless://, trojan:// or ss://. The body carries the server, port, identity credentials and some transport parameters. VLESS and Trojan commonly place extra parameters in the query string and the node label at the end. Traditional VMess share links often encode a set of structured fields in the link, while Shadowsocks links organize the encryption method, password, address and port. Clients may differ in extension-field names and decoding tolerance.

When copying a link manually, copy everything from the protocol scheme through the final character; do not keep only the address and user ID. Question marks, hashes, slashes and percent signs have structural meaning and may be truncated or replaced by chat tools or text editors. A QR code is only a graphical representation of a link, so a successful scan does not prove that its content is complete. After importing, open the node details and compare the transport, security layer, SNI, path, service name, public key, short ID and flow-control settings with the server-provided values.

How common fields map to connection layers

Subscription updates versus local edits

Many clients overwrite nodes in a subscription group with remote content during updates. If you edit a subscription node directly, the change may disappear on the next update. To keep a local adjustment, first check whether the client supports copying the node locally or assigning separate rules to the subscription, or ask the server to correct the source data. Do not leave an important fix only in a temporary edit to a subscription node. Routing rules, system-proxy settings and client preferences are usually local configuration and may not be overwritten with node updates, but follow the behavior documented by the specific client.

If a subscription will not update, first verify the system clock, network and subscription address, then check the HTTP status and parsing messages in the client log. If all nodes suddenly stop working after an update, compare the protocol, address, port and security fields before and after the update instead of reinstalling immediately. If only a few nodes fail, the issue is more likely limited to their parameters or server status. For a detailed order of checks, see the step-by-step guide to node timeouts and connection failures.

Use the original subscription when migrating between clients

When moving from v2rayN to v2rayNG, or switching between v2rayNG and v2flyNG, import the original subscription or complete share links whenever possible and let the target client generate configuration for its own core. Copying a runtime JSON exported by another client may bring along local ports, platform paths, private routing rules and unsupported fields. After migration, test one basic node before importing complex rules. This separates node compatibility from local-routing compatibility and avoids introducing several variables at once.

Selection path

Choose a protocol by device, subscription capability and use case

Let server capabilities define the available range first

A protocol cannot be chosen by the client alone. If the server provides only VMess, changing the type to VLESS will not create a working connection. If a subscription lacks a REALITY public key and short ID, enabling an option cannot generate them. The first step is therefore not to pick a theoretically best name from every option, but to list the combinations actually provided by the server and fully supported by the current client core. Only nodes in that intersection are worth comparing for speed, resource use and maintenance cost.

Next consider whether legacy devices or multiple clients must share the setup. When an existing V2Fly environment must remain compatible, VMess or a Shadowsocks configuration supported by both sides is usually easier to keep consistent. If every device uses an Xray core and the server explicitly provides VLESS with REALITY, test that combination first. Trojan suits deployments with a complete TLS setup when the client can correctly handle the certificate and server name. Choose around the conditions at hand, not by treating protocol names as a ranking.

On desktop, prioritize management and long-term stability

On Windows, macOS and Linux, start with v2rayN. Desktop systems often run browsers, development tools, communication apps and system updates at the same time, so clear system-proxy controls, routing rules and logging are important. If a subscription offers VLESS with REALITY and the current Xray core supports it fully, test that as a modern combination. If existing VMess, Trojan or Shadowsocks nodes are stable, keep using them rather than migrating just to chase a different name.

Desktop use also requires understanding the difference between TUN and the system proxy. The system proxy mainly affects applications that follow system settings, while TUN uses a virtual network interface to capture a broader range of traffic. Both are local traffic entry points and do not change the remote node’s protocol. If one application bypasses the proxy, check the entry point and routing first instead of switching between VMess and VLESS. Complex routing, including rule matching and DNS behavior, may affect the result more than the protocol itself.

On Android, match the core first, then observe background stability

When a subscription centers on Xray capabilities and includes VLESS, REALITY or specific flow fields, prefer v2rayNG. When it mainly contains VMess, Shadowsocks and other nodes within V2Fly’s supported range and you want the v2fly core, choose v2flyNG. After choosing, observe recovery with the screen off and after a network change. If the node works in the foreground but disconnects frequently in the background, check background policies and battery restrictions before judging the protocol unstable.

Mobile devices are not ideal for keeping many dead nodes and complex test rules indefinitely. Long node lists increase management overhead, while automatic selection or speed tests may wake the network. Keeping a small set of verified nodes organized by purpose is more effective than continually adding protocol types. When downloading a client, arm64 is the usual choice for mainstream recent Android devices; use the universal build if the architecture is uncertain. The specific files are available in the Android section of the Download Center.

Recommended order by goal

There is no single best protocol outside its environment

VLESS’s separated responsibilities suit modern Xray combinations; VMess offers mature legacy compatibility; Trojan has a clear password-and-TLS structure; Shadowsocks is convenient for lightweight deployments; and REALITY serves a specific secure-handshake model. Each addresses different constraints. Make the choice by answering five questions in order: What does the server provide? What does the client core support? Are all subscription fields present? What are the device and background conditions? Is the actual route stable? Once all five are clear, the protocol name itself is far less mysterious.

If the choice is still unclear, keep two nodes for different purposes: one focused on stability and compatibility, and another for testing a new combination. Validate the test node for long enough before replacing the primary node. Do not change the protocol, transport, DNS, routing and local entry point at the same time. Change one layer at a time and record connection setup, sustained transfer and reconnection behavior before and after. Only then will the result be reusable.

Practical checks

Protocol migration, parameter verification and troubleshooting

Save a working baseline before migrating

The most common migration mistake is overwriting the old configuration before confirming that the new node works. Before starting, record the current working client, core family, protocol, transport method and security layer, and keep the original subscription address. Define the migration goal clearly: replacing old VMess with VLESS newly provided by the server, switching from v2flyNG to v2rayNG to use REALITY, or simply moving desktop settings to another device. Each goal requires a different scope of checks.

If the server provides both old and new nodes, import the new node as a separate entry instead of editing the old one directly. After it connects, test domain access, sustained transfer, network switching and commonly used applications before deciding whether to replace the old entry. This preserves a known-good baseline if the new parameters are wrong. If the old configuration is no longer available, preserve the full text of the new subscription even more carefully to avoid losing fields while moving it between clients.

Check connection failures in reverse order through the setup chain

Start with the network target. Confirm that the address contains no extra spaces, the port is numeric, the domain resolves and the device has basic connectivity to the destination port. On Windows, use the following command in PowerShell to check whether the TCP port can be reached. Replace the example domain with the actual server address:

Test-NetConnection example.com -Port 443

On macOS and Linux, use the built-in system tools for the same kind of check:

nc -vz example.com 443

If the port is unreachable, protocol authentication has not started; fix the address, network path or server listener first. If the port is reachable but the core reports a handshake failure, check the system clock, security layer, SNI, certificate or REALITY parameters. If the handshake succeeds but authentication fails, verify the UUID, password, encryption method and user configuration. If the connection works but the destination cannot be reached, inspect DNS, routing and the local proxy entry point. Layered troubleshooting is more reliable than reinstalling the client or switching protocols at random.

Frequent failure points by protocol

For VMess, pay particular attention to the system clock, user identifier, historical alterId fields and whether the transport parameters came from one consistent configuration. With VLESS, a correct UUID can still fail if the security layer, flow or transport does not match. For Trojan, verify the password, SNI and certificate conditions. For Shadowsocks, ensure that the password and encryption method match exactly and that plugin parameters are present. For a REALITY combination, check the public key, short ID, server name, fingerprint and flow together; none should be guessed.

“Parse failure” and “connection timeout” in logs mean different things. A parse failure usually means the configuration syntax or fields are not accepted by the core. An authentication failure means processing reached the relevant protocol stage. A connection timeout may occur at the address, port or network-path stage. A handshake error is more often related to TLS, REALITY or transport negotiation. Locate the stage first, then inspect its parameters. The final log line alone may lack context, so review earlier entries from the same connection, without leaving the most verbose logging enabled permanently.

When the connection works but applications do not, check the local entry point

A node showing as connected only means that the core has started or that a probe succeeded. Whether browsers, command-line tools and other applications use the proxy also depends on the system proxy, TUN, application-specific proxy settings and routing rules. If one browser works but another program does not, the problem is usually closer to the local entry point. If all domains fail while direct address access works, check DNS. If some sites use the wrong outbound, inspect the matching order for domain and address rules.

Routing rules are processed according to the core configuration order or the client’s generation logic. A broad rule placed first can hide a later, more specific rule. During troubleshooting, temporarily switch to the client’s simple proxy mode to confirm that the node itself works, then restore custom routing step by step. Do not mistake a routing problem for a VLESS, VMess or Trojan protocol problem. After changing the local SOCKS or HTTP port, update applications that use those ports as well.

Keep reusable troubleshooting records

A complete record should include the device platform, client, core family, node protocol, transport, security layer, test time window and the stage where the error occurred. Do not save the actual password or user credentials. “Port reachable, handshake failed” is more useful than “node broken.” “Works on Wi-Fi, fails to recover after switching networks” is more useful for locating a mobile issue than one latency number. After several investigations, you can establish a fixed sequence suited to your environment.

For a first-time setup, return to the quick-start path and establish a baseline with subscription import and default settings. If the issue occurs only during first installation or system-proxy setup, see v2rayN first-run installation and initial setup. When choosing a different client, start with v2rayN on desktop. On Android, choose v2rayNG or v2flyNG according to the Xray or V2Fly core required, using the Download Center to reach the relevant platform.