Project relationships: shared history, separate development
Project V's suite of network communication tools includes V2Ray as a core project. V2Fly continues community maintenance and development of V2Ray; Xray originated from V2Ray and has since followed its own independent development path. “V2Ray client” is often used informally for graphical tools across this ecosystem. It doesn't mean they all use the same core or support identical configuration fields.
When following a guide, identify the client first, then check which core it uses. If the server requires a particular protocol, transport, or security setting, confirm that the core supports it before entering the values. For configurations involving VLESS and REALITY in particular, verify core capabilities and server parameters; changing field names at random won't make them compatible. Importing a subscription only passes parameters to the client—the core still needs to support them.
Three Clients: Interface Management and Core Execution
v2rayN is an open-source graphical client for desktop platforms, with server management, subscription updates, routing, and proxy settings. Available cores and features depend on the package and current configuration. v2rayNG is an open-source Android client that uses the Xray core; v2flyNG is also for Android and uses the V2Fly core, making it suitable for configurations that require it. Choose based on your device platform and parameter compatibility.
None of these three tools is a subscription service. Client downloads, subscription access, and remote service availability are separate things. Switching clients won't extend a subscription or change server-side data or connection limits. If no servers appear after a subscription update, check the group URL and update result first. If servers are listed but connections fail, check the selected configuration, protocol parameters, and logs. Narrowing down the problem to one layer is more effective than repeatedly importing the same URL.
Open-Source Licensing: Understand the Client and Core Separately
Open source means the code is available under the applicable license; use, modification, and distribution must still comply with its terms. The V2Ray core maintained by V2Fly uses the MIT License, while Xray-core uses MPL-2.0. Clients have their own license terms, so a core's license does not automatically cover the entire installer and its dependencies. If you plan to redistribute or modify software, review the licenses for the client, core, and bundled components separately.
Community maintenance enables ongoing bug fixes and feature development, but open-source status doesn't replace configuration checks. Subscription URLs often contain access credentials; hide the full URL, user identifiers, and other sensitive parameters before sharing screenshots. When asking for help, include the menu path, error type, and steps you've tried rather than posting a complete configuration with credentials. Sample URLs on this site only illustrate field formats and are not usable services.
Update Types: Subscriptions, Clients, and Rule Data
Updating a subscription retrieves server configurations; updating the client changes its graphical interface and bundled components; updating routing data affects domain or address matching. These actions modify different things. When troubleshooting a connection, don't run all three updates at once or it will be hard to tell whether the cause was a remote configuration change, a change in core behavior, or a different routing result. Keep your current configuration and note the error first, then choose the update that addresses the problem.
Before upgrading the client, close any running instances and back up subscription groups and custom routing rules. After upgrading, test a server that worked previously before trying new features. Set the subscription auto-update interval to suit your usage and provider's requirements. Frequent requests don't necessarily improve availability and may trigger rate limits. If a subscription URL has expired, changing the interval won't fix it; address the URL itself first.
Connection Checks: Separate Test Results from App Behavior
A successful server test doesn't mean every app is using the proxy. First verify the destination in a browser, then check the client logs for the corresponding connection, and finally confirm that routing chose the expected outbound route. A real connection test, TCPing, and loading a webpage check different parts of the connection, so one test number can't tell you whether the entire path is working. Network changes, DNS caches, and the destination site's status can also affect results.
If only one app fails, check its proxy options and traffic coverage first. If all apps fail, check whether the core is running, a server is selected, and the local port is listening. Even when you want global proxying, distinguish between routing app traffic into the proxy and sending traffic that has entered through a proxy outbound. System proxy or TUN usually controls the former; routing rules control the latter. For setup steps, see Getting Started. Check the platform guide for permission differences.