At a glance

On Android, choose a core based on your node’s requirements—not the app’s name or which one seems newer. For VLESS + REALITY or XTLS Vision, start with v2rayNG, which uses the Xray core. Choose v2flyNG when you have a configuration specifically intended for V2Fly. This guide distinguishes projects, cores, and clients, outlines the protocol combinations to check, and walks through moving a desktop setup to Android.

How Project V, V2Fly, and Xray are related

Project V is an ecosystem of network proxy tools and related components, with V2Ray as its core software. The core reads configuration, establishes inbound and outbound connections, handles protocols, and applies routing. The client provides the node list, subscription management, and settings interface. These are different layers: similar-looking client interfaces don’t mean they run the same core.

V2Fly is a community project that continues to maintain V2Ray. Xray-core grew out of a V2Ray fork and later developed independently, including its protocols, security layer, and transport implementations. The two share some history and concepts, but you shouldn’t assume that every V2Fly version can read a current Xray configuration as-is.

  • v2rayN: A desktop client. When checking a configuration, look beyond the node type and verify which core is actually running and its version. The client’s name alone doesn’t tell you whether it’s using V2Fly.
  • v2rayNG: An Android client that uses the Xray core. Suitable for nodes that require Xray-related protocol combinations.
  • v2flyNG: An Android client that uses the V2Fly core. Suitable for configurations and environments confirmed to work with V2Fly.

Protocol support: check the full combination

To assess compatibility, check at least four parts: protocol, transport, security layer, and flow control. VLESS is a protocol, WebSocket is a transport, TLS and REALITY are security-layer configurations, and xtls-rprx-vision is a flow control value. Stopping at “supports VLESS” can miss the fields that actually determine whether the connection works.

Common configuration checks for Xray and V2Fly
Configuration or feature Xray core V2Fly core
VMess + WebSocket + TLS Commonly supported combinations; still verify the path and hostname Commonly supported combinations; still verify the path and hostname
Basic VLESS configuration Supported; specific combinations depend on the core version Also supported in some cases; this doesn’t mean all Xray extensions are supported
VLESS + REALITY Use a version that supports the feature and provide the required fields Not a compatible substitute for this type of configuration
XTLS Vision flow control Check the server requirements and the flow value Don’t transfer an Xray Vision configuration as-is
Full JSON configuration Use the configuration structure for the corresponding version Use the configuration structure for the corresponding version; compatibility with Xray isn’t guaranteed

Names such as VMess, VLESS, and Trojan identify protocol types, but don’t guarantee the same transport combination. The client must also pass through the node’s WebSocket path, TLS server name, fingerprint, and other required settings. Even when both cores support a protocol, a missing field can still cause the handshake to fail.

Bottom line: Check security and flow first, then choose an Android client

If a node explicitly specifies security=reality or requires flow=xtls-rprx-vision, choose v2rayNG and confirm its bundled Xray core supports the configuration. Don’t try to make it work with v2flyNG by removing the security layer or flow control field.

Android client: v2rayNG or v2flyNG?

If you don’t have an existing configuration constraint and need to import a range of common share links, v2rayNG is a good place to start. This recommendation reflects its Xray feature coverage, not a guarantee that it will be faster on every network. If your configuration provider specifically requires V2Fly, or you already have a verified native V2Fly configuration, stick with the matching environment.

v2rayNG: Xray core

Recommended

For nodes that need Xray features such as REALITY or Vision. After importing, open the node editor and verify the security layer, server name, and flow control. Don’t rely on the node name to determine its configuration.

Best for: First-time installs, nodes that explicitly require Xray, or setups already using a similar Xray configuration on desktop

v2flyNG: V2Fly core

For configurations specifically intended for V2Fly. If a VMess + WebSocket + TLS node already works, there’s no need to migrate just because the fork has a different name. That also doesn’t mean V2Fly is always more compatible.

Best for: Existing V2Fly configurations and checking how native V2Fly configurations behave

If you install both apps to compare them, start only one VPN connection at a time. Android’s VPN service, per-app rules, and background restrictions can all affect traffic. If results differ after switching between the apps, first check which service is currently running before attributing the difference to the core.

  • Basic VMess nodes only: Either core may meet your needs. Stick with the configuration you’ve already verified works.
  • REALITY required: Choose v2rayNG with the matching feature support; don’t treat v2flyNG as a drop-in replacement for the same configuration.
  • Only have a native JSON file: Check the target core and configuration format version before choosing a client. Don’t import it based on the file extension alone.

Configuration checks: ports, fields, and import results

The core isn’t the only variable. A mismatch in the server address, port, user ID, transport path, or security layer can result in a node that imports successfully but doesn’t work. The ports below are troubleshooting examples, not defaults for every node or client. Use the values shown in the node editor and local settings.

443
Example server-side TLS port; not a guarantee that the connection will work
10808
Example local SOCKS listening port; check it separately from the remote port

The remote port 443 points to a service on the server. The local address 127.0.0.1:10808 is where the app listens on your device. Entering the local port as the node’s server port won’t send the connection to the right place. Android’s VPN mode typically routes traffic through a system virtual network interface, so you don’t need to enter this local port manually in every app.

  1. Check how the node was imported. In v2rayNG, tap “+” on the main screen and choose “Import from clipboard” to import a share link. Menu wording may vary slightly by version. Add subscription URLs to a subscription group rather than importing them as single-node share links.
  2. Check the node editor next. Make sure the address and port match the original configuration. For VMess, check the user ID; for WebSocket, check the path and Host; for TLS, check the server name.
  3. Check REALITY separately. Confirm that the public key, shortId, server name, fingerprint, and other parameters match the provider’s requirements. Field labels can vary by version; don’t rely on your TLS setup experience instead of checking them.
  4. Finally, check that traffic is being routed. After starting the connection, confirm that Android VPN permission has been granted. If only some apps have problems, check per-app proxy settings, routing, and DNS before switching cores.

Desktop and Android: a shared subscription doesn’t sync every setting

v2rayN and Android clients can use the same subscription source, but a subscription only provides node details. It won’t sync desktop system proxy settings, routing rules, or Android per-app proxy settings. If the subscription service generates different formats for different clients, choose the appropriate output. Don’t assume the same URL returns identical content in every client.

Migration plan: match node settings, configure traffic routing separately on each device

Desktop: v2rayN
  • Note the node in use and the core actually running.
  • Check the system proxy status; it’s not the same as the routing mode.
  • For REALITY, confirm that you’re using a compatible Xray configuration.
Android: v2rayNG or v2flyNG
  • Choose a core based on the node requirements, then import the subscription.
  • Check the node’s key fields, not just its display name.
  • Grant VPN permission, then check per-app proxy settings and routing separately.

Using the same subscription can reduce duplicate setup, but verify separately that both devices receive the same nodes and apply the same rules.

If a node works on desktop but not Android, compare its protocol settings first, then check the current network. Home and mobile networks may differ in DNS, connection policies, and link conditions. Test the same destination on both devices over the same Wi-Fi network. Once you’ve confirmed the configurations match, switch networks to avoid changing multiple variables at once.

  • Protocol fields match, but only domain access fails: check DNS and domain-based routing rules.
  • Only some apps can’t connect: check whether they’re excluded from VPN routing.
  • Nodes changed after a subscription update: check the subscription group URL, update results, and server output format.

Common misconceptions and how to choose

Is Xray always faster than V2Fly?

There’s no basis for that assumption. Throughput depends on server load, network path, transport combination, and device performance. For a fair comparison, keep the node, network, and destination fixed. First confirm that both clients establish a connection correctly, then compare real-world performance. Speed tests on different servers or at different times can’t be attributed to the core alone.

If V2Fly supports VLESS, why can’t it use a REALITY node directly?

VLESS is only one part of the protocol stack. REALITY and Vision involve additional features and configuration semantics that basic VLESS support doesn’t cover. If the original node requires REALITY, switching to ordinary TLS or removing the flow setting changes the connection requirements and usually won’t work with the original server.

The subscription updates, but nodes won’t connect. Is the core the problem?

Not necessarily. A successful update only means the subscription content was fetched and parsed. Connecting to a node also depends on server reachability, authentication, the security handshake, and routing. Check the logs for unsupported configuration fields, then look for authentication and handshake errors. A successful subscription update doesn’t rule out a configuration problem.

Do I need to buy a new subscription after changing clients?

The client and subscription service are separate. Whether you can keep using a subscription depends on the service terms, device limits, and output format—not the app’s name. Check with the provider to confirm supported protocol combinations and clients before migrating.

Bottom line: Choose the core for the node, and check traffic routing on each device

For a first install with a node that requires Xray features, choose v2rayNG. If you already have a working V2Fly configuration, you can keep using v2flyNG. If a connection fails, check the full protocol combination and logs. If the connection succeeds but apps still don’t work, check VPN routing, DNS, and routes. Don’t blame every issue on differences between the forks.