Xray vs. V2Fly: Comparing the Cores Behind v2rayNG and v2flyNG

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

Project V is a collection of tools and technologies for network proxying, with V2Ray as its core project. The V2Fly community continues to maintain the V2Ray core, while Xray was forked from the V2Ray codebase in 2020 and developed independently. The projects share a history, but their cores now evolve separately. Similar-looking configuration files don’t guarantee that every feature is interchangeable.

The core establishes connections, applies routing, handles DNS, and transfers data. The client displays nodes, manages subscriptions, provides settings, and launches the core. On Android, v2rayNG uses the Xray core and v2flyNG uses the V2Fly core. Desktop v2rayN is a client—not a third protocol or an alias for either core.

• Project names: Xray and V2Fly refer to two separate core development paths.
• Client names: v2rayN, v2rayNG, and v2flyNG are the apps you interact with.
• Protocol names: VMess and VLESS are protocols that clients and servers use to exchange proxy traffic.
• Transport and security layers: WebSocket, TCP, TLS, and REALITY describe other parts of a connection; they are not client names.

So, “The node says V2Ray—which app should I install?” isn’t enough to choose a client. Providers may use “V2Ray node” as a catch-all for several configurations. Check the fields in the node details and the core features the server requires.

2. Protocol compatibility: VLESS is not REALITY

A common source of confusion is treating VLESS, REALITY, and XTLS as a single feature. VLESS is a proxy protocol; it does not itself provide encryption for the entire connection. TLS and REALITY are separate security-layer options. XTLS Vision involves flow control and data handling; a common configuration field is flow=xtls-rprx-vision.

“Supports basic VLESS” doesn’t mean “supports every VLESS share link.” A link may include security=reality, type=tcp, and flow=xtls-rprx-vision at the same time. If any required feature is unsupported, the link may import but fail to start—or start but fail during the handshake.

3. v2rayNG vs. v2flyNG: Choose a client for your nodes

The two apps have similar names, but choosing between them is straightforward. Start with the provider’s requirements, then consider how you maintain your setup. Broader feature support doesn’t make every connection faster. For the same standard VMess node, link quality, exit congestion, and routing rules usually matter more than the client’s name.

If your current client works, first identify what switching is meant to solve. A new node requiring REALITY or a core that doesn’t recognize the flow is a clear feature requirement. Hearing that a core is “faster” isn’t enough reason to migrate. Before upgrading or switching devices, save your subscription URL and essential routing settings—but never post links containing account details in public forums.

• Only have a subscription URL? Check the node details after importing, or ask the provider which core and minimum version they recommend.
• Only have standard VMess nodes? Either core is an option; decide based on your existing setup and actual connection results.
• Have a mixed subscription? Check that each node parses correctly, especially entries using REALITY or Vision.
• Need custom JSON? Use the target core’s configuration format. Don’t import an entire Xray configuration as a V2Fly configuration.

4. Which share-link fields determine compatibility?

A subscription distributes a list of nodes; it isn’t a connection protocol. Base64 is commonly used to encode the list, while vmess:// and vless:// are node-sharing formats. Base64 only changes how text is represented—it can’t add REALITY support to a core that lacks it, and it shouldn’t be treated as encryption.

When checking a VLESS node, sort its fields into the four groups below. These descriptions explain what the parameters mean; they aren’t a ready-to-use node link. Get actual values from the provider—don’t guess or assemble them from experience.

REALITY clients use the public key information provided by the server; the private key stays on the server. Some versions of the editor may use different field names, so check the documentation for that version to confirm which fields correspond. The public key in a share link isn’t a value for you to generate yourself. Changing it arbitrarily breaks the relationship required for the handshake.

1. Import from a complete link or subscription to avoid truncating query parameters when copying by hand.
2. Open the node editor and confirm that the protocol, transport, security layer, and flow are all preserved.
3. If an entry is skipped, check the import format and app version first. Don’t assume that a missing node means the server is down.
4. If the entry appears but the connection fails, check the core logs and server parameters.

5. Importing and testing on Android: remote ports vs. connection tests

In the commonly used Chinese-language version of v2rayNG, subscription management is usually under “Subscription group settings” in the side menu. Add the URL, then select “Update subscription” from the main-screen menu. To add a single share link, tap “+” in the upper-right corner, then “Import from clipboard.” Menu labels may vary slightly by version. Check the current interface in v2flyNG too; don’t assume one version’s menu path applies to every release.

These three items are examples, not speed-test results or defaults for every version. The remote port is the server’s connection endpoint; a local listener port is where apps send traffic to the client. Don’t mix them up. Some versions use a mixed listener port, so check the actual settings. Don’t add an HTTP endpoint that doesn’t exist just to match a tutorial.

1. Record the versions: Find the app version and core version on the About screen or in the startup log. Include both when reporting an issue; the app version number doesn’t replace the core version.
2. Check the node: Select the imported node and verify the server port and security layer. Don’t enter a local port such as 10808 as the server port.
3. Start the service: The first time you start in VPN mode, approve the permission prompt from Android. Stop any other service using Android’s VPN connection before testing.
4. Verify access: Open a destination that should use the proxy, then check the logs for connection and routing entries. A “running” status alone doesn’t mean the destination’s traffic is going through the proxy.
5. Understand the test: TCP latency only reports the result of a particular connection test. It doesn’t fully verify authentication, TLS, REALITY, or access from an actual app.

6. Sharing a subscription between desktop v2rayN and Android

Sharing a subscription avoids entering nodes twice, but it doesn’t sync all local settings. Desktop system proxy settings, Android VPN permissions, per-app rules, and DNS policies are configured separately. Even with the same node selected on both devices, different routing rules may send traffic to the same destination through different exits.

If the desktop works but Android doesn’t after switching networks, first compare the node actually selected on each device and the core’s capabilities. Then check Android’s app routing and DNS resolution path. Don’t skip these checks just because the subscription is the same. Subscription URLs may contain access tokens; hide the full URL, UUID, and other account details in troubleshooting screenshots.

7. Troubleshooting import failures, handshake errors, and slow speeds

Choosing a core addresses feature compatibility, not every network issue. The stage where an error occurs is more useful for diagnosis than asking which core is “more powerful.” First check whether the node imports, then whether the core starts, then the remote handshake and destination access. Compare performance only after that.

Should you switch from V2Fly to Xray for better speeds?

There’s no universal answer. Vision’s processing may perform differently in suitable scenarios, but that doesn’t mean it’s faster on every network. A meaningful comparison uses the same device, network, server, and comparable configuration, and tracks handshake time, download throughput, and stability separately. If the protocol or route changes, you can’t attribute the entire difference to the core.

The node only says VLESS. What should you ask first?

• Does it use standard TLS or REALITY?
• Does it require xtls-rprx-vision, and which transport type does it use?
• Which core does the provider recommend, and what’s the minimum core version?
• Can the provider share a complete link instead of just the server address and UUID?