A download and configuration index for graphical clients, bringing together installation links for four platforms, subscription and routing steps, and the relationship between the Xray and V2Fly cores. Choose a client for your device first, then import a subscription, enable a server, and configure the system proxy.
From downloading to reliable daily use, the main differences are not the number of buttons but whether the client, configuration source, proxy mode, and routing rules match. The steps below follow a practical workflow and can be switched from the settings on the left.
For desktop systems, start with v2rayN, which covers Windows, macOS, and Linux. Subscription management, server lists, routing rules, and system proxy controls follow one workflow. On Android, choose between v2rayNG and v2flyNG: the former uses the Xray core and offers broad protocol and transport support, while the latter uses the V2Fly core and suits users already working with that configuration ecosystem. Base the choice on the operating system, processor architecture, and configuration compatibility; installing multiple overlapping clients is unnecessary.
The download page separates packages by platform and architecture, and explains the differences between the desktop build, classic interface, arm64, and universal packages. Confirm the device requirements before downloading to avoid mismatched package formats, incorrect architecture choices, or unrecognized configuration fields.
Subscription links retrieve and update server configurations in bulk, while a single link, QR code, or configuration file is better for temporarily importing one server. After adding a subscription, run an update and wait for the server list to be written locally before selecting the active entry. Adding a subscription without updating it is a common reason no servers appear. When multiple sources are in use, choose clear group names and keep the original subscription name so the scope of an update failure is easier to identify.
An update can overwrite server fields within the subscription-managed scope, and manually edited remarks or transport parameters may change after the next refresh. Save long-term custom configurations separately instead of mixing them with automatically updated subscription entries.
The system proxy mainly affects apps that follow the operating system proxy settings. TUN mode takes over more connections at the network-interface level and is useful for programs that ignore system proxies. Rule-based routing determines whether traffic for different domains, address ranges, and applications goes direct, through the proxy, or is blocked. These features operate at different layers, so selecting a server does not mean every program is connected. For a first setup, verify basic connectivity with the system proxy, then decide whether to enable TUN and finally adjust routing rules.
Record the current settings before changing modes, and change only one variable at a time. If websites work but a particular program cannot connect, LAN devices behave unexpectedly, or DNS results change, this makes it easier to determine whether the difference comes from connection takeover or routing rules.
When a connection fails, first confirm that an active server is selected and the subscription is up to date. Then check the client log for protocol fields, address, port, and transport-parameter warnings. Next verify that the local listening port is not occupied, the system proxy state matches the client, and the firewall allows the program to connect. If the issue occurs only in TUN mode, check driver permissions, DNS settings, and routing rules instead of repeatedly importing the same subscription.
A latency test reflects only part of a route under a specific test method and cannot replace a real connection check. When sorting servers, distinguish Ping, real-connection latency, and download speed tests, then consider actual web access, file transfers, and application sessions.
v2rayN, v2rayNG, and v2flyNG are graphical clients for configuration editing, subscription management, server switching, system proxy control, and log viewing. Xray and V2Fly belong to the core processing layer and handle protocols, transports, routing, and connection execution. To assess compatibility, check both whether the client exposes the required settings and whether the selected core understands the relevant fields.
When subscriptions, servers, proxy modes, DNS, and routing rules all change together, connection differences are difficult to isolate. A safer order is to confirm that the client starts, import the configuration and select a server, verify the system proxy, then add TUN or custom rules. Keep a rollback point at each step so log messages remain easier to interpret.
The homepage provides a platform index rather than distributing installation files directly. On the download page, choose an entry based on the operating system, processor architecture, and package type.
Windows users can choose between the newer cross-platform desktop interface and the classic WPF interface. Both organize server lists, subscription updates, system proxy controls, and routing settings for desktop environments that manage multiple configuration sources graphically.
On the download page, choose the desktop or classic build based on your interface preference; before installing, confirm the system architecture and permission policy.
Go to DownloadsThe macOS entries are split between Apple Silicon and Intel processors. The client follows the desktop configuration workflow, bringing subscriptions, servers, system proxy controls, and routing settings together for users who want a similar experience across desktop systems.
If you are unsure which chip you have, check the processor or chip name in System Information before selecting the matching disk image.
Go to DownloadsAndroid offers two client paths: v2rayNG uses the Xray core and suits configurations requiring broad protocol and transport support, while v2flyNG uses the V2Fly core as an alternative for that ecosystem. Both support subscription import, QR-code scanning, and server switching.
Most newer mainstream devices should start with the arm64 package; if the architecture is unclear, read the universal-package guidance on the download page.
Go to DownloadsThe Linux download page provides deb and rpm packages for common package systems, further divided into x64 and arm64 builds. The graphical client suits desktop users who want to manage subscriptions, servers, and the system proxy through an interface while retaining access to logs.
Confirm your distribution's package system first, then use system architecture commands or system information to choose the matching build.
Go to DownloadsThese names often appear together in configuration documentation, but they represent different ecosystem concepts, core families, and graphical clients. Understanding the layers is more useful than simply memorizing product names when assessing protocol support and configuration compatibility.
Project V established an open technology ecosystem centered on proxy protocols, transport methods, routing rules, and configuration structures. Early users often used V2Ray as a name for the broader system, but installation typically involves three layers: the graphical client, the core program, and configuration files. The client handles the interface and system integration, the core executes connections and routing, and the configuration describes the parameters both must read. Once these layers are separated, terms such as “client update,” “core update,” and “configuration format change” become easier to distinguish.
V2Fly continues the core implementation and configuration ideas of the Project V ecosystem, emphasizing open collaboration, protocol implementation, and routing capabilities. Xray extends protocol and transport support within a similar configuration model, so many basic fields are understood by both, while newer features, transport details, and specific parameters may be supported by only one core. Compatibility cannot be judged from a shared-link prefix alone; also confirm which core the client is calling and whether the target fields fall within its capabilities.
v2rayN is a graphical desktop client for Windows, macOS, and Linux. v2rayNG targets Android and uses the Xray core, while v2flyNG also targets Android but uses the V2Fly core. Clients turn tasks that once required editing configuration files into subscription groups, server lists, routing modes, system proxy controls, and log views. A graphical interface lowers the cost of daily management but does not change the underlying protocol requirements: addresses, ports, identifiers, transports, security settings, and domains must still match the server configuration.
These clients and cores collaborate through open-source development, with each project using its own software license. Open development allows protocol implementations, bug fixes, platform adaptations, and interface changes to be reviewed continuously, while different clients can build their own workflows around similar configuration models. For everyday users, the practical benefits are clearer release notes, a better understanding of whether a feature comes from the client or the core, and a way to assess configuration-field or system-permission changes before upgrading.
Client upgrades commonly affect the interface, installation method, system proxy integration, and how the core is packaged. Core upgrades are more likely to affect protocol implementation, transport features, routing rules, or configuration parsing, while subscription updates mainly change server entries. When connectivity changes after an upgrade, first identify which layer changed. If only the subscription changed, reinstalling the client usually will not help; if the log reports an unknown field, check core capabilities; if the program will not start or the system proxy was not written, check client permissions and platform dependencies.
VMess, VLESS, Trojan, Shadowsocks, and other protocols can appear across different cores and clients, but REALITY, transport options, fingerprint fields, and routing expressions may vary in capability. When an import fails, check the active core, the client's configuration controls, and the configuration source rather than comparing only server names.
Client and core release cycles are not always synchronized. Before upgrading, record the current proxy mode, core selection, subscription group, and custom routes. After the upgrade, verify the existing configuration before enabling new features. This separates program-upgrade issues from configuration changes.
The site focuses on downloading, installation, subscription import, server activation, system proxy, TUN mode, traffic routing, and troubleshooting. Protocol sections support client selection by explaining design trade-offs, resource use, core support, and subscription compatibility.
Adding a subscription URL only saves the configuration source; you must also run a subscription update. After updating, check the current group, filters, and log messages. If the list is still empty, confirm that the URL is reachable and that its response can be parsed by the current client. See the FAQ for more steps.
Selecting a server only identifies the current endpoint; you must also enable a takeover method that suits the app. Browsers can usually use the system proxy, while programs that ignore it may require TUN mode. Start with Quick Start for basic verification before expanding the scope of traffic takeover.
Choose based first on the core capabilities required by the configuration. v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. If the configuration source requires a specific core or field, keep them aligned. For ordinary subscriptions, check the provider's stated protocol and transport types.
Not necessarily. Ping, real-connection latency, and download-speed tests cover different paths and use different methods, so their results may conflict. When choosing a server for daily use, consider real-connection tests, web response times, and sustained transfer performance.
The article section adds operational details that the homepage cannot cover, focusing on server evaluation, core ecosystems, and configuration management across devices.
Learn how to weigh latency, traffic multipliers, exit regions, and protocol types, and why a single value in a server list cannot replace real connection testing.
Read the full article →Map the relationship between Project V, V2Fly, and Xray by ecosystem layer, and clarify whether v2rayN, v2rayNG, and v2flyNG belong to the client layer or the core layer.
Read the full article →Compare unified subscription updates, configuration-file export and import, and QR-code sharing, including cross-platform field compatibility, update overwrites, and how to preserve manual settings.
Read the full article →