V2Ray Protocols and Core Technologies: A Practical Reference

1. Start with the Protocol, Transport, Security, and Client Layers

What goes into a connection

In v2rayN’s “Add Server” window, the protocol type is just the starting point. The client also needs the server address, port, user credentials, transport, and transport security settings to build a complete connection. For example, if you select VLESS, the address might be your-server.example, and the server configuration supplies the port. The user identity is usually a UUID; the transport might be tcp, ws, or grpc; and transport security might be tls or reality. Each field has a distinct purpose. Choosing the same protocol doesn’t make the rest of the server settings interchangeable. The address and port specify the destination, the identity fields determine whether the parties can authenticate each other, and the transport and security fields define how the connection is established.

Here, “proxy protocol” refers mainly to how the client and server structure requests, identify users, and pass destination addresses. VMess, VLESS, Trojan, and Shadowsocks belong to this layer. “Transport” describes how data is carried: tcp uses a direct stream connection, WebSocket adds its own handshake and message framing, and gRPC runs over HTTP/2 streams. Use the transport the server actually supports; it isn’t an arbitrary client-side option. Even with the correct address and credentials, a mismatch in the path, service name, or transport type can end the connection during the handshake.

REALITY does not belong in the protocol type field

tls and reality are transport security options; REALITY is not a standalone proxy protocol alongside VLESS. A common configuration lists VLESS, tcp, and reality together: VLESS handles the proxy data, while the connection uses REALITY over TCP as required by the server. To interpret a configuration, identify the protocol field first, then the transport, and finally the security field. If a share is labeled only “REALITY node” without naming a protocol, check the original link or the provider’s instructions. Don’t create a server entry based on the label alone.

A “core” is the program that interprets and runs the settings above. v2rayN is a desktop GUI client for Windows, macOS, and Linux. v2rayNG and v2flyNG are Android GUI clients. The interface manages entries, subscriptions, and system settings, but the available fields also depend on the core and its version. Saving a configuration in the interface doesn’t guarantee the core can run it. If a field isn’t recognized, check the client, the active core, and the server’s requirements—not just the server address.

Use a field checklist instead of guessing the protocol

When you receive server details, record the protocol, address, port, credentials, transport, security type, and any transport-specific parameters. WebSocket commonly uses a Host value and path; gRPC requires checking serviceName; TLS often requires the server name; and REALITY also needs the public key, short ID, and other handshake parameters supplied by the server. If anything is missing, ask the configuration provider for the original details. Rules like “this protocol usually uses this port” aren’t reliable: the server sets the port, and you can’t infer it from the protocol name.

This page explains how client fields map to server settings; it doesn’t recommend changing an unknown server’s existing configuration. After importing a subscription, the GUI may hide complex parameters in the edit window. Open the entry details to verify them rather than relying on the name shown in the list. Providers can choose any display name; it doesn’t identify the protocol or prove that transport security is configured correctly. Checking each layer is more useful than repeatedly switching modes.

2. VMess and VLESS: Two Different Field Models

VMess: background and practical configuration

VMess is an early, widely used proxy protocol in the Project V ecosystem. It handles user identity and data encapsulation at the protocol layer, with its own connection format. In a GUI client, you’ll typically see fields for the address, port, user ID, and security or encryption options tied to the server configuration. Field names in older tutorials may not match the current interface: some belong to legacy formats, while others have moved to transport or TLS settings. Use the current server parameters and the meaning of the client fields. Don’t add values to an existing configuration just to match an outdated tutorial.

VMess can use different transports; VMess does not mean WebSocket, and it doesn’t necessarily mean TLS is enabled. When a connection fails, distinguish between a mismatch in protocol identity fields and a failed transport handshake. If the server specifies a ws path but the client is set to tcp, the connection won’t work even with the correct user ID. If the server requires TLS, also check the server name and related security settings. Switching the protocol type usually requires matching server-side configuration; you can’t simply change the VMess entry to VLESS in the client.

Why VLESS leaves security to other layers

VLESS continues to identify connections using a user ID, but keeps the protocol layer lighter and generally doesn’t handle data encryption itself. For transport security, use TLS or REALITY as configured on the server. This separation makes it easier to consider the protocol and transport security independently, and lets VLESS work with different transports. It also means you must check the security layer explicitly. Seeing “VLESS” doesn’t tell you that a security option is enabled, and it doesn’t mean you can skip the server-provided public key or server name.

UUID is the common identity field for VLESS. Some configurations also include flow, which specifies a particular operating mode—not a performance switch to set arbitrarily. Use it only when the server explicitly provides the same flow and the client’s core supports that combination. Leaving it blank and entering a value can correspond to different server configurations. If flow is missing after importing a link, first check the subscription output format and parsing results instead of adding a value to every entry. When entering details manually, compare each field with the original parameters rather than relying on a generic screenshot.

How to choose between them

If you already have a VMess server that works reliably and your subscription includes its identity, transport, and security settings, there’s no need to switch protocols just for a newer-sounding name. For a new configuration, check what the server actually provides and whether the target core supports its transport and security options. VLESS has a relatively lightweight protocol layer, but total connection overhead still includes TCP, any TLS handshake, the selected transport, and application traffic. A lighter protocol layer doesn’t mean faster performance in every network scenario. For most users, a consistent configuration and stable connection matter more than small differences in framing.

When migrating an existing server, keep the original entry for comparison, then import a new entry and check its fields. Two entries using the same address and port don’t necessarily share authentication settings. For testing, keep the device, network, and application the same, then check whether the connection succeeds. Don’t change the protocol, transport, and system proxy at the same time—you won’t know which change made a difference. For client import steps, continue with the Getting Started Guide.

3. Trojan and Shadowsocks: More Than Just a Password Field

Trojan’s reliance on TLS

Trojan uses a password for authentication and is typically deployed over a TLS connection. Common client fields include the address, port, password, and server name; certificate validation should match the server configuration and domain. Trojan’s password is not the same as the UUID used by VMess and VLESS. A GUI may place both near “user information,” but their meanings aren’t interchangeable. When you receive a Trojan share link, check that it includes the server name. The address may be a domain or an IP address, while the TLS handshake needs the name expected by the server. Don’t infer every handshake parameter from the destination address alone.

Trojan can also be combined with additional transport settings, depending on the core and server. You can’t compare its speed just by counting the proxy protocol’s framing bytes: establishing a TLS connection, network round-trip time, and connection reuse all affect the first request. Ongoing transfers depend on network quality, server load, and application data volume. For an existing entry, it’s more useful to confirm that the password, server name, and TLS settings match, then verify that the application is actually sending requests through the client’s local proxy.

The method field in Shadowsocks

Shadowsocks is often abbreviated to SS and uses a password and encryption method as key parameters. Its ecosystem dates back to the early days of proxy clients, which typically ask for the server address, port, password, and method. Different methods aren’t interchangeable: the client method must match the one used by the server, not just the password. Some methods also have specific implementation requirements, so “supports Shadowsocks” doesn’t mean “supports every method.” If an imported entry is listed but won’t connect, check that the method was parsed correctly in the edit window before changing routing rules.

Shadowsocks and Trojan may both show a “password” field, but the field alone doesn’t identify the protocol. They use different connection formats and server implementations; pasting SS settings into a Trojan entry won’t create an equivalent configuration. Optional Shadowsocks plugins or extra transport layers shouldn’t be mistaken for the protocol itself. If your setup includes a method, plugin parameters, and a server name, identify the original format first, then enter each value under the correct field. Don’t put plugin options in the transport security fields.

Choose based on the server you already have

If your existing server uses Trojan, select Trojan in the client and keep its TLS parameters. If it uses Shadowsocks, select Shadowsocks and verify the encryption method. If you manage the server yourself, first confirm that the target client and core support the method, then configure the server and subscription output accordingly. SS has fewer fields, which can make manual entry more straightforward, but the password isn’t the only possible source of errors: the method, port, and plugin parameters must also match. Trojan may look simple to configure, but the TLS server name and certificate validation still matter.

Maintenance also matters when comparing the two. When several people share setup instructions, clearly documenting the protocol, method, or TLS name helps prevent mistakes more than sending only “address + password.” After the subscription source updates its parameters, review the entry details to confirm the expected fields actually changed. To organize subscription groups and filter entries by purpose, see Subscription Groups and Node Filtering. Renaming a protocol isn’t a way to organize the list.

4. REALITY: Often Listed Alongside Protocols, but Part of the Security Layer

Understand the common combinations

REALITY is a transport security mechanism in the Xray ecosystem and is commonly used with VLESS. A provider might label an entry “VLESS · REALITY,” which describes two separate settings: VLESS is the proxy protocol, and reality is the security type. The transport must also be checked separately; tcp is a common example. If a client has a VLESS entry but no matching security option, or its core doesn’t recognize REALITY parameters, entering only the address and UUID won’t be enough. When you see a newer security field, first check core support, then confirm that the client’s edit window displays it correctly.

A REALITY configuration typically includes the server name, public key, and short ID specified by the server. Some combinations also use flow and other handshake parameters. The client can’t calculate these values from the domain name. The public key must match the server configuration; don’t reuse a key from another server. The short ID must follow the server’s instructions, and an empty value may have a specific meaning. These fields may be tucked under an expandable “Transport Security” section in the GUI. Open the entry after importing it and check carefully for blank fields or fields that weren’t parsed.

Separate security-layer issues from proxy-layer issues

If the REALITY handshake parameters don’t match, the connection may end before the proxy protocol authenticates the user. Repeatedly changing the VLESS UUID won’t usually help. Check these items in order: confirm the server address and port; make sure the transport matches the server; select reality as the security type; compare the server name, public key, and short ID field by field; then check the UUID and flow. This order helps distinguish a wrong destination, a handshake failure, and an identity mismatch. For the specific cause, check the active core’s logs.

Core logs are closer to the point of failure than the status shown in the list, but one error can have several underlying causes. For example, “handshake failed” doesn’t necessarily mean the public key is wrong; a network interruption or a server-side change can produce a similar error. Keep track of which field you change, and reconnect after each change. If you imported several entries at once, use one entry with complete original parameters as a reference. This helps distinguish missing fields caused by subscription conversion from an unavailable server.

Compatibility and where REALITY applies

Don’t treat REALITY as a universal option that can be enabled for any protocol. Select it only when the server uses it and the client’s core supports that combination. An existing TLS configuration won’t migrate automatically if you change the security type to reality; they require different parameters. If a subscription mixes standard TLS and REALITY entries, preserve each entry’s original security type instead of changing them all at once. v2rayN uses the selected core to run the configuration. On Android, check the core used by v2rayNG or v2flyNG and its actual support as well.

Before entering settings manually, make a short checklist of the protocol, transport, and security fields from the original link, then compare them one by one after entry. “Saved” in the client only means the form accepted the input; it doesn’t prove the server can handle that combination. If the core reports an error at startup, check core and field support. If it starts normally but can’t connect, check the server parameters and network path. For startup errors, see Troubleshooting Xray Core Startup Failures.

5. V2Fly, Xray, and the Role of GUI Clients

Different core families in the same ecosystem

Project V has grown into an ecosystem of protocols, configuration formats, and client tools. V2Fly continues the V2Ray project’s core development, while Xray is an independently developed core family with its own implementations of some protocol extensions, transports, and security features. They share historical roots and similar configuration concepts, but they aren’t identical programs with different names. “Supports VLESS” doesn’t mean a core supports every VLESS flow, security type, or extended field. Check compatibility for the specific combination of fields, especially newer security mechanisms and transport options.

GUI clients organize server entries, subscriptions, and routing settings into configurations the core can use. v2rayN is for Windows, macOS, and Linux, with desktop tools for editing servers, managing subscriptions, configuring routing, and setting the system proxy. v2rayNG is an Android client that uses the Xray core; v2flyNG is an Android alternative that uses the V2Fly core. On Android, if your server configuration relies on an Xray-specific feature, check that v2rayNG supports it. If it relies on the V2Fly ecosystem, check whether v2flyNG supports your setup. The client’s name is not the protocol name and can’t replace the server parameters.

Configuration compatibility has three layers

First is conceptual compatibility: both cores may understand concepts like “outbound,” “routing rule,” and “user ID.” Second is syntax compatibility: the same concept may use different fields, values, or defaults in configuration files. Third is feature compatibility: a core may parse a protocol without implementing every related extension. GUI clients add their own import parsing and configuration conversion on top of these layers. A native core JSON file, a share link, and a subscription text file are therefore not equivalent formats with different wrappers.

If a server works on one device but not another, compare the edit details on both—not just the display names. Check the protocol, transport, security type, flow, server name, and identity fields, then check whether the Android client’s core supports those values. Some fields may be ignored during import while the client still creates a visible entry; others may trigger an error only when the core starts. Separating “import succeeded,” “core started,” and “application request succeeded” can narrow down the issue considerably.

This routing example is a core setting, not a subscription link

The snippet below shows a routing rule that sends a domain to an outbound named direct. It’s a JSON object fragment and only works when added to a complete core configuration with a matching outbound. Don’t paste it into the client’s subscription URL field. The example domain is included only to show where the field goes.

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

domainStrategy controls how routing handles domain names; type specifies the rule type; and outboundTag must refer to an outbound defined in the complete configuration. Routing decides which outbound handles a request; it doesn’t change the server protocol used by that outbound. If you want to build rules around domains and DNS results, check how DNS and routing interact. See V2Ray DNS Split Routing Configuration. Get the basic connection working before changing routing, so you don’t confuse DNS issues with protocol issues.

6. Connection Speed, Resource Use, and Battery Life on Android

First connection and ongoing transfers are different

“Speed” includes at least connection setup time, time to the first response, and sustained throughput. Protocol framing and authentication can affect processing overhead, but the first connection also depends on DNS lookup, TCP setup, TLS or another security handshake, the transport handshake, and network round-trip time. Transports such as WebSocket and gRPC add their own processing steps; whether they’re worthwhile depends on the existing server setup and application needs. Large transfers over an established connection may be limited mainly by bandwidth, congestion, server load, and device performance. There’s no basis for ranking VMess, VLESS, and Trojan by absolute speed based on their names alone.

For a fair comparison, keep the conditions consistent: use the same network, a similar time of day, the same server resources, and the same security and transport settings. Also distinguish a fresh connection from an established one. If you compare VLESS + tcp on one server with Trojan + TLS on another, any difference reflects the servers and networks as well as the protocols. A connected status in the client only shows whether that stage completed; test real application requests to confirm the app is using the expected route. On desktop, also check whether the system proxy is enabled and whether the application uses it.

CPU and memory use come from the entire processing chain

The core handles encryption and decryption, protocol framing, routing matches, DNS, and logging. Handshakes and DNS may be more noticeable with many short connections; encryption and data copying can account for more of the work during sustained high-volume transfers. More complex routing rules, verbose logs, and a larger number of simultaneous connections also affect resource use. VLESS has a relatively lightweight protocol layer, but that doesn’t mean the whole configuration always uses less CPU. Changing the security type or transport also changes the overall processing path. When measuring resource use, note which applications and traffic types are active, not just whether the client is running.

Assessing battery use on Android

On Android, battery use with v2rayNG and v2flyNG can be affected by the system network interface, background keep-alive activity, Wi-Fi or mobile network conditions, and frequent wakeups. The protocol is only one factor. Streaming or syncing continuously keeps the network and processor active; apps that repeatedly open short-lived connections can increase wakeups and handshakes; and a weak mobile signal can increase radio power use. No protocol can be guaranteed to use the least power. For a fair comparison, use the same network conditions and similar application activity, then check actual active time in the system’s battery usage stats.

If idle battery drain seems unusually high, first distinguish ongoing traffic handled by the client from repeated reconnects. Check whether subscription auto-updates are too frequent, look for apps making continuous background requests, and see whether network changes cause repeated connection attempts. To reduce overhead, start by cutting unnecessary background activity, reviewing background operation settings, and making sure the server configuration matches the client core. Switching protocols without changing these conditions often won’t isolate the cause. Don’t draw conclusions about all-day battery life from a brief test.

7. Subscriptions and Share Links: Importing Doesn’t Guarantee Complete Settings

Know which of the three input types you have

A client may accept a single share link, subscription text containing multiple links, or structured subscription content defined by a provider. A single link usually starts with a protocol identifier and encodes server fields. A subscription URL, on the other hand, is where the client retrieves content; it isn’t itself a server. Some providers also publish configuration files for specific clients. A URL opening in a browser doesn’t mean v2rayN, v2rayNG, and v2flyNG can all parse it the same way. Before importing, check the format specified by the provider and choose the matching import option in the client.

Compatibility has at least two parts: whether the client recognizes the subscription format, and whether its parser preserves all fields each server entry needs. Seeing entries in the list only means the parser extracted some displayable information. For VLESS + REALITY, check the UUID, transport, security type, public key, short ID, server name, and any flow. For Shadowsocks, check the method, password, and plugin parameters. For Trojan, check the password and TLS name. After a bulk import, inspect representative entries from different protocols. This is more likely to reveal conversion issues than testing only the first entry.

How updates, groups, and manual edits interact

Subscription groups organize sources and can have their own update policies and filter rules. An update generally fetches the content again from the remote source, so entry names and parameters may change. Whether manual edits to a subscription entry survive the next update depends on how the client handles them. It’s safer to fix the subscription source or manage entries that need ongoing independent changes separately from subscription-generated entries. Filter keywords organize the list; they don’t fix protocol parameters.

If a subscription URL imports an empty list, first confirm it returns content the client can read—not just an informational page that opens in a browser. Then check whether group filters exclude all entries, whether you’ve mistaken a single share link for a subscription URL, and whether the content uses another format. Don’t invent entries by guessing server addresses; if the original format doesn’t include key fields, the client can’t recover them from display names. When using multiple sources, give each group a clear alias so you can trace where entries came from.

Check shared fields before moving between clients

When moving a server from desktop v2rayN to Android, use a share link or subscription format that the target client explicitly supports, then verify the imported entry details. Routing groups, system proxy settings, and Android per-app proxy settings are local client behavior; they don’t move with a server share link. The server parameters may be the same, but you still need to configure which traffic is proxied on each device. When using v2flyNG, also check whether the entry requires Xray-specific features. Changing how the subscription is encoded won’t add support for features the active core doesn’t have.

A reliable migration takes two steps: first, import and connect to one representative entry with complete fields on the target device; then migrate the full group. If the first entry fails, keep the original link and compare it with the imported fields to determine whether the issue is text parsing, core startup, or the application request. If you have many groups, see Subscription Groups and Node Filtering to organize them by purpose, then choose an update schedule. This makes it easier to retain troubleshooting clues than repeatedly deleting and reimporting every entry.

8. Choose by Use Case and Verify Each Layer

Start with the source, then consider the device

If you already have a server or subscription, follow the protocol and complete parameters it provides instead of choosing a preferred protocol name and trying to retrofit the entry. On desktop, use v2rayN and choose the installer for your version of Windows, macOS, or Linux. On Android, check that v2rayNG supports the Xray features you need. If your existing configuration targets the V2Fly core, see whether v2flyNG is suitable. Find the available installers on the client downloads page. After choosing a client, confirm that its active core can run the server’s protocol, transport, and security combination.

If you manage the server and need to choose a new configuration type, start with the server features your team maintains, the subscription formats you already generate, and the devices you need to support. If you need REALITY, first check that the core and client support the relevant fields, then plan the VLESS configuration. If you already have a stable VMess or Trojan setup, documenting its fields clearly is safer than migrating just to standardize names. For Shadowsocks, confirm the target clients share support for the method. Test one representative entry before generating a full subscription. No protocol is “best” in isolation from the server and devices.

Find the failure in one of three stages

Stage one is import: does the entry appear, and do its details include the key fields from the original configuration? Stage two is core startup: do the client logs report unknown fields, invalid parameters, or a local port conflict? Stage three is the application request: once the core starts, does the target app use the correct local or system proxy, and do the routing rules send its traffic to the expected outbound? If import fails, check the subscription format. If startup fails, check the core and field combination. If the application request fails, check system settings, DNS, routing, and application behavior. Don’t label every failure “protocol unsupported.”

Desktop browsers and command-line tools may use different proxy settings. The “Set system proxy automatically” option in v2rayN’s tray menu mainly affects applications that follow the system proxy. Terminal tools may also need their own environment variables or application-level settings. If the browser works but the terminal doesn’t, check where each gets its proxy settings before changing the server protocol. For the steps, see Troubleshooting the macOS System Proxy in Browsers and Terminals. Browse Frequently Asked Questions by topic for common setup questions.

Keep a record of settings you can verify later

For each representative entry, record the protocol, transport, security type, core family, and configuration source—but don’t record credentials or other login secrets. After updating a subscription, switching cores, or changing server settings, recheck these details before testing the connection. If something goes wrong, note the error type and the order of changes. Remove addresses, identities, passwords, and other sensitive details before sharing logs. Keeping track of which layer changed makes troubleshooting much easier than simply noting “it worked before, but not now.”

Configure routing only after verifying the basic connection. First confirm the client can connect using the correct server settings, then set up LAN bypass, split-routing rules, or DNS as needed. To share a local proxy port with other devices, you’ll also need to configure the listening address and system firewall; the server protocol alone doesn’t determine whether sharing will work. For details, see Allow LAN Connections. Change one layer at a time and retest with the same application so you can interpret the results.

Use the same sequence when moving from manual entries to subscription management: verify one connection first, then test bulk import, and finally configure routing and the device’s proxy scope. If this is your first setup, follow the interface steps in the Getting Started Guide. If you’re already connected and just need to identify a field, consult the relevant section on this page. Treat protocol selection, core compatibility, and application proxy settings as separate steps so you can pinpoint what changed.