Xray vs. V2Fly Core: How to Choose Between v2rayNG and v2flyNG

At a Glance

When choosing an Android client, start with your server’s requirements, then check whether the client and core support the required settings. For VLESS, REALITY, or XTLS Vision, consider v2rayNG with the Xray core. If you already have a verified V2Fly configuration, v2flyNG may be a better fit. This guide distinguishes protocols, transports, security layers, and subscription formats, then walks through import checks and controlled testing—so you don’t mistake a client’s name for a performance guarantee.

Project V, V2Fly, and Xray: Projects vs. Clients

V2Ray is a network proxy tool in the Project V ecosystem. Its core handles inbound connections, routing, DNS, and outbound connections. V2Fly is a community project that continues V2Ray’s development, while Xray became an independent project in 2020, based on code related to V2Ray. They share a common origin, but their features, configuration fields, and release schedules have evolved separately. Similar names don’t guarantee full compatibility.

On Android, v2rayNG and v2flyNG are clients, not protocols. They provide interfaces for managing subscriptions, editing nodes, viewing logs, and connecting through Android’s VPN service; the integrated core handles proxy connections. This guide discusses v2rayNG as using the Xray core and v2flyNG as using the V2Fly core. Actual features also depend on the core version bundled with the app and the options exposed by its interface.

Project layer: Project V, V2Fly, and Xray refer to projects or technology ecosystems, not subscription URLs.
Core layer: Determines which protocols, security mechanisms, transports, and routing fields can be used.
Client layer: Determines how share links are parsed, nodes are edited, and traffic is routed through the client.
Server layer: Determines which protocol combinations actually work. Switching clients doesn’t change the server configuration.

Desktop v2rayN is also a client. A node that works on desktop can serve as a reference for Android, but desktop-only settings—such as local listening ports, system proxy options, and routing file paths—can’t simply be copied over. Check the server address, protocol parameters, and transport settings, rather than relying on the node’s display name.

Protocol and Transport Differences: A Node’s Name Doesn’t Guarantee Compatibility

A node has at least three components: protocol, transport, and security layer. For example, VMess is a proxy protocol, WebSocket is a transport, and TLS is a security layer. VLESS and REALITY aren’t interchangeable terms either: VLESS is a proxy protocol, while REALITY is an Xray security mechanism. Seeing a share link that starts with vless:// isn’t enough to choose a client.

Node or configuration requirement	Xray approach	V2Fly approach	What to check
VMess + WebSocket + TLS	Supports common combinations	Supports common combinations	Check the path, Host, TLS server name, and credentials
VLESS + REALITY	Choose an Xray version that supports the required feature	Don’t assume the same protocol name means this combination is supported	Check the public key, shortId, server name, and server requirements
XTLS Vision flow control	Part of the Xray feature set	Not a drop-in alternative implementation	The client and server flow parameters must match
V2Fly-specific transport or configuration fields	Can’t be assumed to work out of the box	Verify against the relevant core version	Also check support in the client’s editor and importer
Routing by domain, IP, and inbound conditions	Supports routing	Supports routing	Don’t assume rule formats, match order, or rule resources are interchangeable

VLESS isn’t exclusive to Xray just because of its name. What matters is how it’s combined with a transport, security layer, and flow control. For REALITY nodes, use an Xray client that supports the required combination. Changing REALITY to standard TLS or removing flow to force the configuration to save won’t make the original server accept a different handshake.

Bottom Line: Choose Based on the Full Parameter Set

Check the protocol, transport, security, and flow in the node details first. If you see REALITY or xtls-rprx-vision, choose a v2rayNG build that supports these fields. Don’t delete parameters to make the configuration fit a different core.

v2rayNG vs. v2flyNG: Choose Based on Your Existing Nodes

If your subscription provider explicitly requires Xray, REALITY, or Vision, the choice is usually clear. For standard VMess nodes, either client may work. Compare import accuracy, connection stability, and ease of use instead of assuming one core is always faster.

v2rayNG: The Xray Feature Set

Recommended

For the use cases covered here—especially REALITY and Vision nodes—start with v2rayNG. After importing, check the key fields: a node appearing in the client doesn’t mean every parameter was preserved correctly.

Best for: Android users whose server requires Xray features, including VLESS + REALITY.

v2flyNG: The V2Fly Configuration Path

A good fit when you already have a verified V2Fly configuration and a tested node combination. Check the core version bundled with the client and where the configuration is entered. In particular, confirm that share links can fully represent the transport you need.

Best for: Existing V2Fly server configurations, verified VMess nodes, and established operations workflows.

If v2flyNG is already working reliably and your nodes don’t require Xray-specific features, there’s no need to switch just because you’ve heard “newer core.” Likewise, if you already use v2rayNG for standard VMess nodes, there’s no reason to install another client. A configuration you can reproduce and troubleshoot is usually more useful than maintaining two sets of inconsistent routing rules.

Subscriptions and Share Links: Check the Fields After Importing

A subscription is a source of content for the client’s management layer, not a top-level core configuration key. A subscription URL typically returns several share links or configuration data the client can recognize. Base64 is just a common encoding; it doesn’t encrypt the data or guarantee that both clients will parse it the same way. A single subscription can contain nodes using different protocols, so check each one individually.

Check the address type. Add subscription URLs that start with https:// through the subscription manager. Import individual share links that start with vmess:// or vless:// through the share-link or clipboard import option. A webpage for purchasing a subscription isn’t a subscription URL.
Open the node details after updating. In v2rayNG, you can usually open “Subscription group settings” from the main screen menu, add the URL, then update the subscription. Menu wording can vary by version. Confirm the imported fields in the node details; seeing a name in the list isn’t enough.
Check the identity and endpoint. Compare the server address, port, and UUID or password. Then check the transport, WebSocket path, Host, and TLS server name. Copying only the address can leave out essential handshake parameters.
Check Xray-specific fields. For REALITY nodes, verify the public key, shortId, server name, and server-required fingerprint. For Vision nodes, also check flow. If a field is blank or doesn’t match, get a valid configuration again rather than guessing.
Check the logs before connecting. If you see an unknown protocol, unknown transport, or configuration parsing error, first check core capabilities and importer support. If the configuration loads but the handshake fails, check the fields, device time, and server status.

Some settings in full configurations—such as routing, DNS, and outbound tags—can’t necessarily be represented in a single share link. Two clients may show a node with the same name and share the same server connection parameters, yet use different routing policies. Using the same subscription reduces duplicate entry, but doesn’t prove the final configurations are identical.

Testing the Connection: Server Ports, Local Proxies, and Android VPN

Keep port types separate. A server port connects to the remote server; a local SOCKS or HTTP port lets apps on the device connect to the client; and Android’s VPN permission determines whether the client can route app traffic. The three numbers below are illustrative examples, not defaults for every version of either client or results from performance testing.

443

Example remote TLS server port

10808

Example local SOCKS listening port

10809

Example local HTTP listening port

For example, if a node connects to server port 443 and the local SOCKS listener uses port 10808, don’t change the node’s port to 10808. Apps can use 127.0.0.1:10808 only when a local listener is enabled and its type matches. Android apps usually route through the client’s VPN mode, so you don’t need to enter a proxy port in each app.

Step 1: Check system permission. After starting the connection, confirm that Android’s VPN permission has been granted. Before testing the other client, stop the first one to avoid mistaking a replaced VPN session for a failed node.
Step 2: Check which apps are covered. If per-app proxying is enabled, confirm that your browser is included. Check whether the list means “include” or “exclude”—they have opposite effects.
Step 3: Check routing and DNS. Confirm that the rules send your destination through the proxy outbound and that the domain resolves. If the IP is reachable but the domain isn’t, check the DNS path first instead of immediately switching cores.
Step 4: Verify access. Open a known-working HTTPS page and check the logs to confirm the result. A latency test returning a value only shows that one probe succeeded; it doesn’t prove all app traffic is going through the proxy.

Both core paths support traffic routing, but whether rules match also depends on domain visibility, DNS settings, and rule order. Copying a configuration with different outbound tags may send traffic somewhere other than the intended proxy. For an overview of configuration layers, see Advanced Configuration and check which settings belong in the client interface versus the core configuration.

Compare Under the Same Conditions: Don’t Mistake Network Fluctuations for a Core Advantage

A connection that seems faster after switching cores may be due to a different node, routing setup, or test time—or simply connection reuse or caching. A fair comparison requires the same server to support the same protocol combination in both clients. Don’t change a REALITY node to another protocol just to compare results, then attribute the outcome to the core.

Record both client versions and their bundled core versions, along with the server’s protocol, transport, and security layer. Write down the exact version numbers instead of saying “latest.”
Use the same Wi-Fi or mobile network throughout the test. Keep the device’s battery level and temperature similar, and stop large background downloads.
Keep the node, DNS, per-app scope, and routing rules the same. Test the same HTTPS page in alternating runs, completing at least five tests per client. Don’t keep only the fastest result.
Record successful connections, page availability, latency test type, and sustained transfer performance separately. If short connections work but longer transfers fail, use the logs to investigate; a single latency figure can’t summarize the result.
Save the steps needed to reproduce a failure. If only one client fails to parse the configuration, check its importer first. If both fail during the handshake, check the server and shared network conditions first.

Bottom Line: Identify the Layer That Differs Before Switching

If the same node imports differently, correct the fields or use a compatible import method. If the configurations match and the error is reproducible, investigate the client and core versions. Without records from controlled tests, don’t use a one-off speed change to choose a client.

Desktop and Android Together: Share the Source, Test Each Platform

You can use the same subscription source with v2rayN on desktop and v2rayNG or v2flyNG on Android, subject to your provider’s device and connection limits. Updating the subscription syncs its contents; you still need to check the selected node, routing rules, DNS, and per-app list separately on each device.

Setup: Use One Node Source, Respect Each Platform’s Limits

Desktop: v2rayN

Confirm that the core in use supports the required node features.
Set up the system proxy or TUN to suit your desktop apps.
Check local listening ports and outbound routing.
After updating the subscription, confirm that the selected node still works.

Android: v2rayNG or v2flyNG

Choose a client based on the full protocol combination first.
Set up Android VPN permission and per-app options separately.
Check reconnection and DNS behavior after switching networks.
After updating, check key fields—not just the node count.

Using one subscription reduces duplicate entry, but doesn’t replace connection testing on each platform. Change one setting at a time to keep troubleshooting steps traceable.

The choice comes down to two cases: if you need an Xray-specific feature, choose a v2rayNG build that supports the required parameters; if you already have a verified V2Fly configuration, choose v2flyNG. For common protocol combinations supported by both, prioritize accurate imports, reliable traffic routing, and reproducible tests. For platform and interface differences, see Client Comparison; for terminology, see Quick Glossary.