Project V is a project ecosystem, V2Ray is its core software, V2Fly is the community that continued V2Ray development, and Xray is an independent branch that grew from related code. v2rayN, v2rayNG, and v2flyNG are graphical clients for managing connections. This guide is for anyone choosing a client, checking subscription compatibility, or considering a core switch. It explains where each name fits and how to choose based on your existing configuration.
Start with four layers: project, core, client, and protocol
A search for “V2Ray download” can turn up project pages, command-line tools, and graphical clients. These names are related, but they are not interchangeable. Before following a guide, identify which layer it covers rather than relying on similar names.
| Layer | Common names | Role |
|---|---|---|
| Project and community | Project V、V2Fly | Organize projects and maintain code, documentation, and related tools. |
| Proxy core | V2Ray、Xray | Listen for local connections and handle routing, DNS, and protocol connections. |
| Graphical client | v2rayN、v2rayNG、v2flyNG | Manage subscriptions, edit settings, launch the core, and display logs. |
| Connection protocol | VMess、VLESS | Define authentication and data exchange between the client and server. |
On desktop, for example, you select a server in v2rayN and enable the system proxy. An app connects to the local proxy, and the core routes traffic to the appropriate outbound. The interface creates and manages the configuration; the core establishes the protocol connection to the remote server. Changing the interface does not change the protocol, and updating a subscription does not update the core.
From Project V to V2Fly and Xray: understanding the branches
Project V’s development dates back to around 2015, with V2Ray as one of its key implementations. Its design was not limited to a single protocol; it combined features such as inbounds, outbounds, transport, and routing. V2Ray is therefore neither another name for VMess nor simply a subscription manager.
Around 2020, the original project’s maintenance pace changed, and the V2Fly community took over and continued development of the V2Ray core and related ecosystem. Xray later emerged as an independent branch in the same technical lineage, continuing to evolve connection technologies including XTLS. “Branch” describes the code and its history; it does not mean that every later feature is released in both projects at the same time.
Project V ecosystem
└─ V2Ray core and related tools
├─ V2Fly community continues V2Ray development
│ └─ v2flyNG: Android graphical client with the V2Fly core
└─ Xray: independent branch developed from related code
└─ v2rayNG: Android graphical client with the Xray core
v2rayN: desktop graphical client
└─ Can manage different cores; available options depend on the release package and configurationThis diagram shows the main origins and common pairings, not a hierarchy. v2rayN is not another name for V2Fly or Xray, and the two Android clients are not the same app with different icons. Each is adapted to the configuration features, subscription parsing, and system network interfaces of its integrated core.
- V2Fly is not a new protocol: Think of it as the community and the V2Ray implementation it maintains.
- Xray is not a general-purpose newer version of V2Ray: It is an independently developed branch, so check its upgrade path and configuration details separately.
- Shared origins do not guarantee full configuration compatibility: The same JSON fields may differ in support, defaults, or behavior. Test before migrating.
Which core does each client use?
Start by grouping clients by operating system, then narrow down your options based on subscription requirements. The desktop client v2rayN supports Windows, macOS, and Linux; available packages and features depend on the release. On Android, the main choices are v2rayNG and v2flyNG. The recommendations below apply specifically when the server requires Xray features; they are not a performance ranking for all connection setups.
v2rayNG: Android with the Xray core
RecommendedIncludes the Xray core. If your configuration uses VLESS, REALITY, or XTLS Vision, first check that the current release supports all the parameters required by the server, then import it.
Best for: Android users whose subscription specifically requires Xray-related features.
v2flyNG: Android with the V2Fly core
Includes the V2Fly core and suits connection configurations already tested in a V2Fly environment. Choose based on protocol, transport, and parameter compatibility—not on which client name looks more like V2Ray.
Best for: Android users whose existing service and configuration are designed for V2Fly.
v2rayN: desktop client with selectable cores
Manages desktop subscriptions, routing, and core processes. Before using a configuration intended for Xray or V2Fly, check which cores the release package includes, which core the configuration selects, and what the startup logs show.
Best for: Windows, macOS, and Linux users who manage connections on a desktop.
Choose in this order: operating system → server requirements → active core
First, find a client that runs on your device. Then check the protocol combination required by your subscription, and finally confirm the core in the startup logs. A client name containing “v2ray” does not prove that it runs the V2Fly core.
Updating a graphical client and updating its core are also separate tasks. A newer interface may improve subscription parsing, but the loaded core still handles connections. When troubleshooting, note the client name, active core, and core version shown in the logs—not just the window title.
VMess, VLESS, REALITY: a protocol name is not a complete configuration
VMess and VLESS are proxy protocols; WebSocket is a transport; TLS and REALITY relate to connection security; and XTLS Vision is associated with a specific flow-control configuration. These fields belong to different layers and cannot be swapped at random when an import fails. In particular, changing a VMess configuration to VLESS will not make the server adapt automatically.
| Configuration combination | Parameters to check | What to consider |
|---|---|---|
| VMess with WebSocket and TLS | Address, port, user ID, path, Host, server name | Common cores support these features, but every field must still match the server. |
| VLESS with TLS | User ID, transport, server name, flow-control requirements | Do not rely on the VLESS label alone; check whether the implementation supports the specific combination. |
| VLESS with REALITY and Vision | Server name, public key, short ID, fingerprint, flow | Usually treated as an Xray-related configuration; check support on both ends. |
For example, a remote port of 443 only tells you which port the connection targets. It does not prove the connection uses standard HTTPS, and it is no reason to omit TLS or REALITY parameters. A VMess user ID can be correct while an incorrect WebSocket path still causes the handshake to fail. Likewise, a reachable VLESS address will not help if the public key or server name is wrong; changing the routing mode will not fix it.
- Check the service details first: Confirm the required client, core features, and complete set of parameters—not just the start of a share link.
- Then check the imported configuration: Open the node editor and make sure the transport, security, and flow-control fields are present.
- Finally, check the logs: Distinguish a configuration parse error from a handshake failure or connection timeout; not every failure means the core is incompatible.
REALITY does not turn on automatically when you install Xray. The server must use a matching configuration, and the client needs the corresponding parameters. Similarly, a VMess entry in a subscription does not require one specific core; choose based on actual support and connection results.
Using the same subscription on desktop and Android: keeping settings consistent
One subscription link can be used on multiple devices, but the same URL does not guarantee that every field and entry will be identical after import. Client parsing, filter settings, update times, and core support can all affect the result. Test one configuration before updating the rest in bulk.
Approach: use the same subscription source, then check each device’s local connection
Desktop: v2rayN
- After importing the subscription, check the protocol, transport, and security parameters for one representative configuration.
- Start a connection and use the logs to confirm which core is actually running.
- If you use the system proxy, check that your apps follow the system proxy settings.
Android: v2rayNG or v2flyNG
- Choose a client with a core that meets the server’s requirements.
- Grant the system VPN permission when you start a connection for the first time.
- Check per-app settings to make sure the target app is included.
A shared subscription provides the same remote configuration source; local ports, system proxy settings, VPN permission, and per-app scope still need to be configured on each device.
The desktop system proxy and Android VPN routing use different connection mechanisms. The former usually relies on apps reading the proxy settings; the latter handles traffic through a system-authorized virtual network interface. Even with the same remote configuration selected on both devices, the apps routed through the core, where DNS is resolved, and how private addresses connect directly may differ.
- Record the address, remote port, protocol, transport, and security type for the same configuration on both devices. Do not share user IDs, subscription URLs, or keys.
- Update the subscription on each device, check the update time, and look for entries hidden by filters.
- Test the same destination site on both devices. First confirm that traffic is being routed through the local interface, then check the core’s outbound and DNS logs.
- Adjust routing only after the connection works. Avoid changing the core, DNS, and rules at the same time, or it will be hard to identify what caused a change.
Ecosystem questions: where to check
Why does the log show Xray when I installed v2rayN?
This is normal: the client and core have different roles. Check the core name at the start of the startup log, then check which core the current configuration selects. To review specific parameters, open “Settings” → “Parameter Settings” in v2rayN. Section names may vary between releases, so use the current interface as a guide.
Can I copy the entire data directory from v2rayNG to v2flyNG?
Import the subscription or share link again in the target client instead of overwriting its internal data directory. After importing, open a configuration and check its key fields, then grant VPN permission again and review per-app settings. Importing a subscription transfers the configuration source; it does not transfer system permissions.
Why does the subscription import successfully but fail to start?
A successful import only means the client could parse the subscription format. Check the runtime logs. If they report an unknown field or invalid configuration, verify the active core and protocol combination. If they report that an address is already in use, check the local listening port. For example, if another process is listening on 10808, stop the conflicting process or change the local port, and update any apps that use it.
Will switching to Xray definitely make the connection faster?
The core name alone cannot tell you. Keep the remote server, network, and destination the same, change one setting at a time, and record whether the connection succeeds and what errors appear in the logs. Server load, packet loss, transport, and routing can all have a greater effect on performance. Fix incompatible settings before comparing speed.
Keep a recovery option before switching cores
Understanding the project lineage helps avoid blind trial and error. If your connection already works, there is no need to replace the core just because a name has changed. If the server requires a new feature, updating the interface alone is not enough. Keep the original configuration, add a test configuration, and switch your everyday setup only after it passes testing.
- Back up: Export the client configuration and note subscription groups, routing mode, DNS settings, and local listening ports.
- Test: Start with one configuration and one destination, then check that private network addresses that should connect directly still behave as expected.
- Save the logs: Keep the core startup information and the first relevant error. Before sharing logs, hide subscription tokens, user IDs, and keys.
- Plan how to recover: If the new configuration will not start or essential apps stop working, restore the original configuration first, then check incompatible fields one at a time.
In short, Project V describes the technical origins, V2Fly and Xray describe the core development paths, and the three clients show where connections are managed. For practical choices, ask three questions: What can I install on this device? What does the server require? Which core is actually loaded? To configure local connections and routing, continue with the Getting Started guide or advanced configuration guide.