Xray vs. V2Fly: Which Core Should You Use with v2rayNG or v2flyNG?

How Project V, V2Fly, and Xray are related

Project V is an ecosystem of network proxy tools, with V2Ray as its core software. V2Fly continues the community development of V2Ray, while Xray started as a V2Ray fork and later developed its own protocol extensions and implementation path. They share a configuration history, but they are not the same program under different names. The fact that both use a file called config.json does not make them interchangeable.

The client handles the interface, subscription management, and system-level traffic routing; the core parses configuration, establishes connections, and applies routing. v2rayNG bundles Xray on Android, while v2flyNG bundles V2Fly. On desktop, v2rayN's core options depend on the specific version, node type, and core settings. Its flexibility should not be assumed to apply to either Android client.

Version numbers from these two development tracks are not directly comparable. Track the app version and core version separately: an app update may change the interface without switching core families, while a node connection error may stem from a field unsupported by the bundled core. When troubleshooting, having both version numbers is more useful than simply saying you installed the latest version.

Protocol support: check the full connection setup

VMess and VLESS are proxy protocols; WebSocket and gRPC are transport options; TLS and REALITY are connection security settings. Choose a client by checking all of these layers together. Seeing a vless:// link alone does not prove that every VLESS-compatible implementation can connect to the same server.

config.json: shared structure and migration limits

Common configs include inbounds, outbounds, and routing. Inbounds accept traffic from local apps, outbounds determine how to reach destinations, and routing selects an outbound. The example below uses a traditional JSON structure common to both and sets up a local SOCKS connection with direct routing. It's for understanding the fields only: it contains no remote proxy node and does not create an encrypted proxy connection.

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": ["127.0.0.0/8"],
        "outboundTag": "direct"
      }
    ]
  }
}

Here, listen limits the local listening interface, tag is an internal reference name, and outboundTag must match an outbound tag. The direct outbound is listed first, so traffic that matches no rule also goes direct. If you migrate only the routing rules without the referenced outbound, the config may fail to load rather than automatically filling in the missing node.

• Shared fields still depend on the format: V2Fly's different config formats and Xray's configuration documentation are not interchangeable. First confirm which JSON format the client accepts.
• Don't copy extension fields blindly: Handle security: "reality" and flow: "xtls-rprx-vision" according to the documentation for the corresponding Xray version.
• Key fields vary by version: Use the actual core version as the source of truth for the names and compatibility of REALITY client key fields. Don't add fields based only on an old screenshot.
• Migrate assets too: Check geodata files referenced by routing rules, file paths, and tag names together. Valid JSON syntax does not mean all runtime requirements are in place.

Subscription imports and Android VPN routing

A subscription distributes node details; it is not a core protocol. Adding the same subscription URL in two clients does not mean both will recognize every node field, and conversion can sometimes drop transport parameters. If both clients import the same number of nodes but one can't connect, open the node's settings and compare them with the original connection parameters instead of repeatedly refreshing the subscription.

Android VPN routing and the proxy core are separate layers. The client receives traffic through the system VPN interface, then passes it to its internal processing chain; this does not mean the remote node uses a traditional VPN protocol. Usually, only one VPN service can be active for a given user or profile. When switching between v2rayNG and v2flyNG, stop the first client before authorizing and starting the second. Otherwise, the system may revoke the original service, which can look like a random connection drop.

1. On first launch, approve the system VPN request, then check whether the client reports a startup error.
2. To exclude specific apps, check the client's per-app proxy settings and confirm whether the list includes apps or bypasses them.
3. If the connection stops after you leave the app, check Android background restrictions and battery optimization before changing the server protocol.
4. Pause other tools that use the VPN interface during testing to reduce traffic-routing conflicts.

Connection problems: check the port, handshake, then DNS

Choosing a core doesn't replace network troubleshooting. A connection timeout may mean the server port is unreachable; a TLS error may point to the server name or device clock; and pages that won't load may be caused by an unexpected DNS path. The three numbers below are diagnostic reference points, not client defaults or performance benchmarks.

Control conditions when comparing performance: use the same network, server, time window, and test destination, and record connection success rate, latency, and sustained throughput separately. One latency test can't show which core uses less battery or delivers higher throughput; mobile network changes, device temperature, and background tasks can all affect the results. Before sharing diagnostic logs, remove connection details such as subscription URLs, user identifiers, and keys.

Choosing between v2rayNG and v2flyNG

If the server explicitly provides an Xray-specific connection setup, v2rayNG is the more direct choice. If you have a V2Fly config that has worked for a long time and don't need new protocol features, v2flyNG can reduce migration variables. Judge both by actual connectivity and field compatibility; there's no need to replace a proven config just to use a different core name.

• Setting up a new VLESS + REALITY + Vision connection: Choose v2rayNG and check that the bundled version supports the Xray capabilities the server requires.
• Keeping a custom V2Fly config: Test it in v2flyNG first. If migration is necessary, convert fields and assets one by one.
• Using a VMess-only subscription: First confirm that transport and TLS parameters are complete, then compare the clients' per-app and routing controls for everyday use.
• Sharing nodes between desktop and Android: Verify the core, DNS, and routing settings separately in v2rayN and the Android client. Subscription sync is not full config sync.