Xray vs. V2Fly Core: VLESS, XTLS, and REALITY Support Compared

At a glance

Choose a core based on node parameters, not the client name. Nodes using REALITY or xtls-rprx-vision require an Xray core that supports those features. For VMess, WebSocket, and standard TLS, check the transport fields and configuration format as well. This guide is for readers moving configurations between v2rayN, v2rayNG, and v2flyNG. It explains the differences between protocols, transports, security layers, and client import capabilities, then walks through verification from startup logs to local ports.

1. Xray and V2Fly: Core Branches and Clients Are Different Layers

V2Ray is the name of a proxy tool and its configuration ecosystem. The V2Fly community continues to maintain the V2Ray core, while Xray grew from a V2Ray code fork and developed its own protocol extensions, transport implementations, and configuration changes. The two share a common origin, but that does not mean newer fields are always compatible. Nor should a complete JSON file be treated as a universal format.

Clients manage subscriptions, edit nodes, configure system proxies, and launch cores. Cores parse runtime configurations, establish inbound and outbound connections, and handle routing. A client displaying a node does not mean its bundled core can run it. Successfully importing a subscription and completing a protocol handshake are two separate checkpoints.

v2rayN: A desktop client. Check the core name and version in the actual startup log; don't infer which core is running from the app icon or subscription group name.
v2rayNG: An Android client that uses the Xray core. Features such as REALITY still require support from the client's editor, subscription parser, and core.
v2flyNG: An Android client that uses the V2Fly core. Choose nodes based on its actual core and import format; it is not an interchangeable, similarly named version of v2rayNG.

2. Where VLESS, XTLS, and REALITY Support Differs

VMess and VLESS are proxy protocols; TCP and WebSocket are transports; TLS and REALITY are configuration options related to connection security. XTLS Vision uses a specific flow-control mode to handle connections. These terms belong to different layers and are not interchangeable “protocol options.”

Feature	Xray core	V2Fly core	What to check when migrating
VMess	Supported	Supported	Check the UUID, encryption settings, transport, and TLS parameters
VLESS	Supported; often used with Vision and REALITY	Implemented in older versions; check the version and configuration format in use	VLESS support does not imply support for Xray extensions
WebSocket + TLS	Supported	Supported	Check the path, Host, serverName, and certificate validation
XTLS Vision	Supports the corresponding VLESS flow-control settings	Does not support Xray's Vision implementation	Check whether flow is set to xtls-rprx-vision
REALITY	Supported	Does not support Xray's REALITY implementation	Check the security layer, public key, serverName, shortId, and other parameters
Complete runtime JSON	Parsed according to the Xray configuration specification	Parsed according to the corresponding V2Fly configuration version	Similar configuration structures are not necessarily interchangeable

VLESS itself does not provide transport encryption equivalent to TLS. When you see a VLESS node, check its security layer rather than assuming protection based on the protocol name alone. The existence of older VLESS implementations also does not mean V2Fly can accept subscription nodes that use REALITY or Vision.

The security: "xtls" syntax in older guides is not the same as the commonly used flow: "xtls-rprx-vision" setting today. Don't try to “fix” an old configuration by changing the string to TLS. The server listener, flow control, and client capabilities all need to match.

3. Choose a Core by Node Parameters, Not Speed Labels

The first requirement when choosing a core is that it can run the configuration; connection quality comes later. Latency depends on the route, server load, DNS, routing, and network conditions. No core guarantees a particular speed increase. The recommendations below apply only to nodes with explicit REALITY or Vision parameters.

Xray core

Recommended

If a node uses REALITY, xtls-rprx-vision, or another setting that explicitly requires Xray, choose an Xray version that supports those fields and make sure the client preserves all parameters.

Best for: VLESS + REALITY, Vision, and nodes whose server explicitly requires Xray.

V2Fly core

If you already have VMess or other nodes deployed with the V2Fly configuration specification, you can keep using the corresponding core and configuration workflow. Check transport, DNS, and routing structures separately before migrating.

Best for: Maintaining existing V2Fly configurations, VMess nodes, and setups that don't depend on Xray extensions.

For a common VLESS + TCP + REALITY node, check the address, port, UUID, flow, security layer, server name, public key, and shortId individually. Set the fingerprint as specified by the provider. The server determines which shortId values are valid; don't copy one from another node or assume a fixed length is required.

In the node editor, confirm that the protocol is VLESS and the transport matches the server.
Check that the security layer is REALITY. Set xtls-rprx-vision only if the server requires Vision.
Check the public key and server name. The connection address, WebSocket Host, and serverName are not necessarily the same value.
After startup, check the logs. First confirm that the configuration was accepted, then check whether the handshake and application access succeed.

4. Configuration Compatibility: Share Links vs. Runtime JSON

A share link describes a node, which the client converts into a runtime configuration. A complete JSON file may also include local listeners, DNS, routing, and multiple outbounds. Successfully importing a share link only proves that the parser accepted it. Successfully copying a JSON file does not mean another core recognizes every field in it.

The snippet below shows how to identify the Xray security layer; it is not a standalone configuration. It does not include the server address, user credentials, or REALITY connection parameters. Do not save it as a complete configuration and try to start it.

{
  "streamSettings": {
    "network": "tcp",
    "security": "reality"
  }
}

Protocol layer: Check protocol and its corresponding settings. Replacing only the protocol name while keeping the existing user structure will not work.
Flow-control layer: In common Xray VLESS outbound configurations, flow belongs in the user entry. It is not a field to add arbitrarily to streamSettings.
Transport layer: Check streamSettings.network and the corresponding transport settings. Compatibility between new and legacy transport names depends on the core version in use.
Security layer: Check security and its related settings object. Do not pass realitySettings unchanged to a core that does not support it.
Routing layer: Check that outboundTag exists. A node can complete a handshake while applications remain unable to connect because a rule points to the wrong outbound.

5. Verify Local Ports and Handshake Logs in Order

During testing, confirm the local entry point before testing the remote connection. The three numbers below are examples: 10808 and 10809 must match the actual local listener settings. Port 443 is a common remote TLS port, not a requirement for every node, and it does not identify which protocol the service uses.

10808

Example local SOCKS listener port

10809

Example local HTTP listener port

443

Example remote secure connection port

Check startup: If the logs show an unknown protocol, unknown transport, or configuration parse error, fix the configuration or use a compatible core before testing connection speed.
Check the listener: Verify the local address and port. If you see address already in use, find the process using the port or change the local port and update the test command to match.
Check the handshake: If the core has started but connections fail, check the remote port, UUID, flow, serverName, public key, shortId, and system time.
Check routing: If command-line requests work through the proxy but the browser does not, check the system proxy, browser proxy settings, and routing results. Don't switch cores as a first step.

If curl is installed on your desktop and the SOCKS endpoint is 127.0.0.1:10808, use the command below to test a single request through an explicit proxy. --socks5-hostname sends target domain resolution to the SOCKS proxy; it does not confirm system-wide DNS behavior or proxy settings for every application.

curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://v2ray88.com/

Receiving an HTTP response means that this request completed its connection flow; it does not mean every site and rule is working. If the response is an access restriction from the site itself, distinguish it from a failed proxy handshake. When recording an error, include the time and error type. Remove subscription links, UUIDs, and other sensitive connection details before sharing logs.

6. How Desktop and Android Clients Handle Configuration

A single subscription source can provide nodes using different protocols. Even after importing the same link, the lists on two devices may differ because of parser behavior, filters, or update times. Start by testing a node both clients can clearly identify; matching node counts are not a substitute for checking compatibility.

Approach: Assign Clients by Node Features

Desktop: v2rayN

Use the corresponding Xray core for REALITY or Vision nodes.
Check the startup log to confirm which core and version are actually running.
Test the local proxy endpoint before enabling full routing rules.

Android: Choose by Protocol

Use v2rayNG for nodes that require Xray features.
Use v2flyNG for nodes supported by V2Fly.
When switching clients, disconnect the other client's VPN first.

Bottom line: The subscription source can be the same, but runtime capabilities depend on the client, core, and node parameters on each device.

If Android prompts you to authorize a VPN connection, confirm it as instructed by the system. After switching clients, also check which apps are included in per-app proxy settings. An excluded app may be unable to connect while other apps work normally. This alone does not indicate a problem with REALITY parameters or the core implementation.

7. Frequently Asked Questions About Switching Cores

Why does the subscription import successfully, but startup reports an unknown security type?

Open the failed node's editor and check whether REALITY is selected, then check the core name in the startup log. If V2Fly is running, switch to an Xray setup that supports the required fields. If Xray is already running, check the core version and the configuration generated by the client; simply updating the subscription won't help.

Can I change REALITY to TLS to use the node with v2flyNG?

Changing the client setting alone won't work. The two options use different handshakes and server configurations. Ask the server provider for a TLS node with matching settings, then import it with the new parameters. Clearing the public key or renaming the security layer will not turn the original REALITY endpoint into a standard TLS endpoint.

If a VMess node works with both cores, do I still need to switch?

If the existing node, DNS, and routing all work, there's no need to switch just because the core has a different name. If you do need to migrate, keep the original configuration and test the transport path, TLS server name, and certificate validation separately before adding routing rules step by step.

The logs show no errors, but the browser still can't connect. What should I check first?

First, send a request through the actual local port using an explicit proxy. If the command succeeds, check the system proxy status in v2rayN and see whether the browser has separate proxy settings. If the command fails, go back to the core logs and distinguish a local connection refusal from a remote timeout or handshake failure.

Follow this order: identify the required node features, check whether the client parses them correctly, confirm that the core supports them, verify the generated configuration, and make sure application traffic enters the proxy. For more on individual fields, see the Configuration Reference. To establish a working connection for the first time, follow the Quick Start Guide; adjusting one setting at a time makes issues easier to pinpoint.