V2Ray Protocol and Core Guide

Configuration Layers: A Protocol Name Isn't a Complete Connection Setup

Separate the proxy protocol, transport, and security layers

A server profile in a client involves at least three questions: which protocol describes the destination and identity, which transport carries the data, and how the secure connection is established. VMess, VLESS, Trojan, and Shadowsocks mainly answer the first question; TCP, WebSocket, and gRPC address the second; TLS and REALITY are security-related options. A client may put these fields in the same editor, but they serve different purposes and aren't interchangeable. Knowing only that a server uses VLESS isn't enough to recreate its connection.

For example, two profiles may both use VLESS, but one uses TCP with REALITY while the other uses WebSocket with TLS. Their handshakes, required fields, and server-side setup all differ. Copying the first profile's public key into the second, or entering the second profile's path in the first, usually won't fix anything. Record the protocol, transport, and security layer separately, then note the address, port, and authentication details. That makes it easier to check what each field means, even if the client interface changes.

Distinguish the server address from the handshake name

The server address determines where the connection goes first; it can be a domain name or an IP address. In TLS, the server name is usually provided through the SNI field for the handshake and certificate identity check. It doesn't have to exactly match the text in the address field, but it must match the server's setup. The WebSocket Host is an HTTP request header, while the path selects an access endpoint. These fields sometimes use the same domain, which can make them look redundant. Check each one separately when troubleshooting; changing the address alone doesn't necessarily update the other names.

Local inbounds, system proxy settings, and routing belong to another group of settings. The local inbound accepts application connections; the system proxy directs some apps to that inbound; routing determines which outbound handles traffic after it reaches the core. If an app doesn't use the system proxy, changing protocol encryption won't route it through the core. If a route sends traffic direct, switching servers won't change that connection's outbound. Android VPN capture works differently from the desktop system proxy, so compare what each setting affects instead of copying every toggle across devices.

Change one thing at a time to preserve useful diagnostics

After importing a profile, keep the original and adjust local behavior one item at a time. Use the server-provided details for the address, authentication, transport, and security settings; set the local port, per-app scope, and log level to suit your device. Changing the protocol, DNS, and routing all at once makes both success and failure hard to explain. Make a copy for comparison, change one variable, and note whether the error occurs at startup, during the handshake, or while accessing a destination. See the glossary for brief field definitions; use the Getting Started Guide for the full first-import procedure.

VMess: Authentication, Time, and Encryption

Design background and connection overhead

VMess is an important early proxy protocol in the Project V ecosystem. It incorporates identity authentication, request details, and data protection into its design. It isn't simply a label added to an ordinary TCP connection: the client and server must process requests using the same format. For choosing a setup, VMess offers mature ecosystem support and a range of transport combinations. The trade-off is that you need to understand how its own encryption relates to an outer secure connection. With older profiles, distinguish legacy authentication schemes from current implementations; not all VMess links use the same format.

You can't judge VMess speed by whether it's encrypted. A request involves local name resolution, a transport connection, authentication, and forwarding at the remote end. Adding TLS on top also adds handshake work. Modern processors have varying levels of hardware support for common encryption algorithms. Small requests may be limited mainly by round-trip time, while sustained downloads are more likely to reveal throughput limits. If VMess seems slower than another connection, first confirm that the routes, server load, and transport are comparable before attributing the difference to protocol overhead.

UUID, encryption, and the limits of alterId

When editing a VMess profile, the UUID is an identity credential, not a node label or a random string you can generate and use on your own. Both implementations must support the selected encryption method. An automatic option in the client usually picks an algorithm for the current environment; it doesn't fix authentication errors. Don't choose a mode without data encryption just to reduce overhead. The outer TLS layer and the protocol's own protection have different roles. Use a particular combination only when the deployment calls for it, not because fewer layers are always better.

Older guides often mention alterId. It relates to a legacy compatibility mechanism; modern VMess AEAD profiles typically use a value of zero, and some clients hide the field. If a subscription still includes a non-zero value, changing it to zero doesn't complete a migration—the server must support the corresponding authentication method. First confirm the provider's requirements, then check whether the active core supports that format. Keeping an outdated parameter can lead to a successful import but a failed connection. A profile that passes syntax checks doesn't prove that client and server authentication match.

Check system time before transport fields

VMess authentication involves time, so a significantly incorrect system clock can cause requests to be rejected. Start troubleshooting by enabling automatic time sync and checking the date and actual time, not just the displayed time zone; a different time zone doesn't necessarily mean the clock is wrong. Then check the UUID, port, and whether the server still accepts the profile. Once the authentication details are confirmed, move on to the WebSocket path, Host, and other transport fields. This helps avoid mistaking an authentication problem for a network outage.

When importing a VMess link, check how its fields map to the client's editor. Some legacy links use older fields for the transport name, TLS toggle, and hostname, and an importer may fill in defaults according to its own rules. Review the imported settings, especially the address, SNI, path, and encryption method; don't rely only on the protocol label in the profile list. If the same profile works on another device, compare the fields and core logs instead of repeatedly deleting and re-pasting the same link.

VLESS and REALITY: Keep the Lightweight Protocol Separate from the Secure Handshake

VLESS reduces the protocol's built-in responsibilities

VLESS is designed to simplify the protocol's own authentication and request handling. Unlike VMess, its base protocol doesn't provide the same kind of data encryption. In common configurations, encryption is set to none; that describes this layer and doesn't mean the entire connection is necessarily unencrypted. To determine whether the connection is protected, check whether the outer layer uses TLS or REALITY and whether its verification is configured correctly. This layered design is flexible, but don't generalize the meaning of one field to the whole connection.

So VLESS can't be reduced to “no encryption means faster.” Reducing some protocol processing is only part of the cost; TLS or REALITY still handles handshakes and data protection, and transport encapsulation can also be a significant overhead. Whether VLESS suits a device depends on the server's combination, the core implementation, and network conditions. On desktop, first confirm that the core used by v2rayN supports all required parameters. On Android, confirm that the client core and profile type match; recognizing a UUID doesn't prove that all features are supported.

REALITY is not a standalone proxy protocol

REALITY is a secure connection option in the Xray ecosystem and is often used with VLESS. The client typically needs the server's public key, server name, shortId, and a fingerprint setting. These values work together in the handshake and can't be derived from a standard TLS configuration. REALITY handles configuration differently from certificate-based domain verification, but that doesn't mean identity checks can be ignored. The client should hold only the public parameters needed to connect; the server's private key must never appear in subscriptions, screenshots, or client input fields.

A public key may look like a string you can simply copy, but it must correspond to the server's key. The shortId must also match a value and format accepted by the server. The server name must meet the deployment requirements; don't fill it with an arbitrary reachable domain. The fingerprint option controls related handshake behavior. It's a compatibility parameter, not a region or speed setting. If an importer omits a field, the profile may still appear in the list but fail during the handshake. Check each value against the original parameters instead of disabling verification to bypass an error.

Flow and transport aren't freely interchangeable

In VLESS, flow identifies a specific flow-control scheme, such as an XTLS Vision-related value. It isn't a general-purpose speed boost and doesn't work with every transport combination. If the server requires Vision, the client must support it and use a compatible transport and security layer. Adding a flow when the server hasn't configured one can cause failures. A parameter excerpt from a tutorial only applies to its complete configuration; don't copy it out of context into WebSocket or another access method.

A practical check order is “protocol and UUID → transport → security layer → public key and server name → shortId → flow.” First confirm that the editor hasn't replaced any fields with defaults, then use the core log to distinguish a parameter parsing error from a remote handshake failure. Parsing errors often indicate unsupported features or invalid field formats; handshake failures call for checking server requirements and network reachability. If a profile starts failing after a subscription update, keep the old record and compare fields instead of assuming the public key changed.

Trojan and Shadowsocks: TLS Requirements and Encryption Methods

Trojan relies on TLS for its secure connection

A typical Trojan connection establishes TLS first, then performs protocol authentication and forwards data. The key client fields are the server address, port, password, and server name. Its configuration may look shorter than some alternatives, but TLS still requires proper identity verification. A certificate name mismatch, an invalid certificate chain, or an incorrect system clock can stop the connection before the password is checked. If Trojan fails, don't start by repeatedly changing the password; check which stage appears in the logs.

If the address is an IP but the certificate was issued for a domain, enter the correct server name as specified by the provider. SNI supplies the name during the handshake, while certificate verification confirms the server's identity. They're related, but not the same setting. Skipping certificate verification weakens identity checks and isn't a routine fix. If the server uses a special trust setup, follow its documented requirements. For a standard public certificate, fix the time, name, or certificate chain and keep normal verification enabled.

Shadowsocks encryption methods are protocol requirements

Often shortened to SS, Shadowsocks is designed for straightforward proxy forwarding and encryption. The client needs the server address, port, password, and encryption method. The method isn't a performance setting you can choose independently; both ends must use the same protocol option. A correct password won't help if the methods don't match. Legacy configurations and newer protocol variants may use different key requirements, so don't assume every SS profile works with just a password swap.

Traditional AEAD methods and the Shadowsocks 2022 series differ in areas such as key handling. The required method name and encoded key format for the latter should come from the server or subscription; don't enter an arbitrary short password. Support depends on the active core, not just on whether the client interface lists Shadowsocks. If an import reports an unknown method, check the spelling and core capabilities first. Changing it to a familiar method won't make the server adopt a different algorithm.

Transport combinations and UDP requirements

Trojan and SS may use additional transport parameters in some deployments, but don't assume a generic share link can represent every extension. In particular, an importer may not support all extra parameters in an SS link. Before using a profile, confirm that the required combination can be represented by the current client and its core. If an extension disappears after import, treat that as a compatibility issue rather than testing the speed of a profile with missing fields.

For voice, gaming, or other datagram traffic, test the UDP path separately. A protocol's UDP support doesn't guarantee that the local inbound, client traffic capture, server forwarding, and destination network all allow datagrams. Successful TCP browsing only confirms that the corresponding request path works. Test with an app that actually needs UDP and check the logs to determine whether the app bypassed the core, the server failed to forward traffic, or the destination didn't respond. Don't blame the app just because a website loads.

Speed, Resources, and Battery: Separate Handshakes from Sustained Transfers

Fast connections and fast downloads are different outcomes

Opening a short webpage is affected mainly by name resolution, connection setup, the handshake, and time to first byte. Sustained downloads depend more on line capacity, congestion control, server egress, and device performance. A protocol that reduces handshake work may improve short connections without increasing long-session throughput. Conversely, a line that downloads well may still feel slow to start because of resolution or handshake delays. When comparing protocols, record connection success rate, first response, and sustained transfer separately; one latency figure can't describe the whole experience.

TCP, WebSocket, and gRPC differ in encapsulation and connection management, but their real-world impact depends on implementation and deployment. WebSocket adds an HTTP upgrade and frame processing; gRPC relies on the relevant HTTP/2 behavior and server support. These transports often serve an access architecture, not a universal goal of reducing latency. Packet loss, congestion, and intermediary devices also affect results. A comparison that doesn't control for network and server conditions can only evaluate those specific connections, not establish a fixed speed ranking for protocols.

CPU, memory, and the limits of connection reuse

Resource use depends on whether encryption can use processor instructions, core buffer strategies, active connection count, and log volume. On a lightly loaded desktop, differences between protocols may be hidden by browser and system tasks. Small devices are more likely to hit thermal limits during sustained high throughput. When monitoring resources, consider throughput and duration too: the same CPU percentage can represent very different amounts of data. Don't assume the client interface's process usage accounts for the core's full resource use; they may run as separate processes.

Connection reuse attempts to let multiple logical requests share fewer underlying connections. It may reduce repeated connection setup, but can also add wait time under congestion, with mixed short and long requests, or when implementations don't match. It isn't a universal optimization for every protocol. Keep the default first; compare settings only when there are many short connections and the server supports reuse. If enabling it causes intermittent pauses, return to the baseline of separate connections. When routing, DNS, and transport also change, you can't credit the results to the reuse setting alone.

On Android, battery use depends largely on wakeups and reconnects

On mobile, battery use depends not only on encryption but also on keeping the wireless connection active, background wakeups, keepalive frequency, and reconnects after failures. A protocol that appears to use less computing power may consume more battery if it disconnects and rebuilds secure connections frequently. Switching between mobile and Wi-Fi networks also adds reconnection overhead. When evaluating v2rayNG or v2flyNG, compare under similar signal strength, screen-on time, and app workload; don't treat one background battery ranking as a fixed property of a protocol.

VpnService captures Android traffic, but that doesn't mean the core has connected successfully. Battery restrictions may interrupt background processing after the screen locks, so the connection may resume when you wake the screen. Per-app settings may also let some apps bypass the core entirely. Check background restrictions and traffic capture scope before changing protocols. See v2rayNG permissions, battery settings, and per-app routing for setup steps. For the difference between latency tests, see How latency testing works; don't use ICMP results as a substitute for real proxy requests.

V2Fly and Xray: Ecosystem Background and Configuration Compatibility

How graphical clients and cores work together

Project V provides useful background for understanding this ecosystem. V2Fly continues V2Ray-related development, while Xray developed from related code and has followed its own feature path. They share some concepts and configuration conventions, but they're not simply different names for the same project. A graphical client manages profiles, subscriptions, local traffic capture, and logs; the core handles connections, routing, and protocol processing. A client editor offering a server type only shows that it can create the profile—the active core still has to run it.

For desktop, v2rayN is a good starting point for managing and maintaining configurations across platforms, but protocol support still depends on the selected core. On Android, v2rayNG primarily uses Xray capabilities, while v2flyNG is an alternative for the V2Fly path. Before choosing between them, check the server's required protocol and extensions, then consider which interface you prefer. Seeing the same subscription in both apps doesn't mean every profile will behave identically in each.

Shared fields don't make configurations fully interchangeable

Both core families may use top-level concepts such as inbounds, outbounds, routing, and DNS, and may support protocols with the same names. However, extensions, defaults, and specific transport support can differ. Don't assume that V2Fly can run REALITY or XTLS Vision features from the Xray ecosystem unchanged just because the JSON looks similar. Migration in the other direction also requires checking V2Fly-specific settings and how the client generates configuration. The safest unit to migrate is the meaning of each field, not a wholesale copy of the file.

Custom configurations and graphical editors may also have different lifecycles. A client typically generates a runtime configuration from settings saved in its interface and may overwrite temporary files at startup. Direct edits to a generated file may not survive the next connection. For persistent customization, use the client's designated custom configuration option and confirm which system proxy, routing, or DNS features the interface still controls. Otherwise, the file may contain one set of rules while the runtime loads another, sending troubleshooting in the wrong direction.

Reading a minimal configuration snippet

The snippet below is an Xray-style routing object. It shows field structure only; it's not a complete, runnable configuration. domainStrategy specifies how domains are handled during route evaluation. Rules are matched in order, and outboundTag must refer to an outbound tag that is already defined. This snippet doesn't create a server or enable the system proxy. Before adding it to an existing configuration, confirm support in the active core and check whether the client regenerates routing settings, so you don't paste a valid rule into the wrong place.

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

Review core updates alongside the client's configuration-generation capabilities. An update may add protocol fields or change compatibility handling, but it won't supply parameters missing from the server. If startup fails, inspect the first parsing error, confirm that the expected core is running, then check the generated configuration fields. If a previously working setup fails after an update, keep a rollback copy and reproduce the issue with a minimal configuration. Open source enables code review and ongoing maintenance, but doesn't make different implementations inherently compatible. See client comparisons for differences between clients.

Subscriptions and Share Links: A Successful Import Doesn't Guarantee Complete Fields

Address, content format, and connection profile are separate things

A subscription URL usually fetches a set of server profiles, while a single share link directly describes one profile. They serve different purposes: subscriptions can be updated later, while share links are generally snapshots of the parameters at the time they were created. A subscription using a regular web URL doesn't mean its content is a webpage, nor does it guarantee that any client can parse it. A server may return a list of links, encoded text, or a specific configuration format; the client needs the corresponding import capability to convert that content into editable server profiles.

A successful subscription download only confirms that a response was received. If the response is a login page, an error, or an unsupported format, the profile list may still be empty. First distinguish a failed request from a parsing failure, then decide whether to change the network route. Some clients let you choose whether subscription updates use a direct connection or an existing proxy. If that profile is already broken, forcing updates through it can create a dependency loop. Check the update setting and available connections before changing anything; don't keep retrying the same URL while switching routes without checking the error.

Where different link formats can lose information

VMess share links commonly contain encoded structured data; VLESS and Trojan links usually express settings through the address and query parameters; SS has multiple encoding formats. Special characters in names, paths, and service names must follow the relevant escaping rules. Chat app line breaks, a truncated copy, or double encoding can change parameters. An importer may tolerate some errors without preserving the original meaning, so always check key fields after import.

VLESS flow, the REALITY public key and shortId, the TLS server name, and the WebSocket Host and path all need careful checking. A format conversion that keeps only the protocol, address, and authentication may drop the extensions that determine the handshake. Don't compare profiles by their labels alone; labels don't affect the connection. See Share links vs. subscription URLs for more on importing; follow its steps alongside the parameter guidance on this page.

Maintain subscription updates separately from local changes

Subscription managers usually update server profiles by group. Which local edits are preserved depends on the client. Changes made directly to a subscription-generated profile—such as its port, name, or transport parameters—may be overwritten on the next update. For ongoing comparisons, make a local copy and note its purpose, but remember that you'll need to sync server-side changes yourself. Routing rules and per-app scope are generally local policies; don't assume a subscription update will fix them. With each change, confirm which layer you're editing.

When moving between clients, import the original subscription again first, then check the extension fields. Don't treat one client's full configuration file as a universal subscription. Desktop system proxy ports, Android per-app lists, and local DNS choices are device-specific and need to be set again after migration. Test at least one real webpage request and any UDP-dependent app you need, then confirm that the update process works reliably. A successful first connection only verifies the current profile; it doesn't prove the next subscription update will map every field correctly.

Choosing a Setup and Troubleshooting: Match Requirements Before Comparing Results

Choose candidate setups based on the server and device

If you already have a working service, start by keeping the combination the server explicitly supports and you've verified, rather than switching protocols for its own sake. On desktop with v2rayN, check the system architecture and installation method first, then confirm the selected core. On Android, if you need Xray-related features such as REALITY or Vision, check the corresponding v2rayNG settings first. If you already have a V2Fly configuration and matching feature requirements, consider v2flyNG as an alternative. Find installation options in the Download Center; this protocol guide doesn't replace choosing the right system build and architecture.

For frequent short-page visits, focus on connection setup, name resolution, and time to first byte. For long transfers, watch sustained throughput, packet loss, and device temperature. Background messaging apps depend more on traffic capture scope, connection recovery, and OS background restrictions. If you have several kinds of requirements, don't expect one setting to optimize everything. Establish a stable baseline, then adjust routing or per-app scope for the apps that need it. This usually produces results that are easier to explain than changing protocols and transports at the same time.

Pinpoint the stage where a connection fails

If the core won't start, check configuration parsing, port conflicts, and feature support first; testing remote speed is pointless at this stage. If the core starts but can't connect, check the address, port, system time, and transport settings. If it connects but the security handshake fails, check the server name, certificate, public key, shortId, or authentication details. If the logs show that a request was forwarded but the destination didn't respond, investigate server egress, destination reachability, and DNS results. Don't keep blaming the client import process for every failure.

If webpages work but some apps don't, first check whether those apps are routed through the proxy, then inspect routing and UDP requirements. Some desktop apps don't use the system proxy, and Android per-app exclusions may send traffic direct. Even after traffic reaches the core, rules may direct it to direct or block. Check rule order and outbound tags together. DNS results can also affect IP-based rule matching, so understand the scope of a domain strategy before changing it. Don't confuse DNS choices with protocol authentication.

Use different checks for slow speeds and connection timeouts

For a timeout, first determine whether a connection can be established. Check system time, subscription validity, port, transport, and core logs in order. For slow speeds, compare node load, network path, and local settings once the connection works. See Node timeout troubleshooting and Layered troubleshooting for slow speeds for separate checklists. Both issues can happen at once, but repeated speed tests won't diagnose authentication failures, and a single successful connection doesn't rule out sustained congestion.

Keep a record you can refer back to: client name, active core, protocol and transport combination, failure stage, and most recent setting change. Leave out access credentials. Once the connection is stable, return detailed logging to its normal level and remove duplicate test profiles to avoid selecting the wrong one later. If the problem returns, compare against your baseline before changing one setting at a time. For general questions, see the FAQ; to repeat the import and verification process, return to the Getting Started Guide. Choose based on the complete configuration and your actual needs, not the protocol label alone.