Project V is the name of the project ecosystem, with V2Ray as its core tool. V2Fly is the community that continued V2Ray development, while Xray evolved from a V2Ray fork. When choosing a client, distinguish the interface, core, and node protocol, then check the server settings. This guide is for anyone choosing a desktop or Android client, troubleshooting VLESS and REALITY compatibility, or moving an existing subscription.
1. Understand the project, core, client, and protocol
“Installing V2Ray” might mean downloading a graphical client or setting up the server core. These are not the same thing. A graphical client imports subscriptions, selects nodes, and configures the system proxy; the core parses configuration, applies routing, and establishes connections. A protocol defines how communication works—it is not a standalone app.
| Layer | Examples | Role |
|---|---|---|
| Project ecosystem | Project V | A project for networking tools, with V2Ray as its core tool. |
| Maintainer community | V2Fly | Continues development of the V2Ray core and maintains related code and documentation. |
| Connection core | V2Ray、Xray-core | Handles inbound and outbound connections, protocol handshakes, DNS, and routing rules. |
| Graphical client | v2rayN、v2rayNG、v2flyNG | Manages configuration, provides the user interface, and starts or invokes the core. |
| Proxy protocol | VMess、VLESS | Defines how clients and servers authenticate and carry proxy requests. |
So, a client with “v2ray” in its name does not necessarily run the V2Ray core. v2rayNG, for example, uses the Xray core. To check compatibility, look at the actual core and node settings—not just whether the app names look alike.
2. From Project V to V2Fly: which development line continued?
Project V began as a modular suite of network proxy tools, with V2Ray as its core component. V2Ray combines inbound and outbound connections, transports, routing, and DNS. It can run locally to handle app traffic or on a server to accept remote connections. Over time, “V2Ray” also became a catch-all term for an entire proxy setup, which is why the name is often used loosely.
After development slowed in the original project, the V2Fly community took over and continued V2Ray development. V2Fly is the name of a community, not another software layer you need to install alongside V2Ray. When users refer to the “V2Fly core,” they usually mean the V2Ray core maintained by the V2Fly community.
- When reading older guides: Check whether V2Ray refers to the core program or is being used as shorthand for the entire proxy setup. Menus shown in a guide usually belong to the client.
- To identify the running program: Distinguish
v2rayfromxray, then check the core name and version in the startup log. - When moving a configuration: Check both the configuration format and the core version. A JSON file that parses successfully does not mean the current core supports every field.
V2Ray is not the same as VMess. VMess is just one of the protocols it supports; routing, DNS, and local proxy access are also important core features. Conversely, a VMess node does not prove that the server runs V2Ray—Xray can handle VMess too.
3. Xray is a fork—not a drop-in rename for every configuration
Xray emerged as a V2Ray fork in 2020 and went on to develop as an independent core. The two share a technical foundation, but their features, configuration fields, and development pace have diverged. VLESS, XTLS Vision, and REALITY are common terms in modern Xray configurations, but they are not three protocols at the same layer.
- VLESS: A proxy protocol. VLESS does not encrypt traffic on its own, so it typically needs an appropriate secure transport configuration.
- REALITY: A transport security mechanism in the Xray ecosystem. The client must support it and have the required authentication parameters from the server configured correctly.
- Vision: A flow-control scheme related to XTLS. A node may set
flowtoxtls-rprx-vision; the value must match the server's requirements. - TLS: A widely used transport security protocol. A node using TLS does not necessarily use REALITY; the two are not interchangeable just because both provide an “encrypted connection.”
For example, a node that explicitly requires VLESS, REALITY, and xtls-rprx-vision needs a client and core that support all three. “Supports VLESS” alone is not enough to establish compatibility. Nor can you change the node's security type to TLS to work around unsupported fields.
4. How v2rayN, v2rayNG, and v2flyNG map to their cores
Choose your platform first, then a client that supports your node's requirements. The recommendations below assume your node explicitly requires Xray features; they are not a universal ranking. Core options in v2rayN vary by release and version, so check your installed package and startup log.
Xray route: v2rayN / v2rayNG
RecommendedOn desktop, check that v2rayN is actually using Xray for the selected node. On Android, use v2rayNG with the Xray core. For nodes requiring REALITY or Vision, verify core support and make sure all node parameters are present.
Best for: Users with an existing VLESS + REALITY node that requires Xray features.
V2Fly route: v2flyNG / matching desktop core setup
On Android, v2flyNG uses the V2Ray core maintained by V2Fly. To use the same core on desktop, first check whether your current v2rayN release supports it. Do not assume every version offers the same core options.
Best for: Users with an existing configuration based on V2Fly who have confirmed that its required protocols and transports are supported.
v2rayN is a desktop client; subscription groups, node lists, and the system proxy toggle in its interface belong to the client layer. v2rayNG and v2flyNG are Android clients that typically route device traffic through Android's VpnService. A VPN indicator means the local connection service is running; it does not mean the remote node has authenticated successfully.
Bottom line: Write down the node requirements, then choose the core
Start by noting “protocol + transport + security type + flow,” for example, “VLESS + TCP + REALITY + xtls-rprx-vision.” Check client support against those requirements. It is more direct than choosing by name or repeatedly reinstalling software.
5. Identify the running core and connection path in four steps
When troubleshooting, keep the client version, core version, and node parameters in separate notes. Updating a client may also change the core, or it may update only the interface; updating a subscription mainly changes node configuration. These updates are not interchangeable. The example below uses local SOCKS port 10808; check your client's settings for the actual port.
- Check the startup log first. Start a node, open the client's log or information window, and note the core name and version. If configuration parsing fails, investigate unsupported fields or core compatibility before blaming the network.
- Next, check the node editor. Verify the address, remote port, UUID, transport, and security type. A server port of
443does not necessarily mean standard TLS is in use, and it certainly does not mean you can open the server directly in a browser. - Confirm the local listener. If the settings show a SOCKS inbound at
127.0.0.1:10808, connect your test app to that address. If the port is already in use, close any duplicate client processes or choose a different local port and update the app settings accordingly. - Finally, check how traffic is routed. On desktop, make sure the system or app proxy points to the right endpoint. On Android, confirm the connection service is running and that the target app is not excluded by per-app rules. Test a basic connection before adding complex routing.
If curl is installed and your client is listening on the SOCKS port above, you can run a one-off request. --socks5-hostname sends the target hostname to the SOCKS proxy for resolution. This helps rule out differences caused by local DNS resolution, but check the logs to see how the core handles DNS and routing.
curl --socks5-hostname 127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.comThe 10-second connection timeout and 20-second total timeout are just test limits, not measures of network performance. If the local port cannot be reached, first check that the client is running. If the core log shows a remote handshake failure, verify the node credentials and security parameters. Keep local endpoint issues separate from remote authentication failures.
6. Move between devices: reuse subscriptions, not entire configurations
A subscription typically contains node details, while a full configuration may also include local ports, DNS, routing, file paths, and inbound settings. Importing a complete desktop configuration into an Android client can run into differences in fields, paths, or traffic handling. A safer approach is to import the same subscription source on each device, then configure device-specific rules separately.
Migration plan: Share node settings, configure each device separately
Desktop: v2rayN
- After importing the subscription, check which core the selected node actually uses.
- Note the local proxy port to avoid conflicts with other processes.
- Set up the system proxy if needed, then add routing rules one at a time.
Android: v2rayNG or v2flyNG
- Choose a client based on node requirements, not just its name.
- Import the same subscription and check the security type and flow after import.
- Configure per-app proxy rules and background permissions separately.
The same subscription may not look identical on both devices. Parsing support, filtering rules, and update times can all affect the results. Test the connection on each device after migration.
Check routing separately too. geosite:cn matches domain groups, while geoip:cn matches IP address ranges; neither is a protocol. Even if both cores recognize these formats, you still need the corresponding data files, correct tags, and rule order. If only some sites break after switching cores, check the matched outbound and DNS results before replacing all your nodes.
7. Quick answers to client and compatibility questions
If v2rayN is installed, do I need to open a separate Xray window?
Usually, the client starts and manages the core process for you. Connect to a node and check the logs first. If the client reports a missing core file, install the relevant component as directed by your release package. Starting a second core process may claim the same local port and prevent the client from starting.
Can I freely switch between v2rayNG and v2flyNG?
Check the node requirements first. If the node uses protocols and transports supported by both, import it into each client and test. If it depends on REALITY or a specific flow, do not assume the V2Fly route has the same implementation. Keep the original configuration, verify one node, then move the rest of your settings.
Will switching to Xray automatically make the connection faster?
You can't tell from the core name alone. Compare connection success and throughput using the same node, network, and test target. Server routes, transport settings, and routing results can all affect performance; the core name does not guarantee speed.
Why does the client still say the protocol is unsupported after a successful subscription update?
Downloading a subscription and starting the core are separate steps. Open the failed node's editor, check the protocol, security type, and flow, then look for unsupported fields in the startup log. If the client does not recognize the parameter, update to a compatible client and core; repeatedly updating the subscription will not help.
Do older VMess nodes have to be migrated to VLESS?
There is no need to migrate just because the names have changed. First check whether your existing node still meets your needs. A protocol migration requires the server to provide the corresponding configuration; changing VMess to VLESS in the client does not convert the node. Import the new node settings from your provider and test them separately.
Use this order: confirm the platform, list the node requirements, check the actual core, then verify the local endpoint and routing. For step-by-step setup help, see the client installation and connection guide. To organize DNS and routing rules, see advanced configuration. Start with a working minimal setup, then add features to make troubleshooting easier.