This guide is for readers sorting out V2Ray ecosystem names, choosing v2rayN or an Android client, or troubleshooting core compatibility. You’ll learn how Project V, V2Fly, and Xray relate, then choose a client by protocol and platform.
Start with the four layers: projects, cores, protocols, and clients
These names are easy to confuse because they belong to different technical layers. Project V refers more broadly to the early project and ecosystem; V2Fly is the community and project group that continued V2Ray development; Xray is a core family that evolved from the same technical lineage; and v2rayN, v2rayNG, and v2flyNG are graphical clients users operate directly.
The core is responsible for establishing connections, applying routing rules, and handling inbound and outbound traffic. A graphical client manages subscriptions, generates configuration, starts the core, displays logs, and exposes controls such as system proxy or VPN mode. A client name containing “v2ray” does not mean it runs only one core, nor that similarly named protocols support exactly the same parameters.
- Project ecosystem: The broader scope of code, documentation, community collaboration, and related tools.
- Proxy core: Reads configuration and handles connections, such as V2Ray Core and Xray-core.
- Proxy protocol: Defines how the client and server exchange data, such as VMess, VLESS, and Trojan.
- Graphical client: Organizes subscriptions, server lists, routing, and core settings into an interface users can operate.
Think of a connection as an execution chain: the user selects a node in the graphical client, the client converts the subscription into core configuration, and the core connects to the server using protocols such as VMess, VLESS, or Trojan. The system browser or another app usually connects to a local listening port such as 127.0.0.1:10808, after which the core forwards the traffic.
How Project V, V2Fly, and Xray evolved
Project V is the starting point for understanding this history. In its early context, it described a set of network tools and design ideas centered on V2Ray, with V2Ray Core as the key execution component. As maintenance and community collaboration changed, the V2Fly community continued maintaining V2Ray-related code, documentation, and ecosystem projects. Today, “V2Fly” usually refers to this community-maintained line.
Xray is another core line that grew out of the V2Ray technical ecosystem. It shares similar JSON configuration concepts, inbound and outbound models, and routing structures, while continuing to expand transport methods, protocol implementations, and lower-level capabilities. The two share common roots and many concepts, but they are different core families; their version numbers, supported parameters, and release schedules should not be treated as interchangeable.
| Name | Primary role | Where users see it | What to check |
|---|---|---|---|
| Project V | Early project framework and ecosystem concept | Historical overviews, technical articles, older documentation | It is not a graphical client that needs to be installed separately |
| V2Fly | V2Ray community maintenance line and project collection | V2Ray Core, v2flyNG, configuration documentation | Check V2Ray Core versions and supported parameters |
| Xray | Independently developed core family | Xray-core, v2rayN core settings, v2rayNG | Check protocol capabilities implemented specifically or preferentially by Xray |
| V2Ray | Can mean the core software, but is also often used broadly for the ecosystem | Subscription guides, node names, client descriptions | Use the context to determine whether it means the core or the ecosystem |
Bottom line: do not judge compatibility by name similarity
Before importing a configuration, check the node protocol, transport layer, and core requirements. A client being able to display a node does not mean the selected core can correctly process every parameter.
So it is inaccurate to call Xray simply “a newer version of V2Fly,” just as it is inaccurate to treat V2Fly as a desktop client. A more useful description is that V2Fly and Xray are different maintenance lines within an ecosystem with shared roots. A graphical client may be designed around one fixed core or offer several cores for users to switch between.
What do v2rayN, v2rayNG, and v2flyNG use?
v2rayN is a graphical desktop client for Windows, macOS, and Linux. It offers subscription groups, server lists, routing settings, log viewing, and core management. In the v2rayN 7.x interface, for example, users can check the current core type under the settings. Available options may vary by version, so record both the client version and core family when migrating a configuration.
v2rayNG is an Android client that primarily uses the Xray core to handle connections, making it suitable for subscriptions containing VLESS, VMess, Trojan, and common transport combinations. v2flyNG also runs on Android, but uses a core from the V2Fly line. It is a better fit when V2Ray Core is explicitly required or when users need to compare behavior with V2Fly configurations.
| Client | Platform | Core relationship | Common use cases |
|---|---|---|---|
| v2rayN | Windows、macOS、Linux | Manage and select supported cores on desktop | Multiple subscription groups, batch latency tests, desktop routing rules |
| v2rayNG | Android | Uses the Xray core | Mobile network connections, per-app routing, subscription imports |
| v2flyNG | Android | Uses a V2Fly core | Run V2Ray Core configurations and compare V2Fly behavior |
Confirm the platform
On desktop systems, start with v2rayN. On Android, choose v2rayNG or v2flyNG based on the core you need.
Check the protocol
Open the subscription node details and record whether it uses VMess, VLESS, or Trojan, along with transport parameters such as TCP, WebSocket, or gRPC.
Check the core
In v2rayN, open “Settings” → “Parameters” → “Core Type” to confirm which core runs the current configuration.
Update the subscription
After switching cores, update the relevant subscription group again to avoid continuing to use a server configuration generated from an old cache.
Read the logs
After connecting, check the startup version, listening port, and handshake errors in the logs. If an unknown field appears, first verify that the core supports it.
VMess, VLESS, and Trojan are not the same thing as a core
VMess, VLESS, and Trojan are protocol types used for outbound connections, while Xray-core and V2Ray Core are the programs that execute them. Matching protocol names only indicate the general direction of a configuration. Whether it imports and connects successfully also depends on the core version, transport combination, and whether the client fully converts subscription fields into core configuration.
VMess configurations usually include a UUID, server port, encryption fields, and transport parameters. Older configurations may contain an additional ID, while modern configurations typically use alterId: 0. VLESS does not use VMess’s authentication structure and commonly appears with TLS, Reality, TCP, WebSocket, or gRPC. Trojan typically uses a password field and is often paired with TLS and a server name.
- For VMess: Check the UUID, server port, transport type, and TLS toggle. Older nodes may also include an additional ID.
- For VLESS: Focus on flow control, encryption fields, Reality or TLS parameters, and the core currently used by the client.
- For Trojan: Focus on the password, server name, certificate domain relationship, and transport settings.
- If a subscription imports but will not start: Look in the logs first for “unknown field,” “failed to load config,” or a port-in-use message.
Local SOCKS entry: 127.0.0.1:10808
Local HTTP entry: 127.0.0.1:10809
Troubleshooting order: client status → core logs → local port → system proxy → outbound connectionPorts also need to be distinguished as local listening ports and remote server ports. For example, 127.0.0.1:10809 used by a browser is the local HTTP proxy entry point, while 443 or another port in the node details is the remote service entry point. They serve different roles; changing the local port does not automatically change the server port in the subscription.
Common naming mistakes and practical troubleshooting
Mixing up ecosystem names most often causes two problems: downloading a client for the wrong device platform, or installing the right client but selecting a core that cannot interpret the subscription parameters. Troubleshoot from the interface layer down to the core instead of repeatedly deleting and re-importing the same subscription.
Does installing v2rayN mean V2Ray Core is definitely running?
Not necessarily. Open “Settings” → “Parameters” → “Core Type” to see the selected core, then confirm the actual core name and version loaded in the startup log.
Are subscriptions for v2rayNG and v2flyNG interchangeable?
Common VMess, VLESS, and Trojan nodes may be recognized by both, but support for specific flow-control and transport parameters varies by core. After importing, compare the node details field by field and perform a real connection test.
Why does the connection drop immediately after a successful subscription import?
Read the core log first. If it shows an unknown field, check the core type. If it shows “connection refused,” verify the remote address and port. If local listening fails, check whether 10808 or 10809 is already in use.
Do I need to rebuild the node list after switching cores?
It is recommended to update the current subscription group again and restart the client. This makes the client generate configuration for the new core’s capabilities and prevents an old process or cache from continuing to occupy the local port.
Does an Xray label on a node mean it can only use Xray?
The node name is simply a label supplied by the subscription provider. Expand the node details and judge by the protocol, transport, flow control, and TLS parameters rather than the server remark alone.
“Core started successfully” in the log only means that the configuration was accepted and listening began; it does not mean the remote connection is complete. A fuller verification sequence is to confirm that the core process started, verify that the local port is listening, enable the system or in-app proxy, visit the target site, and finally check whether the exit address changed as expected.
How to choose a core and client for your needs
If you mainly manage multiple subscriptions on desktop, run batch real-connection latency tests, and need granular direct, proxy, and block rules, v2rayN offers the most complete management interface. Before choosing a node, isolate sources by subscription group, compare latency and protocols, then confirm that the core type matches the node requirements.
On Android, choose v2rayNG first if the subscription explicitly targets Xray or uses parameters preferentially supported by the Xray line. Choose v2flyNG when you need to run a V2Fly core or reproduce V2Ray Core configuration behavior. Do not keep both clients in VPN mode at the same time, or they will compete for the system connection entry point.
- Filter by platform first: Use v2rayN on desktop; on Android, choose between v2rayNG and v2flyNG.
- Then filter by core requirements: Read the subscription guide and node parameters to check for specific flow-control, transport, or version requirements.
- Keep the default local ports: When there is no port conflict, start with 10808 and 10809 to make issues easier to locate using common guides.
- Run a real connection test: After testing latency, actually open a webpage and check the logs; a basic TCP probe does not prove that the protocol handshake succeeded.
- Record working combinations: Note the client version, core family, subscription group, and working nodes so you can compare quickly after an upgrade.
Bottom line: choose in this order—platform, protocol, core, node
First choose a client available for the device, then confirm the subscription protocol and core capabilities, and only afterward compare node latency. This order helps prevent core incompatibility from being mistaken for a routing problem.
The relationship between Project V, V2Fly, and Xray does not require memorizing similar names. Keep four questions separate—who maintains the project, what executes the configuration, which protocol carries the connection, and which client the user operates—and you can evaluate new versions or subscription formats yourself. For most users, the key detail is not how often a project name appears, but which core the client actually starts and whether it supports the node’s complete parameter set.