Xray and V2Fly cores: XTLS, REALITY, and Protocol Compatibility Compared

How the two core branches differ

The V2Fly core generally refers to the community continuation of v2ray-core. It handles inbound and outbound settings, routing, DNS, transport, and policies. Xray-core grew into an independent branch from the early v2ray-core codebase. It retains many similar configuration structures while extending support for VLESS, XTLS, REALITY, and more. These are not two themes for the same program, and switching between them is not as simple as renaming the client.

Desktop and Android clients mainly handle subscription management, node editing, system proxy controls, and log display. The core is what actually establishes connections and applies routing. Whether the same server address, port, and user ID work with another core depends on matching protocol fields, transport, security layer, and core version.

The versions above indicate the generation used when checking configurations for this article; they are not necessarily the latest versions shown in the download center. Core updates may add fields, remove legacy aliases, or change validation rules. Before migrating a configuration, confirm the version actually running and check the first version line in the logs.

Why XTLS Vision and REALITY are the main differences

XTLS is a transport optimization system in the Xray branch. In current node configurations, it is most often used with VLESS and the xtls-rprx-vision flow control. The client and server must both understand the corresponding flow value. If the server requires Vision but the client core ignores or does not recognize the field, the connection will usually fail during the handshake rather than downgrade automatically to standard TLS.

REALITY is Xray’s security and handshake scheme. A working client configuration typically needs the server address, port, user ID, serverName, public key, shortId, fingerprint, and other details. If the subscription lacks the public key or the shortId does not match, the core will reject the handshake even when a TCP connection can be opened to the address and port.

A typical Xray REALITY outbound snippet

{
  "protocol": "vless",
  "settings": {
    "vnext": [
      {
        "address": "198.51.100.20",
        "port": 443,
        "users": [
          {
            "id": "11111111-2222-3333-4444-555555555555",
            "encryption": "none",
            "flow": "xtls-rprx-vision"
          }
        ]
      }
    ]
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "serverName": "www.example.com",
      "fingerprint": "chrome",
      "publicKey": "Example public key showing the field location",
      "shortId": "6ba85179e30d4fc2"
    }
  }
}

This snippet is only for identifying the field hierarchy; its address, user ID, and public key do not identify a usable node. Passing it to a core without REALITY support commonly results in a configuration parsing error, an unknown security type, or startup failure. The correct fix is to switch to the matching Xray core, not delete the offending field and continue.

Matching protocols do not guarantee interchangeable configurations

Xray and V2Fly share many historical configuration concepts, including inbounds, outbounds, routing, dns, and policy. A basic VMess outbound is often easy to migrate, but a complete configuration may also reference branch-specific fields, rule resources, transport parameters, or experimental features. A core being able to read the JSON only proves that syntax and field validation passed; it does not prove that traffic is being routed as intended.

Subscriptions add another layer of client-side conversion. The content may be a list of share links or structured data generated by a server. v2rayN, v2rayNG, and v2flyNG parse the subscription first, then generate the runtime configuration required by the core. As a result, the same subscription can show the same node name in two clients while producing different JSON.

Migration checklist

1. Check whether the node uses VMess, VLESS, or another protocol. Do not rely solely on the node label.
2. Check key fields including security, flow, network, serverName, Host, and path.
3. Confirm the core and version actually used by the target client, and record the first line of the startup log.
4. Establish a connection with one node first, then test domain resolution, direct-connection rules, and proxy rules.
5. Import the full subscription only at the end, so a batch of nodes does not hide an individual configuration error.

Which core do v2rayN, v2rayNG, and v2flyNG use?

v2rayN is a desktop client. In current use, it typically relies on the Xray core for VLESS, Vision, and REALITY nodes. The client handles the node list, subscription updates, system proxy, and routing settings, while the core process handles the actual connection. When troubleshooting, distinguish the client interface version from the core version; they are not the same version number.

v2rayNG is an Android client powered by the Xray core, making it suitable for sharing subscriptions that include REALITY or Vision nodes with a desktop setup. v2flyNG targets V2Fly core configurations and is better suited to environments that explicitly use V2Fly servers, standard VMess/VLESS, and an existing v2ray-core configuration model.

• v2rayN: Go to “Settings” → “Parameter Settings” → “Core Basic Settings” to check the core path and log level. The common local mixed-proxy port is 10808; use the value in the current configuration.
• v2rayNG: Go to “Settings” → “Advanced Settings” to check the local proxy port, DNS, and logging options. After enabling a node, use the log page to confirm the Xray version and handshake errors.
• v2flyNG: Use it to run configurations generated for the V2Fly core. Before importing, confirm that the subscription contains no Xray-specific parameters such as REALITY or Vision.

Choose a core by node type and troubleshoot the connection

If the subscription clearly includes VLESS, REALITY, or Vision, choose v2rayN on desktop and v2rayNG on Android; this is usually the shortest path. If the server explicitly runs V2Fly, the nodes use standard VMess or VLESS, and an existing routing configuration has been verified, use v2flyNG to stay within the same core family.

Do not assume protocol incompatibility from a “node timeout” alone. A timeout can also result from an unreachable address, a blocked port, an incorrect system clock, abnormal DNS results, or a stopped server. Core incompatibility more often appears as configuration or handshake errors such as unknown field, unsupported security, failed to parse config, or invalid flow.

Five steps to verify the client

1. Stop the current connection completely and confirm that the old core process has exited.
2. Open the client settings and record the core name, core version, local SOCKS port, and HTTP port.
3. Start only one node and check whether the logs show that the configuration loaded and the local listener started.
4. Enable the system proxy, visit the target domain, and verify the matched routing rule and outbound tag in the logs.
5. Restore automatic subscription updates and the full routing rules only after the single-node test succeeds.

The final decision on core selection

The overlap between Xray and V2Fly covers many basic proxy configurations, but they are now independently evolving cores. Xray is identified mainly by the combination of VLESS, XTLS Vision, and REALITY. V2Fly’s value lies in maintaining its own configuration model and server deployment path. There is no rule that guarantees compatibility after rewriting every node into one kind of JSON.

For most users, the most reliable order of checks is node fields, client core, server implementation, and runtime logs. Use v2rayN on desktop and v2rayNG on Android to cover Xray-specific nodes; use v2flyNG when maintaining a clearly V2Fly-based environment. After changing cores, recheck the subscription, DNS, routing, and local proxy ports.

• See reality or xtls-rprx-vision? Choose Xray.
• Using standard VMess, VLESS, WebSocket, gRPC, or TLS? The two cores may be compatible, but verify every field.
• Configuration parsing failed? Check the core version and unknown fields first; do not change the server address prematurely.
• Connected but routing is wrong? Check the routing rules, DNS, and the final configuration generated by the client.