Project V is an ecosystem of projects, V2Fly is the community maintaining V2Ray, and Xray is an independent core that grew out of V2Ray. v2rayN, v2rayNG, and v2flyNG are clients users interact with. This guide is for anyone choosing a client, migrating a subscription, or troubleshooting protocol compatibility. First identify what each name refers to, then choose a core based on the node's requirements and check the connection in the logs. Don't assume compatibility based on names alone.
What Project V, V2Ray, and V2Fly Mean
Project V began as an effort to build modular network proxy tools, with V2Ray as its best-known implementation. V2Ray is more than a single proxy protocol: it brings together inbound and outbound connections, routing, DNS, and transport mechanisms. The term “V2Ray node” is often used by providers as shorthand for a type of connection configuration; it doesn't tell you whether the node uses VMess or VLESS.
V2Fly is the community that continues to maintain and develop V2Ray. Keep the community name separate from the software name: the core maintained by V2Fly is generally still called V2Ray or v2ray-core. When a client says it uses the “V2Fly core,” it usually means the core implementation comes from this maintenance community—not that there's a separate network protocol called V2Fly.
| Name | Layer | What it does | What it doesn't tell you |
|---|---|---|---|
| Project V | Project ecosystem | The project background behind modular network proxy tools | Whether a particular subscription is compatible |
| V2Ray | Core software and project name | Handles connection, protocol, routing, and DNS settings | Whether every client with the same name uses the same core |
| V2Fly | Community and maintenance | Maintains the V2Ray core and related documentation | Which protocol a node uses |
| Xray | Independent core project | Continues developing protocols and transport features from a fork | Whether any configuration works unchanged across cores |
| v2rayN、v2rayNG、v2flyNG | Graphical client | Imports nodes, manages subscriptions, generates configuration, and starts the core | All features, based on the client name alone |
So asking “Which is better, V2Fly or v2rayN?” mixes two different layers: a maintenance community and a graphical client. The more useful questions are: Which core is v2rayN running, and does that core support the node's required protocol, transport, and security settings?
Xray and V2Ray: Shared Origins Don't Mean Configurations Are Interchangeable
Xray forked from the V2Ray codebase in 2020 and has since followed its own release and development path. The two share technical roots, so their configurations often use similar concepts for inbounds, outbounds, and routing. That doesn't mean every field, transport option, or protocol extension is implemented in both.
To assess compatibility, break the node down into its components instead of relying on the phrase “V2Ray supported.” VMess and VLESS are protocols; TCP and WebSocket are transport options; TLS and REALITY are connection security mechanisms. REALITY isn't a proxy protocol that can be swapped in alongside VMess or VLESS, and VLESS doesn't automatically enable transport encryption.
- Check the protocol first: See whether the share link starts with
vmess://orvless://, and check which protocol the client shows after import. - Next, check the transport: Verify settings such as TCP or WebSocket. For WebSocket, check the path and Host too—not just the server address.
- Then check the security settings: For TLS, verify the server name and certificate validation. For REALITY, check the server name, public key, short ID, and other required parameters.
- Finally, check extensions: If the node specifies
xtls-rprx-visionflow control, confirm that both the client and its core can represent and handle that configuration.
Likewise, a JSON parser accepting a file only confirms that its syntax or some of its fields passed validation. It doesn't prove that the client can negotiate a connection with the server. When migrating, check startup and connection logs: an unrecognized configuration field, a handshake failure, and a connection timeout each point to a different troubleshooting path.
Choosing Between v2rayN, v2rayNG, and v2flyNG
v2rayN is a desktop client for managing subscriptions, selecting nodes, configuring the system proxy, and generating configuration. The core it invokes handles the actual connection. Available cores and UI options vary by release package and version, so check the package notes, settings, and startup logs. The “v2ray” in its name doesn't mean it can only run V2Ray.
On Android, v2rayNG is built around the Xray core, while v2flyNG uses the V2Ray core maintained by V2Fly. Although their names are similar, don't assume they support identical core features or expose the same settings. The recommendations below are for scenarios that need Xray features, not a speed ranking for every network.
v2rayNG: An Xray Option for Android
RecommendedIf a node uses VLESS + REALITY or explicitly requires an Xray feature, first confirm that v2rayNG supports the relevant settings. After importing, check the security type, server name, and flow control—not just the node name.
Best for: Android users with subscriptions that explicitly provide Xray configurations.
v2flyNG: A V2Fly Option for Android
Uses the V2Ray core maintained by V2Fly. It's a good fit if you already have a tested V2Ray configuration and want to stay with that configuration ecosystem. Still check the specific protocol and transport requirements before choosing it.
Best for: Android users with an existing, working V2Ray configuration.
v2rayN: Desktop Subscription and Configuration Management
For Windows, macOS, and Linux desktops. Choose a release package for your operating system and processor architecture, then check which core is active. Menu locations may differ between platforms and UI versions.
Best for: Managing desktop subscriptions, system proxy settings, and traffic routing.
Bottom line: Start with the node requirements, then choose a client
Check whether the subscription requires REALITY, Vision, or another specific feature. If it does, verify Xray support. Otherwise, base your choice on whether your existing configuration runs reliably; there's no need to migrate a working setup just for a different core name.
Subscriptions, Share Links, and Full JSON: What Gets Converted?
A subscription URL usually returns a set of node details, sometimes as a list of Base64-encoded share links. The client parses this data, then combines it with local settings such as ports, DNS, and routing rules to generate the core configuration. So “the subscription imports” and “the generated connection works” are two separate checks.
A full JSON configuration may include inbounds, outbounds, routing, DNS, and logging—not just a list of nodes. Importing server-side JSON as a client node, or passing one core's full configuration directly to another core, can result in reversed connection directions, incompatible fields, or conflicts with local listeners.
- Identify the data type. A single
vless://link is a node share link. An address starting with HTTP or HTTPS may be a subscription URL. JSON containinginboundsandoutboundsis usually a full configuration; check what it's intended for before importing it. - Check the import result. Verify that the server address, port, user ID, transport, and security type were preserved. A node name is just a label; it doesn't prove the parameters are complete.
- Check which core is actually running. Look for the core name and version in the client logs. Updating a desktop client and updating its core are separate tasks, so record both versions.
- Check the local entry point. For example, if the client is listening for SOCKS connections on
127.0.0.1:10808, your test tool must connect to that address and port.10808is only an example; use the value configured on your device.
A subscription usually doesn't sync all local settings. Even if two devices import the same URL, their per-app proxy settings, DNS, system proxy, and routing rules may differ. A shared node doesn't guarantee identical traffic behavior.
How to Check a Subscription on Desktop and Android
When using multiple devices, test one node on one device first, then reproduce the same protocol combination on the other. Don't change the core, node, DNS, and routing rules all at once; even if the connection comes back, you won't know which change fixed it. Use the checklist below to record the results on both devices.
Checklist: Test the same subscription in each environment
Desktop: v2rayN
- Record the client version, core name, and core version.
- Import the subscription, then test one specific node.
- Check the local listening address, port, and system proxy status.
- Test apps that follow the system proxy first, then check other programs.
Android: v2rayNG or v2flyNG
- Choose a client with a core that supports the node's required features.
- Select the same node as on desktop and check its transport and security settings.
- When connecting for the first time, confirm that system VPN authorization is complete.
- Check whether per-app proxy settings exclude the app you're testing.
Sharing a subscription avoids entering the same details twice, but you still need to check local routing, DNS, and which traffic each device proxies.
For example, if a desktop browser works but a terminal app doesn't, the cause may have nothing to do with Xray or V2Ray protocol support: terminal programs may not use the system proxy and may need a proxy set explicitly. If only one Android app can't connect, check per-app settings before switching cores. For more on traffic routing and split tunneling, see the Getting Started Guide and Advanced Configuration.
Frequently Asked Questions About Cores and Clients
Why do v2rayN logs show Xray even though the name includes V2Ray?
A client name doesn't tell you which core is running. Stop the connection, check the current node and core settings, then restart and look for the core name and version in the logs. When reporting a problem, include both the client and core versions—not just “v2rayN.”
v2rayNG connects, but the same subscription fails in v2flyNG. What should I do?
Compare the same node, not just whether the whole subscription updated successfully. Check for REALITY, xtls-rprx-vision, or other core-specific parameters. If the node requires an Xray feature, use an option that supports it; don't delete security settings just to force an import.
Will switching to Xray always make my connection faster?
You can't tell from the core name alone. Keep the node, destination, network, and test method fixed. Record whether the connection succeeds, its latency, and sustained transfer performance, then compare the logs. If the node or network also changes, you can't attribute the results to the core or draw a general conclusion about speed.
The client still says a field is unrecognized after an update. What should I check?
First, use the logs to identify the core and version that actually started. Then determine whether the field came from subscription conversion or custom JSON. Back up your current settings and test a standard node on its own. If that works but the custom configuration doesn't, focus on the configuration format and which core supports the field. Don't keep changing the local proxy port.
Follow a simple order: identify the node's requirements, choose a core that supports them, then let the client handle importing and connecting to the system. Project V, V2Fly, and Xray help explain the ecosystem, but a successful connection still depends on compatible configurations at both ends and traffic entering through the right local endpoint.