Xray vs V2Fly Core: VLESS and REALITY Explained

First, understand how Xray, V2Fly, and Project V are related

Project V was the source of the early V2Ray technology stack, while v2ray-core has since been maintained by the V2Fly community. Xray diverged from the same code base and gradually developed its own protocol implementations, configuration fields, and release cadence. The two still share many fundamentals—such as inbound and outbound handlers, routing, DNS, VMess, VLESS, and multiple transport methods—but they should no longer be treated as two names for the same program.

The core handles the actual connection work: parsing node settings, listening on local ports, establishing remote transports, performing DNS queries, and applying routing rules. v2rayN, v2rayNG, and v2flyNG provide the user interface and configuration management layer. After you choose a node, the client generates a configuration the core can read and starts the corresponding process. As a result, the same subscription may show identical names in different clients without offering exactly the same underlying capabilities.

The main difference between the two paths appears in newer protocol extensions. V2Fly focuses on its own configuration system, foundational protocols, and general-purpose transport capabilities, while Xray has continued expanding combinations involving VLESS, XTLS Vision, and REALITY. If a node uses only VMess, TCP, WebSocket, or standard TLS, either core may work. Once the configuration includes a specific flow, a REALITY public key, or a short ID, choose the core based on those fields.

VMess versus VLESS is not the same as one core versus the other

VMess is an earlier proxy protocol in the Project V ecosystem. A node usually includes a server address, port, user ID, transport method, and TLS settings. VLESS uses a more streamlined authentication structure, but it does not automatically determine the transport or encryption method. VLESS can be paired with TCP, WebSocket, gRPC, and TLS, or—with the Xray path—XTLS Vision or REALITY.

So the claim that “Xray supports VLESS while V2Fly supports only VMess” is inaccurate. Both cores support basic VLESS scenarios; the important detail is the combination of fields behind VLESS. When a node link or subscription record contains flow=xtls-rprx-vision, security=reality, a public key, a short ID, or fingerprint parameters, use an Xray core that can interpret those fields.

What XTLS Vision and REALITY actually do

XTLS is a set of transport optimizations and traffic-handling mechanisms in the Xray ecosystem. The setting most often seen today is VLESS paired with xtls-rprx-vision. Vision adjusts how data is handled based on the connection content, with a focus on reducing redundant processing in certain TLS-over-TLS scenarios. It is not a standalone node protocol and cannot be enabled independently of VLESS, the transport layer, and the server configuration.

REALITY is a transport security scheme used by Xray. A client connection requires the server address and port, along with the correct serverName, public key, and short ID; fingerprint and spiderX parameters may also be involved. Its configuration differs from standard TLS: you cannot simply change the security type from TLS to REALITY while leaving every other field untouched. The server private key must correspond to the client public key, permitted serverName, and short ID as one complete set.

Many REALITY nodes use 443 as the remote port, but the port number does not identify the protocol. Port 443 can also carry standard TLS, and other available ports can be configured by the server. Use the security type and its accompanying fields in the subscription record as your guide—not the presence of port 443.

Check REALITY settings in this order

1. Confirm that the protocol is VLESS, then verify the server address, remote port, and user ID. Make sure there are no extra spaces or truncated characters.
2. Confirm that the security type is REALITY rather than standard TLS, and that the transport type matches the server.
3. Verify the complete serverName domain. It can differ from the server address; do not remove it just because the node address is an IP address.
4. Verify the public key and short ID. The short ID is hexadecimal; when copying it, do not include quotation marks, commas, or line breaks.
5. If a flow field is present, confirm that its value matches the server. The common value is xtls-rprx-vision; do not shorten it to vision.
6. Save the changes and restart the connection, then check the core log. If the old process is still running, it may continue using the previous configuration.

Why the same subscription can still fail after switching cores

A subscription transfers node information; it does not guarantee that every client can interpret every field without loss. Common subscription formats encode the protocol, address, port, user ID, transport, and security parameters into links or structured records. If the subscription provider uses newer Xray fields that the client parser does not map, the node may appear in the list while its public key, flow, or short ID is actually empty.

Another source of failure is configuration conversion. Clients usually do not pass subscription content directly to the core. They first convert it into an internal data model and then generate the runtime configuration. If REALITY is converted to TLS, serverName is treated as the server address, or flow is ignored, the core log may report invalid fields, authentication failure, or a broken handshake. Repeatedly refreshing the subscription will not fix this; open the node details and check each field.

Routing rules can also create the illusion of core incompatibility. The node may be connected, but if a destination domain is sent to a direct outbound by the rules, the result will not match expectations. During troubleshooting, start with a simple routing mode to verify the basic connection, then restore domain, address, and rule-set routing. DNS needs separate attention as well, especially when its results do not match the routing conditions.

Use logs to identify the failing layer

• Core will not start: Check the configuration syntax, core files, listening ports, and duplicate processes. If the log says address already in use, close the process occupying the port or change the local listening port.
• Connection drops immediately: Check the server address, port, user ID, flow, security type, public key, and short ID, focusing first on missing fields.
• Connection times out after waiting: Check whether the current network can reach the remote address and port, then confirm that the server is listening. Do not start by changing complex routing rules.
• The core connects but webpages will not load: Check the system proxy, local SOCKS or HTTP port, DNS, and the direction of routing outbounds.
• Some domains work while others fail: Check domain rules, address rules, DNS results, and routing priority instead of switching cores immediately.

How to choose between v2rayN, v2rayNG, and v2flyNG

Windows, macOS, and Linux users generally manage desktop connections through v2rayN. Check the protocol details before choosing a node. If it uses VLESS, XTLS Vision, or REALITY, make sure Xray is the core actually being launched. For VMess, WebSocket, and standard TLS only, continue using a configuration that has already proven stable instead of switching frequently just because of the protocol name.

On Android, v2rayNG uses the Xray core and is suitable for subscriptions containing Xray extension fields. v2flyNG uses the V2Fly core and suits users who want to stay with the V2Fly configuration path. Their interfaces are similar, but their underlying configuration capabilities are not identical field for field. When migrating nodes, check the details page rather than comparing only subscription groups and node names.

Client selection also depends on where routing rules come from. Both Xray and V2Fly support routing and DNS, but their field structures, rule capabilities, and version histories differ. Copying an entire advanced configuration can trigger unknown-field errors. A safer approach is to import the node connection parameters, rebuild the routing rules in the target client, and use logs to confirm that domains and addresses reach the intended outbound.

Keep this information before changing clients

• Record the node protocol, remote address, port, user ID, transport method, and security type.
• For VLESS nodes, also record flow. For REALITY nodes, record the public key, short ID, serverName, fingerprint, and path fields.
• Record the current local SOCKS and HTTP listening ports so the system proxy does not keep pointing to the old client.
• Save routing rules separately from node parameters so a routing problem is not mistaken for a failed node.
• After switching, test a single node first, then update the full subscription group and automatic update task.

FAQ: compatibility, speed, and configuration migration

The core name alone does not determine connection speed. Results also depend on the server route, congestion, round-trip latency, packet loss, transport overhead, TLS processing, device performance, and routing rules. XTLS Vision is designed to reduce redundant processing in specific scenarios, but that does not imply a fixed percentage speed increase.

Likewise, REALITY cannot be enabled by changing one option on an ordinary VMess node. It requires a coordinated server-and-client configuration with the correct key and identifier fields. If the subscription does not provide those parameters, the client cannot fill them in automatically. When a connection fails, return to the configuration source and verify the fields instead of generating a random public key or short ID.

Use this checklist when choosing a core

There is no need to guess from project history when choosing a core; read the node’s actual fields. For common combinations such as VMess, WebSocket, gRPC, and standard TLS, prioritize existing compatibility. For VLESS, continue by checking the security type and flow. When XTLS Vision, REALITY, a public key, and a short ID appear, the Xray path is the more direct choice.

If the node connects but access behaves unexpectedly, check the local ports, system proxy, DNS, and routing first. Focus on core compatibility only when the logs clearly show unknown fields, configuration parsing failures, or a protocol handshake mismatch. Working layer by layer avoids switching repeatedly between the node, core, routing, and system proxy.

1. Check the protocol: confirm whether it is VMess or VLESS instead of relying on the node name.
2. Check the security type: distinguish standard TLS from REALITY and record serverName.
3. Check flow: choose Xray when xtls-rprx-vision is present, and confirm that the server uses the same setting.
4. Check the client: use v2rayN to manage the corresponding core on desktop; on Android, choose v2rayNG or v2flyNG according to the Xray or V2Fly path.
5. Check local listeners: the system proxy, browser proxy, and client ports must match.
6. Check the logs: first determine whether the issue is at core startup, remote connectivity, the TLS handshake, DNS, or routing.
7. Restore complex settings last: after the basic connection works, enable subscription auto-updates, DNS policies, and routing rule sets.