From V2Ray to V2Fly and Xray
Project V is a good starting point for understanding the V2Ray ecosystem. V2Ray combines inbound connections, routing, outbound connections, and transport capabilities, making it more than a client for a single protocol. The server lists and toggles users interact with day to day usually belong to a graphical client layered on top. When someone says “V2Ray client,” first clarify whether they mean the interface, the runtime core, or the protocol used by a connection. These concepts are related, but they belong to different layers.
V2Fly continues community development of V2Ray, while Xray has evolved from related code into its own feature set. The two share configuration conventions but also differ in implementation and development. Similar-looking basic fields do not mean that every configuration can be used unchanged in either core. For VLESS, REALITY, transport extensions, or specific security options, check support in the core you actually run instead of relying on the client name alone.
What each of the three clients does
v2rayN is an open-source desktop client with a graphical interface for managing servers, updating subscriptions, choosing proxy modes, and configuring routing. v2rayNG is an open-source Android client that uses the Xray core; v2flyNG also targets Android and offers a V2Fly core. Choose a client based first on your operating system, then on the protocol features your connections need. Being able to import a configuration does not mean every field is supported.
A graphical client translates interface settings into a configuration for the core, so interface labels do not necessarily map one-to-one to native JSON fields. The core may support options that the graphical interface does not expose. For advanced settings, read the current client's documentation and check what the core fields mean. Following instructions for a different client's interface can lead you to mistake similar labels for identical features.
Open-source licensing and configuration responsibilities
Open source means code can be reviewed, used, and redistributed under the applicable license; it does not mean every related project uses the same license. Xray-core and V2Fly's V2Ray-core use MPL-2.0. Review the license terms for the client interface, core, and bundled components separately. When modifying, distributing, or integrating software, follow the relevant project's license text rather than relying on a blanket description of the ecosystem.
Open-source status does not remove the need to assess where a configuration comes from. The subscription publisher sets connection parameters, the remote server determines service availability, and the local client controls traffic entry and routing. For unfamiliar configurations, understand the routing destinations, DNS settings, and listening scope. In particular, do not expose a local proxy listener to other devices just to troubleshoot.
Update clients, cores, and rules separately
Client interface updates, core updates, and rule data updates affect different layers. An interface update may move menu items; a core update may change supported fields or runtime behavior; a rule data update may affect domain or IP collection matches. When troubleshooting a change after an update, identify which layer changed first, then compare connection parameters and routing results instead of blaming every issue on the server.
Keep the local settings you need before updating, then test the same app request that previously reproduced the issue. If you have many custom rules, check that specific rules still come before general ones. The download page provides client links, and the protocol reference explains design trade-offs. For the behavior of a particular field, consider the core currently running and its logs.
Read the protocol and core reference → Compare the three clients →