V2Fly and Xray are two core families that grew from a shared technical foundation, while v2rayN, v2rayNG, and v2flyNG are client interfaces for configuration, subscriptions, and system proxying. This guide is for anyone who sees these names but cannot tell how they fit together. By the end, you’ll know which core is running, whether a subscription is compatible, and which layer to focus on when upgrading.
Four concepts that are easy to mix up
The short version: Project V is the ecosystem behind the technology; V2Fly and Xray are core families; VMess and VLESS are protocols or configuration capabilities; and v2rayN, v2rayNG, and v2flyNG are the clients users interact with every day. They belong to different layers and should not be compared as equivalents.
The core handles the actual data processing. It reads inbound, outbound, DNS, routing, and transport settings, listens on local ports, and decides where traffic goes according to the rules. For example, after a client sets its local SOCKS endpoint to 127.0.0.1:10808, the core—not the interface button—accepts connections, matches domain rules, and establishes remote connections.
The client interface turns complex configuration into usable menus. Adding subscriptions, choosing nodes, switching the system proxy, viewing logs, and generating core configuration are usually handled by the client. Whether a connection continues after the interface closes depends on how the client runs and whether the core process is still active.
Where each name fits
- Project V: An open-source technology ecosystem built around proxy cores, protocols, configuration formats, and supporting tools.
- V2Fly: A community-maintained core family. Its main project is commonly known as v2ray-core and continues V2Ray’s modular architecture.
- Xray: An independent core family that evolved from a related codebase. Its main project is commonly known as Xray-core.
- VMess and VLESS: Protocols that may appear in node configurations. A protocol name alone does not identify the client or guarantee compatibility with every transport parameter.
- v2rayN, v2rayNG, and v2flyNG: Desktop or Android clients that manage subscriptions, edit nodes, and invoke a core.
Bottom line: identify the layer before troubleshooting
If an import fails, first check whether the client can recognize the subscription. If startup fails, check the core log. If web traffic is routed incorrectly, inspect routing and DNS. Mixing these issues together often leads to repeated reinstalls without finding the configuration error.
How Project V split into the V2Fly and Xray paths
Project V originally centered on the V2Ray name, with inbound, outbound, routing, DNS, and underlying transport designed as composable modules. Configuration structures such as inbounds, outbounds, and routing.rules reflect this design.
Around 2020, the original community’s maintenance organization and contribution model changed. The V2Fly community continued maintaining v2ray-core, focusing on compatibility, module maintenance, and the evolution of existing configurations. Xray-core developed independently from the shared technical foundation, with its own release cadence, extensions, and implementation choices.
A “shared origin” does not mean the two are identical today. They still share many concepts, including inbound and outbound handlers, routing rules, VMess, VLESS, SOCKS, and HTTP local endpoints, but specific fields, defaults, transport extensions, and support for new features may differ. A core starting successfully does not mean every copied field behaves as expected.
| Comparison | V2Fly family | Xray family |
|---|---|---|
| Common core name | v2ray-core | Xray-core |
| Version identification | Commonly seen in the 5.x release line | Commonly seen in the 1.x release line |
| Primary license | MIT | MPL-2.0 |
| Configuration foundation | JSON configuration with modular inbound and outbound handlers | JSON configuration with modular inbound and outbound handlers |
| Compatibility check | Check the protocol, transport, security parameters, and version | Check the protocol, transport, security parameters, and version |
| Recommended approach | Keep the same core family when continuing with a verified V2Fly configuration | Use Xray when the subscription explicitly requires Xray capabilities |
What the license difference means
MIT and MPL-2.0 both allow public use, research, and code redistribution, but their notice and source-disclosure obligations differ when you create derivative work. Ordinary users generally do not need to choose between them when installing a client. Developers embedding a core into their own software, modifying source code, or redistributing it should read the license text included with the project.
Clients have their own licenses as well. The commonly distributed codebases of v2rayN, v2rayNG, and v2flyNG currently use GPL-3.0, and client and core licenses must be understood separately. A client’s license does not automatically change the independent core it invokes to the same license.
Bottom line: compatibility depends on capabilities, not family names
If existing nodes are stable, there is no need to switch immediately just because the other path adds a new feature. Switching cores is justified when a subscription explicitly requires specific transport fields, the current core cannot recognize the configuration, or the log points to a missing capability.
Which cores power v2rayN, v2rayNG, and v2flyNG?
v2rayN is a desktop client for Windows, macOS, and Linux. It is neither a protocol nor an alias for a single core. The 7.x release line provides interfaces for subscriptions, routing, system proxying, TUN, and core management. It commonly runs with Xray-core and can also use a supported V2Fly core when configured accordingly.
v2rayNG is an Android client that primarily invokes Xray-core. It brings share links, subscription groups, routing settings, and the VPN service entry point together in a mobile interface. v2flyNG also targets Android, but follows the V2Fly core path. The interfaces may look similar, but their core origins and feature support timelines are not necessarily the same.
A subscription service provides node data; it does not install a particular client on the device. A standard VMess or VLESS share link may be recognized by different clients, but specific transport extensions require checking core capabilities. Seeing a node name only means the link was parsed successfully, not that every connection parameter is fully supported.
| Client | Platform | Core relationship | Best suited for |
|---|---|---|---|
| v2rayN | Windows、macOS、Linux | Desktop client that manages supported cores, commonly using Xray-core | Desktop subscription management, system proxying, routing, and TUN |
| v2rayNG | Android | Xray-core | Subscriptions explicitly designed for Xray or requiring its capabilities |
| v2flyNG | Android | v2ray-core | The V2Fly path when keeping the same core family is important |
How to identify the core currently running
Check the version
In v2rayN 7.x, open “Help” → “About” and record the client version first. The client version and core version are separate numbers; do not treat them as one.
Check the core type
Go to “Settings” → “Parameter Settings” → “Core Type” to see which core is selected for the current node configuration. The field location may change between minor releases, but its name usually includes Core or the equivalent core label.
Read the log
Start the node and open the runtime log. Its opening lines usually show
Xray 1.xorV2Ray 5.x. This is more reliable than guessing from the client icon.Check on mobile
In v2rayNG or v2flyNG, go to “Settings” → “About” and record the client version. Then check the startup log for the core name and version number.
Test the local endpoint
Confirm in the log that the local endpoint is listening. A common SOCKS example is
127.0.0.1:10808. If the port is already in use, change it or stop the old process occupying it.
How to assess subscription, protocol, and core compatibility
A subscription is usually a set of node entries. After updating it, the client first parses VMess, VLESS, and other share content, then generates configuration the core can read. There are two gates: the client must recognize the subscription format, and the core must support the converted protocol and transport parameters.
With VLESS, seeing a vless:// prefix is not enough. Also check the server address, port, user ID, encryption field, transport, server name, and security-layer parameters. Missing any critical field can appear as a connection timeout, handshake failure, or configuration error in the log.
VMess does not mean “it will connect as long as V2Ray is supported.” Clock skew, an incorrect user ID, a mismatched transport path, or an incorrect TLS server name can all cause failure. Start troubleshooting with the first error in the log instead of changing DNS, routing, and protocol parameters at the same time.
{
"inbounds": [{
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks"
}],
"routing": {
"domainStrategy": "AsIs",
"rules": [{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
}]
}
}Four-step compatibility check
- Check parsing first: After updating the subscription, do nodes appear, and are their addresses and ports complete? No nodes usually indicates a subscription URL, content-format, or update-process problem.
- Then check startup: After selecting a node, watch the core log. Unsupported configuration fields usually trigger an error before a connection is established.
- Next check the handshake: If the core starts normally but the connection fails, verify the protocol, security layer, transport, server name, and system time.
- Finally check routing: If the node is connected but some websites behave incorrectly, inspect DNS, routing rules, the system proxy, and TUN. Do not keep changing the subscription format.
Bottom line: node visibility, core startup, and connection success are different states
A node appearing in the list only means the client parsed it. A listening port in the log only means the core started. A normal response from the destination confirms that the protocol, transport, DNS, and routing are working together correctly.
How ordinary users should choose and maintain a setup
On desktop, start with v2rayN and let verified configuration and subscription requirements determine the core. On Android, use v2rayNG when the subscription documentation explicitly provides parameters for Xray; if an existing configuration is based on V2Fly and has been stable, v2flyNG can reduce migration variables.
Separate client upgrades from core upgrades. A client upgrade may change menus, subscription storage, or system-proxy behavior; a core upgrade may change configuration validation, protocol implementation, or routing capabilities. Upgrade one layer at a time so the log makes the source of any change easier to identify.
Before migrating, record the client version, core version, local listening port, routing mode, and DNS settings. On desktop, at minimum note whether the SOCKS port is 10808, whether the system proxy is global or rule-based, and whether TUN is enabled. Saving only the subscription URL cannot fully restore these local options.
- Stability first: When existing nodes, DNS, and routing work normally, upgrade on a set schedule instead of switching core families frequently.
- Requirements first: When a specific protocol extension is needed, confirm the server and subscription documentation first, then choose a core that implements it.
- Logs first: When a connection fails, preserve the startup log and the first error instead of changing several parameters in succession.
- Configuration first: A node with the same name may generate different configurations in different clients. Compare the actual fields, not just the node name.
- Upgrade by layer: Update the client, core, and subscription separately, and run a connection and routing test after each update.
Does v2rayN mean it uses the V2Fly core?
No. v2rayN is a desktop client, and the 7.x release line can manage cores and configurations. Open “Settings” → “Parameter Settings” → “Core Type”, then use the startup log to confirm whether Xray-core or v2ray-core is actually running.
Can the same subscription be imported into all three clients?
Standard VMess and VLESS entries can usually be parsed by multiple clients, but specific transport fields may not be compatible. After importing, check the node count, start nodes one at a time, and read the logs. Do not confuse “displayed successfully” with “fully supported.”
Why does the original configuration fail after switching cores?
First look for errors such as unknown field, invalid value, or unsupported in the log, then check the transport, security layer, and routing fields. If restoring the original core makes it run again, the issue is more likely a configuration difference than a subscription account problem.
How should I handle port 10808 already being in use?
First quit any old client or core process still running in the background. If both must run at once, choose an unused port in the local listening settings and update the browser or system proxy to point to it.
Do I need to install both v2rayNG and v2flyNG?
Usually not. Choose one according to the core required by the subscription. You can test them separately for compatibility, but do not let both clients manage Android’s network connection at the same time.
Ultimately, Project V is a map of technical relationships, not a piece of software that needs to be installed separately. V2Fly and Xray implement the cores, while the three clients organize subscriptions, nodes, routing, and system network entry points into usable interfaces. When something goes wrong, check the client, core, protocol, transport, DNS, and routing in that order; the troubleshooting path is much clearer than simply switching software.