V2Ray Protocols and Core Engines Compared

01 / Configuration layers

The four layers of a node configuration

A single node in a client list is actually a combination of several settings. The server address and port specify where to connect. VMess, VLESS, Trojan or Shadowsocks define how proxy requests and authentication are handled. TCP, WebSocket and other transports carry the data, while TLS or REALITY provide connection security. Calling all of this a single protocol is convenient, but can lead to poor choices: two entries both labeled VLESS may have very different connection requirements because their security and transport settings differ.

A proxy protocol is not a transport protocol

A proxy protocol tells the remote server the destination address and may also specify the user identity, request type and data format. The transport layer carries that information to the server. A proxy protocol may work with different transports, but not every combination is supported by the core and server. When reviewing a node, note the protocol, transport, security type and extra fields separately. Don't rely on abbreviations in the node name: those labels are set by the subscription provider and don't define how the connection works.

For example, WebSocket adds an HTTP upgrade handshake and typically uses a path and request host. Direct TCP transport doesn't automatically use these fields. Choosing WebSocket doesn't replace proxy authentication or guarantee an encrypted connection. Likewise, enabling TLS doesn't turn a standard proxy request into a different proxy protocol. Clients place these options next to each other for convenience; that doesn't mean they belong to the same technical layer.

Assess security layers and traffic entry points separately

The local inbound is where apps such as browsers connect to the client; the remote outbound is the main focus of this guide. Common local SOCKS or HTTP listening ports are not the node's server port. The system proxy usually directs apps to a local HTTP endpoint, while apps that support SOCKS can be configured to use that endpoint directly. After traffic reaches the core, routing rules may send some requests directly to their destination. So, seeing that the system proxy is enabled only confirms that the entry point changed; it doesn't prove that every connection uses the currently selected node.

Keep authentication separate from transport security. User IDs and passwords determine whether access to the service is allowed; certificate validation determines whether the TLS peer is trusted. These checks fail for different reasons and require different fixes. If an identity field is wrong, disabling certificate checks won't help. If the certificate name doesn't match, repeatedly changing the user ID won't help either. Identify the layer at fault before changing settings, so you can test one thing at a time.

Build a configuration checklist you can verify

Before comparing nodes, record these four layers locally, along with the core and client in use. There's no need to copy sensitive values; just note whether each field is present and whether it comes from the same configuration. If a subscription provides a complete configuration, preserve the original combination rather than changing the transport based on guesswork. The server won't change its settings just because you chose a different option in the client. Even with the correct address and identity, a wrong path or security layer can break the handshake.

This layered approach also helps when reading terminology and logs. When you see a message about a handshake, authentication, path or routing match, first identify the relevant layer, then check its settings. See the glossary for definitions of inbound, outbound and routing. The following sections explain why these settings come in different combinations and which differences matter when choosing a setup.

02 / Proxy protocols

VMess and VLESS: design trade-offs

VMess is an earlier proxy protocol in the Project V ecosystem, with mechanisms for user authentication, request headers and data protection. VLESS takes a different approach: it reduces extra processing in the proxy layer, relies more on an external security layer to protect connections and leaves room for further extensions. Neither protocol is simply a newer or older choice, and changing a node's type from VMess to VLESS isn't an upgrade. The server must provide the matching inbound, and the client must retain the corresponding identity, transport and security settings.

VMess: authentication modes and time

VMess configurations typically include a user ID and security options. Older guides often mention legacy fields such as the number of alter IDs, while modern configurations more commonly use AEAD authentication. When importing an older node, check which authentication method the server actually uses and whether the current core still supports it. Don't fill in every field from an old screenshot by default. Adding legacy parameters to a modern subscription configuration can cause compatibility problems; more fields don't make a configuration more complete.

Time is another easy-to-miss factor when troubleshooting VMess. Some authentication processes rely on a time window, so a significantly inaccurate system clock can cause authentication to fail. Check the device's actual date and time, along with automatic time sync—not just the selected time zone. Changing the time zone while keeping the correct absolute time usually won't cause an authentication mismatch. If all VMess nodes fail at once while other protocols work, check time sync as one possibility, but confirm with logs rather than assuming the protocol is at fault.

VMess data protection adds some processing overhead, but actual resource use also depends on the algorithm implementation, processor, external TLS, number of connections and traffic patterns. If a node also uses TLS, protection comes from more than VMess alone. Keep or change this combination based on the server's design and compatibility requirements. Don't disable an existing security layer just to avoid one round of encryption: connectivity and deployment security are separate questions that need to be checked independently.

VLESS: leaner doesn't mean encryption is built in

VLESS handles proxy requests and user authentication, but classic configurations don't encrypt application data themselves. In common client interfaces, encryption: none is a normal field value for this setup; it doesn't mean that outer TLS or REALITY is disabled. Check the security type as well rather than judging protection from that one line. Connections over untrusted networks need an appropriate security layer as required by the server. Don't treat an unprotected configuration as a general deployment recommendation.

VLESS is often used with Xray extensions such as Vision in the flow field. flow isn't a speed setting you can choose at will; it has specific protocol semantics and implementation requirements. Entering the same value won't produce the same result if the server doesn't enable that flow, the transport combination doesn't meet its requirements or the core doesn't implement it. Preserve the value supplied by the subscription and check which core the client actually uses instead of chasing a particular field name.

Choosing a setup in your client

If an existing VMess configuration has been reliable and the provider still maintains it, continuing to use it is usually safer than modifying it by hand. If a new configuration explicitly offers VLESS with matching TLS or REALITY settings, use the combination as provided. For a fair comparison, test nodes with the same server region, similar network routes and the same time window. Otherwise, differences may come from the network path rather than the proxy protocol. Compare connection failure and reconnection behavior alongside download speed.

In v2rayN, check the protocol and security settings in the node editor, then confirm which core the configuration actually uses. In v2rayNG, also verify that imported extra fields were retained. If the chosen combination isn't supported by the current implementation, use a client or core that can interpret the full configuration rather than clearing unfamiliar fields. For details on where the two cores differ, see the core compatibility section.

03 / Alternative designs

Trojan and Shadowsocks: where each fits

Trojan and Shadowsocks often appear side by side in node lists, but they handle authentication and data protection differently. Trojan typically relies on TLS for connection security and carries proxy requests with password authentication. Shadowsocks uses a lightweight proxy design with its own pre-shared-key-based data protection. Check the specific protocol version, algorithm and transport combination before comparing network performance. A short label such as Trojan or SS doesn't tell you enough to assess compatibility.

Trojan: TLS settings matter as much as the password

A typical Trojan configuration needs a server address, port, password and TLS server name. A correct password can't compensate for failed certificate validation, and a successful TCP connection doesn't mean the TLS handshake and authentication both completed. If the connection stops at certificate validation, check the server name, certificate chain and device time. If TLS completes but the server rejects the request, verify the password and server inbound. Troubleshooting one stage at a time is usually more effective than repeatedly changing ports.

The server address and server name can serve different purposes in a configuration: the address determines where the network connection goes, while the server name is used in the TLS handshake and certificate name check. Using an IP address in the address field doesn't mean the server name should be changed to that IP. Preserve the name provided by the subscription. Skipping certificate validation changes the trust boundary and isn't a routine fix; first check the server name, system time and server certificate configuration.

Some implementations combine Trojan with different transports, in which case the path, host and transport settings also affect the connection. An extended combination exported by one client shouldn't be assumed to work in every implementation that supports Trojan. To assess compatibility, check whether the target core supports that specific combination—not just whether Trojan appears in its type menu. If the transport reverts to a default after import, verify it before connecting; otherwise, a lost setting may be mistaken for a broken node.

Shadowsocks: the cipher is a required setting

Key Shadowsocks fields usually include the address, port, encryption method and password. Classic AEAD methods and the later 2022 methods follow different specifications, with different key requirements and implementation support. Similar names don't make them interchangeable: both ends must use the same method and specification. In particular, don't use an arbitrary-length password with a method that requires a specific key length or encoding, then blame the network when it fails.

Legacy stream ciphers found in older guides shouldn't be the default for new configurations. Use a method the provider actively maintains and both cores support rather than reverting to an outdated setting to match an old screenshot. Some subscriptions also include transport extensions, which aren't part of the base Shadowsocks protocol. A client may understand the address and password but not those extra fields, so check the node details even when the import appears to succeed.

Don't assume “lightweight” means better performance

The basic Shadowsocks processing path can be relatively simple, but that doesn't mean every Shadowsocks node is faster or uses less battery. Hardware acceleration, packet loss, server load and the client's connection management strategy can all affect results. Trojan's use of TLS doesn't mean every request incurs the full handshake cost again; connection reuse and session resumption also matter. Treat design characteristics as clues for analysis, not a fixed performance ranking in place of testing.

If a provider offers both types of node, start with the combination your client can fully parse and use reliably in everyday apps. For apps that need UDP, check support across the client, core, server and current mode; a working website doesn't prove UDP works. For a broader look at latency, server distance and traffic multipliers, see how to choose and test nodes, and consider protocol choice in the context of the full network path.

04 / Security layers

TLS, REALITY and transport methods

REALITY is often listed alongside VMess, VLESS and Trojan in promotional labels or node names, but it isn't a proxy protocol that handles proxy requests on its own. A common setup pairs VLESS with REALITY: the proxy layer handles destination requests, while the security mechanism protects the connection and authenticates the peer. TLS is a more general-purpose security protocol. Compare complete combinations, not “VLESS or REALITY”—that treats settings from different layers as alternatives.

TLS: connection names, certificates and negotiation

TLS provides encryption, integrity protection and peer authentication. The client checks the peer certificate against the configured server name, including the certificate chain and validity period. The network connection address, TLS server name and host field in a WebSocket request may match or may be set separately. Don't replace all three just because they look like domain names. Which fields need to match depends on how the server assigns certificates, accepts transport and handles requests.

ALPN negotiates an application-layer protocol; it isn't a region selector or speed boost. When a transport depends on a particular application protocol, the client and server must negotiate a compatible result. A fingerprint can affect how the TLS handshake appears and whether implementations are compatible, but unusual settings aren't automatically better. If the subscription provides these fields, test them as given. If it doesn't, don't copy settings from another node. Different server inbounds may have entirely different requirements, and copying individual settings can break a working combination.

REALITY: authentication depends on matching parameters

REALITY is implemented in the Xray ecosystem and uses a paired authentication mechanism that differs from standard certificate-chain validation. Clients typically need a server name, public-key-related parameters, a short ID and a fingerprint; field names can change as implementations evolve. These values must come from the same valid configuration—don't combine parameters from different nodes. The public key verifies the paired server, and the short ID must be among the values allowed by the server. Neither is an optional decoration.

Common VLESS, REALITY and Vision setups also require a compatible core and transport. A client that supports VLESS doesn't necessarily support REALITY; supporting REALITY doesn't mean every flow works with every transport. Treat the full combination supported by the server as a unit. If a connection fails, check the core, server name, authentication parameters and flow first, then network reachability. Don't repeatedly change one field in isolation.

REALITY can't fix an incorrect server address or guarantee the quality of a remote server. A successful security negotiation only confirms that this stage worked; proxy authentication, the destination connection and routing can still fail. Save the provider's complete settings, use a core that supports the combination and verify the parsed configuration after updates. Don't treat REALITY as a universal switch that makes time, identity or certificate concepts irrelevant.

The trade-offs of direct TCP and WebSocket

Direct TCP usually involves fewer intermediary processing layers. WebSocket adds an HTTP upgrade and message framing, providing another way to connect that is often used with existing reverse proxies or application server setups. Extra encapsulation adds overhead, but the actual experience also depends on whether the deployment path is well designed. You can't predict throughput from the number of layers alone, and you shouldn't change a WebSocket-only server to TCP to reduce them. That changes the connection endpoint; it isn't a client-side optimization.

Another common misconception is that multiplexing is a default improvement for every transport. Multiplexing lets multiple logical connections share underlying resources, but packet loss, long-lived traffic or specific protocol flows can cause interference, and some combinations have explicit limitations. Follow the current core documentation and server configuration, then test with real apps. A toggle in the client only means that the client lets you edit the setting; it doesn't mean the setting suits every node.

05 / Performance and battery

Connection speed, resource use and mobile battery life

Protocol comparisons often get reduced to a speed ranking, but rankings without test conditions aren't useful elsewhere. App performance includes connection setup time, request latency, sustained throughput, retries and long-term stability. The proxy protocol is only one factor: network round-trip distance, DNS resolution, congestion, server load and destination response time can matter just as much. For a useful comparison, hold these factors steady first, then look at differences from the protocol combination and client settings.

Measure latency, handshakes and throughput separately

A client's TCP connectivity test usually checks only the connection to the node's entry point; it doesn't prove that proxy authentication or a destination request will succeed. A real request is closer to app behavior, but its results also depend on the test server's region, cache and availability. A sustained download measures throughput, not short-request responsiveness. Understand what each test actually measures, and compare the same metric under the same conditions rather than subtracting results from different tests.

A first connection usually involves DNS lookup, transport setup and a security handshake. Later requests to the same destination may benefit from connection reuse. Test both the first visit and continued use so you don't compare a warmed-up connection against a new one. If a node is slow to open initially but works normally afterward, investigate the handshake and DNS first. If it starts well but degrades during sustained transfers, look at congestion, packet loss, server limits and device temperature. Different symptoms call for different fixes.

Resource use depends on implementation and workload

Encryption uses processor resources; extra encapsulation adds processing and memory copies, while connection reuse and buffering affect memory use. Hardware-accelerated algorithms may work well on one processor but offer no advantage on another device. The client interface and proxy core may run as separate processes, so distinguish between them when checking system resource use. Low usage by the interface alone doesn't mean the entire proxy chain is equally efficient.

High memory use may come from active connections, caches or buffers and doesn't automatically indicate a problem. More useful signs include whether usage keeps growing under a similar workload, levels off when traffic stops, or coincides with system reclamation or a process exit. Frequent disconnects and reconnects can require more handshake work than keeping a few stable connections; overly aggressive connection reuse can also make requests share a blocked channel. Tune settings for the real workload rather than chasing the lowest possible resource reading.

On mobile, check radio use and background activity

On Android, battery use comes not just from protocol processing, but also from wireless activity, background app requests and wake-ups. Frequent keepalives, repeated automatic speed tests and continuous retries after failures can keep a device from entering a low-power state. Cellular transfers on a weak signal can use even more power. When comparing v2rayNG and v2flyNG battery use, keep the network type, screen state and app workload consistent, and check for automatic updates or test tasks.

System background restrictions affect long-running connections. Relaxing them may help the client stay active, but it also changes the battery conditions. Don't allow background activity in one test and restrict it in another, then attribute the entire difference to the core. Test foreground use, screen-off idle and wireless network changes separately. Note whether connections recover, reconnect or actually transfer data. One download with the screen on doesn't reflect everyday mobile use.

For a comparison, change one variable at a time and repeat tests at similar times, keeping the original working configuration as a fallback. Don't use continuous maximum-speed downloads as your only measure: they change device temperature, data use and system scheduling all at once. For everyday browsing, reliably completing short requests is often more useful than peak throughput. Describe results for the specific device, network and configuration tested, not as a protocol ranking for everyone.

06 / Core compatibility

How V2Fly, Xray and clients fit together

V2Ray began in the Project V ecosystem. V2Fly continues the community maintenance of related projects, while Xray developed from this technical foundation and took its own implementation path around VLESS, XTLS and REALITY. They share some concepts and configuration conventions, but they're no longer interchangeable versions of the same program. First choose a core that implements your target configuration; then consider resource use on your device and ease of maintenance.

The client interface and core do different jobs

A graphical client handles subscription management, node editing, the system proxy and startup controls. The core reads the runtime configuration and handles connections, routing and transport. v2rayN is a desktop client for managing configurations and the relevant cores for your platform and package. v2rayNG targets Android and primarily uses Xray; v2flyNG is an alternative based on V2Fly. A client name isn't a proxy protocol. Whether a node works ultimately depends on the configuration it generates and the core it runs.

A field supported by the client interface isn't necessarily supported by the core currently running. Conversely, a core may support a feature that the interface can't yet edit. Check the import result, runtime logs and selected core together. This is especially important when migrating an older configuration or changing cores: don't assume the current settings match the previous defaults. “Started” in the interface only confirms that the startup action completed; it doesn't validate a real request to a destination.

Shared protocol support still has configuration limits

Both cores may support VMess, VLESS, Trojan or some Shadowsocks methods, but specific transports, security extensions, field names and defaults can still differ. REALITY and XTLS Vision are key capabilities of the Xray branch; don't assume V2Fly can interpret them unchanged. If a configuration relies on these features, use a matching implementation. Removing required fields just to make the configuration parse changes how the connection works; it doesn't make the configuration compatible.

Similar-looking JSON can also be misleading. Both cores may use structures such as inbounds, outbounds and routing, but field values, extensions and DNS handling can vary by implementation. When migrating, start from the required behavior and check each setting rather than handing an entire file to a different core. In particular, verify that routing tags exist, outbound references are correct and required data resources can be loaded.

The snippet below illustrates routing semantics; it isn't a complete configuration you can run by itself. It means that, after matching the specified domain set, traffic uses the outbound named direct. At runtime, an outbound with that name must exist, and the related domain data must be available. This example also shows that compatibility depends on more than the proxy protocol: supporting resources and tag references matter too. Copying a rule without the matching outbound won't produce the expected direct connection.

{
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

Test core changes with a limited scope

Before switching, keep the working configuration and test one node that the target core explicitly supports. Then check DNS resolution, frequently used sites, apps that need UDP and system proxy recovery. If only one kind of node fails, check that protocol's extension fields first. If all nodes fail, check core startup errors, listening ports and configuration generation. This separates a core that won't start from a protocol compatibility issue and helps prevent misdiagnosis.

Core and client updates can happen independently. If something breaks after an update, check whether the changes affect a protocol, configuration parsing or default behavior, then compare against a known-working node. Don't immediately rebuild every subscription. The client downloads page lists options for three clients by platform. For a deeper look at the core families, see the Xray-core vs. V2Fly-core comparison. Choose based on what your configuration needs, not on treating the branch relationship as a quality ranking.

07 / Subscription formats

Subscription formats, share links and migration checks

A subscription distributes configurations; it isn't a new proxy protocol. A subscription URL usually returns a set of nodes for the client to parse into internal entries, while a share link often represents a single node. Both may use encoded data, but encoding doesn't make it private. Treat subscription URLs and node authentication fields as sensitive: don't include them in public screenshots, forum posts or unredacted logs. To troubleshoot, describe whether a field is present; never share its actual value.

A successful fetch doesn't guarantee a complete import

A subscription update involves several stages: making a network request, identifying the content, parsing fields and writing entries. Receiving a response doesn't guarantee that it's a node list the client understands; it could be a login page, error message or a different configuration format. If no nodes appear after an update, first distinguish a request failure from a parsing failure. For the former, check the URL and network path. For the latter, check whether the provider's format is compatible with the client instead of repeatedly clicking Update.

Common share-link formats use conventions for VMess, VLESS, Trojan and Shadowsocks, but extension fields can differ even when the prefixes match. A parser may recognize transport paths, server names, flow, fingerprints and REALITY authentication parameters correctly while another ignores them. So even if the expected number of nodes appears, inspect some of their details. The most troublesome case isn't always a failed import: a seemingly normal entry may have silently lost a critical field.

Don't confuse node lists with complete runtime configurations

A node list usually provides outbound connection details. A complete configuration may also include inbounds, DNS, routing and policies. A client's regular subscription importer may not accept a complete configuration, while its full-configuration importer may not apply every setting from the interface. Identify what you're importing before choosing a feature. If a full configuration controls routing, repeatedly switching interface presets may appear to have no effect. That's not necessarily a protocol failure.

When moving from v2rayN to v2rayNG or v2flyNG, prefer a compatible subscription or share-link format explicitly provided by the source. Copying a runtime configuration generated by the desktop client may not preserve the inbounds and runtime environment needed on mobile. Mobile traffic routing, file paths and background restrictions differ from desktop, so the same outbound protocol doesn't make the entire configuration portable. Preserve the node's meaning, not every platform-specific field.

Account for overwrites and network paths when updating

Subscription groups usually help the client identify which nodes come from the same source. An update may replace, delete or recreate those entries. Manual changes to subscribed nodes may not survive the next update. To compare settings temporarily, use the client's copy or standalone-entry feature, and check whether the copy remains linked to the original subscription. Keeping the original group makes it easier to tell whether a problem came from a provider change or a local edit.

Whether an update request uses a direct or proxied connection affects reachability. But updating through a proxy can also create a dependency: if the current node stops working, the client may be unable to fetch new settings through it. In that case, use an available network path or a separate working node instead of retrying indefinitely. Don't set update intervals too short either; match them to the provider's update schedule and the device's background conditions. More frequent requests won't make nodes faster.

After migrating, test one node first, then check its group, routing and everyday apps. There's no need to change everything at once. If an update succeeds but fields are missing, tell the provider the target client, protocol type and missing field names—don't send authentication details. For specific update failures, see the subscription update troubleshooting guide. For basic concepts, return to the import steps in the user guide, keeping fetching, parsing and running as separate stages.

08 / Selection workflow

Choose a protocol and verify it for your use case

You don't need to find one protocol that's permanently best for every situation. First identify the working combinations supported by your device, client and server, then choose one that reliably meets your needs. For desktop, use v2rayN to manage configurations; on Android, start with v2rayNG, and consider v2flyNG when you specifically need V2Fly behavior. The client is the configuration interface; connection capabilities ultimately depend on the core and complete settings. The same node name doesn't mean two devices have the same operating conditions.

Everyday browsing and long-term reliability

For web browsing, documents and messaging, prioritize short-request success, first response time and recovery in the background over peak download speed. If a protocol combination is stable, the server is maintained and the client parses it completely, there's no need to migrate just to get a different label. To switch, test the new combination under the same network conditions. Check that common destinations, DNS and reconnection work, then make it your daily option while keeping the old working configuration.

For workloads with frequent short connections, pay attention to handshakes and connection reuse, but don't blame every slow response on the handshake. A slow destination, routing that incorrectly selects a direct connection or an unsuitable DNS result can look similar. First confirm that requests use the intended outbound, then compare protocols. Otherwise, you may be measuring two different network paths rather than how two protocols handle the same workload.

Mobile networks, sustained transfers and specialized apps

If you often switch between Wi-Fi and cellular, recovery matters more than the lowest latency in a single test. Check whether old connections are released after a network change, new requests recover automatically and background restrictions let the client keep running. If problems occur only after switching networks, reconnect and check DNS and the current network before changing protocols. Repeatedly changing security settings won't usually revive a stale connection and only adds more variables.

Large file transfers and long video sessions depend more on sustained throughput and device temperature. Control the server region and test time, and watch for repeated interruptions rather than relying on a single peak-speed result. For apps that need UDP, verify support across the entire path: the local traffic entry point, core outbound, server and remote destination can all be limiting factors. A successful web request checks only part of the connection and can't replace testing the app itself.

On devices with limited resources, prefer a mature implementation and a combination with fewer extra layers that both sides explicitly support. That doesn't mean removing necessary security. More effective steps often include reducing automatic speed tests, keeping log volume reasonable, avoiding duplicate background tasks and checking for unexpected reconnects. If the device runs hot, distinguish real traffic, background updates and retries after connection failures before comparing protocol processing costs. Otherwise, changes in app workload may be mistaken for a core issue.

Troubleshoot connection failures in a fixed order

First, confirm that the app reaches the client: the system proxy points to the right endpoint, the local listener is running and the app follows the proxy setting. Second, confirm that routing selects the intended outbound; a failed direct connection isn't a failed node. Third, confirm that the remote address is reachable, then use logs to check the security handshake, proxy authentication and destination connection. This works from local to remote, narrowing the cause at each layer and usually gives more reliable results than replacing an entire node configuration first.

If the logs show that the configuration can't be parsed, fix core compatibility and field issues first. If the security handshake fails, check the server name, time and matching authentication parameters. If authentication fails, check the identity fields and inbound type. If authentication succeeds but the destination is unreachable, check DNS, routing and the server's access to that destination. Change one setting at a time, record the result and restore the original value before testing another branch. Even without an immediate fix, this makes clear what you've ruled out instead of creating a loop of simultaneous changes.

For rule order and domain handling, see custom routing rule syntax. If the client says connected but pages won't load, follow the system proxy, routing and DNS troubleshooting checklist. To reinstall or switch platforms, choose the relevant option on the client downloads page. A good protocol choice is a configuration you can explain, verify and roll back—not a ranking detached from the device and network.