Project V, V2Fly, and Xray Explained: Open-Source Ecosystem and Client Core Guide

At a glance

Project V is the ecosystem concept; V2Fly and Xray are two core maintenance branches that emerged later; and v2rayN, v2rayNG, and v2flyNG are clients for importing subscriptions, choosing nodes, and managing the system proxy. You will learn which core executes a configuration and what to check for protocol, transport, routing, and local-port compatibility before switching clients.

Start with three layers: ecosystem, core, and client

The key is not memorizing who “replaced” whom, but separating the software stack into three layers. Project V is best understood as the ecosystem around proxy protocols, core implementations, configuration formats, and client tools. V2Fly and Xray mainly refer to actively maintained core branches, while v2rayN, v2rayNG, and v2flyNG sit at the client layer users operate directly.

The core handles the actual data processing: listening for local inbound traffic, creating remote outbounds, applying DNS policies, matching routing rules, encapsulating VMess or VLESS traffic, and handling TCP, WebSocket, gRPC, and other transport settings. Clients generally do not reimplement these protocols. They convert subscription data into a core-readable configuration, then manage the core process—starting, stopping, and switching it as needed.

Project V: A historical and ecosystem-wide umbrella term covering protocol design, core programs, configuration systems, and surrounding tools. It should not be assumed to mean a specific installer.

V2Fly: The community-maintained continuation of the V2Ray technical line, whose core program is commonly called v2fly-core or v2ray-core. It continues to support VMess, VLESS, routing, DNS, and various transport combinations.

Xray: A separate core branch that grew from the existing codebase. Its configuration structure shares much with the V2Ray ecosystem while extending its own protocol and transport capabilities.

Client: Provides a graphical interface, subscription updates, QR-code import, node lists, system-proxy controls, and logs. The client name does not necessarily match the core currently running.

How to tell: ask “which core executes the configuration?”

The interface name only identifies the client being operated. Core versions, process names, and the Core type shown in logs reveal which branch ultimately executes VMess, VLESS, and routing rules.

Timeline: why one ecosystem has two core branches

Project V initially centered on the V2Ray core and gradually established a stable JSON configuration structure. Typical configurations include inbounds, outbounds, routing, dns, and log. A surrounding client can provide a graphical interface simply by generating these fields and calling the core program.

As maintenance organizations, development goals, and feature priorities changed, the ecosystem split into distinct maintenance paths. V2Fly continued the community maintenance of V2Ray, while Xray developed independently from a similar configuration base. Their shared history explains why many fundamentals match, but it does not mean every field, protocol extension, or transport parameter is interchangeable.

Early stage: The V2Ray core, VMess protocol, and JSON configuration system became the ecosystem’s foundation, with clients providing the interface around the core.
Community continuation: V2Fly continued maintaining v2ray-core and gradually advanced its modular structure and v5-related configuration capabilities.
Independent evolution: Xray-core retained many foundational concepts while expanding implementations for VLESS, transport security, flow control, and more.
Client divergence: Desktop and Android clients packaged different components for their target cores, and subscription fields began to diverge between branches.

This is closer to “parallel maintenance on a shared foundation” than a simple old-versus-new relationship. V2Fly’s 4.x configuration conventions, its v5 direction, and Xray-core 1.x’s extension pace each follow their own path. Version numbers cannot be compared across branches: Xray-core 1.8.x is not necessarily older than v2fly-core 5.x, because the two version sequences have no shared scale.

V2Fly vs. Xray: shared ground and key differences

Both core branches can handle common proxy paths: a local application connects to a SOCKS or HTTP inbound port, the core selects a proxied or direct outbound according to routing rules, and then establishes the remote connection defined by the node. VMess, VLESS, TCP, WebSocket, gRPC, TLS, DNS splitting, and domain rules are common terms when comparing the two.

Shared terminology does not mean identical configurations. Whether a subscription node works depends on the protocol, transport, security layer, flow-control fields, and the client’s conversion logic. A standard VMess over WebSocket + TLS configuration is usually broadly compatible; a VLESS node with Xray-specific extensions should be handled by an Xray-core version that explicitly supports those fields.

Xray core

Recommended

Best suited to VLESS configurations with Xray extension fields, and a common primary core in v2rayN and v2rayNG. Before choosing it, verify that the client version recognizes the subscription’s security layer, flow control, and transport parameters.

Best for: daily use, extended VLESS configurations, and nodes with explicit Xray fields

V2Fly core

Continues the V2Ray community branch and works well with standard VMess, VLESS, and conventional routing configurations. With v2flyNG, the client and core lineage are clear, making it easier to verify that a configuration falls within V2Fly’s supported range.

Best for: standard V2Ray configurations, the V2Fly branch, and already-compatible subscriptions

Judging by the node name alone

“High speed,” “dedicated line,” and “V2Ray node” are not technical fields, so they cannot tell you which core is required. The useful details are the protocol, transport, security layer, port, and extension parameters.

Best for: not a selection criterion; inspect the configuration details and verify its fields

Performance should not be judged by core name alone. In one sample test using the same computer, node, and routing rules, true TCP connection latency measured 86, 91, and 88 ms; the 5 ms spread across three runs already matters. Congestion during peak hours usually causes far more variation than the difference between two cores with similar configurations. For a fair comparison, keep the node, test time, DNS setup, and system-proxy mode constant.

Bottom line: compatibility matters more than version numbers

If a subscription contains Xray extension fields, prefer Xray-core; if the configuration was clearly generated for V2Fly, use v2fly-core. Do not swap cores across branches simply because one version number is higher.

Which core do v2rayN, v2rayNG, and v2flyNG use?

v2rayN is a desktop client focused on subscription groups, node testing, routing modes, system-proxy controls, and core management. Its commonly used primary core is Xray-core, but the client version, downloaded core components, and user selection affect the actual result. “Using v2rayN” alone does not prove which core is running; check Settings and the logs.

v2rayNG is an Android client following the Xray core branch, suitable for importing VMess, VLESS, and other configurations supported by Xray. v2flyNG also runs on Android but follows the V2Fly core branch. Their interfaces and basic workflows may look similar, but their core lineages differ; when migrating nodes, do not compare only the server address and port.

Client	Platform	Primary core	Where to check
v2rayN	Windows、Linux	Usually Xray-core, depending on the client version and Core type setting	“Settings” → “Parameter settings” → “Core type”; also check the startup log
v2rayNG	Android	Xray-core	Open Settings and Logs from the side menu to view core startup details
v2flyNG	Android	v2fly-core	Confirm the version on the Settings page, then verify core details in the runtime log

Confirming the active core in v2rayN

Open Parameter settings

After launching v2rayN, go to “Settings” → “Parameter settings.” Do not rely on the window title: the client name does not identify the core process currently running.
Check the Core type

Open “Core type” and verify the core option mapped to protocols such as VMess and VLESS. The layout may vary between 7.x releases, but the basis for identification remains the protocol-to-core mapping.
Restart the core

Save the change, then select “Restart service” or reconnect to the node so the new choice takes effect. If you only change the dropdown without restarting, the old core process may still be running.
Read the startup log

Open the log window and look for the core name, version, and configuration-load result. A sample entry should include a full version such as “Xray 25.3.6,” not merely the client version.
Check local ports

Make sure the SOCKS and HTTP ports are not being used by another program. Common settings use 10808 and 10809, but the actual values under “Parameter settings” are authoritative.

Why subscriptions, imports, and split routing depend on the core

A subscription is not the core itself; it is usually a distribution method for a set of node details. After fetching it, the client parses URIs or structured data and generates the core configuration. The same subscription may show a different number of nodes in different clients, often because a client does not yet recognize a protocol field or its group filters hide some nodes.

A node being “imported successfully” does not mean the core can start. For VLESS, the address, port, user identifier, and transport are only the basic fields. If the configuration also includes a security layer, flow control, server name, fingerprint, or transport path, missing any required parameter can cause the handshake to fail. For VMess, pay attention to the user identifier, transport, TLS state, and time skew with the server.

Subscription layer: Distributes nodes. Updates may run every 6, 12, or 24 hours, depending on the server-side policy.
Client layer: Parses subscriptions, stores groups, selects nodes, and generates core configuration files.
Core layer: Validates fields, listens on local ports, applies DNS and routing rules, and establishes remote connections.
System layer: Applications hand traffic to the local inbound through the system proxy, SOCKS proxy, or transparent forwarding.

Split routing is also executed by the core, not determined by the node name. Client options such as “bypass LAN,” “direct-connect to mainland China addresses,” and “global proxy” are ultimately converted into matching rules for domains, IPs, ports, or protocols. When switching from the Xray branch to V2Fly, check rule-set formats and extension fields; do not simply copy the client database and assume identical behavior.

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks"
    }
  ],
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

The snippet above shows only the layer relationship: a local SOCKS inbound listens on 127.0.0.1:10808, while private addresses go through the direct outbound. A real configuration also needs complete outbound, DNS, and logging sections. Changing the listen address to 0.0.0.0 may allow devices on the same network to connect, so also verify the client’s LAN-access switch, the operating system firewall, and access controls.

Common misconceptions and migration checks

The most common misconception is calling all related software “V2Ray.” That may be understandable in casual conversation, but it is too vague for troubleshooting. A precise report should include the client, core, protocol, transport, and failure stage—for example, “v2rayNG imported the VLESS node successfully, but Xray-core reported an invalid transport field after startup.”

Another misconception is that the same subscription must produce identical results in all three clients. In reality, subscription parsing, field mapping, and default routing belong to each client implementation; the core only processes the configuration the client generates. If nodes are missing, update the subscription and clear group filters first, then check whether the current client version recognizes the protocol.

Does v2rayN always run the V2Fly core?

Not necessarily. Go to “Settings” → “Parameter settings” → “Core type,” verify the entry mapped to the protocol, restart the service, and check the core name and full version in the log.

Can v2rayNG and v2flyNG directly overwrite each other’s configurations?

First compare the protocol, transport, security layer, flow control, and routing rules field by field. Standard VMess configurations are usually easier to migrate; VLESS configurations with specific extensions should be re-imported and tested against the target core.

Why does the core stop immediately after startup even though the subscription has nodes?

Open the core log and look for configuration parsing errors first, then check whether local ports such as 10808 and 10809 are already in use. If the log reports an unknown field, switch back to the core branch that matches the configuration.

What should I do if latency suddenly rises after switching cores?

Test true connection latency three times in a row using the same node, and confirm that DNS, routing mode, and system-proxy settings have not changed at the same time. If the results are 82, 137, and 89 ms, investigate network variation rather than judging core performance from a single 137 ms reading.

Does a VMess node require a specific core branch?

Standard VMess configurations are generally compatible with both branches, but transport and TLS parameters still need checking. If an existing configuration is stable, there is no reason to switch cores just to pursue a higher version number.

Migration checklist to keep

Record the client name and version, such as v2rayN 7.11.3, rather than writing only “desktop version.”
Record the core name and version shown in the log, such as Xray-core 25.3.6 or the corresponding v2fly-core version.
Record the node protocol, remote port, transport, security layer, and server name.
Record the local SOCKS and HTTP ports, along with the system-proxy mode.
Test subscription updates, core startup, true TCP connection latency, and web access separately so issues from different stages are not conflated.

In short, Project V is the entry point for understanding the history and ecosystem; V2Fly and Xray are independently maintained core branches with a shared foundation; and v2rayN, v2rayNG, and v2flyNG are clients for specific platforms. There is no need to argue over which name is more “official.” Confirm that the client fully parses the subscription, the core supports the node fields, and routing rules behave as expected.