Project V is the broader project ecosystem, with V2Ray as its core tool. V2Fly continues V2Ray development, while Xray has evolved as an independent fork. v2rayN, v2rayNG, and v2flyNG are user-facing clients—not three different proxy protocols. This guide is for users familiar with nodes and subscriptions who want to sort out the names: understand the history and roles, choose a core based on server settings, then set up imports, routing, and updates on desktop and Android.
From Project V to V2Fly: Project Names and Maintainers
Project V set out to provide a modular suite of proxy tools, rather than limit every connection to one protocol or transport. V2Ray is the best-known core tool in this ecosystem, handling inbound connections, outbound connections, routing, and related protocol processing. Early documentation often mentioned Project V and V2Ray together, so the names are sometimes used interchangeably in casual discussion. They do not refer to two separate clients that must both be installed.
A few milestones help make sense of how the ecosystem evolved. The dates indicate stages in the project's history; they do not mean that old releases from those years are suitable for deployment today. Check the documentation for your current version to confirm feature support.
- Around 2015: The V2Ray project takes shape. Development centers on configurable inbound and outbound connections and routing, with VMess becoming one of its signature protocols. The distinction between the command-line core and graphical clients also becomes clearer.
- Around 2019: The V2Fly community takes over maintenance. After the original project's maintenance changed, the community continued work on V2Ray code, documentation, and releases. “V2Fly” primarily identifies the maintenance community and its project ecosystem; the core is still commonly called V2Ray.
- Late 2020: The Xray fork appears.Xray branches from the V2Ray codebase and goes on to be maintained independently. Their shared origins explain why some configuration structures look similar, but do not mean their features have stayed in sync.
- 2023: REALITY becomes part of Xray.It is a connection security mechanism, not a standalone proxy protocol at the same level as VMess or VLESS. Check the combination of protocol, transport, and security settings when configuring it.
So “V2Fly took over maintenance” does not mean everyone must switch clients to v2flyNG, nor that existing nodes need a new protocol. The maintainer, core software, and graphical interface are three separate concerns. When reading an older guide, first work out whether “V2Ray” means the core, the broader protocol ecosystem, or the client being used. That distinction can save a round of unnecessary troubleshooting.
The Xray Fork: Shared Origins Don’t Guarantee Lasting Compatibility
Xray and V2Fly are related through their code history, not a parent-child relationship. Since the fork, each project has been free to change features, configuration fields, transport implementations, and defaults independently. Both can serve as proxy cores, but “both came from V2Ray” is not enough reason to swap executables and assume an existing configuration will work unchanged.
| Aspect | V2Ray maintained by V2Fly | Xray |
|---|---|---|
| Project relationship | Continues community maintenance and releases for V2Ray | Independent project forked from a shared codebase |
| Configuration checks | Check the version in use and its configuration format | Check the version, fields, and feature combination in use |
| Shared capabilities such as VMess | Transport and security parameters still need to be checked | Transport and security parameters still need to be checked |
| When REALITY is required | Don’t assume compatibility based on similar names | Check whether the client exposes the relevant settings and the core supports them |
| Graphical client relationship | The client determines how the core is invoked and its configuration generated | The client determines how the core is invoked and its configuration generated |
For example, if the server provides a VLESS + REALITY configuration, the client must support VLESS and preserve and pass through the server name, public key, short ID, and other parameters. Field names and import mappings can vary across versions, so check the documentation for the version you use. Seeing a node name after import does not prove that all connection parameters were retained.
Bottom Line: Choose a Core from the Connection Settings, Then Pick a Client
Start by listing the server's required protocol, transport, security settings, and flow-control parameters, then check the client and core versions. If your existing configuration works, switch only when you need a specific new feature or fix, and keep a recoverable copy of the original configuration.
How Cores, Protocols, Transports, and Clients Fit Together
A node can connect only when settings across several layers match. VMess and VLESS define proxy protocols; TCP and WebSocket are ways to carry data; TLS and REALITY are security options. This classification is a guide to how the features fit together, not a promise that any protocol, transport, and security option can be freely combined.
- Client interface: Manages subscription groups, QR code or clipboard imports, node selection, logs, and options such as the system proxy or Android VPN connection.
- Proxy core: Reads the configuration generated by the client, starts listening ports, and handles protocol handshakes, DNS, routing, and outbound connections.
- Node settings: Specify the server address, port, user ID, and protocol fields. Matching addresses do not mean the configurations are identical.
- Local traffic routing: Determines how app traffic reaches the core. System proxy settings, manually configured proxy ports, and virtual network connections cover different kinds of traffic.
Here are example local port numbers to illustrate how the components fit together. They are not shared defaults for all three clients. Check the current client's listening settings and make sure the ports are not already in use.
If your browser is set to use 127.0.0.1:10809, it connects to the local HTTP proxy—not directly to the remote server on port 443. The core then makes an outbound connection based on the node and routing settings. Entering the local listening port as the server port, or changing a node without routing app traffic through the proxy, can leave you with a configuration that looks right but cannot connect.
Choosing Among the Three Clients: Platform and Server Requirements
v2rayN is mainly used on desktop and provides settings for nodes, subscriptions, routing, and proxy cores. Supported platforms, interface options, and available cores depend on the release package. v2rayNG is for Android and uses the Xray core; v2flyNG is also for Android and uses the V2Ray core maintained by V2Fly. Similar-looking client names do not mean their versions are interchangeable, and a client version number does not tell you the core version.
v2rayN: Desktop Configuration Management
RecommendedFor this guide's focus on organizing desktop nodes and routing, v2rayN is the recommended desktop starting point. Choose the installer for your operating system and architecture, then check which core the current configuration actually uses—not just the node type shown in the main window.
Best for: Managing desktop subscriptions, checking logs, and verifying core settings against node requirements.
v2rayNG: Android with Xray
A good fit for Android configurations that require Xray features. After importing, check the transport, security, and flow-control fields one by one. Also verify Android VPN permission and which apps are routed through it.
Best for: Using Android nodes confirmed to work with Xray, including configurations that require REALITY.
v2flyNG: Android with V2Fly
A good fit for Android users with an existing V2Fly setup. Choose based on whether the server settings, core features, and import format match—not on the assumption that a client is compatible with every node just because its name resembles V2Ray.
Best for: Continuing to use a V2Fly connection setup that has already been tested on Android.
The recommendation applies only to the desktop management scenario covered here; it is not a general ranking of the three clients. Platforms have different connection mechanisms and interfaces. Even if a subscription shows a node with the same name on every device, check the configuration generated on each one. Find downloads and platform details on the client page, and compare terminology in the protocol reference.
One Subscription on Desktop and Android: Nodes Sync, Settings Don’t
A subscription URL provides a set of node configurations. It is not a proxy core or a universal routing standard, and it does not automatically sync DNS, system proxy settings, app exclusions, or update schedules across devices. A single share link usually describes one connection; after importing it, changes made on the server may not automatically sync to the local copy.
Setup: Use the Same Subscription, Then Verify Each Device
Desktop: v2rayN
- Add the URL under “Subscription Group” → “Subscription Group Settings”; menu labels vary by version.
- After updating the subscription, select a node and check its protocol, transport, and security fields.
- Check the listening port and system proxy status, then use an app to confirm its traffic reaches the core.
Android: v2rayNG or v2flyNG
- Add the same URL under “Subscription Settings,” then select “Update Subscription.” The menu may differ by version.
- Check the imported configuration against the chosen core's supported features. Matching node counts do not prove compatibility.
- Start the connection, grant Android VPN permission, and check per-app settings and actual access.
A subscription can provide the same set of nodes, but local routing, DNS, and app coverage still need to be configured and verified separately.
When migrating, keep node data separate from local policies. Updating a subscription may recreate node entries. Before editing a subscribed node, check how the client saves changes; save it as a manual configuration if needed. Subscription URLs may contain access tokens, so hide the full URL and user IDs in screenshots, logs, and support requests.
- Record your baseline: Note the client and core versions, node type, and currently working network. Save the original configuration.
- Change one thing at a time: First test the node connection, then adjust DNS, and finally change routing rules such as geosite and geoip. Don’t change every layer at once.
- Check rule data: Confirm that referenced categories exist and review rule order. Files with the same name may contain different data or have different update dates.
- Test real-world access: Check destinations that should bypass the proxy and those that should use it. Use logs to identify the selected outbound route; a successful latency test does not mean every app will work.
Common Questions and Troubleshooting for the V2Ray Ecosystem
Compatibility issues often show up only after an import, update, or device switch. Troubleshoot in this order: client setup → core startup → node handshake → DNS and routing → app traffic. This is more effective than repeatedly switching clients.
Does installing v2rayN mean the V2Fly core is installed too?
You can’t tell from the name alone. Check the release package documentation, then confirm the program and version in use from the client's core settings and startup logs. Seeing VMess or VLESS in the node editor identifies the configured protocol, not the core running in the background.
Why does the same subscription work on desktop but not after importing it on Android?
Select the same node and compare the server port, transport, security settings, and flow-control fields, then check the Android core logs. If the settings match and the handshake succeeds, check Android VPN permission and per-app settings. Don’t delete and recreate the entire subscription first, or you may lose a useful troubleshooting baseline.
Do I need to reconfigure routing after switching to Xray?
Review the rules; don’t assume they all need rewriting. Check whether the fields are supported, geosite and geoip data load, rule order is preserved, and the tags for direct, proxy, and blocked routes still point to the right outbounds. Test the route with one clearly defined rule before restoring the full rule set.
Do all VLESS nodes require REALITY?
No. VLESS is a proxy protocol; REALITY is a security mechanism used in certain configurations. Follow the combination specified by the server. Don’t switch to REALITY if the server requires TLS, and don’t guess the server name, public key, or short ID just because you see VLESS.
Choosing tools in the Project V ecosystem comes down to a practical sequence: check the server connection settings, confirm core capabilities, choose a client for your platform, then verify subscriptions, routing, and app traffic. The history explains the names; your current versions and actual configuration determine whether a connection works. For help getting started with imports, read the Getting Started guide.