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

1. How Project V, V2Fly, and Xray are related

Project V is a family of network proxy tools, with V2Ray as its core software. The V2Fly community continues V2Ray's development and maintenance. In the context of client core selection, “V2Fly core” generally means the V2Ray core maintained by that project. Xray branched from V2Ray's codebase in 2020 and has since followed its own path for features and configuration.

A shared codebase doesn't mean today's configurations are interchangeable. Both projects retain core concepts such as inbounds, outbounds, and routing, and support some of the same protocols. But newer features, field names, and configuration formats can differ. A configuration that Xray can read isn't necessarily usable as-is with V2Fly.

• Client: Provides server lists, subscription imports, QR code scanning, and system integration. This guide compares v2rayNG and v2flyNG on Android; the corresponding desktop client is v2rayN.
• Core: Reads the configuration and handles connections. v2rayNG uses Xray, while v2flyNG uses V2Fly. For v2rayN, check the installed version and the configuration in use to confirm which core is selected.
• Protocol and transport: VMess and VLESS define proxy protocols; TCP and WebSocket are transport methods; TLS and REALITY are separate connection security settings.

2. Support for VMess, VLESS, REALITY, and XTLS

Don't judge compatibility by whether a node is labeled “V2Ray.” At a minimum, a node specifies an address, port, authentication method, and transport settings, and may also include TLS or REALITY parameters. A subscription group name is just a label—not a statement about protocol support.

VLESS doesn't provide transport encryption, so using VLESS doesn't mean TLS is enabled. REALITY is not a proxy protocol alongside VMess and VLESS. In Xray configurations, it's a transport security setting, often used with VLESS and Vision. These names refer to different configuration layers.

XTLS is a line of technical development, and XTLS settings found in older guides may not work with current nodes. If you see flow=xtls-rprx-vision, use the complete combination provided by the server. Don't follow an outdated tutorial and change the transport security setting directly to xtls. A node appearing in the client doesn't mean the core accepts all its parameters.

3. Choosing between v2rayNG and v2flyNG on Android

The two clients overlap in what they do, but “newer core means faster” and “older protocol means more stable” aren't reliable ways to choose. Real-world performance also depends on server load, network access, DNS, routing, and the transport combination. Without tests on the same network and server, there's no basis for claiming a consistent speed difference.

These recommendations are based on protocol requirements, not a performance ranking for every device. If v2flyNG starts successfully, the sites you need are reachable, routing behaves as expected, and your subscription doesn't use Xray-specific features, keeping your current setup is usually easier to maintain than switching without a clear reason. If the server requires REALITY, however, use a compatible client instead of repeatedly editing a configuration the core can't support.

4. Check node fields and distinguish remote ports from local listeners

Start your first round of checks with the ports. The examples below use remote port 443, local SOCKS port 10808, and local HTTP port 10809. The last two are examples only; not every client or version uses the same ports.

The node provider sets the remote port, which must match the server's listening port. Local ports accept connections from apps on your device; they don't need to match the remote port. Android VPN mode routes traffic through the system VPN interface, so it isn't simply a matter of having every app connect manually to local port 10808. Changing the listening address can also affect whether other devices can access it, so don't expose a listener to your local network just to troubleshoot.

1. Protocol and authentication: Confirm whether the node uses VMess or VLESS and whether its user ID is complete. The editing screens for the two protocols are not interchangeable.
2. Transport: Check whether the node uses TCP or WebSocket. For WebSocket, also verify the path and Host. Whether a field should be empty depends on the server configuration.
3. Standard TLS: Check the SNI and the server's certificate requirements. Don't make skipping certificate checks a permanent workaround.
4. REALITY: Verify the server name, server-provided public key, Short ID, and fingerprint settings. Link parameters such as pbk, sid, and sni may not use the same names as fields in the core's JSON configuration.
5. Vision: Make sure flow matches the server and that the current core supports the transport combination. Don't delete flow control just to clear an error.

5. Two ways to use one subscription on desktop and Android

You can use the same node source with v2rayN on desktop and an Android client on your phone, but don't assume their runtime configurations are identical. A subscription usually updates server entries; system proxy settings, VPN routing, per-app rules, DNS, and local routing remain device-specific.

To migrate, add the subscription in the new client and update it first, then edit a target node and check its fields. Keep a record of the old client's configuration, but enable only one proxy endpoint during testing. Android typically allows only one active VPN service per user at a time. Switching between clients that compete for the VPN interface makes connection results hard to compare.

• Share links and QR codes may contain access credentials. Don't post them in public forums.
• Subscription updates may overwrite manual changes to server entries. Record any changes you need to keep separately.
• Desktop system proxy mode and Android VPN mode may route different traffic. Don't compare results based only on what happens in a browser.

6. Imported successfully but won't connect? Check four layers

Seeing a node in the server list only means the client parsed or saved it; it doesn't mean a connection was established. Start by checking whether the configuration starts, then check the remote connection, handshake, and traffic routing. Change one type of setting at a time so you can tell what fixed the issue.

1. Check core startup. Open the client log and look for configuration parsing or startup errors first. If you see messages about an unknown field or flow control, check core support and version before changing DNS.
2. Check remote reachability. Confirm the server address and port are correct, and distinguish a connection timeout from a refusal or DNS resolution failure. Each points to a different layer; they shouldn't all be dismissed as a protocol issue.
3. Check handshake parameters. For TLS errors, check the device clock, SNI, and certificate. For REALITY, check the server name, public key, and Short ID. If server parameters are missing, ask the node provider rather than guessing combinations.
4. Check routing and traffic capture. If the core is running but apps still connect directly, check VPN permission, per-app lists, bypass rules, and DNS. On desktop, check the system proxy status in v2rayN and whether the target app uses the system proxy.

To compare two cores, keep the device, network, server, and protocol/transport combination the same, then record the results. Network changes, different egress routes, and routing rules introduce extra variables. A single latency reading during a connection test doesn't represent download throughput, much less prove that one core is faster in every environment.

7. Common questions about choosing a core