Project V / V2Fly / Xray
Where cores and clients differ
The client interface, proxy core, and remote service are three separate components. Open-source describes how code and licensing are made available; a working connection also depends on local settings, network paths, and server status. Knowing what each layer does helps you update and troubleshoot the right component.
01 / Project V
From a toolkit to a configuration system
Project V focuses on networking tools, and V2Ray is one of its widely used proxy software projects. V2Ray is not the name of a single transport protocol; it is a configuration system for organizing inbounds, outbounds, routing, and DNS. In everyday use, “V2Ray client” usually means a graphical app that generates these configurations and launches a core. Understanding this distinction helps avoid treating a toggle in one interface as a capability shared by every core.
A connection typically enters through a local inbound, is assigned an outbound by routing, and then communicates with the remote server using the relevant protocol. Server lists manage connection parameters, the system proxy provides a traffic entry point, and routing modes determine where traffic goes. All three can affect the experience, but they are not interchangeable. When troubleshooting, first check whether the request reaches the client, then whether it matches the expected outbound, and finally whether the remote handshake succeeds. This makes the diagnostic sequence clearer.
02 / V2Fly · Xray
Different cores in the same ecosystem
V2Fly continues community maintenance of V2Ray, while Xray has developed a separate core based on related technology. They share many configuration concepts, but their feature sets and field details are not identical. A client recognizing a shared link does not guarantee that the current core supports every parameter it contains. For specific security mechanisms, flow control, and newer transport combinations, check both the client's import support and the core actually running.
v2rayNG is based on the Xray core, while v2flyNG offers an Android option with the V2Fly core. v2rayN uses a desktop interface to manage servers, rules, and core runtime parameters; available options depend on the distribution and configuration. When switching cores, keep the original parameters and compare the generated configurations. Do not keep changing cores just because a connection fails: a wrong address, time, port, or TLS name usually will not be corrected automatically by another core.
03 / Open source
Open-source code and licensing
v2rayN, v2rayNG, and v2flyNG are open-source client projects. The V2Fly and Xray cores use the MPL 2.0 license; check the individual licenses for graphical clients and bundled components. Open source provides a public basis for reviewing implementations, modifying code, and discussing issues, but suitability for your device still depends on system requirements and real-world testing. Distributing apps, modifying code, and republishing components are subject to their respective license terms; these projects should not all be treated as if they had the same license.
For everyday use, pay close attention to configuration and permission boundaries. Subscription URLs may contain access credentials, share links may include user identifiers, and logs may record destinations. Before sending troubleshooting information to someone else, remove these details and keep only the error type, sequence of events, and necessary fields. Open-source status does not change your trust relationship with a remote service or replace the need to assess subscription sources. Installing a client and choosing a service source are separate decisions.
04 / Configuration maintenance
Updating the interface, core, and rule data
Client, core, subscription, and rule data updates each affect different things. A client update may change menus and how configurations are generated; a core update changes protocol implementation and runtime behavior; a subscription update refreshes remote server parameters; and a rule data update affects matches against categories such as geosite and geoip. A successful subscription update does not mean the client is up to date, and installing a new client does not make an expired subscription valid again.
Save your current configuration before updating, especially custom routing, DNS, listening ports, and per-app settings. After the update, verify the basic connection in its original mode before testing additional features. If only one rule behaves differently, check the data set and rule order; if no servers start, inspect the core startup logs first. Change one layer at a time. This usually preserves more evidence than resetting everything and makes it easier to return to a known working state.
05 / Reading path
From installation steps to configuration guides
For your first setup, follow the guide to install the client, import a subscription, choose a server, and verify the connection. Once the basic route works, use the glossary to distinguish system proxy, global routing, TUN, and DNS. “Global proxy” usually refers to a routing policy; it does not mean every app sends traffic to the client. Conversely, a virtual network adapter can capture traffic while rules still send some destinations direct. Keeping these two dimensions separate makes it easier to describe the current network state accurately.
If you already have a working configuration, there is no need to rewrite everything just to match an example. Start with one clear goal, such as keeping LAN traffic direct, adding an exception for a domain, or organizing multiple subscription sources. Record the behavior before and after each change, then check the logs. The configuration snippets on this site explain fields and relationships; a complete working setup also needs the appropriate inbounds, outbounds, authentication parameters, and data files. Copying a fragment of JSON is not a substitute for a complete client configuration.