Project V and V2Fly
Project V is an open-source ecosystem of network proxy tools, including V2Ray, one of its core software projects. The V2Fly community continues development and documentation for V2Ray-related cores. In everyday conversation, “V2Ray” is also used loosely to refer to related clients, but v2rayN installed on a desktop is not itself a core. Knowing the difference makes it easier to understand what a guide means by “updating the client” versus “switching the core.”
Graphical clients typically manage subscriptions, server lists, routing templates, and system settings, then pass the resulting configuration to a core to run. A field shown in the interface does not by itself prove that the current core supports it. Check the selected core, server requirements, and configuration generated by the client. Recording all three is usually more useful during troubleshooting than replacing the whole setup.
Xray and V2Fly do not support exactly the same features
Xray is a separate core project that grew from related code. The two projects share some concepts but have evolved independently. Understand VMess, VLESS, transport, and security layers separately. REALITY is a security-related technology, not simply another standalone server protocol alongside all proxy protocols. Whether a configuration works depends on the specific combination, not just whether the client recognizes the share link.
For configurations involving XTLS or REALITY, check the requirements for the corresponding Xray implementation. Different cores are not guaranteed to handle every field, default, or behavior identically. When migrating, keep a working copy of your configuration, then test a connection known to be supported and check the logs for unknown fields, transport mismatches, or handshake errors. The configuration window shown here illustrates inbound and routing fields; it is not a complete, runnable configuration.
What the three open-source clients include
v2rayN is a desktop client with graphical server, subscription, and routing management. v2rayNG is for Android and is commonly distributed with the Xray core. v2flyNG offers an Android option based on the v2fly core. All three are open-source clients, but similar names do not mean their interfaces, core capabilities, or platform permissions are identical.
Open source means the code can be viewed, used, and redistributed under each project's license terms; it does not mean every component uses the same license. Treat the graphical interface, core, and routing data as separate components. A client is not a subscription service: installing software does not provide working servers. The provider determines a subscription's validity period, contents, and terms of use. Choose a client by first checking which protocols your configuration requires, then considering your platform and preferred workflow.
Updating the client, core, and subscription
Client updates mainly affect the interface, configuration management, and platform support. Core updates affect protocol implementation and runtime behavior. Subscription updates fetch server details from a remote source. These update different components. Reinstalling the interface usually will not fix an expired subscription, and repeatedly updating a subscription will not fix an interface problem. Identify the affected layer before choosing what to update.
Before updating, save any settings you need and note the selected core, routing mode, and local listening ports. After updating, test a basic connection before restoring custom rules and TUN. A subscription update may replace parameters from its source, so manage persistent manual settings separately from subscription groups. Subscription URLs, share links, and full configurations may contain access credentials; do not include them in public screenshots or troubleshooting reports.
Troubleshoot configuration in data-flow order
A connection can be traced through several stages: the app, inbound, routing, outbound, and remote server. If a browser does not use the system proxy, the issue is between the app and inbound. A port conflict is a local listener issue. Traffic sent to the wrong tag points to routing. A mismatch in remote parameters calls for checking outbound settings and the server. DNS can also affect name resolution and rule matching, so consider it from the start, not only at the end.
Change one variable at a time and keep logs from before and after each change. First confirm that the server configuration connects, then test routing rules, and finally configure transparent traffic capture. A website loading only proves that one request completed; it does not prove that every app, domain, or transport followed the expected route. To confirm what is happening, check client logs alongside the app's own proxy settings rather than relying on the tray icon alone.