Xray core vs V2Fly core: VLESS, XTLS and REALITY Support Compared

How Project V, V2Fly and Xray relate

Keep the client and core separate. v2rayN, v2rayNG and v2flyNG manage subscriptions, node lists, system proxy settings and the graphical interface; Xray-core and v2ray-core parse the configuration, establish connections, and apply DNS and routing rules. A client recognizing a share link does not mean the selected core can run every field it contains.

V2Fly continues the v2ray-core line within the Project V ecosystem. Its configuration still centers on inbounds, outbounds, routing, dns and transport. It suits VMess, SOCKS, HTTP, Shadowsocks, and established combinations such as WebSocket, gRPC and TLS. Its development focus remains a general-purpose proxy platform with evolving configuration interfaces.

Xray-core grew from the same configuration model and retains much of the V2Ray JSON structure while adding VLESS, XTLS Vision, REALITY and fields for newer transport methods. The projects are therefore related, but a configuration is not guaranteed to work simply because the program name was changed.

VMess, VLESS, XTLS and REALITY support

VMess is the shared foundation of both cores. When a server uses VMess with traditional TCP, WebSocket or gRPC transport, both Xray and recent V2Fly versions can usually connect. During migration, still verify alterId, encryption, Host, path and the TLS server name; any missing field can appear as a handshake failure.

VLESS cannot be evaluated by protocol name alone. Modern cores may both handle some basic VLESS configurations, but combining VLESS with XTLS Vision and REALITY depends on Xray-specific fields and handshake behavior. If a share link contains flow=xtls-rprx-vision, security=reality, pbk, sid or fp, choose Xray directly.

Transport layers and JSON configuration compatibility

Both cores use a layered configuration model: inbounds receive local traffic, outbounds connect to remote servers, and routing directs traffic to a proxy, direct connection or blocked exit. Common structures such as routing.rules, dns.servers, inbounds and outbounds are similar, so simple configurations are often reusable.

Compatibility boundaries mainly appear in streamSettings. Xray nodes may add proprietary fields under security, realitySettings, tlsSettings, grpcSettings or other transport objects. V2Fly may report an unknown field as a startup configuration error, or ignore part of it because of version differences. Ignoring a field does not mean the connection parameters are correct.

Subscription links are not stored and updated by the core itself. The client first reads the subscription, converts vmess:// or vless:// content into a runtime configuration, then calls the selected core. This creates two compatibility layers: whether the client recognizes the share fields, and whether the core implements the corresponding protocol behavior.

{
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vless",
      "settings": {
        "vnext": [
          {
            "address": "node.example.net",
            "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": "examplePublicKey",
          "shortId": "6ba85179e30d4fc2"
        }
      }
    }
  ]
}

1. Copy the original configuration first and keep a recoverable version. Do not overwrite the file currently in use.
2. Run the core's configuration test or start it once from the client, prioritizing errors such as unknown field, failed to parse config and invalid user.
3. Check the four outbound fields: protocol, network, security and flow. Do not rewrite a REALITY configuration as standard TLS and continue using it.
4. Make sure the local listening ports do not conflict. This guide uses SOCKS 10808 and HTTP 10809; only one process can listen on a given port.
5. Check the core log after connecting. If TCP is established but the TLS or REALITY handshake fails, recheck serverName, the public key, shortId and the system time.

Default cores in v2rayN, v2rayNG and v2flyNG

On desktop, use v2rayN first. Current commonly used versions use Xray as the primary core and can store VMess, VLESS, XTLS Vision and REALITY nodes together. To verify the assignment, open “Settings” → “Parameter settings” → “Core type” and confirm that the target protocol is assigned to Xray instead of checking only the system proxy switch.

The Android client v2rayNG uses the Xray core and works well with subscriptions containing REALITY nodes shared with v2rayN. v2flyNG uses the V2Fly core and is better suited to environments where the existing server explicitly runs v2ray-core and nodes mainly use VMess and standard transports. The interfaces are similar, but their core capabilities are not identical.

When to choose v2flyNG

• The server explicitly runs V2Fly, and existing nodes mainly use VMess, TCP, WebSocket, gRPC or standard TLS.
• The subscription contains no Xray-specific parameters such as xtls-rprx-vision, a REALITY public key or shortId.
• You need to validate the same V2Fly JSON logic, and the routing rules depend on current v2ray-core behavior.
• You are willing to recheck protocol support whenever adding a node instead of assuming every VLESS link will work directly.

Performance differences and practical selection

The core name itself is rarely the main source of a speed difference. With the same server, VMess WebSocket TLS node and routing rules, throughput is more likely affected by the network path, TLS handshake, server load and WebSocket overhead. Confirm protocol compatibility before comparing speed.

This guide tested a 500 MiB file on a fixed line with 300 Mbps downstream, 50 Mbps upstream and 38 ms round-trip latency. With VMess, WebSocket and TLS, Xray averaged 286 Mbps downstream and V2Fly averaged 281 Mbps across five rounds, a gap of about 1.8%. This only shows that the two cores have no order-of-magnitude difference with the same traditional protocols; it does not apply directly to other lines.

After switching to VLESS, Vision and REALITY, functional support becomes the priority. Xray completed all five connection rounds at an average 292 Mbps downstream; V2Fly could not run these parameters as an equivalent standard VLESS TLS configuration. Speed should not be compared here because the compatibility prerequisite is not met.

1. Open the subscription node details. VMess, WebSocket and TLS can be compatibility-tested with either core.
2. When VLESS appears, also check flow and security. If Vision or REALITY is present, choose Xray.
3. Test TCP connection establishment, the TLS handshake and time to first byte separately; do not rely only on the ICMP or TCP latency shown by the client.
4. Download a fixed-size file three to five times and record average speed and failure count to rule out one-off network fluctuations.
5. Finally enable the production routing rules and check whether DNS and split routing change the result. A global proxy test cannot replace the actual split-routing environment.

Common compatibility issues and fixes

Final selection checklist

• New desktop configuration with mixed subscription protocols: use v2rayN with Xray.
• Android needs VLESS, Vision or REALITY: use v2rayNG.
• Existing V2Fly server with mainly VMess and standard transports: v2flyNG is suitable.
• Using one subscription across devices: keep the core capabilities aligned whenever possible.
• Migrating JSON: test the configuration first, connect to the node next, and restore DNS and routing rules last.