PROJECT V / V2FLY / XRAY
Understand the difference between open-source cores and GUI clients
Downloading a client gives you software to install and manage. The core determines configuration capabilities, and server details must be imported before a connection can be established. Check each of these three steps separately.
Project V and the core ecosystem
Project V is an ecosystem of network proxy tools and related capabilities, with V2Ray as a key component. The V2Fly community continues development and maintenance of the V2Ray core, while Xray has evolved from related technical foundations along its own path, with its own core and features. They share some protocol concepts and configuration conventions, but they aren’t different interfaces for the same program. When comparing V2Ray cores, consider supported protocols, transport combinations, configuration fields, and client integration together.
The core reads configuration, accepts inbound connections, matches routes, and establishes outbounds. A GUI client converts subscriptions and settings into a configuration the core can use, and provides controls for starting and stopping it, viewing logs, and integrating with the system. Similar names don’t mean clients use identical cores; one client may also support multiple cores. Checking the core that actually started and its logs is more reliable than judging compatibility by the app’s name.
Protocol names describe how the two ends of a connection exchange data; transport describes the channel that carries it, and security parameters affect the handshake and authentication. When you import a share link, the client parses these fields but doesn’t fill in configuration missing from the server. If a connection fails, check the server address, port, time, and handshake parameters first, then consider whether the core supports the configuration. Don’t assume every error is caused by the software installation.
Choose from three open-source clients by device
v2rayN is designed for desktop use, with subscription management, routing settings, and support for multiple cores. The desktop edition uses a cross-platform interface; the classic WPF edition offers a different desktop interface and workflow. Choose based on your operating system, architecture, and interface needs. Don’t install both editions in the same directory just because they share a name. Back up subscription groups, routes, and custom settings before upgrading or migrating to avoid losing your setup.
v2rayNG is designed for Android and uses the Xray core for its primary connection capabilities, receiving app traffic through the system VPN interface. v2flyNG is an alternative client that uses the V2Fly core. Their interfaces and import workflows may look similar, but check core support separately. Before choosing a mobile client, confirm that the server configuration is compatible with its core, then check per-app proxy settings, background operation, and battery policies. A client’s name doesn’t guarantee a successful connection.
All three clients come from open-source projects. Open source means the source code and applicable licenses are available for review; it doesn’t mean every modified build comes from the same source. When reviewing licenses, distinguish the client from its integrated core: the V2Ray core uses the MIT License, while the Xray core uses the MPL-2.0 License. Each client also has its own licensing terms. Check the applicable terms separately before modifying or distributing software.
Manage software, subscription, and rule updates separately
Software updates change what the client or core can do; subscription updates refresh server details; rule resource updates affect domain and address matching. These are different kinds of updates. Reinstalling the client usually won’t fix an expired subscription URL. A routing rule that doesn’t match doesn’t necessarily indicate a server problem; the cause may be classification resources, rule order, or how the target domain is identified. First determine what needs updating, then use the appropriate update option.
Before enabling automatic subscription updates, verify the full process manually. Confirm that the URL is reachable, the content is recognized, and group filters are correct; then set an interval based on how often the source actually changes. Whether to update through a proxy depends on whether the current network can reach the subscription URL. Don’t make updates depend on a connection that isn’t working. Repeated refreshes won’t fix certificate errors; check the system clock and the specific error instead.
After changing a core or rule resources, keep a fixed set of test targets: one domain expected to connect directly, one expected to use the proxy, and a LAN resource you actually need. Check the logs to see whether each matches the expected rule. Confirm the results before changing DNS or enabling TUN to reduce interactions between variables. Before exporting configuration or sharing screenshots, remove server identifying details, subscription credentials, and other private information that isn’t relevant to troubleshooting.
Follow the connection path through the handbook and logs
The system proxy provides an entry point only to apps that choose to read that setting; it doesn’t force every program to use the same path. Routing rules determine the outbound after traffic reaches the core, so “global proxy” and “all apps are covered” aren’t the same thing. If a browser works but another program doesn’t, first check whether it uses the system proxy or needs a local proxy address entered separately. Consider TUN takeover only after that, rather than repeatedly changing rules at the wrong layer.
DNS issues also depend on where resolution happens. An app may use the system resolver to get an address, while the core may resolve domains when matching routes or establishing connections. An address in the logs doesn’t mean the original domain was preserved; enabling traffic sniffing doesn’t mean every connection’s domain can be recovered. For domain-based routing, check how the inbound, resolution path, and sniffing settings work together. Read FakeDNS configuration alongside the traffic takeover scope; changing just one resolver address isn’t enough.
When reading error logs, note the time, target, and error type, then identify whether the failure occurred during resolution, connection, handshake, or routing. A connection timeout and a certificate error need different remedies; a core that won’t start is a separate problem from a target you can’t reach. The complete setup is in Quick Start, while combined configurations are covered in the advanced handbook. To identify the layer where a problem occurs, follow the checks in FAQ categories, then return to the relevant settings page.