OPEN-SOURCE ECOSYSTEM / PROJECT & CORE
Project V, V2Fly, and Xray
First, distinguish the project ecosystem, proxy core, and graphical client. Similar names don't mean configurations are interchangeable, and support for the same protocol doesn't guarantee identical support for every extended field.
EcosystemProject V / V2Ray
Graphical clientv2rayN · v2rayNG · v2flyNG
Project history and roles
Project V is an open-source ecosystem built around network proxy tools, with V2Ray as one of its major projects. As the ecosystem developed, the V2Fly community continued maintaining related cores, while Xray followed a separate path of core development. Graphical clients build on these capabilities to provide subscription management, server selection, and settings. The client controls the buttons and interface, but the background core typically establishes connections and applies routing rules. An interface update doesn't necessarily mean protocol support has changed.
Core families and protocol support
VMess, VLESS, and Trojan are common protocol names in connection settings. REALITY is a security-related mechanism, not a standalone client. A configuration may also include a transport, server name, and other handshake parameters. To troubleshoot incompatibility, check whether the client can generate the required fields, the selected core can read them, and the remote server uses matching settings. Successfully importing a subscription doesn't guarantee that every protocol combination will work.
Open-source licensing for the three clients
v2rayN, v2rayNG, and v2flyNG are available as open-source client projects and are free to use. v2rayN targets desktop systems and is suited to managing subscriptions and routing in one place. v2rayNG is primarily used with Xray configurations, while v2flyNG offers a mobile option for the V2Fly ecosystem. Open source means the code is available to inspect and use under the applicable license; it doesn't mean every component shares the same license. V2Fly and Xray cores typically use MPL 2.0. Each client and its dependencies are governed by their respective project licenses.
Updates and preserving settings
Clients, cores, subscription contents, and geosite and geoip data all have separate update schedules. Updating a subscription refreshes server configurations; it doesn't upgrade the app. Updating rule data doesn't replace the core. When something goes wrong, identify which layer needs updating and record your current settings and custom rules. After an upgrade, retest the same scenarios, paying particular attention to routing order, listening ports, and protocol compatibility. Keeping configuration notes you can refer back to is more effective than updating everything at once and guessing what caused a change.