Project V is the project’s background; V2Fly and Xray represent distinct core development paths, while v2rayN, v2rayNG, and v2flyNG are graphical clients. This guide is for users choosing a client, migrating subscriptions, or troubleshooting protocol incompatibilities. Start by separating each layer’s role, then check the node protocol, transport settings, and runtime logs to verify compatibility—don’t rely on names alone.
Project V, V2Fly, and Xray: Project History, Not a Product Hierarchy
Project V began as a modular toolkit for network proxying, with V2Ray as its core implementation. The core accepts local connections, applies routing rules, handles DNS, and connects to remote servers according to its configuration. Early users often used “V2Ray” to mean the entire setup, which blurred the distinctions between clients, protocols, and cores.
Around 2020, the V2Fly community continued developing and maintaining the V2Ray core. Xray-core also forked from the V2Ray codebase that year and went on to develop independently. The projects share a history, but they are not the same release, and Xray is not simply a new name for V2Ray. Check each project’s features, configuration fields, and release schedule separately.
- Project V: The project and toolkit behind the ecosystem—not a proxy protocol you can select in a client.
- V2Fly: The community that maintains the V2Ray core. When discussing technical issues, specify the exact V2Ray core version.
- Xray: The name of both a project and, commonly, Xray-core. It has its own protocol implementations and configuration changes.
- Graphical clients: Provide node lists, subscription management, and settings interfaces, but still rely on a core to apply connection configurations.
The two core branches share many configuration concepts, such as inbounds, outbounds, and routing rules. Similarity doesn’t mean every configuration is interchangeable. For features like specific security mechanisms, flow-control parameters, or newer transport implementations, consult the documentation for the core you’re using. Don’t copy an entire configuration just because its JSON looks similar.
Three Clients: The Interface Name Doesn’t Tell You Which Core Is Running
v2rayN is a desktop client for configuring connections, managing subscriptions, and controlling runtime behavior. It is not another name for the V2Ray core, nor should it be assumed to run only one core. Supported platforms, available cores, and configuration options vary by release; check your current installer and client interface.
| Client | Platform | Core behavior | Where to check |
|---|---|---|---|
| v2rayN | Desktop | Calls an available core based on the node type and client settings; the client’s name alone doesn’t determine which one | Core selection settings and startup logs |
| v2rayNG | Android | Uses the Xray core to handle proxy connections | App version details and runtime logs |
| v2flyNG | Android | Uses the V2Ray core maintained by V2Fly | App version details and runtime logs |
The client version and core version are separate. Updating the graphical interface doesn’t necessarily change protocol support, so don’t infer capabilities from the app version shown under “About.” Restart the connection and check the logs for the core name, version, and any startup errors. Some desktop releases manage cores separately, and a stale process can easily lead to confusion.
- In v2rayN, open “Settings” → “Parameter Settings” and check the core options available in your version. If there’s a separate core management section, check that too.
- Select a node and restart the connection. Find the startup details in the main window’s log area and note the core name and version actually in use.
- On Android, check the version details and runtime logs in v2rayNG or v2flyNG separately. Don’t judge by the app icon or subscription name.
- When reporting an issue, include the client version, core version, operating system, and error text. Remove subscription URLs, UUIDs, and access credentials before sharing.
Menu names can change between versions. If you can’t find an option, look for the relevant core, parameter, or log settings instead of changing unrelated options based on an old screenshot. If the interface doesn’t expose a core feature, switching subscriptions alone won’t enable it.
Protocols, Transports, and Security Settings: Check Compatibility at Every Layer
VMess and VLESS are proxy protocols; WebSocket and gRPC are transport options; TLS and REALITY involve connection security. These terms belong to different layers. Knowing that a node uses VLESS isn’t enough to tell whether a particular client can connect to it.
VMess isn’t exclusive to any one graphical client, and VLESS isn’t the same thing as REALITY. Xray and V2Fly differ in specific features. In particular, don’t assume that a node using Xray-specific parameters will work with every VLESS implementation. Support also depends on the core version and the client’s ability to import those settings.
| Configuration layer | Examples | What to check |
|---|---|---|
| Proxy protocol | VMess、VLESS | The protocol, user ID, and authentication settings must match on the server and client |
| Transport | WebSocket、gRPC | The path, Host, or serviceName must match the server configuration |
| Connection security | TLS、REALITY | Include the correct server name, certificate validation, public key, and other required settings |
| Specific flow control | xtls-rprx-vision | Confirm core support and compatibility across the server, client, and transport combination |
| Local proxy endpoint | 127.0.0.1:10808 | An example of a local listening address; record it separately from the remote server port |
Example ports aren’t universal defaults. If your local proxy listens on 127.0.0.1:10808, configure your browser or other apps to connect to that local address. The node’s server address and remote port still come from the server configuration. Changing the local port won’t fix remote authentication failures or add protocol support.
A subscription link distributes configuration; it isn’t a proxy protocol. A successful download only means the client received a response. Even if nodes appear after parsing, some fields may have been dropped. After migrating, check a sample node’s transport, security, and flow-control settings, then test the connection.
Choosing a Core: Start with Your Existing Nodes, Not the Names
First, list what the server actually requires, then choose a client and core. There’s no need to migrate a working standard VMess or VLESS setup just because the core has a different name. If the server explicitly requires REALITY or specific flow control, choose a client and core that fully support that combination.
Xray core
RecommendedFor servers that explicitly require a VLESS, REALITY, and Vision combination, start with an Xray version that supports those settings and confirm the client can generate the required configuration. This recommendation applies to those node requirements; it isn’t a general performance ranking for all network conditions.
Best for: Setups with specific Xray feature requirements; v2rayNG on Android, or v2rayN on desktop after checking its core settings.
V2Fly core
If your existing server and configuration are built around V2Fly, you can continue using the corresponding V2Ray core. Before migrating, check transport, security, and routing settings individually; don’t reuse fields specific to another branch without verifying compatibility.
Best for: Tested V2Fly configurations, v2flyNG on Android, and users who want to maintain their existing configuration setup.
Bottom line: Check the node settings, then test one node
Keep your original configuration and switch the client or core for a single test node. Confirm that all settings are present, startup succeeds, and the target site loads before migrating other nodes. Change one variable at a time so you can tell whether an issue comes from protocol support, importing, or routing.
Core names alone don’t determine connection speed. Server location, network congestion, packet loss, device performance, and transport all matter. For a useful comparison, test the same node and destination at similar times. Record whether it connects and whether you see reconnects or log errors. Don’t attribute differences between network routes to the core.
Migrating Between Desktop and Android: Share Subscriptions, Manage Local Settings Separately
The same subscription can provide configuration to multiple devices, but first confirm that the target client supports its format and node types. Local proxy endpoints, system-wide routing, and app exclusion rules usually differ between desktop and Android. Don’t assume these settings sync with the subscription.
Setup: Use One Node Source, Test Traffic Routing on Each Device
Desktop: v2rayN
- After importing the subscription, check a node’s protocol, transport, and security settings.
- Check which core is running in the logs and note the local listening port.
- Set up the system proxy or TUN as needed, then test your target apps individually.
- Keep your existing routing rules to avoid changing DNS and split-tunneling settings at the same time.
Android: v2rayNG or v2flyNG
- Choose the Xray or V2Fly route based on the node’s requirements.
- After importing the same subscription, confirm the node count and key settings.
- Start the connection, approve the system VPN prompt, and check that no other connection is already active.
- Reconfigure per-app rules and check background activity restrictions separately.
Subscriptions distribute nodes, but update timing, local routing, DNS, and app scope still need to be managed separately on each device.
A desktop system proxy usually affects only apps that follow that setting; it doesn’t route every program through the core. Android’s VPN routing and per-app selection have their own scope, too. So “works on desktop, not on Android” is a clue for troubleshooting—not immediate proof that one core is better than another.
- Export or back up the original client configuration and save routing and DNS settings separately.
- Import the subscription into the new client and test using the same node as before.
- First confirm that the core starts, then verify that system or app traffic is actually reaching the client.
- Restore routing and DNS settings one at a time, testing after each change and keeping a rollback configuration.
Common Questions: Troubleshooting Similar-Sounding Names
Does installing v2rayN mean I’m using the V2Fly core?
No. Check the core options under “Settings” → “Parameter Settings,” then restart the selected node and review the startup logs. Go by the core name and version actually running; the client name alone doesn’t tell you which core is handling the node.
The subscription imported successfully. Why does the connection fail as soon as I start it?
Open the node details and check the protocol, transport, security, and flow parameters. Then review the logs for unsupported fields, authentication errors, or a port conflict. A successful import only confirms that parsing worked. If a local port is in use, close duplicate client processes first—don’t change the remote port.
Can I move a VLESS node directly from v2rayNG to v2flyNG?
Check the full configuration first. A node with REALITY or other Xray-specific settings can’t be treated like a standard VLESS node. Keep the original configuration, then check the fields and logs on the target client. If its core doesn’t support them, use a client compatible with that node or ask the server provider for a compatible configuration.
The interface says connected, but websites won’t load. Should I switch cores first?
Try loading a page and check whether the logs show the corresponding request. If there’s no request, check the system proxy, VPN permission, or per-app routing. If there is, investigate DNS, routing, and remote errors. A running status in the interface doesn’t prove that traffic has reached the destination.
What should I record if something breaks after an update?
Record the client versions before and after the update, the core version actually running, the node protocol and transport, and the first relevant error. Reproduce the issue with the original node and routing settings, and keep a rollback configuration. Before sharing logs, remove subscription URLs, server credentials, and user IDs; include only what’s needed to troubleshoot.
The deciding factor is whether the complete configuration can be represented correctly and run reliably. Keep project history, core capabilities, client interface, and system traffic routing distinct in your notes to make future upgrades, migrations, and troubleshooting easier. For your first setup, start with the installation and import guide. If startup or traffic routing isn’t working, visit the Help Center.