Xray vs. V2Fly cores: choosing between v2rayNG and v2flyNG

First, distinguish the client from the core

v2rayNG, v2flyNG, and v2rayN are clients that provide a user interface and system integration. The client typically manages subscription groups, node lists, and system proxy controls. The core it runs handles protocol handshakes, outbound connections, routing, and DNS. Client updates and core updates are related, but they are not the same thing.

Project V provides context for these names. The V2Fly community has continued development of the V2Ray core, so names such as V2Ray and v2ray still appear in core programs and configurations. Xray-core branched from related code in 2020 and went on to develop its own features and release track. The two share a history, but that does not mean every configuration can be used interchangeably today.

• v2rayNG: An Android client with the Xray core built in. The interface handles imports and start/stop controls; the core handles the connection.
• v2flyNG: An Android client that uses the V2Fly core, suitable for checking and running configurations built for that core.
• v2rayN: A desktop client. Check the current version, node configuration, and startup logs to confirm which core it uses; the word “v2ray” in its name does not tell you what is running.

A subscription is not a core either. A subscription URL returns node details or configuration data, which the client converts into a runnable configuration. Seeing node names after import only confirms that the import worked. It does not guarantee that every transport parameter was retained or that the core supports those parameters.

Protocol compatibility depends on the full set of parameters

Start by opening the node editor and checking the protocol, transport, transport security, and flow. VMess, VLESS, and Trojan are protocol names; WebSocket and gRPC are transport types; TLS and REALITY relate to connection security; and xtls-rprx-vision is a specific flow-control setting. These are different layers, so a “supports VLESS” label alone cannot establish compatibility with the complete configuration.

VLESS alone does not distinguish Xray from V2Fly; V2Fly also has a VLESS implementation. REALITY, Vision, and specific transport options are more likely to cause incompatibilities. Conversely, if an existing VMess node works reliably, there is no need to redeploy the server just because you see the name Xray.

Choosing and importing on Android

On Android, choose based on the node requirements first, then consider which client suits your workflow. These recommendations cover typical VLESS + REALITY imports; they are not speed rankings for every network. Throughput on the same node can also vary with the route, signal, server load, and routing rules, so you can’t infer performance from the core name alone.

1. Check what you’re importing. Tell a subscription URL apart from a single-node share link. Don’t paste a subscription URL into the server address field or share it publicly in screenshots or support logs.
2. Test a single node first. On the v2rayNG home screen, tap “+” in the upper-right corner, then “Import from clipboard.” Edit the imported node and check its address, port, UUID, and transport security settings.
3. Manage subscriptions separately. Open “Subscription group settings” to add a group and URL, then return to the home screen and use the menu to update the subscription. Menu labels may vary slightly by version; follow the current interface.
4. Test after connecting. Select a node, start the connection, and approve the system VPN prompt. Test access first, then configure per-app proxy settings so you’re not changing two variables at once.

When switching from v2flyNG to v2rayNG, compatible subscription or node details may carry over, but the full app state does not. Review per-app lists, DNS options, and bypass rules again. Keep only one VPN connection active while testing; a later connection may replace the earlier one, making system behavior look like a node failure.

On desktop, check which core is actually running

The v2rayN client version, the core version bundled with it, and a core updated later may all differ. Open “Settings” → “Parameter settings” to check the local listener and related options, then review the node editor and startup logs for the core name, version, and configuration errors. Core selection options vary between releases, so don’t assume a menu location from one version applies to all versions.

The remote port and local proxy port are separate settings. The 443 in a node is where the server listens; 127.0.0.1:10808 entered in a local app points to the proxy running on your computer. The latter works only if a listener is actually using that address and port and supports the required proxy protocol. Don’t change the local port to the remote port to try to fix a handshake failure.

System proxy and TUN are ways to route traffic into the client; they cannot add protocol support the core lacks. If the node parameters are incompatible, enabling TUN will not fix the connection. Conversely, if the node connects but an app ignores the system proxy, check how that app connects instead of immediately switching between Xray and V2Fly.

Release cadence and troubleshooting steps

Xray and V2Fly release independently, so their version numbers cannot be compared directly. Android clients usually bundle a newer core with app updates; desktop clients may also manage core files separately. To decide whether to upgrade, check whether the release notes cover the protocol you use, a transport fix, or a configuration change. Update frequency alone is not a measure of stability.

1. Record the current setup. Note the client version, core version from the startup log, node protocol, and time of the error. Keep a recoverable copy of the configuration before upgrading, and avoid changing the subscription, routing, and DNS at the same time.
2. Check whether the configuration starts. If you see an unknown field, unknown transport, or unsupported flow, first check the core version and where the configuration came from. Updating the subscription won’t necessarily resolve missing core support.
3. Then check remote reachability. For a connection timeout, check the address, port, network, and server status. A successful latency test does not replace a full protocol handshake or guarantee that websites will work.
4. Check the handshake parameters. For TLS certificate errors, check the system clock and SNI. For REALITY, verify the public key, shortId, and serverName. Don’t disable certificate verification as a substitute for troubleshooting.
5. Finally, check traffic routing. If the core connects but an app still fails, check the system proxy, TUN, per-app list, DNS, and direct-connection rules. Change one setting at a time and test again.

For a meaningful performance comparison, keep conditions consistent: use the same device, network, server, and routing policy, and repeat tests at different times. One website load or latency results from different nodes cannot tell you which core is more efficient. This guide does not rank speeds outside a defined test environment or present one core as the fix for every connection issue.

Common core selection questions