Project V is the broader project, V2Ray one of its core tools, V2Fly the community maintaining it, and Xray an independent core forked from V2Ray. When choosing a client, first check the protocols, transport, and security layer required by your server, then confirm which core the client actually runs. This guide is for anyone choosing a desktop or Android client, or troubleshooting a link that imports but won’t connect.
Know the difference between projects, cores, and clients
In everyday conversation, “install V2Ray” can mean installing a graphical client or deploying the core program. These are different layers: the client manages subscriptions, server lists, system proxy settings, and the user interface; the core reads configuration, establishes connections, handles DNS queries, and applies routing rules. A subscription service provides server details—it isn’t part of the core itself.
When troubleshooting, identify exactly what you mean. If the window opens, that only confirms the client interface is running. If a subscription updates, that only confirms its URL is reachable. Check separately whether the core starts, the remote handshake succeeds, and app traffic reaches the local proxy.
| Name | Layer | Role |
|---|---|---|
| Project V | Project ecosystem | A project and design ecosystem built around network communication tools. |
| V2Ray / V2Fly | Core tool and maintenance community | The V2Fly community maintains the V2Ray core and related work. |
| Xray | Independent core fork | Forked from V2Ray, with protocols and transport capabilities developed independently. |
| v2rayN | Desktop client | Manages servers and subscriptions, and runs the relevant core based on version and configuration. |
| v2rayNG / v2flyNG | Android clients | Run on either the Xray or V2Fly core and provide proxy management on Android. |
From Project V to two core branches
Project V’s early work shaped V2Ray’s configuration system and modular design. Inbound connections, outbound connections, routing, and DNS each have distinct roles; they aren’t all bundled into a single “proxy switch.” That shared history is still reflected in the configurations of both core branches.
- Project V and V2Ray take shape: V2Ray is a core tool in Project V. The VMess protocol and composable transport and routing configuration are key to understanding the early ecosystem.
- V2Fly takes over community maintenance: The V2Fly community continues development and maintenance of the V2Ray core. “V2Fly core” usually refers to the V2Ray core maintained by this community, not a connection protocol called V2Fly.
- Xray forked in 2020: Xray forked from V2Ray and has developed independently since. Features such as VLESS, XTLS-related flow control, and REALITY depend on the specific branch and version—don’t assume support based solely on their shared origins.
This isn’t a linear upgrade path where “old software gets renamed as new software.” V2Fly and Xray have their own versions, configuration documentation, and release schedules. A field added in one branch isn’t automatically compatible with another just because both can read JSON. Even fields with the same name may have different accepted values and behavior; check the documentation for the core you’re using.
Check the full set of parameters for compatibility
VMess and VLESS are protocols; WebSocket is a transport; TLS and REALITY are security-layer configurations that need to be checked separately. They belong to different layers. “Supports VLESS” doesn’t mean a client supports every VLESS configuration, or that any two endpoint configurations are interchangeable.
- Protocol: Check
vmessorvlessfirst, then verify authentication details such as the user ID. Changing the protocol name doesn’t replace server-side setup. - Transport: Check the network type and its parameters. For example, the WebSocket path and request hostname must match the server’s inbound configuration.
- Security layer: Check TLS or REALITY and the associated parameters, such as the server name, public key, and short ID. The certificate server name doesn’t always match the address you connect to.
- Flow control and versions: Values such as
xtls-rprx-visionrequire a compatible core, transport combination, and server configuration. Don’t use them with every VLESS node.
A subscription link distributes server parameters; it doesn’t guarantee compatibility. A client may parse the address and port successfully but fail to recognize an extension parameter. After importing, check the node editor to make sure key fields were retained, then review the connection log.
How to choose: check the server setup first, then pick a core
If your server requires VLESS + REALITY, start by checking the Xray route. If you already have a VMess + WebSocket + TLS setup, verify that your current core meets the requirements parameter by parameter. There’s no need to migrate everything just to use a newer name.
How to choose among the three clients
For desktop, choose the v2rayN release that matches your operating system—Windows, macOS, or Linux—and processor architecture. Available core options, interface layouts, and platform features vary by release. Don’t assume that a menu shown in one Windows version looks or works exactly the same on other platforms.
The Android options are more distinct: v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. Similar names don’t mean they’re just different skins. The core required by your node’s features usually matters more than interface preferences.
v2rayNG: Xray-based Android client
RecommendedThis recommendation applies to Android setups whose nodes require Xray features. After importing, check REALITY, flow control, and transport parameters—don’t rely on protocol abbreviations in the node name.
Best for: Android devices connecting to nodes that specifically require Xray features.
v2rayN: Desktop configuration hub
Manage servers and subscriptions on Windows, macOS, and Linux desktops. The core that actually runs depends on the release, core settings, and node type; check the startup log to confirm.
Best for: Desktop system proxy, subscription groups, and routing management.
v2flyNG: V2Fly-based Android client
Best for environments built around V2Fly configuration and feature support. Before moving existing nodes over, confirm the current core supports their protocol combinations. Don’t apply Xray-specific parameters as-is.
Best for: Android devices using an existing V2Fly server and configuration standard.
These options aren’t ranked by speed. Throughput and latency also depend on the network route, server load, transport settings, and local network. Without comparable test conditions, a core’s name can’t tell you its performance advantage as a fixed percentage.
Using one subscription across desktop and Android
You can use the same subscription on multiple devices, provided both clients support its format and node configurations. A subscription usually won’t sync local listening ports, system proxy status, or per-app settings; those are controlled by each client.
Setup: share node details, manage local proxy settings separately
Desktop: v2rayN
- After importing the subscription, check which core the active node actually uses.
- Start the node, then verify the system proxy or in-app proxy settings.
- Note the local listening address, port, and routing mode.
Android: v2rayNG
- Import the same subscription and check the selected node’s transport and security-layer fields.
- When starting it for the first time, approve the system VPN connection request.
- If per-app proxying is enabled, check that the target app is included as expected.
Sharing a subscription avoids entering node details twice, but each client still needs its own updates. Node lists, routing rules, and proxy status won’t stay perfectly in sync automatically.
For example, a desktop app manually configured to use 127.0.0.1:10808 will work only if the client is listening on that port and the app is set to the correct SOCKS or HTTP proxy type. Here, 10808 is an example to check against, not a required default for every release. Don’t change the listening address to 0.0.0.0 just to make troubleshooting easier; this could expose the local proxy to more devices.
Think of routing in two layers: the system proxy or Android VPN determines which traffic enters the client; routing.rules determines which outbound route that traffic takes once it reaches the core. If a node connects but only one app fails, check the traffic entry point and per-app settings before switching cores.
Checks from import to connection
Keep the original client configuration before migrating, then test one node with the simplest working setup. Don’t change the subscription, routing, DNS, and core version all at once, or it’ll be hard to link a failure in the logs to a specific change.
- Record the environment: Note the operating system, client version, core name, and core version. v2rayN’s core startup log is a key way to confirm which executable is actually running.
- Check node parameters: Verify the server address, remote port, protocol, user ID, transport path, and security layer. The remote port and local proxy port are separate fields.
- Check startup results: If you see
address already in use, close duplicate instances or change the conflicting local listening port. This error occurs before the client connects to the server. - Check the traffic entry point: On desktop, verify the system proxy or app-level proxy settings. On Android, make sure the VPN is running and the target app isn’t excluded.
- Restore advanced rules: Once the basic connection works, restore custom DNS, routing rules, and subscription update settings one at a time. Check the logs after each change.
Choosing and migrating: common questions
If I installed v2rayN, does that mean I’m using V2Fly?
No. Start a node and check the core name and version in the log. The client’s name doesn’t identify the active core. To switch, use the core options available in your release and recheck node compatibility.
Why can’t I connect after importing a VLESS link?
Open the node editor and check the transport, security layer, server name, and flow control in order. If you’re using REALITY, also verify the public key and short ID. Then check the core version and logs. An “import successful” message doesn’t confirm that extension parameters were applied correctly.
Do I need to rebuild my VMess nodes if I switch to Xray?
Usually, keep the server configuration and test whether the new core supports the entire existing setup before importing. Don’t change the node protocol from VMess to VLESS on your own; changing client fields won’t complete the migration unless the server is configured accordingly.
The same subscription works on desktop but not Android. What should I check first?
First make sure both clients have the same node selected, then compare core versions and key parameters. If they match, check Android VPN permission, per-app settings, and device time. A successful desktop connection only confirms that the connection works in that desktop environment.
Choose based on verifiable requirements: the platform can run the client, the core supports the node configuration, the traffic entry point is set up correctly, and the logs show no configuration or handshake errors. Understanding the core branches helps narrow down troubleshooting; their names don’t guarantee connection quality. For field definitions, see the configuration reference. For your first connection, follow the getting started guide.