Project V and its core families
Project V is an open-source ecosystem built around network proxy components, with V2Ray as one of its widely used core implementations. V2Fly continues community development of V2Ray, while Xray has developed its own core from related code. They share some configuration concepts, but protocol extensions, field support, and defaults can differ as each project evolves. Treating them as the same core can lead you to overlook compatibility when importing configurations or consulting documentation.
The core handles protocols, establishes transports, matches routing rules, and resolves domains. A graphical client organizes these capabilities into node lists, subscription groups, and settings screens. An option in the interface doesn't mean every available core interprets it the same way. When troubleshooting compatibility, note which client and core you're using, then check the documentation for the relevant fields. Don't infer the entire configuration from the beginning of a share link.
What the three clients do
v2rayN is an open-source graphical client for desktop systems, with node imports, subscription updates, routing management, and system proxy controls. It makes common settings easy to manage through the interface while leaving room for custom configurations. After switching cores or changing node types, recheck the generated transport and security settings. Saving a node entry doesn't mean the remote server supports its features.
v2rayNG is an open-source Android client that uses the Xray core; v2flyNG uses the V2Fly core as an alternative compatibility option. The apps may have similar interfaces, but that doesn't mean all extended fields are interchangeable. Choose based on your configuration requirements, then consider subscription format support, app-level routing, and background behavior. If you use the same subscription on desktop and mobile, configure local listening and system-level traffic handling separately on each device.
Open-source licenses and feature support
The V2Fly core is licensed under MIT, and the Xray core under MPL 2.0; clients and their dependencies have their own applicable licenses. Open source allows you to read, use, and modify code within the terms of its license, but doesn't mean every component follows the same release schedule. License information helps explain the conditions for using and distributing software; it doesn't replace checking specific features, runtime requirements, or configuration details.
A client is a connection tool; it doesn't provide a usable remote service on its own. You must supply the server address, authentication details, and related parameters. Example addresses on this page are for explaining fields, and routing snippets show matching logic only. When using examples to learn, distinguish structural examples from values that must be replaced with parameters from a service you already have. Don't mistake a demonstration configuration for a complete node.
Updates and configuration maintenance
The client interface, core, and routing data files can change independently. After a client update, some fields may be generated again; after a rules data update, the domains or addresses included in a category may change. Keep track of where configurations come from and which parts you've customized, and add clear notes to important rules. If behavior changes, compare the generated configuration and logs before deciding whether to revert a setting.
Subscriptions are useful for centrally updating remote parameters; backups should cover local settings. They aren't interchangeable: subscriptions may not include system proxy preferences, app-routing lists, or manually added routing rules. When moving between devices, keep reusable node details separate from device-specific listening, permissions, and startup settings. V2RayKit's configuration reference is organized by field, while its tutorials follow the setup process—choose whichever suits the issue you're working on.