Project V Ecosystem Explained: V2Fly, Xray Cores, and How the Clients Fit Together

How Project V, V2Fly, and Xray fit together

Project V began as a collection of projects built around network proxy tools, with V2Ray as its central tool. In everyday searches, “V2Ray” can mean the core program or, more broadly, the ecosystem of clients that use these protocols. Confusing the two can lead to questions like “If I installed V2Ray, why do I also need to choose Xray?”

The V2Fly community continues V2Ray development, and its core is commonly called V2Ray-core or the V2Fly core. Xray-core forked from V2Ray in 2020 and has developed independently since. The two share some history and have partly similar configuration structures, but they are not different names for newer and older versions of the same program, nor are their features automatically kept in sync.

Project V ecosystem
└─ V2Ray core tool
   ├─ V2Fly community continues development → V2Ray-core
   └─ Forked in 2020   → Xray-core, developed independently

Client interface
├─ v2rayN   → Uses the appropriate core based on node settings and client version
├─ v2rayNG  → Xray-core
└─ v2flyNG  → V2Fly’s V2Ray-core

The arrows show historical origins or usage relationships, not organizational affiliations. Clients handle subscriptions, node selection, and the user interface; cores handle connections, transport, DNS, and routing rules. A client launching successfully doesn’t mean its core started successfully, and importing a node doesn’t mean the current core supports every parameter it uses.

Which cores do the three V2Ray clients use?

v2rayN is a desktop client; it isn’t limited to V2Ray-core. It can manage different node types and select a suitable core based on the client version, protocol, and settings. To find out which core a connection uses, check the core type settings and startup logs—not just the main window title.

The difference is clearer on Android: v2rayNG uses the Xray core, while v2flyNG uses V2Fly’s V2Ray core. Capitalization in the names doesn’t define the technical distinction; the core implementation does. The recommendation below applies only when an Android node specifically requires Xray features. It isn’t a performance ranking for all devices and networks.

Choosing a V2Ray protocol: the protocol name isn’t the whole configuration

VMess and VLESS are proxy protocols; WebSocket and gRPC are transport methods; TLS and REALITY relate to the connection’s security layer. They operate at different layers. Seeing “VLESS” doesn’t mean every client that supports VLESS can use the node. Check the transport, security layer, and any related extension fields too.

VLESS does not provide the same protocol-level encryption mechanism as VMess, so it’s typically used with an appropriate security layer. REALITY is a security-layer solution in the Xray ecosystem, not a drop-in alternative to a standard TLS option. VMess doesn’t automatically mean “older core only”; compatibility depends on both implementations and their parameters.

• Protocol layer: Check whether it’s VMess or VLESS; don’t rely on the node’s display name.
• Transport layer: Check whether it uses TCP, WebSocket, or another transport, and verify any required fields such as path and Host.
• Security layer: Check whether it uses TLS or REALITY, and verify the server name and corresponding validation parameters.
• Extension fields: If the configuration includes flow, check whether the current core supports its specific value. Don’t remove it arbitrarily to silence an error.

Importing subscriptions: keep node lists and local settings separate

A subscription usually provides node connection details; it doesn’t take over all proxy settings on your device. The same subscription can produce similar node lists in different clients, but routing, DNS, per-app rules, and proxy mode are often controlled by local settings. Some subscription formats can also affect how fields are parsed, so open a node after importing and check its parameters.

If v2rayNG shows only some nodes after importing a subscription, first check the subscription contents and node types, then look for update or parsing errors. Menu labels may change between versions, so look for the corresponding function. Don’t assume the core is broken, and never post a subscription URL in a public forum—it may contain access credentials.

1. Keep the existing group and create a separate test group to avoid overwriting working nodes during troubleshooting.
2. After updating, check the protocol, transport, and security layer of a known working node.
3. Connect with the same node in each client and compare the logs. Don’t mistake results from different nodes for differences between clients.

v2rayN TUN mode and local proxy ports

System proxy settings provide a proxy endpoint for apps that respect them; TUN routes traffic through a virtual network interface. v2rayN’s TUN mode depends on the relevant components, permissions, and routing configuration provided by the client. The fact that a node uses Xray doesn’t mean the same core directly handles TUN.

Command-line tools may also use their own proxy options or environment variables. When troubleshooting, first check whether the app is sending traffic to the local endpoint, then check the connection from that endpoint to the node. The port numbers below are manual configuration examples, not shared defaults for all three clients. Check your local settings before using them.

• Check the listener: In v2rayN, open “Settings” → “Parameter Settings” and check the local listening ports. If the interface has changed, find the corresponding inbound settings and confirm them in the startup logs.
• Use the matching protocol: Point an HTTP proxy option to the HTTP endpoint and a SOCKS option to the SOCKS endpoint. For a mixed endpoint, check which protocols it actually supports.
• Avoid conflicts: When testing different clients, quit one before launching the next to prevent them from trying to use the same port.
• Check permissions: If TUN won’t start, check its required components and permissions. If the regular system proxy fails, first check the listener and app settings.

Testing V2Ray node speed: troubleshoot one layer at a time

Latency checks, webpage tests, and download throughput tests measure different things. A successful TCP connection only shows that an address and port are reachable; it doesn’t prove that protocol authentication, transport parameters, or the remote exit are working. When testing V2Ray nodes, consider core logs and real-world access—not just the number in the node list.

1. Step 1: Check that the core starts. Look first for errors such as port conflicts, configuration parsing failures, or unsupported fields. These are local issues; switching remote nodes usually won’t fix them.
2. Step 2: Check the remote connection. Look for connection timeouts, TLS handshake failures, or authentication errors. Fix a mismatched server name or incorrect credentials rather than changing proxy mode.
3. Step 3: Check real requests. Repeat the test with the same node and target webpage. Record the time, network type, and whether it succeeded; don’t judge core performance based on a single result.
4. Step 4: Check DNS and routing. If only certain domains fail, check the matched outbound tag and DNS results to see whether rules sent traffic through a direct connection or another outbound.

Ecosystem FAQs

Follow this order when choosing: platform, node feature requirements, client-to-core compatibility, then local proxy and routing settings. Project V’s history helps explain the names, but whether a configuration works depends on the installed package, node parameters, and logs.