V2Ray Protocol and CoreSelection Guide

// 01 · DECISION MODEL

Separate protocol, transport, security, and routing

A client configuration is more than one protocol

V2Ray GUI Clients compress complex settings into a handful of form fields, which can make it seem that choosing VMess or VLESS completes the technical setup. In practice, a connection has at least five layers: the application creates raw TCP or UDP traffic; a local client entry receives it; the proxy protocol handles authentication and encapsulation; the transport carries proxy data over TCP, WebSocket, gRPC, or another medium; and TLS or REALITY handles the outer handshake and encryption. Once data reaches the remote side, outbound and routing rules decide whether it is sent directly, proxied, or blocked. A mismatch at any layer can appear as “the configuration imports successfully but cannot connect.”

The protocol layer mainly determines authentication fields, request structure, and core implementation. VMess, for example, uses a user identifier and its own protocol format, while VLESS is lighter and delegates encryption and transport security to the outer layer. The transport layer determines how data is framed, whether HTTP semantics are involved, and whether intermediate links can forward it correctly. The security layer handles certificate validation, server names, key exchange, and identity verification. Routing does not change the protocol itself, but directly determines which requests enter the proxy connection. Troubleshoot by locating the failing layer first; changing several options at once only hides the real cause.

Use constraints instead of looking for the “strongest protocol”

There is no universal protocol ranking outside its operating environment. Selection depends on what the server provides, what the client core can parse, what the operating system requires, and whether the path includes a reverse proxy or infrastructure that accepts only certain transports. If the server is fixed to VMess, the client cannot change it to VLESS on its own. If a subscription provides only WebSocket, changing the local transport to gRPC will not work. The protocol, address, port, user ID, transport, and security fields in the client must match the server one by one.

Prioritize decisions in this order: availability, compatibility, resource cost, then maintenance cost. First confirm server and core support; next confirm that the subscription carries every required field; only then compare connection time, throughput, and battery use. For multiple devices, check whether desktop and Android clients can reuse the same subscription. If one platform cannot fully recognize a combination, the maintenance burden will often outweigh its minor performance benefit.

Create a baseline you can revert to

When comparing protocols, keep one verified baseline configuration and do not overwrite it. The baseline helps rule out interference from local ports, the system proxy, DNS, and routing rules. Before testing a new configuration, temporarily use global proxying or the simplest routing mode, then restore split routing after the basic connection works. If the connection is normal until the rules are restored, the problem lies in routing or DNS, not the protocol settings. GUI clients usually support copying configurations or managing them in subscription groups; use groups to reduce field confusion caused by repeated imports.

// 02 · PROTOCOL FAMILIES

VMess, VLESS, Trojan, Shadowsocks, and REALITY

VMess: a complete protocol format with broad compatibility

VMess is a core proxy protocol from the early Project V ecosystem. It was designed to combine user authentication, time validation, and data encapsulation in one protocol. Common client fields include the server address, port, user ID, alterId, encryption method, and transport settings. In modern configurations, alterId is usually zero; if an older subscription still provides a nonzero value, keep it as specified by the server rather than changing it to match newer conventions. VMess is sensitive to system time. If one device works while another does not with the same configuration, check automatic time synchronization.

VMess benefits from years of tooling and broad compatibility across existing deployments. Many subscription formats can reliably express its basic fields. The trade-off is a more involved protocol structure than VLESS, with additional authentication and encapsulation work. On modern desktop and mobile hardware, this is rarely the bottleneck; network round trips, transport choice, TLS handshakes, and server load usually matter more. If an existing VMess configuration is stable, migrating solely to chase a small theoretical overhead reduction may not justify the reconfiguration and cross-device testing.

VLESS: separating authentication from security

VLESS retains user ID authentication but does not duplicate data encryption inside the protocol. Security is delegated to outer mechanisms such as TLS and REALITY. This reduces protocol-layer overhead and clarifies the role of transport security. Along with the address, port, and user ID, VLESS configurations often include a flow field. Not every VLESS configuration needs flow; fill it in only when the server enables the corresponding flow-control mode. The most common related value is xtls-rprx-vision; leaving it blank or entering the wrong value makes client and server behavior diverge.

VLESS does not mean REALITY, nor does it imply a particular transport. It can be combined with TCP, WebSocket, gRPC, and other transports, and used with TLS or REALITY. After selecting VLESS, check network, security, serverName, flow, and related fields. In modern Xray configurations, VLESS is often paired with REALITY and Vision because these capabilities work together within the same core family. If a configuration must be handed to a client that supports only V2Fly features, first confirm that the target core has an equivalent implementation.

Trojan: password authentication over TLS

Trojan uses a relatively direct set of fields: server address, port, password, TLS server name, and optional transport parameters. It depends on a correct TLS deployment, and the client verifies the certificate using the server name. Using an IP address for the connection target while entering a domain as the server name is valid because the destination and certificate identity can differ. However, an empty or misspelled server name, or a broken certificate chain, will make the connection fail before proxy data starts flowing. Disabling certificate verification may bypass an error temporarily, but removes identity validation and is not a suitable long-term fix.

Trojan has a low learning curve and fits environments where the server already provides standard TLS. Its performance difference from VLESS TLS is usually smaller than the effects of link quality and transport choice. For a meaningful comparison, keep the server location, port, transport, and concurrency the same. If one configuration uses direct TCP while another adds WebSocket and an intermediary, download speed cannot meaningfully rank the protocols.

Shadowsocks: a lightweight encrypted proxy

Shadowsocks is often abbreviated as SS. Its configuration mainly consists of an address, port, password, and encryption method. The structure is simple, resource use is usually low, and TCP and UDP support are mature. The encryption method must match the server exactly; similar-looking method names are not interchangeable. Modern deployments should use an AEAD method supported by both client and server. Older methods may still be parsed by some cores, but their compatibility, security properties, and maintenance status are not equivalent to modern methods.

SS works well when fields should stay simple and configurations need to be reused across clients. Its subscription links are also relatively compact, but generators may encode user information, plugin parameters, and remarks differently. Basic SS configurations are usually easy to migrate; configurations with extra plugin parameters require confirmation that the target client implements the same capability. v2rayN, v2rayNG, and v2flyNG handle common basic configurations, while complex extensions remain subject to each client’s core and importer.

REALITY: a transport security scheme, not a standalone proxy protocol

REALITY often appears alongside VLESS, so it is sometimes mistakenly called a standalone protocol. More precisely, VLESS handles the proxy protocol and user authentication, while REALITY handles the outer handshake and server identity verification. Common client fields include the server name, public key, short ID, browser fingerprint, and optional SpiderX. The public key comes from the server’s key pair, and the short ID must be one permitted by the server. Neither can be generated or replaced arbitrarily on the client. The server name must also match the server configuration.

REALITY is fully supported primarily by the Xray core. After importing a configuration, the interface may recognize VLESS, but the connection will still fail if a subscription converter drops REALITY’s publicKey, shortId, or fingerprint. Expand the configuration details and check each field rather than relying on the protocol label in the list. On devices that require the V2Fly core, prepare a separate compatible configuration instead of expecting V2Fly to ignore REALITY fields and continue working.

// 03 · PERFORMANCE & RESOURCE

Comparing connection speed, throughput, and resource use

Separate handshake time from sustained throughput

“Speed” includes at least connection setup time, time to first byte, sustained download throughput, upload throughput, and stability under concurrency. A lightweight protocol layer does not make every metric faster. A new connection may involve DNS lookup, TCP setup, a TLS or REALITY handshake, proxy authentication, and a connection to the destination. On cross-region paths, network round-trip time is often much greater than local protocol encoding time. Short-lived web requests are more sensitive to handshake round trips, while long file transfers depend mainly on bandwidth, packet loss, congestion control, and server capacity.

When comparing VMess, VLESS, Trojan, and SS, use the same server and route, similar ports, and the same transport layer whenever possible. Disable custom routing that could change the path, and confirm that DNS results match. Run several alternating rounds for each configuration instead of finishing one protocol before starting another, because network load changes over time. Record median performance and failure counts rather than keeping only the fastest run. A small difference usually does not prove that the protocol itself is better.

Transport encapsulation often matters more than protocol differences

Direct TCP adds little framing overhead and suits paths that permit a stable end-to-end connection. WebSocket adds an HTTP upgrade and frame structure around the data, making it easier to integrate with HTTP-aware infrastructure but adding header and framing costs. gRPC is based on HTTP/2 and provides stream and connection management, making it suitable when the server and intermediate path correctly support HTTP/2. HTTPUpgrade and WebSocket have similar entry patterns, but their support depends on the core and server. Do not judge by theoretical overhead alone; check whether the full path buffers, times out, or resets long-lived connections.

Multiplexing lets multiple logical requests share fewer underlying connections. It may reduce repeated connection setup, but packet loss can make several logical streams wait at once, causing head-of-line blocking. Small web requests, real-time communication, and large transfers react differently to multiplexing. If enabling it makes downloads stable but causes occasional web stalls, or one lost packet pauses every request on the connection, disable multiplexing for comparison rather than blaming VLESS or VMess directly.

CPU, memory, and encryption implementations

Resource use depends on protocol parsing, encryption algorithms, TLS implementation, transport framing, log level, and connection count. VLESS delegates data encryption to the outer layer; Trojan relies on TLS; SS uses its configured encryption method; VMess has its own protocol structure. Modern devices usually have efficient cryptographic implementations, so CPU differences may be hard to notice during ordinary browsing. On low-powered devices, high-speed transfers, or heavily concurrent connections, algorithm implementation and the number of memory copies are more likely to become bottlenecks.

Logging also affects resource use. Detailed logs help locate handshake and routing problems, but keeping debug logging enabled permanently increases disk writes, memory buffering, and interface refreshes. Return to a normal log level once the connection is stable. Fewer routing rules do not automatically mean faster routing: well-structured domain and IP sets can be matched efficiently by the core. What should be avoided is a large number of duplicate, conflicting, and poorly ordered custom rules.

A reproducible testing sequence

Start with a single browser and run a cold-start test, recording the difference between the first and subsequent page loads. Then perform a sustained transfer and watch whether throughput remains stable. Next test concurrent requests and UDP applications, and finally restore everyday routing and DNS settings. Change only one variable at a time. If you switch from VMess WebSocket TLS to VLESS TCP REALITY in one step and see an improvement, you cannot tell whether it came from the protocol, transport, or security layer. A better method is to keep transport and TLS unchanged while comparing VMess with VLESS, then change the transport separately, and compare the security layer last.

A connection test in the client interface usually checks only whether the remote side responds; it does not prove that the full application path is stable. Real applications may use different domains, IPv4 or IPv6, UDP, long-lived connections, and concurrent requests. To decide whether a configuration can be your primary one, test web access, sustained transfers, sleep-and-resume, and network changes. If only one application fails, investigate DNS, routing, or that application’s proxy integration instead of randomly changing protocols.

// 04 · MOBILE POWER

Android battery use, background operation, and network switching

Battery use is not determined by the protocol name alone

On Android, proxy clients usually take over traffic through the system VPN service. Power use comes from the continuously running local entry, encryption and decryption, DNS processing, route matching, keepalives, log writes, and frequent reconnections. When the screen is off, system scheduling and background restrictions can change connection state. When switching from Wi-Fi to mobile data, existing TCP connections usually have to be rebuilt. The theoretical encapsulation cost of VMess, VLESS, or SS alone therefore cannot predict overall battery life accurately.

v2rayNG uses the Xray core and suits configurations that require VLESS, REALITY, and Xray routing capabilities. v2flyNG uses the v2fly core and can serve as an Android option for V2Fly ecosystem configurations. Compare their battery use with the same configuration, routing mode, and similar daily activity. If one side has full logging, complex DNS routing, and continuous probing enabled while the other runs a simple proxy, the result cannot be attributed to the core family.

Keepalives and frequent wake-ups

Keepalives maintain connections and detect failures promptly, but intervals that are too short wake the network and processor frequently. Real-time communication needs stable long-lived connections, while ordinary web browsing can tolerate on-demand reconnects. Client and server idle timeouts, along with connection reclamation by intermediate network devices, all affect the right interval. If standby battery use is high, first check for continuous transfers, verbose logging, or repeated reconnects. Adjust keepalives only afterward; setting an extremely short interval blindly is not recommended.

Multiplexing can sometimes reduce the number of underlying connections, but one long-lived connection may also be reclaimed by the system or network. Disabling multiplexing increases connection count and may increase handshakes; enabling it can cause group reconnects if the main connection fails repeatedly. Observe a complete period of foreground use and standby before deciding. The system battery screen shows application activity trends but cannot isolate protocol overhead. Combine it with client logs showing repeated connections, DNS timeouts, and network switches.

How routing scope and DNS affect battery use

Full traffic capture sends more application traffic through the core, increasing processing from background sync, media transfers, and system services. Per-app proxying or sensible domain and IP routing can avoid unnecessary forwarding, but overly complex rules and frequent remote DNS lookups also add cost. The goal is not the fewest rules; it is keeping local traffic, LAN access, and clearly direct destinations from taking a needless detour while ensuring that DNS resolution follows the same path as the final outbound connection.

Incorrect DNS settings can cause duplicate lookups, timeout fallbacks, and connection retries, consuming power that is often mistaken for a protocol issue. If logs repeatedly show resolution timeouts, first confirm that the current network can reach the configured DNS, that queries are routed through the correct outbound, and that IPv6 results match the network’s actual capabilities. Disabling IPv6 is not a universal fix: on a network with stable IPv6, it may force an unnecessary fallback; on one without a complete IPv6 path, trying invalid addresses first may add delay. Test against the current network.

Choosing a practical protocol and transport

If the server offers several options, mobile users should start with the combination whose fields are complete, whose core supports it natively, and whose connection recovers reliably. VLESS REALITY requires the Xray capabilities used by v2rayNG; basic VMess, Trojan, and SS offer broader configuration choices. For transport, direct TCP is usually simpler, while WebSocket and gRPC depend on the server deployment. A transport that is stable on a desktop broadband connection may behave differently when a mobile network switches, so check whether the connection recovers from the background without manual reconnection.

When battery use is high, do not delete the subscription immediately. Copy the configuration and create a comparison: disable verbose logging, reduce unnecessary probing, keep the protocol and server unchanged, and switch only multiplexing. Then keep multiplexing unchanged and compare transports, followed by protocols. Keep screen time and traffic type similar in each round. If high battery use accompanies substantial traffic, it may simply be normal processing cost. If the client stays active with almost no traffic, focus on reconnect loops, DNS retries, and background applications repeatedly making requests.

// 05 · CORE FAMILIES

How the V2Fly and Xray core families relate

Shared foundations and separate directions

V2Fly and Xray both carry forward many core concepts from the Project V configuration model, including inbounds, outbounds, routing, DNS, transports, and policy objects. They overlap substantially in common capabilities such as VMess, basic VLESS, Shadowsocks, SOCKS, and HTTP, so many basic configurations look similar. However, they are independently evolving core families. New features, field names, defaults, and release schedules do not have to remain synchronized. Similar configuration structures do not mean every configuration can be exchanged directly.

Xray has established a clear combination path around VLESS, XTLS Vision, REALITY, and related capabilities. V2Fly continues to maintain its own protocol, transport, routing, and platform capabilities. When choosing a core, do not ask only which one is “newer.” Ask which core provides the subscription’s features, whether the client exposes the required settings, and whether the server uses the same implementation. Basic protocols are easier to move across cores; proprietary security layers, flow control, and experimental fields narrow compatibility.

How the three GUI clients fit together

On desktop platforms, v2rayN is the primary choice. It covers Windows, macOS, and Linux and provides subscription management, system proxy controls, routing rules, and entry points for configuring multiple cores. On Android, v2rayNG is centered on the Xray core and suits configurations that require Xray capabilities such as VLESS, REALITY, and Vision. v2flyNG corresponds to the V2Fly core and fits scenarios where the server and subscription explicitly use V2Fly-compatible features. Choose the operating system on the Get the Clients page for the appropriate installation entry.

Do not confuse the client name with the core name. v2rayN is the GUI management layer responsible for subscriptions, configuration editing, starting the core, and controlling the system proxy. The selected core actually executes the protocol, transport, and routing. In the same v2rayN interface, changing the core can change available fields and runtime behavior. When troubleshooting, record the core type as well as the client name. “v2rayN cannot connect” is not enough information; the same configuration can produce different results under different cores.

Three layers of configuration compatibility

The first is syntax compatibility: whether the JSON parses and field types and object locations meet the core’s requirements. The second is feature compatibility: whether a readable field’s protocol or transport is actually implemented. The third is behavioral compatibility: whether two implementations of a feature with the same name share defaults, fallback rules, and edge-case handling. A successful subscription import proves only that the GUI accepted the input. It does not prove that the core can run it, much less that its parameters match the server.

For example, a VLESS REALITY configuration may import into v2flyNG through a generic link format, with the list showing the address and user ID. If the target core does not support REALITY, the connection will not downgrade to ordinary TLS. The security layer cannot be silently substituted because the server expects a completely different handshake. Use another compatible configuration from the server, or run it in v2rayNG, v2rayN, and an Xray core that support the required feature.

How to verify before switching cores

Before migrating, export or record the original protocol, transport, security, routing, and DNS settings; do not keep only a share link. Check whether the target core supports every important field, especially flow, the REALITY public key, short ID, transport service name, and custom outbounds. After migrating, disable complex routing and verify the basic connection with a single configuration. Restore DNS next, then split routing. This separates protocol incompatibility from DNS behavior differences and changed rule tags.

After switching cores, also check the local listening port and system proxy. A GUI client may use different entries for different configuration modes, while an old browser or application proxy may still point to the previous port. The result can look like “the core started successfully but no traffic is flowing.” If logs show no inbound connections, first check whether the application reaches the local entry. If inbound traffic exists but the remote handshake fails, check protocol and security fields. For port conflicts, see Troubleshooting Local Listening Ports.

// 06 · TRANSPORT & SECURITY

Transports, TLS, REALITY, and key parameters

TCP, WebSocket, gRPC, and HTTPUpgrade

In client settings, TCP usually means protocol data is carried directly over TCP; it does not mean TLS is absent. network selects the transport, while security selects outer security, and they are separate fields. WebSocket requires a path, and some deployments also require Host. The path usually starts with a slash and must match the server and intermediary forwarding rules. gRPC uses serviceName to identify a service; do not paste a WebSocket path into it. HTTPUpgrade also involves a path and Host, but it is a different transport type from WebSocket and requires explicit server support.

After importing a subscription, if the address, port, and user ID are correct but logs show an HTTP status error, a missing service, or an immediate disconnect, check the transport first. Common causes include an extra trailing slash in the path, a converter treating serviceName as path, mixing up Host and server name, and intermediary forwarding that supports only HTTP/1.1 or only HTTP/2. The client cannot guess the server’s deployment through automatic trial and error; form values must be exact.

TLS server names and certificate validation

The serverName in a TLS configuration identifies the peer during the handshake and commonly corresponds to a domain in the certificate. The connection target can be a domain or IP, while serverName should follow the server’s requirements. An option such as allowInsecure controls certificate verification; a normal configuration should keep strict validation enabled. For certificate errors, check the device clock, server name, certificate coverage, and chain rather than disabling verification permanently. Certificate errors occur before proxy authentication, so changing the user ID or password will not fix them.

ALPN negotiates the upper-layer protocol, commonly involving HTTP/2 or HTTP/1.1. Set it manually only when the server or intermediary infrastructure clearly requires it. Adding ALPN arbitrarily can make the client negotiate a protocol the server does not handle correctly. Fingerprint simulation fields affect the TLS client handshake signature, and available values depend on the core. If the subscription provides this field, normally keep it; before editing it manually, confirm the name accepted by the current core.

REALITY’s four key fields

The four fields to verify most carefully in a REALITY configuration are serverName, publicKey, shortId, and fingerprint. serverName is the server name used in the handshake; publicKey is the public key from the server’s key pair; shortId must be permitted by the server; and fingerprint selects the client handshake fingerprint. Any missing field or mistyped character can cause an early connection failure. In share links, these values commonly appear as parameters such as sni, pbk, sid, and fp. After importing, confirm in the configuration details that none was truncated.

VLESS REALITY is often paired with Vision flow control. In that setup, the client’s flow must match the server’s; do not remove it just because another VLESS configuration leaves it blank. Conversely, do not add it when the server has not enabled Vision. REALITY parameters may look like “advanced settings,” but they are required connection data. After conversion, QR recognition, or manual copying causes trouble, compare these fields character by character before repeatedly changing routing modes.

The boundary between routing and protocol settings

Routing rules do not establish the remote protocol connection; they assign requests that have entered the core to different outbounds. The example below shows a common order: block ad categories first, send private addresses and local-region domains directly, and route everything else through the default proxy outbound. It is a parseable Xray/V2Ray routing object fragment. In a complete configuration, make sure outbounds named block, direct, and proxy exist.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:category-ads-all"],
        "outboundTag": "block"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

Rules are matched according to the core’s configuration semantics, and the order of conflicting rules changes the result. Before adding custom rules, check whether the client appends preset rules while generating the final configuration; the order shown in the interface may not match the final JSON order. domainStrategy determines when a domain is resolved to an IP for continued IP-rule matching, affecting DNS query volume and routing results. For domain, ip, and geosite syntax and precedence, continue with Custom Routing Rule Syntax Explained.

// 07 · SUBSCRIPTION COMPATIBILITY

Subscription formats, share links, and field compatibility

A subscription transports configurations

A subscription is not a proxy protocol. It delivers server configurations from the provider to the client. The content may be Base64-encoded lines of share links or a structured configuration the client can recognize. Common share links begin with vmess://, vless://, trojan://, or ss://. The scheme identifies the protocol, while query parameters carry transport, security, server name, path, public key, and other fields. Importing requires decoding, mapping fields, and generating the client’s internal configuration.

Base64 is an encoding, not encryption, and does not determine protocol capabilities. The same subscription URL may return different nodes, remarks, or parameters after an update. When refreshing a subscription, clients usually replace or merge old configurations by group, so manual edits to subscription-generated entries may be overwritten during the next update. To keep local changes, copy the entry into an independent configuration or use the client’s pre- or post-processing features, and record why it was changed.

Why share-link fields go missing

Fields are often lost when the generator, conversion step, and client importer use different names for the same parameter. In VLESS REALITY, for example, the public key may be called pbk, the short ID sid, the server name sni, and the fingerprint fp. If an importer recognizes only one naming scheme, it can still create a list entry with the address and user ID while leaving critical security fields empty. VMess JSON share content can also fail to parse because of legacy fields, character encoding, or special characters in remarks.

When diagnosing a subscription, separate “retrieving the subscription” from “running an individual configuration.” If the subscription URL cannot update, check that the URL is complete, whether authentication is required, the system clock, and whether the network can reach the provider. If the update succeeds but one entry does not run, inspect that entry’s protocol fields. If manually importing the original share link works but importing through the subscription does not, the problem is more likely in the subscription content or conversion process than in the core.

Compatibility across the three clients

v2rayN suits centralized desktop management of common VMess, VLESS, Trojan, and SS configurations, running them through the selected core. v2rayNG targets Android and Xray configurations and is better suited to Xray features such as VLESS REALITY. v2flyNG uses the V2Fly core and fits subscriptions that explicitly provide configurations runnable by V2Fly. All three clients may recognize basic share links, but “parses the link” and “supports every feature in the link” are separate questions.

For a subscription shared across devices, the safest approach is to provide both a basic compatible configuration and configurations requiring a dedicated core, with clear remarks distinguishing them. If every entry depends on REALITY, v2flyNG will not automatically produce a usable alternative. Conversely, using only basic VMess or SS makes cross-core migration simpler, though transport extensions, UDP, and encryption methods still need checking. See How to Import Subscription Links in v2rayN and v2rayNG for the full process.

Safe order for updating a subscription

Before updating, record the entry currently in use and its routing mode. Copy important manual configurations into a non-subscription group first. After updating, do not delete the old group immediately. Check that the entry count is reasonable, remarks have not changed unexpectedly, and the current configuration is still selected before testing the connection. If every entry fails after the update, return to the old configuration to determine whether the subscription changed or the local network is at fault. If only one entry fails, compare its address, port, protocol, security, and transport fields before and after the update.

QR-code import is also share-link parsing. A clear QR image does not guarantee complete content; cropping, scaling, and long-link capacity can all affect recognition. Inspect the configuration details afterward rather than treating an “import successful” message as final verification. Treat subscriptions and share links containing sensitive connection data as access credentials. Do not display their full contents on public pages or in log screenshots. When reporting a problem, keep the protocol type and field names but mask the address, user ID, password, and key parameters.

// 08 · SCENARIO CHOICE

Choose protocols and clients by use case

Existing server: prioritize a match

When a configuration comes from an existing server or subscription, the server determines the available choices. Use the protocol, transport, and security parameters as provided; do not change VLESS to VMess or WebSocket to TCP. On desktop, start with v2rayN and select a core that fully supports the fields. On Android, use v2rayNG for Xray features such as VLESS REALITY and Vision; use v2flyNG when the configuration explicitly targets V2Fly compatibility. Stable operation matters more than choosing the newer-sounding protocol.

When one subscription contains several protocols, first remove entries with incomplete fields or incompatible cores, then compare the actual network path. VMess suits established deployments; VLESS pairs well with modern TLS or REALITY; Trojan fits deployments with clear standard TLS settings; SS works well when basic fields are simple and UDP support matters. Choose based on stability, recovery time, and everyday application behavior—not list order or the impression created by a name.

Across platforms: prioritize compatibility

When sharing a configuration across Windows, macOS, Android, and Linux, first confirm that every client can import it completely. Basic VMess, Trojan, and SS are generally easier to express across environments, and basic VLESS TLS is also widely supported. Once REALITY, Vision, or a specific transport extension is added, verify each core separately. A multi-platform setup can keep one newer primary configuration and one simpler compatibility configuration so that a core difference does not leave a device unable to connect.

Subscription remarks should state readable protocol and purpose information, such as distinguishing Xray-only entries from basic compatible ones, rather than relying on automatic client detection. Validate an update on one device first; once fields and groups look correct, update the others. This reduces the risk that a change in the subscription generator affects every device at once. Devices do not need the same client, but record the core and configuration mapping for each one.

Low-resource and mobile use: minimize extra work

On low-powered devices or when standby battery life matters, prefer configurations supported natively by the core, with a simple transport layer and no complex conversion. SS has a simple structure and VLESS has low protocol-layer overhead, but total resource use still depends on outer security, connection count, DNS, and routing. Direct TCP is often simpler than adding several layers of HTTP semantics, provided the server deployment allows it. Do not disable necessary identity checks or certificate validation to save a small amount of protocol processing.

On Android, reduce debug logging, ineffective DNS retries, and overly short keepalives before comparing protocols. If the connection drops frequently after standby, check background restrictions and network switching rather than changing only the encryption method. Applications that need UDP also require UDP support from the server, protocol, transport, and client entry; a missing layer will break part of the experience. Working TCP web access does not prove that the UDP path works.

Complex routing: prioritize core and rule support

When traffic must be split precisely by domain, IP, application, or protocol type, the client’s rule-generation model and core capabilities matter more than the proxy protocol. v2rayN is well suited to maintaining complex desktop routing, while v2rayNG can use Xray rules on Android. Design rules by defining direct, proxy, and block outbounds first, then organizing high-priority exceptions, private networks, regional sets, and the default path. The more rules you have, the more important clear order and DNS policy become.

Typical routing problems include only some domains failing, LAN devices becoming unreachable, or DNS results and connection outbounds not matching. Switching between VMess and VLESS usually will not fix this. Temporarily use simple routing to verify the basic protocol, then restore rule groups one at a time. DNS leaks, remote resolution, and local resolution are DNS and routing design issues; continue with DNS Leak Checks and Client Configuration.

Final decision checklist

1. Confirm the server: Record the protocol, address, port, transport, security layer, and every authentication field. The client must not change the type unilaterally.
2. Confirm the core: For REALITY and Vision, verify Xray support first; validate V2Fly configurations in v2flyNG or the corresponding desktop core.
3. Confirm the subscription: Check that flow, sni, publicKey, shortId, fingerprint, path, and serviceName remain complete after import.
4. Establish a baseline: Verify the connection with simple routing and standard DNS first, then restore split routing, multiplexing, and advanced options.
5. Test by scenario: Check short-lived connections, sustained transfers, UDP, sleep-and-resume, network switching, and multi-device imports separately.
6. Keep a fallback: Copy the verified configuration; do not migrate protocols, switch cores, and update the subscription at the same time.

If the cause is still unclear, start on desktop with v2rayN and the server’s original configuration. On Android, choose between v2rayNG and v2flyNG according to core support. After an error, locate the layer first: no local inbound traffic means checking the system proxy and port; a failed remote handshake means checking protocol and security fields; failures limited to some domains mean checking routing and DNS; problems after a subscription update mean comparing fields before and after the update. This order usually finds the cause faster than repeatedly changing protocols.