Xray vs V2Fly Core: REALITY, XTLS, and Protocol Compatibility Explained

How the Two Core Branches Relate

V2Fly continues the general-purpose proxy framework of v2ray-core, with configurations built from inbound, outbound, routing, DNS, policy, and transport modules. Xray-core evolved from the same technical foundation, so the two retain many similarities in JSON structure, VMess node representation, and common transport layers. Similarity does not mean configurations are interchangeable: when a configuration contains a branch-specific security layer, flow value, or transport parameter, the other core may refuse to start or ignore fields it cannot recognize.

Xray focuses on VLESS, XTLS Vision, REALITY, and related transport capabilities. V2Fly focuses on a general-purpose proxy core, VMess compatibility, and modular configuration. Here, “core” means the background program that reads the configuration, creates outbound connections, and handles traffic. v2rayN is the desktop management interface that stores nodes, generates configurations, starts the core, and controls the system proxy; they are separate components.

• Shared foundation: Both can receive local application traffic through an inbound and forward it to a proxy or direct outbound according to routing rules.
• Key difference: Xray provides REALITY and XTLS Vision implementations, commonly represented by security: reality and flow: xtls-rprx-vision.
• Version matters: Older and newer releases within the same branch may also differ in supported fields. Check both the core name and version when assessing compatibility.
• Client responsibility: A subscription only delivers node information. Whether a connection works depends on the client parser, core capabilities, and server configuration.

Compatibility Differences: REALITY, XTLS Vision, and Conventional Transports

REALITY is not a standalone proxy protocol. A common combination uses VLESS for user identification and the proxy session, TCP or another supported method for transport, and REALITY for the secure handshake and server identity parameters. Nodes usually also include a public key, short ID, serverName, and fingerprint. If a required value is missing, or the client fails to write it into the core configuration after parsing, the handshake will fail.

XTLS Vision is usually represented by flow: xtls-rprx-vision. It is not the same level of concept as standard TLS, WebSocket, or gRPC: TLS or REALITY describes the security layer, Vision is an Xray traffic-handling mode, while WebSocket, gRPC, and TCP are transport methods. Do not judge a node by the word “VLESS” alone; also inspect its security and flow values.

Choose the core from node fields, not the subscription name

A subscription name is only display text supplied by the server. One subscription can contain VMess, VLESS, Shadowsocks, and multiple transport types at once. After an update, v2rayN parses each entry as a separate node. Check each entry individually instead of applying one compatibility conclusion to the entire group based on its name.

For VLESS links, focus on security, flow, type, sni, fp, the public key, and the short ID. For VMess nodes, check the server address, port, UUID, transport, Host, path, and TLS toggle. Modern VMess configurations typically use alterId: 0; when importing an old backup with obsolete parameters, follow the server’s current configuration.

1. Select the target node in the v2rayN node list, open the editor, and record its protocol, port, transport, security type, and flow.
2. Go to “Settings” → “Parameter Settings” and review the core-related options. Labels may vary slightly between v2rayN versions; follow the wording shown in the current interface.
3. After selecting Xray, restart the current node and open the log window to confirm that Xray actually started, rather than merely changing the displayed group.
4. Run a real connection latency test. A reported latency only confirms that the connection flow completed; it does not guarantee higher download throughput.
5. If switching to V2Fly produces an unknown-field error, configuration parsing failure, or an immediate core exit, switch back to Xray and check whether the node contains REALITY or Vision parameters.

Compare performance on the same node and during the same time window

Core selection is primarily a compatibility issue and only secondarily a performance issue. Results from different nodes, data centers, or time periods cannot be attributed directly to the core. To reduce variables, use the same server, protocol, routing mode, and test target, changing only the client core. Stop active downloads before testing and make sure no second proxy process is occupying the listening port.

A LAN test setup used the Windows desktop client, local SOCKS port 10808, and the same 1 Gbps access server, with three rounds for each core. For VMess + WebSocket + TLS, the median real-connection latency was 86 ms on Xray 25.3.6 and 89 ms on V2Fly 5.28.0; single-thread download speeds were 92 Mbps and 89 Mbps. A difference of about 3% is not enough to show that one core is generally faster, since a momentary route fluctuation can exceed it.

A REALITY + Vision node cannot be compared with V2Fly on an equivalent basis because the underlying capabilities are not equivalent. Compare different Xray versions instead, or compare it with a VMess or standard TLS node separately provided by the server. Keep routing rules identical as well; if one test uses a proxy outbound while another goes direct because of a domain rule, the results are not meaningful.

Test record example
Client: v2rayN
Local entry: SOCKS 127.0.0.1:10808
Remote port: 443
Routing mode: Global proxy
Test rounds: 3
Recorded items: core version, real-connection latency, single-thread download, core log errors

Steps for switching from V2Fly to Xray

Switching cores does not automatically fix node parameters. Older VMess nodes can usually be tested directly, but hand-written JSON, cached subscription data, and custom routing rules require separate checks. Record the currently working nodes and core version first, so you can tell whether a later problem comes from configuration changes, a subscription update, or the core switch.

1. Save the current state: Export the current nodes or back up the v2rayN configuration directory. Also note the active node name, system proxy mode, and local port.
2. Update the core: Use the core management entry provided by v2rayN to update it. Stop the old core process before starting the new one.
3. Check listening ports: Make sure local ports such as 10808 are not occupied by an old process. When the log shows address already in use, end the process holding the port instead of repeatedly clicking Connect.
4. Refresh the subscription: Update the target subscription so the client re-parses the node fields. For REALITY nodes, check that the public key, short ID, SNI, and fingerprint are complete.
5. Validate one by one: Test a known-working VMess node first, then a VLESS + REALITY node. This separates basic network failures from protocol-specific failures.
6. Restore routing: Re-enable the original split-routing rules only after the connection works, then check that DNS, direct domains, and proxy domains match the expected routes.

When switching back to V2Fly, first remove or disable nodes that depend on REALITY or XTLS Vision. Do not delete unknown fields and force the core to start: removing security, flow, or the public key does not convert the original node into a standard TLS node. The client configuration must match the server’s listening method; protocol conversion requires the server to provide the corresponding entry as well.

Common Compatibility Issues and Fixes

Start troubleshooting with the core log. A “connection failed” message only means that one step in process startup, configuration parsing, DNS, TCP connection establishment, or the security handshake did not complete. Log messages such as unknown field, failed to build config, connection refused, timeout, and address already in use point to different causes and should not all be treated as a failed node.

Final choice: use Xray for newer protocols, and keep stable legacy configurations on V2Fly when needed

For most desktop environments using v2rayN, Xray is the better default core. The reason is not that every node will be faster, but that it covers common configurations such as VMess while also handling VLESS, REALITY, and XTLS Vision nodes. When subscriptions frequently mix protocols, standardizing on Xray reduces mistakes caused by switching cores.

V2Fly remains suitable for configurations that clearly depend on its structure, long-tested VMess nodes, and existing automation. As long as server and client versions match, conventional WebSocket, TLS, TCP, and routing features can continue to work. There is no need to change a stable setup merely for a newer name, but new REALITY nodes should have a separate Xray validation path.

• Node contains security=reality: choose Xray.
• Node contains flow=xtls-rprx-vision: choose Xray.
• VMess + WebSocket + TLS: both usually work; choose based on existing stability and log results.
• Hand-written V2Fly JSON: check the fields first, then decide whether to migrate; do not replace the executable core directly.
• New and legacy protocols mixed in one subscription: validate entries with Xray first to avoid frequent core switching.
• The core will not start after switching: check configuration parsing and port conflicts first, then investigate the remote network.