Project V and the core ecosystem
Project V is an ecosystem of network proxy tools, with V2Ray among its widely used core projects. The V2Fly community continues related development, while Xray builds its own implementation and features on shared technical foundations. They have some configuration concepts in common, but that doesn’t mean every field, protocol capability or default behavior is identical. Before following a guide, check which core the client actually uses rather than relying on the app’s name.
“Protocol,” “transport” and “security settings” refer to different layers. A protocol defines how the two ends exchange proxy requests; transport determines how data travels; TLS and similar settings concern connection security. When troubleshooting a connection after import, check each setting against the server’s requirements. Simply changing the protocol name or enabling another feature usually won’t supply missing server parameters.
What the three GUI clients do
v2rayN is a desktop client with GUI tools for server lists, subscription groups, routing and system proxy settings. Its menus make many lower-level fields easier to manage, but available features still depend on the selected core, operating system and supporting components. The cross-platform desktop edition and classic WPF edition primarily differ in interface technology and supported platforms; the interface name alone doesn’t determine protocol compatibility.
v2rayNG is an Android client built on the Xray core; v2flyNG offers an alternative based on the V2Fly core. Android uses VpnService permissions to capture traffic, while desktop clients use different mechanisms such as system proxies and virtual interfaces. A share link that imports on multiple devices doesn’t mean permissions, background operation or app-level traffic settings can be copied over unchanged. Repeat the connection checks when switching platforms.
GPL-3.0 and component licenses
The v2rayN, v2rayNG and v2flyNG client projects are licensed under GPL-3.0. The license allows you to read, use, modify and distribute the code under its terms; distributing modified versions also comes with source-code and licensing obligations. The cores and other components used by a client may have separate licenses, so the client’s license shouldn’t be assumed to apply to every dependency.
Open-source licensing and remote service quality are separate matters. The client provides configuration and connection features; subscription content is maintained by its source, while server availability depends on remote settings, account status and network conditions. This page covers client selection and usage, not subscription accounts. To assess a connection issue clearly, check the software, configuration source and remote service separately.
Keep a working configuration before updating
Clients, cores and routing data may follow different release schedules. An interface update can move menus, a core update can change supported fields, and routing data changes can affect domain categories and route selection. Before updating, note your current traffic capture method, routing mode and custom DNS settings, and back up the client configuration. Keep subscription URLs secure; don’t share backup files publicly.
After updating, test the basic connection first, then check whether subscription groups and custom rules are still in place. If a new problem appears, note the exact error and steps that trigger it; don’t change the core, routing and DNS all at once. Downloads are organized by platform and architecture on the client page. The advanced guide explains how the settings work together, helping you find the right concepts even if the interface changes.
If a term is unfamiliar, start with the glossary to distinguish system proxy, TUN, DNS and routing, then check frequently asked questions for troubleshooting by symptom. If you need to manage multiple subscriptions or add a custom outbound, read the advanced guide. Avoid applying complex configurations during your first connection test.