V2Ray Protocol and Core Technical Reference

Before you open a node in v2rayNG or v2rayN, it helps to separate three layers of the stack; the choices further down get much clearer. Those layers are the client, the core, and the protocol plus transport, and what you can change in each one is not the same.

What each layer handles

The client is the layer you can see. On desktop that is v2rayN; on Android it is v2rayNG and v2flyNG. The client handles the interface, subscription management, routing toggles, and per-app proxy, and it translates node details into a configuration the core can read.

The core is the program that actually opens the connection. It reads a JSON configuration, accepts local traffic through inbounds, sends traffic out through outbounds, and uses the rules in routing to decide which outbound to take. v2rayNG runs the Xray core, v2flyNG runs the V2Fly core, and the desktop v2rayN also favors the Xray core. The core determines which protocols are available — REALITY, for example, exists only on the Xray side, so importing a REALITY node into v2flyNG will fail to parse.

Protocol and transport is the layer that decides real-world behavior. Protocol means the identity and encapsulation scheme — VMess, VLESS, Trojan, Shadowsocks, REALITY; transport means the carrier — TCP, WebSocket, gRPC; and on top of that comes whether TLS is used. This layer usually arrives with the subscription and rarely needs to be written by hand.

In daily use, only a few settings are actually yours to change

Open the client settings and the options an ordinary user really touches cluster in a few places: which node to use, which routing mode, which apps go through the proxy, and whether to start on boot. Protocol and transport come with the node; they are not edited on the spot. So "choosing the right protocol" happens when you pick a subscription or tidy up a self-hosted configuration, not every time you connect. Understanding protocol differences pays off in two ways: when one subscription contains nodes on several protocols, you know which to try first; and when a node will not connect, you can tell whether the problem is in the protocol parameters or in the link itself.

How this page and the Quick start page divide the work

Quick start covers the shortest path to a working connection: import a subscription, pick a mode, connect, verify — only the necessary action at each step. This page does not repeat that main line; it explains the choices behind each step — where the protocols differ, how to choose between the two cores, how subscription fields map to each other, and which combination fits which scenario. If you just want to get online as fast as possible, start with Quick start; if you are choosing a subscription, tidying up a self-hosted configuration, or chasing a stubborn problem, stay here.

Find a chapter by goal

• Want to know how the five protocols differ by design → Protocol family
• Want to compare handshake cost and resource use → Speed and overhead comparison
• Want to know how the v2rayNG and v2flyNG cores differ → Core family
• Subscription import fails or fields do not line up → Subscription formats and compatibility
• Want to understand how transport and routing modes affect things → Transport and routing
• Concerned about battery drain on Android devices → Mobile battery behavior
• Want the recommended combinations up front → Choosing by scenario
• Need a field reference or a troubleshooting checklist → Parameter reference and troubleshooting

Terminology

In this page, node means one complete outbound configuration — server address, port, identity fields, and transport parameters; subscription means a link or file that carries several nodes; core means a processing program from the v2ray-core family; inbound and outbound are the entry and exit points for local traffic. Flow control means the protocol-layer parameters that govern how data is forwarded. REALITY is discussed here as a protocol-layer option, in terms of selection and compatibility, without going into server-side deployment details.

Differences between protocols are mostly not the kind of question — "which one is faster" — that fits in one sentence. They come down to what each design solved first and what it deliberately gave up. Look at the five protocols from their original starting points and most of your selection questions get easier.

VMess: authentication and encryption built into the protocol

VMess is a protocol the V2Ray project created early on, aimed at confirming identity and encapsulating data over links of uneven quality. It carries its own UUID identity field and timestamp check; early versions generated a batch of sub-identities through the alterId mechanism, and later moved to AEAD authenticated encryption, with alterId set to 0 becoming the mainstream practice. The design point is that authentication and encryption both happen inside the protocol, so it works without an outer TLS layer. The cost is an extra encapsulation layer on every packet, plus a request-and-response exchange between client and server at handshake time, which means a few more processor wake-ups on mobile devices.

VLESS: handing encryption to the outer layer

VLESS can be read as a subtraction from VMess. It drops the protocol's own encryption layer, keeping only a lightweight identity marker and optional flow-control parameters, and leaves encryption entirely to the outer channel, usually TLS. The trade-off is explicit: give up the ability to encrypt while running bare, in exchange for a shorter handshake path and fewer encapsulation bytes. VLESS therefore has to be paired with TLS or an equivalent reliable encrypted channel; run bare, it provides no confidentiality. In the Xray core, VLESS can use the flow parameter to enable XTLS Vision flow control and cut the number of encryption layers further.

Trojan: keeping traffic looking like ordinary HTTPS

Trojan does not invent a new traffic shape; it keeps proxy traffic looking like an ordinary HTTPS visit. The server listens on port 443 and holds a real certificate, forwards traffic when the password is correct, and falls back to a real website when it is not. Seen from outside, it is just a normal web server. The trade-off: you must own a domain and a valid certificate, and a mistake in the certificate or port configuration makes it completely unusable; in return there are few configuration concepts to learn and the traffic shape stays very close to regular HTTPS.

Shadowsocks: lightweight symmetric encryption

Shadowsocks takes the lightweight symmetric encryption route. Client and server share a password, the encryption key is derived from it, and there is no extra identity handshake field. Common ciphers are AEAD algorithms such as chacha20-ietf-poly1305 and aes-256-gcm. Its encapsulation overhead is the smallest of the options and its implementation the simplest, which is why it still shows up on devices with limited compute. The cost is that the protocol itself offers no obfuscation layer, so the traffic signature is fairly fixed and has to be supplemented by an outer wrapper or a plugin.

REALITY: borrowing a real site's handshake

REALITY came out of the Xray side and targets one specific problem: the cost of maintaining certificates. A conventional TLS setup requires owning a domain and a certificate; REALITY instead borrows the certificate chain of a real site during the handshake — the client already knows the target site's public key, verification is against that target site, and the server does not need to hold a certificate of its own. For the user, a REALITY node usually needs only a few parameters: the public key, shortId, and the target domain. It is currently paired mainly with VLESS and used together with XTLS Vision flow control.

Trade-offs of the five options side by side

The table shows a clear line of evolution: earlier designs tended to build capabilities into the protocol itself, while later ones hand them to the outer layer and keep the protocol as thin as possible. That line also explains why newer protocols usually require TLS — they moved the security boundary outward.

"Which protocol is faster" has to be broken apart first. The time a connection takes has three parts: the physical round trip, the number of handshake round trips, and the processing time for encryption and encapsulation. The first two depend on server location and link quality, not on the protocol; the protocol only affects the third, plus how many round trips the handshake needs. So switching protocols on the same server usually shows very little difference, while switching servers can change things a lot.

Handshake path: how many round trips

The VMess handshake is a two-part request and response: the client sends its identity and waits for the server to confirm. VLESS carries only a lightweight identity marker and does not wait an extra round. Trojan uses a standard TLS handshake, with the password checked in application-layer data after the handshake. Shadowsocks has no identity round trip at all — the key is derived straight from the shared password. REALITY's handshake looks the same as visiting a real site, and the client verifies the target site's certificate chain. The fewer round trips, the shorter the time to first byte on a high-latency link.

Encapsulation layers: how many times encryption runs

The number of encapsulation layers sets the processor cost. VMess encrypts on its own, so wrapping TLS around it means encrypting and decrypting twice; VLESS and Trojan do no encryption themselves and only run one TLS layer; with XTLS Vision, REALITY can pass proxy data straight through and avoid repeated encryption. On a desktop processor these differences are hard to notice; on a low-power Android device they show up as battery drain and heat, which the Mobile battery behavior chapter covers in detail.

Three overhead dimensions compared

When the differences become noticeable

Protocol differences become visible in three situations: when the link itself has high latency, the effect of handshake round trips is amplified; when the device has limited compute, encryption layers translate directly into battery drain and slower speeds; and when many connections run at once, the per-connection cost adds up. Conversely, on low-latency fixed broadband with a mid-range or better device, the felt difference between VMess and VLESS is usually too small to reproduce reliably.

How to run your own tests and get meaningful results

In the v2rayNG node list you can start a latency test from the menu; the two common kinds are the TCP test and the real-connection test. The TCP test only checks whether the address and port are reachable — fast, but it tells you little. The real-connection test actually establishes a proxy connection, so the result is closer to real use. To compare protocols, work in this order:

1. Fix one server and write the same configuration as a separate outbound for each protocol.
2. Run the real-connection test three times for each and record the range, not a single figure.
3. Finish all the tests in the same time window so you are not comparing across periods.
4. Then add a real browsing test to confirm the numbers match what you feel.

If the three rounds overlap, the protocols are indistinguishable on your current link, and the choice should turn to other factors: whether obfuscation is needed, certificate maintenance cost, and device battery use. For the full workflow of filtering nodes the same way, see First connection check.

A subscription is the main channel for node details to travel from a provider to a client. Understanding its format helps you pinpoint an import failure quickly and keeps fields from getting lost when you move a configuration between clients.

Subscription link vs. share link

A share link describes a single node and looks like vless:// or vmess://; copy one and you import one node. A subscription link describes a group of nodes and is itself an HTTP or HTTPS address; the client fetches it and receives a block of text in which every line is a share link. The value of a subscription is updating: when nodes are added or removed the provider changes one place, and the client syncs on its next refresh instead of you copying each link again.

How the text is encoded

Subscription responses come in two common forms: plain-text share links on separate lines, or the whole block Base64-encoded into a single string. On import the client first tries to parse it as plain text and, if that fails, decodes it as Base64 and parses again. So when you inspect a subscription by hand and see one long string with no line breaks, decode it as Base64 first. After decoding, every line should start with a protocol name.

Field layouts of the four share link types

As you can see, VMess and Shadowsocks pack their fields into a Base64 segment, while VLESS and Trojan spread them across URL query parameters. REALITY nodes usually appear as vless:// links carrying two extra parameters, the public key and shortId; leave out either one and the handshake cannot complete.

Common causes of import failure

• The Base64 segment was truncated while copying, a few characters are missing at the end, and the decoded result is incomplete.
• The server address in the share link is a domain name that does not resolve in your current environment, which shows up as a successful import followed by a failed connection.
• The public key or shortId is missing from a REALITY node, so the node appears after import but the handshake never completes.
• A node in the subscription uses a feature the current client core does not support, so it is skipped on import.
• The subscription URL needs extra request headers or authentication parameters, so it opens when pasted into a browser but fails to fetch in the client.

What the client builds internally after an import

Once the import finishes, the node is translated into JSON the core can read. Below is the minimal skeleton of a VLESS outbound, with the same field names as a real configuration and the address and identity swapped out:

{
  "outbounds": [
    {
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "serverName": "www.example.com",
          "publicKey": "example-public-key",
          "shortId": "0123456789abcdef"
        }
      }
    }
  ]
}

Compare against this skeleton and the import process makes sense: every query parameter in the share link ends up on some key under settings or streamSettings. When fields do not line up, the problem is usually in the link itself, not the client.

Syncing when several clients coexist

Import the same subscription in v2rayN and v2rayNG and the node lists should in theory match. If a node exists on desktop but not on Android, check that node's protocol and transport first: REALITY nodes and VLESS nodes with a flow parameter are skipped by cores that only handle basic protocols. When a subscription updates, clients usually replace the whole subscription group, so local renames or reordering of individual nodes may not survive — for important nodes, note the key fields separately. For several ways to move a configuration between devices, see Syncing V2Ray configurations across devices.

The same protocol parameters can behave completely differently under another transport. Transport decides how data is carried; routing decides which traffic enters the proxy. Together they shape connection success rates and day-to-day experience.

Common transports

The practical rule for transport: if TCP works, use TCP; consider WebSocket and gRPC when you need to sit behind a front-end service or use a specific port. WebSocket has the most configurable options, and a wrong path or Host header is one of the most common causes of connection failure; gRPC has an edge on links with fluctuating quality thanks to multiplexing, but it adds a service name parameter that will also break the connection if it is wrong.

Where TLS and SNI fit into the choice

TLS decides whether traffic is encrypted; SNI declares which domain you are visiting to the other end during the handshake. For VLESS and Trojan, TLS is a prerequisite rather than an option; for VMess it is a layer you can add. REALITY points SNI at a real site and verifies that site's certificate chain during the handshake, so the serverName in the configuration must match the target site — get it wrong and the handshake fails. When choosing a transport, check the SNI field that comes with the subscription first, then decide whether anything extra is needed.

Three routing modes to pick from

v2rayNG and v2rayN usually offer three routing modes:

• Proxy only: traffic is split by built-in rules — what matches goes through the proxy, the rest connects directly. The most common choice day to day.
• Bypass LAN: LAN addresses connect directly and everything else goes through the proxy. Suits setups where you need to reach local devices such as a router admin page or network storage.
• Global: all traffic goes through the proxy. Useful for troubleshooting, but in daily use it adds unnecessary data consumption.

The three modes correspond to different rule sets in the routing section of the core configuration. Switching modes does not change the node itself, only which traffic is sent to the outbound.

Per-app proxy and start on boot

Per-app proxy on Android decides by package name whether an app goes through the proxy, which suits setups where only a few apps should. Once enabled you tick apps one by one, and anything unticked connects directly. Desktop clients have no such setting; rules by process or address range take its place. Start on boot suits devices that stay online for long stretches; on a mobile device it keeps a background connection alive, so whether to enable it depends on how often you use the proxy.

How domainStrategy relates to DNS

The domainStrategy in routing rules decides when a domain name is resolved to an IP. There are three common values:

This setting is coupled with your DNS configuration: if DNS queries do not go through the proxy, the resolution results can expose your real exit. The related symptoms and how to check them are collected in V2Ray DNS leak detection and prevention settings. When you need all traffic taken over by a virtual network adapter, see How TUN mode works and how to enable it.

The earlier chapters boil down to one order of judgment: confirm core support first, then weigh link quality and maintenance cost, and finally fine-tune by device type. Below are suggested combinations for common scenarios.

A three-step order

1. Check the core: does the node use REALITY or a flow parameter? If so, use a client on the Xray core; if not, either core covers it.
2. Check the link and maintenance cost: are you willing to maintain a domain and certificate? If yes, Trojan and VLESS with TLS are both mature choices; if not, VLESS with REALITY removes the certificate step.
3. Check the device: on low-power devices prefer options with fewer encapsulation layers; on desktop, choose for convenience.

Scenarios at a glance

Combinations to avoid

• Running VLESS without TLS: the protocol itself offers no confidentiality, so data travels the link unprotected.
• Using REALITY nodes on the V2Fly core: the core does not support the scheme, so the configuration cannot take effect.
• Treating Shadowsocks as the only option for every scenario: it lacks protocol-layer obfuscation and has few configurable options, leaving no fallback when a link needs a custom path.
• Leaving global mode on all the time on a mobile device: all traffic goes through the proxy, so connection counts and wake-ups both rise.

A workflow you can actually run

1. Import the subscription in the client and confirm the node count matches expectations.
2. Group nodes by protocol and test the ones with fewer encapsulation layers first.
3. Use the real-connection test to filter out nodes that do not work; for the steps, see First connection check.
4. Pick two or three nodes as your regulars and keep the rest as backups.
5. Adjust routing mode and per-app proxy to suit the device type.

For a side-by-side protocol comparison you can also read VMess, VLESS, Trojan, and SS compared, which covers handshake cost, latency, and scenario-based selection and complements the tables on this page. Client choices and system requirements are collected in the download center, and the differences between the three clients in the selection guide.

This chapter closes things out as an index: what the common fields mean, which checks match which symptoms, and where to go next on the site.

Common fields at a glance

Symptoms and what to check

Related pages

• Quick start: the full path through importing a subscription, choosing a mode, connecting, and verifying.
• Download center: platform entries and system requirements for the three clients.
• Selection guide: a side-by-side comparison of v2rayN, v2rayNG, and v2flyNG.
• FAQ: organized by basics, installation and setup, usage tips, and Troubleshooting.
• First connection check: picking nodes, real-connection speed tests, and verifying the proxy is working.
• DNS leak detection: symptoms, where to check, and the relevant settings.
• Multi-device configuration sync: the trade-offs of three ways to move a configuration.
• Four protocols compared: handshake cost, latency, and scenario-based selection.
• TUN mode: how it works and the order to enable it.

One last note

Everything on this page rests on the public design of the protocols and cores and does not touch server-side deployment parameters. There is no single right answer for protocol choice: the same subscription can behave differently on different links, and the same server can drain batteries differently on different devices. Treat this page as the basis for judgment and your own tests as the final word; together they lead to a combination that fits you. If your question is not covered here, look it up by category in the FAQ, or go back to Quick start and walk the main path again.