Project V is the broader project; V2Fly and Xray represent distinct core development paths, while v2rayN, v2rayNG and v2flyNG are client apps. This guide is for anyone choosing a download, checking node compatibility or troubleshooting an import that connects nowhere. Start by separating four layers—project, core, client and protocol—then choose based on your platform and server configuration.
Project V, V2Ray and V2Fly: Projects and Implementations
Project V began as a modular network proxy toolkit, with V2Ray as its best-known core implementation. It handles more than a single proxy protocol, providing inbound and outbound connections, routing, DNS and more. That’s why “V2Ray node” is often used as a broad label: it doesn’t necessarily mean the node uses VMess, nor that the client is running the V2Fly core.
V2Fly is a community project continuing V2Ray development, and its core program is still generally named V2Ray. Xray grew from a fork of the V2Ray codebase and has evolved independently as Xray-core. The two share a history, but they aren’t different display names for the same program, nor does one need to be installed before the other.
- Project: Project V provides context for understanding the ecosystem; it isn’t a desktop app you need to install.
- Connection core: V2Fly’s V2Ray and Xray-core parse configurations, establish connections and apply routing.
- Client interface: Apps such as v2rayN manage subscriptions and node lists, edit settings and launch the core.
- Connection protocols: VMess, VLESS, Trojan and Shadowsocks define connection rules; they aren’t client names.
Once these four layers are clear, “using v2rayN to import a VLESS node that connects through Xray” makes sense: the three names refer to the interface, protocol and engine. When troubleshooting, record each one separately instead of just saying “V2Ray won’t connect.”
V2Fly and Xray: Shared Roots, Different Capabilities
Both paths provide core capabilities such as multi-protocol proxying, routing and DNS, but supported transports, configuration fields and extensions can diverge by version. “Supports VLESS” doesn’t mean a core supports every possible VLESS combination. Check the complete set of protocol, transport, security layer and extension parameters.
| Comparison | V2Fly / V2Ray | Xray-core |
|---|---|---|
| Project relationship | Continues V2Ray’s community-led development | Forked from V2Ray and developed independently |
| Core responsibilities | Inbound and outbound connections, DNS, routing and protocol handling | Inbound and outbound connections, DNS, routing and protocol handling |
| Configuration compatibility | Follow the configuration specification for the corresponding V2Ray version | Share a configuration foundation, but extension fields aren’t universally interchangeable |
| Key limitation | Don’t assume Xray-specific features are supported everywhere | REALITY and XTLS Vision configurations depend on the implementation and version |
| Android clients covered here | v2flyNG | v2rayNG |
For example, if a server requires VLESS, REALITY and xtls-rprx-vision, confirm that the client’s actual core supports this combination, then check the public key, short ID, server name and flow. Changing only the protocol dropdown to VLESS—or merely renaming the program file—won’t meet all these requirements.
Bottom line: Choose a Core That Matches the Node
Start with the server’s protocol, transport and security requirements, then check what the core supports. Don’t infer compatibility from “v2ray” in a client’s name. For Xray-specific features, make sure the client is actually running a compatible Xray version.
Three Clients Compared: Platforms and Cores
The client provides the interface; the core handles the connection. Client updates can change the interface and configuration generation, while core updates can change protocol support or configuration validation. Check and record both versions separately—a single “latest version” label isn’t enough.
| Client | Platforms | Core | What to check |
|---|---|---|---|
| v2rayN | Windows、macOS、Linux | Desktop client that can run cores such as Xray and sing-box; available options depend on the version and distribution | Choose your OS and architecture first, then check the core settings required by your protocol |
| v2rayNG | Android | Uses the Xray core | If you need Xray-specific protocols or extensions, check the bundled core version |
| v2flyNG | Android | Uses V2Fly’s V2Ray core | For the V2Fly path, check support for the node’s transport and security layer |
v2rayN isn’t another name for the V2Fly core. Nor does support for multiple cores mean every distribution includes every option. Desktop and classic interfaces may differ in availability and settings; check the settings and startup logs to see which core is actually running. sing-box is a separate core implementation, not an upgrade path between V2Fly and Xray.
v2rayNG and v2flyNG have similar names, but they aren’t the same app with different icons. Both target Android, but use different core paths; even if both import a shared link, support for transport extensions and configuration fields can differ. Before switching, keep the original node details so you don’t mistake converted import settings for the server’s original configuration.
Check Which Core v2rayN Is Running
The steps below use the Chinese-language v2rayN interface as a reference. Menu labels may vary slightly across desktop distributions; “Core Type” may also appear as “Core Type Settings.” Check the settings, then verify against the logs after restarting. This is more reliable than guessing from filenames in the program folder.
-
Check versions
Open “Help” → “About” and note the client version. Then check the main-window logs for the core startup message and record the core name and version. Include both when sharing troubleshooting details.
-
Check the core mapping
Go to “Settings” → “Parameter Settings” → “Core Type” to see which core is assigned to the current protocol. If your version doesn’t have this setting, don’t rely on screenshots from another version; check the startup logs instead.
-
Check the node
Select the node in the list, right-click and choose “Edit Server.” Check the protocol, port, transport, TLS or REALITY settings one by one. A successful import only confirms that a record was created; it doesn’t mean the core accepted its settings.
-
Reconnect
Save the settings, then right-click the node and choose “Set as Active Server” to apply the configuration again. Check the logs for unsupported fields, core startup failures or address conflicts before testing the connection.
Don’t replace the core executable while a connection is running. The client’s configuration output must match the format the core accepts. If a configuration parsing error appears after an update, restore a known-working client and core combination, then isolate the differences one at a time. This is easier to reproduce than replacing several core files in succession.
Ports, System Proxy and Routing: Separate Settings
Even after the core starts successfully, app traffic still needs a route into the client. Desktop users commonly rely on the system proxy or configure an app to use a local proxy manually. TUN mode uses a virtual network interface and takes over routing. Android clients usually route traffic through system VPN permission; that permission doesn’t indicate a particular node protocol.
These ports illustrate common uses; they aren’t defaults to enter for every version. Some versions use a mixed inbound, with HTTP and SOCKS sharing a port; others listen on separate ports. Check the actual values under “Settings” → “Parameter Settings” for local listeners, then compare them with the logs. The server determines the remote port—don’t change it to 443 just because you see TLS.
- Local inbound: Apps connect to
127.0.0.1and the client’s listening port. A port conflict can prevent the inbound from starting. - System proxy: Directs apps that respect system settings to use a proxy; not every app does.
- Routing: Determines whether requests entering the core go through the proxy, connect directly or get blocked. Enabling the system proxy doesn’t send every request to the remote server.
- DNS: Resolution paths, routing rules and destination-domain matching all affect the result; check the logs to troubleshoot.
Subscription Imports but Won’t Connect? Troubleshoot by Layer
A subscription distributes configurations; it isn’t a new proxy protocol. One update can provide nodes using several protocols, but it can’t give the client core capabilities it lacks. Whether you import from a QR code, clipboard or subscription, the configuration still has to pass through client parsing, generation and core execution.
Why Does the Same Subscription Behave Differently in Two Clients?
Compare the same node’s protocol, transport, security layer and extension parameters, then check each client’s startup logs. If one side is missing the REALITY public key or flow, import the original link again and inspect the edit screen. Don’t compare node names alone.
Will Switching to Xray Guarantee a Connection?
First confirm that the node actually requires an Xray-specific capability, then check the address, port, credentials, server name and device time. Core compatibility only addresses implementation support; an unreachable server, mismatched certificate or invalid credentials can still cause a failure.
Latency Shows a Value, but Pages Still Won’t Load?
First identify what the test measures: an open TCP port doesn’t mean a complete proxy request will succeed. Check that the system proxy points to the local listening port, then run a real connection test. Use the logs to see whether the request reached the core and which routing rule handled it.
Do You Need to Re-add Your Subscription After Updating the Client?
Usually not. First check that the original subscription group and nodes are still there, then verify the updated core selection, local listener and routing settings. If you do need to import again, back up your configuration first. Remove the full subscription URL and credentials before sharing logs.
Recommended Order: Platform, Configuration, Core, Verification
For everyday use, there’s no need to rank the two cores universally. Desktop users should start with their OS and processor architecture when choosing v2rayN; Android users can compare v2rayNG and v2flyNG against the node’s requirements. Match the server’s protocol combination first, then consider subscription management, route editing and personal workflow.
- Confirm the target platform—Windows, macOS, Linux or Android—and choose the matching processor architecture.
- Get the complete configuration requirements: protocol, address, port, transport, security layer and any required extensions.
- Check the client and actual core versions, and confirm that this combination recognizes the configuration.
- After importing, check the logs, then test the local inbound, system proxy and a real web request.
For a closer look at protocols and security layers, see Protocol Guides. For help with menus, subscription updates and routing, visit the Setup Guide. Recording the client version, core version, protocol combination and error logs is usually more useful for troubleshooting than repeatedly switching clients.