Comparing Xray and V2Fly cores: VLESS, XTLS, and REALITY support

1. Xray and V2Fly: The Core Is Not the Client Interface

V2Ray is the name of a proxy software project and is also commonly used as a general term for this type of tool. V2Fly is the community project that maintains V2Ray. The core handles inbound connections, routing, protocol processing, and outbound connections. Xray branched from the V2Ray codebase. The two share a history but now have independent feature development and configuration conventions. Xray is not simply V2Fly under a new name.

The client manages subscriptions, node settings, and system network options; the core handles the actual connection. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. On desktop, when using v2rayN, check which core the current configuration invokes rather than relying on the main window title. After updating the client, check the startup log to confirm the loaded core name and version.

This sequence highlights two different failure cases: seeing a node in the list only means the client parsed the subscription. The node is usable only when the core loads the configuration and completes the remote handshake. A protocol name appearing in the interface does not guarantee that the current core understands every field in that protocol combination.

2. VLESS, XTLS, and REALITY: Where Support Differs

Protocol, transport, and security are separate layers. VMess and VLESS are proxy protocols; TCP and WebSocket carry the data; TLS and REALITY provide connection security. XTLS Vision optimizes eligible traffic through a specific flow-control mechanism. A node labeled “VLESS” alone does not tell you which core to use—you also need to check the security layer and flow.

VLESS does not encrypt payloads on its own; common configurations pair it with a security layer such as TLS or REALITY. It is not simply a “new version” that replaces VMess. To assess compatibility, consider the complete combination—for example, “VLESS + TCP + REALITY + Vision”—rather than comparing only the first item.

3. Two Configuration Examples: Fields to Check Together

These cards illustrate how to identify parameters; they are not ready-to-use nodes. The domains use reserved example names, and the paths and ports are illustrative. Use the values provided by the server or subscription for an actual connection. In particular, don’t combine one node’s UUID with another node’s public key and a third node’s server name.

A REALITY client does not use the server’s private key. It needs the corresponding public key and other authentication details; the private key must remain on the server. shortId is represented in hexadecimal, and valid values are determined by the server. Don’t treat it as a note or generate a replacement for the value in your subscription. The server name is usually set through serverName or the link parameter sni and must match the server configuration.

The “fingerprint” in a client usually refers to an emulated TLS ClientHello profile, not a device identifier. Changing fingerprint to chrome won’t fix an incorrect public key, UUID, or port. REALITY does not necessarily mean Vision is enabled: they are separate configuration options. Set flow only when the server uses a compatible combination.

• VLESS: Check the UUID, encryption, and flow. The common encryption value is none; don’t copy VMess’s auto setting as-is.
• WebSocket: Check the path and Host request header. TLS serverName and the WebSocket Host are separate fields.
• TLS: Keep certificate validation enabled. Don’t hide certificate or server-name errors by skipping validation.
• REALITY: Check the public key, server name, shortId, fingerprint, and core version. Interface labels and JSON fields may vary between versions; follow the current core documentation and the configuration generated by your client.

4. Configuration Migration: Similar JSON Does Not Mean Full Compatibility

Traditional Xray and V2Fly configurations both include structures such as inbounds, outbounds, and routing, but shared structures do not make every field interchangeable. V2Fly configurations also vary by format. Before migrating, confirm which configuration format the target core accepts, then check the specific protocol and transport fields. Handing an entire Xray configuration to V2Fly may cause it to fail during loading.

This example shows a common Xray VLESS + TLS + Vision outbound snippet to illustrate where flow is set. It is not a complete configuration; the example domain and all-zero UUID are deliberately invalid and cannot be used as a real node. The snippet does not include REALITY parameters, and changing tls to reality alone will not convert it.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.example.com",
            "port": 443,
            "users": [
              {
                "id": "00000000-0000-0000-0000-000000000000",
                "encryption": "none",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "node.example.com",
          "allowInsecure": false
        }
      }
    }
  ]
}

1. Save your current settings first. Note the client and core versions, current node, and routing preset. Backup files may contain credentials, so store them securely.
2. Migrate one node first. Reimport it using a node link or subscription supported by the target client, then inspect the generated configuration. Don’t overwrite all routing and DNS settings at once.
3. Confirm the core starts first. If the log reports an unknown protocol, unknown security type, or unsupported flow, fix the configuration or choose a compatible core instead of repeatedly testing network latency.
4. Restore routing next. Check the outbound tags referenced by the rules, domain and IP data files, and DNS handling. A working connection does not mean the old rules migrated correctly.

5. Choosing and Testing v2rayNG vs. v2flyNG

Android users with REALITY or Vision nodes will usually want v2rayNG. If your existing V2Fly configuration uses a standard compatible combination and works correctly, you can keep using v2flyNG. For desktop users, v2rayN is the management interface; the key questions are which core the current node uses and whether that core supports its parameters.

Don’t change the core, node, DNS, and routing preset all at once. Change one thing at a time so you can identify the cause of any issue. The port numbers below illustrate the role of each port; they are not speed-test results or universal client defaults. Check the current configuration to see which ports are in use.

A TCP connection to remote port 443 only shows that this layer is reachable; it does not confirm that VLESS authentication, TLS, or the REALITY handshake succeeded. If local port 10808 is already in use, the core may fail to start, regardless of remote protocol compatibility. DNS follows its own path: a browser resolving a domain does not prove that the resolver used by the core is reachable.

• Core logs: First look for a successful startup and the actual version, then check connection errors. Distinguish configuration loading, DNS, handshake, and timeout errors.
• Traffic routing: On desktop, check whether the system proxy is enabled. On Android, check VPN permission and per-app proxy scope. If traffic is not routed into the core, requests may never reach it.
• Test under the same conditions: Keep the network, node, and routing settings unchanged, then verify with an actual web request. A single latency test does not prove full compatibility.
• Sharing logs: Hide subscription tokens, UUIDs, server addresses, and authentication parameters. Error type, version information, and timestamp are usually enough to help troubleshoot.

6. FAQ: Importing, Starting, and Connecting Are Different