Project V is the starting point for understanding this toolkit. V2Fly and Xray represent different core development paths, while v2rayN, v2rayNG, and v2flyNG manage configuration and connections for users. This guide breaks down the ecosystem by project, core, client, and protocol, then explains how to choose for desktop or Android. It’s for users who have a subscription but aren’t sure which client or core to use.
Project V, V2Fly, and Xray: Understand the relationships
Project V focuses on network communication tools and modular proxy capabilities, with V2Ray as a core project. In everyday use, “V2Ray” may refer to the core program or the broader ecosystem. When troubleshooting, be specific: which client is running, which core it calls, and which configuration the core actually uses.
V2Fly is the community that continues to maintain and develop V2Ray. The V2Fly core usually refers to its v2ray-core. Xray-core branched from v2ray-core and has since followed an independent development path. The two share some history and configuration concepts, but that doesn’t mean their features, fields, or defaults will always match.
- Project V: The project’s background and technology ecosystem—not a separate desktop client to install.
- V2Fly: A community and development path; when discussing connection capabilities, specify v2ray-core.
- Xray: An independently developed core project. Configure features such as REALITY and XTLS Vision according to its actual support.
- Clients such as v2rayN: Turn server details, subscription groups, and routing settings into configurations the core can run.
Client vs. core: How settings become connections
The client handles interaction and management: saving subscription URLs, displaying servers, setting the system proxy, generating configuration, and starting or stopping the core. The core listens on local ports, applies routing rules, performs protocol handshakes, and forwards traffic. The interface may open normally even if the core fails to start because of a port conflict or invalid configuration.
| Client | Primary platform | Core relationship | What to check |
|---|---|---|---|
| v2rayN | Windows、macOS、Linux | Desktop client with multiple core options, including Xray; available choices vary by release | Check the installer’s platform and architecture, and which core the current configuration calls |
| v2rayNG | Android | Uses the Xray core; the Android app handles the interface and traffic interception | Check node parameters, which apps use the proxy, and VPN permission |
| v2flyNG | Android | Uses the V2Fly v2ray-core path | Check whether that core implements the features the node requires |
v2rayN’s cross-platform desktop interface is a separate distinction from its Windows WPF interface. The UI technology determines how windows, the tray, and platform integration work; it does not determine whether the remote handshake uses VMess or VLESS. Switching interface versions doesn’t replace checking the core and node parameters.
On Android, traffic interception is not handled by the protocol core alone. v2rayNG and v2flyNG typically use Android’s VPN interface to capture app traffic and pass it to the core. A VPN-connected status only confirms that the interception tunnel is established; it doesn’t prove the remote node handshake succeeded.
How to troubleshoot: Record the client, then the core
Before reporting an issue, note the client name and version, the core version from the runtime log, and the node protocol. “V2Ray won’t connect” doesn’t distinguish between an interface, traffic interception, configuration, or remote service problem.
VMess, VLESS, TLS, and REALITY: Know what each one means
A connection configuration involves at least a proxy protocol, a transport, and security settings. VMess and VLESS are proxy protocols; WebSocket is a transport; TLS and REALITY are options at the connection security layer. They aren’t interchangeable settings of the same kind, and a longer name doesn’t mean better performance.
- VMess: Implementations are available in both V2Fly and Xray. A successful connection still depends on matching user IDs, transport, security settings, and server configuration.
- VLESS: The protocol itself does not encrypt payloads; use it with an appropriate security layer. Don’t treat VLESS as “VMess with encryption enabled.”
- REALITY: It isn’t a universal TLS option that works the same way across all cores. For VLESS + REALITY parameters, choose an implementation that explicitly supports that combination.
- Vision: A flow-control feature related to XTLS, not a standalone subscription format. The server and client flow-control settings must match.
For example, a VLESS + REALITY subscription may require checking the server address, port, user ID, server name, public key, short ID, and flow control. Required fields and their exact names depend on the configuration and core documentation. Simply selecting VLESS from a protocol menu won’t fill in the other parameters.
Choose v2rayN, v2rayNG, or v2flyNG based on your node requirements
Choose based on your operating system first, then your node requirements. Desktop users can use v2rayN to manage subscription groups and routing in one place. Android users should compare the core capabilities of v2rayNG and v2flyNG. The recommendation below is for Android configurations that require Xray features—not a performance ranking for every use case.
v2rayNG
RecommendedUses the Xray core on Android. If a node explicitly requires REALITY or Vision, first verify support in this setup and check the core version in use.
Best for: Android configurations that explicitly require Xray features.
v2flyNG
Uses the V2Fly core on Android. If an existing configuration relies on V2Fly features and behavior, this may be a good fit; still check the specific transport and security options.
Best for: Android users with an existing, verified V2Fly configuration.
v2rayN
Manage subscriptions, the system proxy, and routing on desktop. Choose an installer that matches Windows, macOS, or Linux and your processor architecture, then check which core runs at runtime.
Best for: Desktop users who want to manage subscriptions and routing in one place.
You can’t predict speed from a client’s name alone. Network path, server load, transport settings, and local traffic interception all affect results. For a fair comparison, use the same server, network, and test destination, changing one variable at a time. Otherwise, you can’t attribute a difference to the core.
v2rayN checklist: From settings to runtime logs
Use these steps to confirm which core actually runs the current configuration. Options may move between releases. If you can’t find a setting, check the client version and interface type instead of relying on screenshots from another version. Custom configurations may also bypass the default core selection for regular server profiles.
-
Record the version
Go to Help → About and note the client version, platform, and interface type. Check the core version separately in the startup log; the client and core versions are not the same.
-
Check the core
Go to Settings → Parameter Settings and look for options related to Core Type. If cores are assigned by protocol, check the setting for the current node’s protocol. Labels and locations vary by version, so use the settings page in your actual release.
-
Check the node
Open the current server’s edit window and check the protocol, address, remote port, transport, and TLS or REALITY parameters. Keep the subscription’s original settings; don’t change the user ID or security parameters just to clear an error.
-
Check the logs
Restart the current configuration and check the main window log for core startup information and errors. First confirm that the configuration was accepted and the local listener started; then check whether the remote connection succeeded.
A successful switch to one core doesn’t mean every node in the subscription will work with it. Nodes may use different protocols or transports. Check each node’s actual requirements rather than assuming that everything from the same provider works identically.
Local ports, system proxy, and routing: What each one does
To distinguish the local entry point from the remote exit, here are two example local ports. These are manual values for illustration, not default ports for any particular release. Apps can use these addresses only if the corresponding listeners are configured.
For example, if you set the SOCKS entry to 127.0.0.1:10808 and the HTTP entry to 127.0.0.1:10809, apps must also use the matching proxy type. Sending an HTTP proxy request to a SOCKS-only listener fails at the local protocol stage, before reaching the remote server. Some versions use a mixed listener; in that case, use its actual configured type.
- System proxy: Tells apps that read system settings which proxy address to use; it doesn’t guarantee that every program will use it.
- TUN: Captures traffic through a virtual network interface, subject to routing, DNS, and exclusion rules. It doesn’t mean every connection is forwarded to the proxy server.
- Core routing: Directs traffic that has entered the core to connect directly, use a proxy, or be blocked. Traffic that never enters the core won’t be handled by these rules.
- Remote port: The server’s listening port; it doesn’t need to match the example local ports 10808 or 10809.
Troubleshooting order: Confirm traffic enters before checking the exit
If an app can’t connect, first check whether the log shows its connection. If there’s no entry, check the app’s proxy settings and traffic interception. If there is an entry, check the routing target, DNS, and handshake errors instead of repeatedly changing unrelated subscription URLs.
Open-source licenses: Check the client and core separately
Network protocols and open-source licenses are separate things. VMess and VLESS describe how communication works; MIT, MPL-2.0, and GPL-3.0 describe the terms for using and distributing code. Projects can communicate without sharing the same license. And a client’s use of a core doesn’t mean every bundled component is covered by a single license.
| Project | Primary license | What to check |
|---|---|---|
| V2Fly v2ray-core | MIT | The core itself and license notices for bundled dependencies |
| Xray-core | MPL-2.0 | Files covered by the license, and the terms for modifying and distributing them |
| v2rayN | GPL-3.0 | Client code, distribution packages, and bundled components |
| v2rayNG | GPL-3.0 | The Android client and separate license notices for its integrated core |
| v2flyNG | GPL-3.0 | The Android client and its dependency licenses |
This table identifies each project’s primary license; it does not replace the LICENSE, NOTICE, or dependency list for a specific release package. For everyday use, download a client that matches your platform, architecture, and node requirements. If you plan to modify or redistribute it, review the license terms for the exact code version instead of relying on the project name shown in the interface.
You can boil the choice down to three steps: identify your platform, check the protocol and security combination your node requires, then verify which core the client actually runs. The subscription provides the details, the client manages them, the core handles connections, and routing selects the exit. Keeping these layers separate makes upgrades and troubleshooting more straightforward.