How Project V, Cores, and Clients Fit Together
Many configuration problems become much easier once the core, graphical interface, and subscription service are understood separately. They belong to different layers: their names may be related, but their responsibilities are not the same.
PROJECT V
Project V provides the ecosystem foundation
Project V established a composable set of network proxy tools and configuration models. A typical configuration contains inbound, outbound, routing, DNS, and transport settings: inbound accepts traffic from local applications, outbound determines how traffic leaves, routing sends different targets to designated exits, and DNS provides domain-resolution results. Graphical clients turn these structures into menus, switches, and subscription groups, so everyday use does not require starting with an empty configuration file.
This layer matters because “system proxy,” “routing mode,” and “remote DNS” in a client interface are not unrelated features. They ultimately become configuration that the core can read. When a connection fails, identify whether the issue occurred while saving the interface settings, generating the configuration, starting the core, or reaching the network exit instead of blaming every problem on the node.
CORE FAMILIES
V2Fly and Xray are two core families
V2Fly continues Project V’s community implementation and configuration model, while Xray maintains its own feature set around a similar configuration approach. Both can handle common inbound, outbound, routing, and DNS tasks and support multiple transport combinations, but their fields, feature boundaries, and release schedules may differ. Before copying a configuration, confirm which core the target client uses; identical node names do not mean every option is interchangeable.
VMess, VLESS, and Trojan describe protocols or configuration methods; V2Fly and Xray describe the core families that execute the configuration; v2rayN, v2rayNG, and v2flyNG are the clients users operate directly. Keeping these three layers separate prevents protocol capabilities, core capabilities, and interface features from being treated as one concept.
CLIENT LAYER
Three clients, three platform entry points
v2rayN is a graphical desktop client for Windows, macOS, and Linux. It handles subscription management, node switching, system proxy, TUN, routing templates, and log viewing. It is not a new protocol; it organizes core configuration in a desktop interface. Each desktop system has different permissions and proxy settings, so enabling the same option can vary by platform.
v2rayNG targets Android and is commonly paired with the Xray core; v2flyNG also targets Android, with the core family as the main reason to choose it. Both can import subscriptions and individual node configurations, and both capture application traffic through the system’s local VPN interface. Choose based on the subscription content and required core capabilities rather than the interface name alone.
LICENSE & MAINTENANCE
Review open-source licenses and release cadence separately
Clients and cores are maintained by different projects, each with its own open-source license, release cadence, and compatibility range. Open source means the code, license boundaries, and change history can be reviewed publicly; it does not mean every component updates on the same day. A client release also needs interface adaptation, core integration, and platform packaging, so a delay between client and core updates is normal.
You do not need to chase every change in daily use. Upgrade after reviewing release notes when there is a protocol-compatibility issue, an operating-system upgrade, or a known bug. Before upgrading, record the current subscription groups, routing mode, and DNS settings. Afterward, verify the basic connection first, then restore custom rules. This separates changes caused by the update from problems in the original configuration.