Project V, V2Fly, and Xray
Project V is an open-source proxy ecosystem built around V2Ray, with core capabilities for protocols, transports, DNS, and routing. V2Fly continues V2Ray's community-led development; Xray has grown from related technical foundations into its own core with additional capabilities. The two have a shared background but differ in features and configuration, so they are more than just different names for the same thing.
Clients organize these capabilities in a graphical interface, making subscriptions, server lists, and common settings easier to manage. The core is what actually handles connections. So a link being recognized by the interface doesn't mean the selected core supports every parameter it contains. If a connection fails, check both the import result and the core logs.
Understand protocols, transports, and security layers separately. VMess, VLESS, Trojan, and Shadowsocks are protocol names commonly found in configurations; WebSocket and gRPC describe transport methods; TLS and REALITY relate to connection security. Whether a combination works depends on what both the server configuration and the client core support—not just the protocol label.
Open-source projects and the three clients
v2rayN manages desktop configurations, with downloads for Windows, macOS, and Linux. It suits users who want to manage subscriptions, switch servers, and adjust proxy and routing settings in one place. v2rayNG is for Android and follows the Xray core path; v2flyNG is also for Android, but uses the V2Fly core path. All three are open-source projects. Choose based on your device platform and configuration compatibility needs.
Open source means the code can be read, used, and maintained under the applicable license. Clients, cores, and bundled dependencies may use different licenses; refer to each project's license text for the specific terms. Free client software and subscription services are separate: the software's pricing does not determine a server provider's terms, quota, or expiration date.
This site organizes downloads and setup guides for these three clients. A client name is not a measure of connection quality: the experience also depends on server resources, network conditions, DNS, routing rules, and app behavior. To evaluate a setup, keep test conditions consistent, check the logs, and distinguish local configuration issues from remote service problems.
Configuration maintenance
Back up before updating
Client updates, core updates, subscription updates, and routing rule data updates are separate operations. The first two affect program behavior; subscription updates change server details; rule data updates affect domain and address classification. When something goes wrong, identify which layer changed most recently instead of resetting everything at once.
Before upgrading, save your current configuration and important settings, and read the release notes. After upgrading, test the same server and apps that worked before making other changes. Keep a record of settings you can refer back to, so you don't miss anything when restoring your setup.
Troubleshooting steps
Logs and specific symptoms
Break down “can't connect” into specific symptoms: did the subscription update fail, did the core fail to start, did DNS lookup fail, or did the connection drop after it was established? Note what happened, then check the relevant step. An incorrect system clock, port conflict, or expired server details can all cause similar connection failures.
Before sharing logs, remove subscription URLs, account details, and server credentials. The error type and essential context are usually enough. For common issues, see the FAQ. To learn the basics chapter by chapter, read the complete guide.