Project V and its core families
Project V provides the broader context for related proxy tools and protocols, with V2Ray as one of its major projects. V2Fly continues V2Ray’s community development, while Xray has developed an independent feature set from related code. They share some history and configuration concepts, but they are not two interface names for the same core. A filename alone does not guarantee that their features are identical.
In this ecosystem, the core establishes connections and handles transport, security, routing, and DNS resolution. The graphical client organizes those capabilities into a settings interface. When an error occurs, first distinguish between “the interface can’t save the settings” and “the core can’t start.” The former may point to input formatting or a client configuration issue; the latter usually calls for checking core logs for unsupported fields or features.
What each of the three clients does
v2rayN, v2rayNG, and v2flyNG are all open-source graphical clients. v2rayN is for desktop platforms and manages subscriptions, routing, and different cores. v2rayNG uses the Xray core on Android, while v2flyNG offers an Android option based on V2Fly. These clients manage configuration and connections; installing one does not provide a working subscription source.
Open source means the project’s code is available under its applicable license. Use, modification, and redistribution must follow each license. A client and its core may use different licenses, so one label cannot describe every component. For everyday setup, focus on software from a clearly identified source, read release notes, and understand the network permissions the app requests.
Protocol names aren’t performance rankings
VMess, VLESS, Trojan, and Shadowsocks describe different protocol designs. REALITY is a security-layer option, so these are not all choices at the same level. Enter the protocol, transport, and security settings as a combination based on the server’s parameters. Simply changing VMess to VLESS or enabling a security option at random won’t create a working configuration.
Connection quality also depends on network path, server load, transport settings, and device resources; protocol names alone can’t predict speed or battery use. On mobile, background operation and traffic handling matter too. Choose for compatibility first, then compare performance under the same network and use conditions. For the reasoning behind each design, read the protocol guide.
Explore protocol and core options →
Handle subscription updates and software updates separately
Updating a subscription fetches configuration from its source again. Updating the client changes its interface and configuration management, and may also update the bundled core. These updates solve different problems: if a URL has expired, check with the subscription provider; if the core doesn’t support a feature, check software and core compatibility. Refreshing a group won’t add missing features, and upgrading the software won’t restore access revoked by the source.
Back up the configuration you need before making changes, and note your original routing mode, DNS, and proxy settings. After updating, test a known configuration before restoring custom settings one by one. If you need help, share the error type and the steps that triggered it. Keep full subscription URLs, share-link QR codes, user identifiers, and access credentials out of public screenshots.