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

1. Xray and V2Fly: Shared Roots, Different Configuration Boundaries

Project V is the starting point for understanding this ecosystem. V2Ray is its core proxy tool, with the V2Fly community maintaining its development. Xray-core forked from the V2Ray project and went on to develop its own features and configuration system. The two share concepts such as inbounds, outbounds, and routing, but that does not mean every JSON file can be used interchangeably.

The client handles the node list, subscription updates, interface settings, and startup; the core processes connections, protocol handshakes, and routing. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. On desktop, the cores available in v2rayN and how they are invoked depend on the distribution and configuration type. When troubleshooting, check the executable and version shown in the startup log.

• Client name: Identifies the interface you use; it does not, by itself, confirm which core is running.
• Node protocol: For example, VMess or VLESS, which defines the structure of the proxy connection.
• Transport: For example, TCP or WebSocket, which determines how proxy data is carried.
• Security and flow control: TLS, REALITY, and Vision belong to different configuration dimensions and should be checked separately.

2. VLESS, XTLS Vision, and REALITY Support Compared

VLESS does not provide transport encryption on its own; it is commonly paired with TLS or REALITY. V2Fly also implements VLESS, so “VLESS always requires Xray” is not accurate. What you need to check is the specific combination of flow control, security layer, and transport. Do not assume that an Xray extension with a given name is also supported by V2Fly.

XTLS Vision is a flow-control mechanism, commonly configured with the value xtls-rprx-vision. It is not a transport, and you cannot enable it by renaming a node’s TLS setting to Vision. REALITY is an Xray security mechanism that requires matching parameters on both the client and server. It is not a subscription encoding format or a standalone client.

Standard TLS typically relies on a certificate and domain validation. REALITY uses a different handshake and authentication parameters; disabling certificate validation is not a substitute. The server’s allowed serverName must match the client’s key material and shortId. A reachable port alone does not mean the proxy handshake will succeed.

3. Configuration: Know Where to Set flow and security

The Xray outbound example below shows how to identify configuration fields and combines VLESS, Vision, and standard TLS. The domain is reserved for examples, and the UUID is illustrative; this is not a working node. For an actual deployment, replace them with the server address, user ID, and certificate domain provided by your server, and confirm that the server enables the required flow control.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "example.com",
            "port": 443,
            "users": [
              {
                "id": "e1dd2b67-68ca-4c8f-a92b-27eb305d91e7",
                "encryption": "none",
                "flow": "xtls-rprx-vision"
              }
            ]
          }
        ]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "example.com"
        }
      }
    }
  ]
}

In this example, encryption: "none" is a VLESS user field; it does not mean the entire connection is sent in plaintext. The outer security: "tls" provides transport security. flow belongs inside the user object, while security belongs inside streamSettings. Putting either field at the wrong level can cause errors or prevent the settings from taking effect.

• Switching to REALITY: You cannot just change tls to reality. You also need the corresponding realitySettings and the parameters provided by the server.
• Key fields: Share links often use pbk to carry the server’s public key material. Depending on the Xray version, JSON configurations may use publicKey or password. Generate the configuration according to the actual core version rather than copying an old screenshot.
• Other mappings: In a share link, sni, sid, and fp usually correspond to the interface options serverName, shortId, and fingerprint. Check each field after importing.
• Migrating old configurations: You cannot migrate legacy XTLS settings to Vision by replacing field names throughout the file. Check the transport, flow control, and server support together.

4. Choosing Between v2rayNG, v2flyNG, and v2rayN

If your existing subscription explicitly uses VLESS with Vision and REALITY, v2rayNG with the Xray core is the preferred choice on Android. Use v2flyNG if your configuration is built around V2Fly and does not rely on those Xray features. There is no need to migrate a working VMess configuration just because the client names differ.

5. Core Switch Connection Failures: Check from Port to Handshake

First distinguish between “the core did not start” and “the core started but the remote connection failed.” For startup failures, check the JSON, field support, file paths, and local port conflicts. For remote connection failures, check the server address, security parameters, network connectivity, and system time. Blaming every failure on core speed can distract from configuration issues you can actually fix.

The local address and ports above illustrate how to check the connection; they are not defaults for every client. First check the SOCKS listening port shown in your client. If it is not 10808, update the command below. Remote port 443 and the local proxy port belong to two separate connections and cannot be substituted for each other.

curl --proxy socks5h://127.0.0.1:10808 https://example.com/

1. Check the local listener: If the local proxy connection fails immediately, confirm that the core started successfully, the port matches, and no old instance is using the same port.
2. Check the imported node: Compare it with the original node parameters and verify the UUID, server port, flow, SNI, and REALITY settings. Base64 is only an encoding; it cannot fill in missing fields.
3. Check the remote handshake: For TLS or authentication errors, check the system time, domain, and key material. Disabling validation is not a general fix.
4. Check proxy coverage: If commands work but your browser does not, check the system proxy, per-app proxy settings, routing rules, and DNS. Changing the server protocol should not be your first step.

To compare cores, use the same node, network, destination, and roughly the same time. Disable variables such as Mux first, then review the logs and connection results. Node load, network routes, server-side throttling, and the destination’s response can all affect speed. Broader protocol support does not guarantee higher throughput on every route.

6. Core Selection FAQ

The decision comes down to a simple checklist: confirm what the server requires, what fields the client can generate, and whether the running core accepts those fields. Keeping these three layers separate is more reliable than guessing compatibility from the client’s name.