Project V and V2Ray: how they relate
Project V is the project behind a set of tools and components for network communications; V2Ray is one of its best-known core names. The core accepts connections, parses protocols, matches routing rules, and establishes outbound connections. A GUI client organizes these capabilities into settings people can use. So “installing V2Ray” often means installing a client that manages the core. If you have a question about a menu or subscription, first identify the client you are using rather than searching for a button based only on the name V2Ray.
This layered architecture explains why the same technical documentation may need instructions for different interfaces. Core documentation covers which fields are valid; client documentation explains how the interface generates those fields. They address different problems. A client can choose a core, generate configuration, and start a process, but that does not make every feature consistent across different cores. This site covers first-time installation and common tasks in the usage guides, and documents raw fields and their dependencies in the configuration reference, so you can find help at the right layer.
How V2Fly and Xray relate
V2Fly is an important part of the V2Ray community's ongoing development, while Xray is a core fork developed from related code. They share some history and configuration concepts, but their protocol implementations, transport capabilities, and field requirements continue to evolve independently. When reading JSON examples, start with shared structures such as inbounds, outbounds, and routing to understand their roles, then check whether the current core supports each field. Shared root object names do not mean their options are interchangeable.
Choose a core based on the requirements of your existing configuration, not on assumptions about performance from a branch name. The protocol, security layer, and transport required by the server must all be supported by the client core. If any are missing, saving the entry in the interface does not mean it will connect. For branch-specific features, consult the relevant documentation and note which core is actually running. When compatibility issues arise, distinguish between an unrecognized field and a recognized parameter that still fails to connect; this helps avoid unnecessary changes.
What the three open-source clients do
v2rayN is a desktop client for Windows, macOS, and Linux, with tools for managing servers, subscription groups, the system proxy, and routing. Available core options depend on the client. v2rayNG is for Android and uses the Xray core; v2flyNG is also for Android and uses the V2Fly core. All three are open-source clients, but their interfaces, permission models, and configuration storage differ. Desktop screenshots are not a reliable guide to Android menus. When migrating, check the connection parameters rather than copying the entire working directory.
Open source means the implementation and licensing terms can be reviewed; it does not remove the need to check configuration compatibility. The client, core, and data files used at runtime may each have different open-source licenses. V2Fly's v2ray-core is licensed under MIT, while Xray-core is licensed under MPL-2.0. Check the relevant license texts separately for redistribution requirements covering the client and its dependencies. Focus on the source, feature set, and configuration compatibility rather than assuming every component has the same terms because it is labeled open source.
Client, core, and subscription updates
Client updates may change the interface and configuration generation; core updates may change protocol implementations and field requirements; subscription updates mainly refresh remote server information. These updates affect different things. An updated subscription does not mean the app itself was updated, and updating the client will not automatically fix an expired subscription URL. Before updating, note your current settings and export any configurations you need. Afterward, check startup logs, core selection, and routing data loading, then test with an actual app request.
The downloads page brings together platform links and installation instructions. The homepage keeps stable usage guidance rather than pinning client version details. To troubleshoot configuration issues, consider the installed client, the core currently running, and the server requirements. JSON snippets in the documentation illustrate structure; defaults, generation behavior, and supported fields in your environment still need to be checked. With these boundaries in mind, installation, migration, and troubleshooting can focus on a specific component instead of trial and error across multiple settings pages.