For desktop, start with v2rayN. On Android, choose v2rayNG or v2flyNG based on your node requirements. Project V provides the historical context: V2Fly and Xray are separate core projects, while clients handle subscriptions, the interface, and configuration. This guide untangles the names in order—from project origins to core features, client platforms, and node settings—so new users can pick the right software and existing users can decide whether to switch cores.
1. Project V, V2Ray, and V2Fly: What’s the Difference?
Project V began as a collection of modular network proxy tools, with V2Ray becoming its best-known core project. It separates inbound connections, routing decisions, and outbound connections into modules, allowing different traffic to follow different paths based on configuration. In everyday conversation, though, “V2Ray” is often used to mean the entire proxy setup. That’s why newcomers can end up mixing up clients, cores, and protocols.
V2Fly is a community project that continues V2Ray development; its core is commonly called V2Ray Core. V2Fly is neither a new node protocol nor the name of an Android interface. The core runs the configuration, while protocols such as VMess define how connections work. They belong to different layers.
- Projects and communities: Project V provides the historical context; V2Fly and Xray maintain separate core implementations.
- Core software: Reads configuration, listens on local ports, and handles DNS, routing, and outbound connections.
- Graphical clients: Manage subscriptions and nodes, translating interface settings into configurations the core can run.
- Nodes and protocols: Describe remote servers and connection parameters; they are not client brands.
So “a V2Ray node in my subscription” doesn’t tell you enough. Compatibility depends on whether the node uses VMess or VLESS, which transport it uses, whether TLS or REALITY is enabled, and what additional parameters the server requires. Sort out those details before choosing software; the product name alone won’t tell you what works.
2. V2Fly and Xray: Shared Roots, Different Paths
Xray branched from V2Ray’s codebase and later developed independently. The two share some concepts and configuration conventions, but that doesn’t mean every field, transport, or newer feature is interchangeable. A configuration that runs on one core may not work unchanged on the other.
| What to compare | V2Fly / V2Ray Core | Xray Core |
|---|---|---|
| Project relationship | Community-led continuation of the V2Ray core | Independent core project forked from V2Ray |
| Common use cases | Existing V2Fly configurations and compatibility with VMess | Setups using VLESS, REALITY, Vision, and related features |
| Configuration compatibility | Check against V2Fly configuration docs and release notes | Check against Xray configuration docs and release notes |
| What to consider when upgrading | Client support and the features required by your node | Client support and the features required by your node |
VMess and VLESS are proxy protocols; WebSocket is a transport; TLS is a secure transport mechanism; REALITY is a secure transport option in the Xray ecosystem; and Vision relates to Xray flow control. These terms can appear together, but they are not alternatives at the same layer. “VLESS + TCP + REALITY” describes settings across multiple layers, not three separate nodes.
3. How the Three Clients Relate to Their Cores
For desktop use on Windows, macOS, or Linux, start with v2rayN. On Android, choose between v2rayNG and v2flyNG. Check the client and core versions separately: an updated interface doesn’t mean the running core is up to date. And just because a core file exists in the installation folder doesn’t mean the current node is using it.
| Client | Platform | Core relationship | What to check first |
|---|---|---|---|
| v2rayN | Windows / macOS / Linux | Can manage different cores; Xray is a common choice. V2Fly availability depends on the version and configuration options. | The core required by the node, startup logs, and whether the necessary core files are present |
| v2rayNG | Android | Based on the Xray core | App version, core version, and support for the node’s parameters |
| v2flyNG | Android | Based on the V2Fly core | Whether the node’s requirements are supported by the current V2Fly core |
v2rayN generates configurations and starts the core; it’s not accurate to say “v2rayN is Xray.” Defaults, available cores, and menu layouts vary by version. To troubleshoot, first check the client details under Help → About, then review the startup log on the main screen and note the core name and version actually in use. If your build shows version details elsewhere, follow the interface you have.
- Note the client version: Record the full version of v2rayN, v2rayNG, or v2flyNG—not just “the latest version.”
- Note the core version: Get the version from the core startup log. Don’t enter the client version as the core version.
- Record the node setup: Check each item, such as VLESS, TCP, REALITY, and Vision—not just the node’s label.
- Record the startup result: “Configuration parse failed,” “local listener started,” and “remote handshake succeeded” describe different states.
On Android, VPN permission lets the app create a local virtual network interface and route traffic into the proxy. It doesn’t change the server protocol. System proxy settings and TUN on desktop also determine how traffic enters the proxy; neither replaces checking node protocol compatibility.
4. Choose a Core for Your Node, Not by Ranking Names
Start by checking your platform, then read the subscription notes or open the node editor. The recommendations below assume the node requires REALITY or Vision. If the server provides a ready-to-use V2Fly configuration, keep its configuration semantics intact rather than migrating first and troubleshooting later.
Xray core
RecommendedIf the node explicitly uses VLESS + REALITY or Vision, choose an Xray version that supports that combination. On desktop, check which core v2rayN is actually running. On Android, use v2rayNG and confirm the app exposes the required parameters.
Best for: Existing REALITY or Vision nodes that require matching core features
V2Fly core
If you already have a working V2Fly configuration, or the server is explicitly set up for V2Fly, keep using the corresponding core. On Android, you can use v2flyNG. On desktop, first check whether your v2rayN build supports it.
Best for: Maintaining existing V2Fly configurations and keeping client and server settings consistent
Bottom line: If the subscription specifies REALITY, check Xray support first
Open the node editor and check the server-required fields, including the public key, server name, short ID, and flow control. Then verify which core actually starts. Don’t try to “fix” a protocol mismatch by randomly switching to VMess or disabling security checks.
If you only have standard VMess nodes, either core may work, but check the transport and core version. You can test webpage loading and connection stability on the same device, using the same node around the same time; change only one variable per test. Speed comparisons across regions or nodes can’t tell you which core is better.
5. From Subscription Import to Traffic Routing: How the Configuration Fits Together
A subscription isn’t the same thing as a core configuration file. The client fetches the subscription, parses it into node details, then combines those details with local ports, DNS, and routing rules to generate a running configuration. A successful subscription update only means that fetching and parsing worked at least in part—not that every node can connect.
- Import a subscription: In v2rayN, go to “Subscription Group” → “Subscription Group Settings” and add the URL. Then update it from the “Subscription Group” menu. Menu wording may vary slightly by version.
- Check the node: Verify the server address, remote port, user ID, transport, and security settings. REALITY nodes also require the relevant parameters provided by the server.
- Start the core: Check the logs for configuration errors, missing files, or a port conflict before testing the remote connection.
- Route app traffic: With system proxy enabled, make sure the app follows the system proxy. With TUN, also check permissions, routing, and DNS.
- Verify routing rules: Visit destinations that should use the direct connection and ones that should use the proxy. Check the connection logs to confirm the outbound route; don’t rely on the status bar icon alone.
The ports below are examples to show how the local and remote connections relate; they aren’t universal defaults. Suppose the client listens locally on 127.0.0.1:10808 and the remote node listens on 443: the app connects to the local port, then the core connects to the remote server. These ports don’t need to match. Don’t change server settings based on this example.
If the log says the local listening address is already in use, check the process or port on your device. If it reports a remote connection timeout, check the remote address, network reachability, and server status. Changing the local port won’t fix incorrect server handshake parameters, and switching cores won’t correct a wrong server name.
6. Common Client and Migration Questions
Why can v2rayN import a node but report an unsupported field on startup?
The client handles importing; the core handles startup. Check the core name and version in the startup log, then compare the unsupported field with the selected core. If the node requires REALITY or Vision, make sure you’re running a compatible Xray core—not just an updated client interface.
I installed v2flyNG on Android. What should I do with a REALITY node?
Keep your existing working configuration, then use v2rayNG if it supports the node’s required combination. After importing the node, check the server name, public key, short ID, and flow control individually. Disconnect the original client’s VPN before testing the other one to avoid mistaking a routing conflict for a protocol issue.
Can I reuse my existing routing rules after switching cores?
Back up your configuration first. Then check whether the target core supports the rule format, rule data files, and DNS settings. Rebuilding or converting rules through the client is safer than copying the entire running configuration. After switching, test outbound routing with one clear domain rule before restoring complex rule sets.
The node shows a latency value. Does that mean I picked the right core?
Not necessarily. A TCP latency test only indicates partial reachability to the remote port; it doesn’t confirm proxy authentication or a successful secure handshake. Run the client’s actual connection test, check the handshake logs, then verify that the destination page loads in a browser.
During migration, keep a known-working node and configuration as a fallback. Change only one thing at a time: the core, node parameters, or routing. When asking for help, share the client version, core version, node protocol combination, and a redacted error excerpt. Don’t publish subscription URLs, user IDs, or private parameters.
- Everyday desktop use: Start with v2rayN, then check which core is running against your node’s requirements.
- Android with Xray nodes: Start with v2rayNG and check that both the app and core support the required features.
- Android with V2Fly configurations: Use v2flyNG to keep the client and server configuration semantics consistent.
- Learn more: See the glossary. To troubleshoot by symptom, see Troubleshooting.