Project V is an ecosystem; V2Fly and Xray are separate core development tracks, while v2rayN, v2rayNG, and v2flyNG are GUI clients that manage settings and run a core. Choose based on the protocols, transports, and security features your nodes require, then check which core the client actually runs. This guide is for users setting up subscriptions across devices, migrating older configs, or sorting out the names V2Ray and Xray.
1. Project V, V2Ray, and V2Fly: What Each Name Means
Project V began with V2Ray and aimed to build proxy communication from modular components: inbounds accept connections, routing rules determine where they go, and outbounds connect to remote servers. VMess is one protocol in this ecosystem, not another name for the entire project. Assuming that “installing V2Ray” means “using VMess only” overlooks the other protocol options that have since emerged.
After the original project’s maintenance changed hands, the V2Fly community took over maintaining V2Ray Core and its documentation. Today, V2Fly usually refers to the community and its development track, while V2Ray Core refers to the proxy engine that runs. They are not two GUI apps that need to be installed in sequence, and V2Fly is not a subscription provider.
- Project V: The Ecosystem and Its History
- Use this name when discussing the project’s origins, modular design, and surrounding tools. It is not a standalone proxy protocol.
- V2Ray Core: The Engine That Runs Your Config
- Handles inbounds, outbounds, DNS, and routing. The core maintained by the V2Fly community continues to use this name.
- Xray Core: An Independently Developed Fork
- Based on V2Ray, Xray later established its own release cadence and feature direction. The config structures share a foundation, but that does not guarantee every field is compatible.
- GUI Clients: Configure and Run the Core
- Manage nodes, subscriptions, routing, system proxy settings, and logs, then translate user choices into core configuration. Seeing an option in the interface does not guarantee that the active core supports it.
When troubleshooting, identify all three layers: the client, the core it runs, and the protocol combination in use. “V2Ray won’t connect” is not enough to tell whether to check subscription import, config generation, or the remote handshake.
2. V2Fly and Xray: Shared Roots Don’t Guarantee Compatibility
Xray forked from the V2Ray codebase in late 2020 and has developed independently since. Both tracks offer core proxy, routing, and DNS capabilities and support many common connection methods. The difference isn’t simply “new versus old”; it comes down to which protocols, transports, config formats, and security features a specific version supports.
| What to compare | V2Fly | Xray |
|---|---|---|
| Common capabilities | Supports VMess, SOCKS, HTTP, and more; exact combinations depend on the version | Also supports common proxy capabilities, with independently developed protocols and transport implementations |
| How to assess VLESS support | Don’t infer compatibility from the name alone; check the specific version and full config | Commonly used with VLESS nodes; check the flow, transport, and security layer as well |
| REALITY and Vision | Don’t use Xray-specific settings with V2Fly without verifying compatibility | Commonly implemented as VLESS + REALITY and XTLS Vision; requires a compatible version |
| Config migration | Check legacy configs and the format supported by the target version | Check core-specific fields, deprecated options, and transport names; replacing the executable alone isn’t enough |
Take VLESS + REALITY as an example: VLESS is a proxy protocol, while REALITY is a security mechanism for the connection. The config may also specify TCP transport and the xtls-rprx-vision flow. These terms are not interchangeable. Switching only the protocol to VLESS while leaving out the server name, public key parameters, or flow won’t reproduce the original node’s connection.
Bottom line: Specify the full connection requirements
Write down “protocol + transport + security mechanism + flow” first, then choose a core that supports the combination. For nodes that explicitly require REALITY, check the Xray version first. If you already have a VMess + WebSocket + TLS config, verify compatibility before migrating just to use a newer name.
3. Three GUI Clients: Choose Separately for Desktop and Android
v2rayN, v2rayNG, and v2flyNG are separate projects, not the same app with different platform suffixes. Similar names don’t tell you what each client supports. In particular, v2rayN’s interface, available cores, and bundled files can change between releases. Check the current client documentation and startup logs.
v2rayN: Desktop Configuration Manager
RecommendedDesigned for desktop use, v2rayN helps manage subscriptions, nodes, routing, and system proxy settings. Supported platforms and core options vary by release; a screenshot of one version’s menus is not a feature list for every version.
Best for: A primary desktop where you need centralized config management and access to core logs
v2rayNG: The Android Xray Track
On Android, v2rayNG routes device traffic through the system VPN interface and commonly uses the Xray core. Support for newer parameters also depends on the bundled core version and the client’s ability to parse share links.
Best for: Android devices with nodes that use Xray features such as VLESS and REALITY
v2flyNG: The Android V2Fly Track
Uses the V2Fly core and suits setups with specific V2Ray Core requirements. Importing the same subscription does not mean it can recognize and apply Xray-specific parameters.
Best for: Android devices with configs verified to work with the V2Fly core
These recommendations focus on desktop config management, not cross-platform performance. Windows, macOS, and Linux users should check that the v2rayN package matches their operating system and CPU architecture. Android users should choose between the v2rayNG and v2flyNG core tracks based on their nodes’ requirements. For more on how the three clients compare, see the client comparison.
- Updating the client: May change subscription parsing, interface options, config generation, and the bundled core version.
- Updating the core: Primarily changes connection implementations and config support; the existing interface may not recognize new fields automatically.
- Updating the subscription: Refreshes node details but does not upgrade the core or guarantee that local routing rules are in sync.
4. Subscriptions and JSON: Importing Isn’t the Same as Migrating
A subscription is first and foremost a way to distribute configuration. After fetching its contents, a client must parse the share links or supported config format and generate its own runtime config. So if a subscription URL opens successfully, that only confirms the content was fetched. Verify separately that all nodes and parameters were preserved and that the connection works.
- Check the parsed results first. After updating the subscription, verify node names, addresses, ports, and protocols. An empty list may point to an unexpected response or unsupported format; don’t immediately blame the remote server.
- Then check key fields. For VMess, verify the UUID and transport settings. For VLESS, verify the UUID, encryption settings, and flow. For REALITY, also check the server name, public key parameters, and short ID.
- Inspect the generated local config. Share links may omit default values, and clients may supply their own. To compare setups, inspect what is ultimately passed to the core, not just the node label.
- Finally, check the runtime logs. Distinguish config parsing errors from connection and handshake failures. If you see an unknown field, check the core version rather than repeatedly changing the node password.
Even two devices using the same subscription can show different node lists. One may not have updated yet, a client may filter out unsupported types, or a parser may drop certain parameters. Subscription URLs may also contain access credentials, so hide the full URL and any identifying information when troubleshooting.
5. Share a Subscription Between Desktop and Android—Not System Proxy Settings
Across devices, keep the node source and required connection parameters consistent; don’t assume the same traffic-routing method applies everywhere. A desktop system proxy is mainly used by apps that honor that setting, while Android’s VPN mode routes traffic through a system interface. They cover different sets of apps, so a working setup on one device does not prove the other is configured correctly.
Setup: Use the Same Subscription, Verify Each Device Separately
Desktop: v2rayN
- Choose a supported core based on the node requirements and note the version that actually starts.
- Add the subscription URL in the subscription group settings, update it, and verify the node parameters.
- If using the system proxy, check that your browser follows the proxy settings.
- Back up routing and DNS settings separately; they are not part of the subscription.
Android: v2rayNG or v2flyNG
- Choose a client based on the Xray or V2Fly track, then import the same subscription.
- On startup, grant system VPN permission and check for conflicts with other VPN connections.
- Set per-app proxy rules as needed and check whether the target app is excluded.
- Test Wi-Fi and mobile data separately so network differences aren’t mistaken for core differences.
A shared subscription keeps node sources consistent, but each device still needs its own checks for update status, routing, DNS, and app coverage.
Change one variable at a time when migrating. For example, keep the existing routing and DNS settings, switch clients, and test one node. Once it works, adjust split tunneling. That way, if something goes wrong, you can tell whether the cause is core compatibility, config generation, or a change in which traffic is routed.
6. Use Ports and Logs to Identify Which Layer Is Working
The three numbers below are config examples to help explain the connection path. They are not default values for every version or performance test results. In actual use, refer to the listening port shown by the client and the server port provided for your node.
If your local SOCKS listener is set to 127.0.0.1:10808, you can test it separately with a command-line tool that supports proxies. The command below requires curl to be installed and the target site to be reachable. It sends DNS lookups through the SOCKS proxy; it does not prove that every app on the device is using the proxy.
curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/- Connection refused immediately: Check the local port, listening address, and whether the core has started. The connection has not reached the remote protocol handshake yet.
- Local connection works, but logs show a handshake error: Check the protocol, security mechanism, system time, and identity parameters against the server config.
- The command works, but the browser fails: Check the system proxy, browser proxy settings, and conflicting extensions before switching cores.
- Only some apps fail: Check per-app proxy rules, routing, and DNS settings. Confirm whether the issue is specific to the app or destination domain.
Next steps: Keep a verified baseline config
Record the client and core versions, the full protocol combination, and the local port. After an upgrade, test this baseline first, then restore the other subscriptions and split-routing rules. This makes it easier to pinpoint cross-device issues than simply noting “using V2Ray.”
The Project V ecosystem has many names, but choosing a setup comes down to three layers: the node defines connection requirements, the core implements them, and the client passes the config to the core and routes traffic on the device. Align these layers before considering interface preferences or cross-device management. For setup and import instructions, see the client setup guide; for protocol fields, see the glossary.