Understanding the difference between projects, cores, and clients helps you assess configuration compatibility. Open-source licenses explain the terms for using code; connection results still depend on configuration and network conditions.
Project V and the role of clients
V2Ray grew out of the Project V proxy toolkit ecosystem, which organizes network connections through configurable inbounds, outbounds, and routing. Inbounds receive local requests, outbounds define how requests are sent, and routing connects match criteria to outbounds. Graphical clients organize these settings in an interface and manage subscriptions, generate configurations, start processes, and display logs. Seeing that the interface reports a successful start confirms only part of the startup process; check that requests actually reach the intended inbound.
“Client,” “core,” and “subscription” are not interchangeable terms. The client is the tool you use, the core handles protocol and transport logic, and the subscription is a configuration source. After installing a client, you still need a connection configuration that you are authorized to use and that works with the current core. The client does not provide a subscription source, and switching interfaces does not change server requirements. Understanding these roles helps you identify which part to investigate when something goes wrong.
How the V2Fly and Xray cores relate
V2Fly continues the community development and maintenance of V2Ray, while Xray emerged from the related code ecosystem. They share some concepts and protocol background but have distinct development goals and feature roadmaps. Similar JSON fields do not mean that every setting is interchangeable. Beyond the protocol name, check the transport, security settings, server capabilities, and whether the current core implements the features you need. REALITY involves security and transport capabilities; a protocol label alone cannot confirm that an entire configuration is compatible.
v2rayNG uses the Xray core, and v2flyNG uses the V2Fly core. v2rayN provides desktop graphical management and can use the appropriate core based on client options and configuration type. Choose a client by checking your configuration requirements first, then your platform and interface preferences. If a field is rejected, record the exact error and identify which core ecosystem the field belongs to. Renaming a subscription or configuration will not make an unsupported setting work.
The three clients and GPL-3.0
The v2rayN, v2rayNG, and v2flyNG client projects are licensed under GPL-3.0. Open source means the code can be reviewed, used, modified, and distributed under the license terms. Distribution of modified versions carries corresponding license obligations. Clients, cores, and other bundled components may have different licenses, so the license label for a client does not cover every component. Everyday users can start by understanding the client's open-source status; developers and distributors should read the applicable license text.
Open source is a transparent development model, not a guarantee of connection results. Check server availability, subscription validity, authentication settings, and whether the network allows the required transport. This site provides Chinese-language guidance on client selection and configuration; it does not assign subjective ratings or equate community maintenance with a fixed update schedule. To compare the three clients, look at specific differences in platforms, cores, and configuration support rather than inferring performance from their names.
Updates, backups, and configuration boundaries
Updating the client, the core, and a subscription are separate operations. A client update may change the interface, configuration generation, or runtime dependencies. A core update affects protocol implementation and supported fields. A subscription update fetches server configurations again from the source URL. Updating a subscription does not automatically fix the system proxy, and updating the app does not renew an expired subscription. When troubleshooting, note recent changes and check the relevant layer instead of updating everything at once and losing useful clues.
Back up subscription groups, custom routing rules, and configurations known to work before making changes. Backups may contain subscription URLs, authentication details, and server settings; keep them somewhere secure and never post them with public logs. When reporting an error, include field names, error types, and the steps taken, but hide sensitive values. A full subscription and a single shared configuration can grant different levels of access; treat both as potentially sensitive.
Routing also needs maintenance. Domain and IP categories depend on the data files used by the client, and changes to category contents can cause the same destination to match a different rule. Rule order, DNS policy, and the default outbound all affect the result. The routing panel above only illustrates the link between matches and outbounds; it is not a complete, ready-to-run configuration. For real use, define the corresponding tags in your outbound configuration and confirm which default outbound handles unmatched requests.