Client downloads and setup guides
Browse three open-source clients, four platform downloads, and English setup steps, from subscription import to routing, DNS, and connection troubleshooting.
Start with your current platform, then choose a file by processor architecture and package format. v2rayN is the main desktop option; Android users can choose between v2rayNG and v2flyNG based on core requirements.
Windows users can choose the v2rayN desktop edition or the classic WPF edition. The desktop edition uses a cross-platform interface for a consistent workflow; the WPF edition keeps the traditional Windows layout, with system proxy, subscription groups, routing rules, and logs organized in the main window.
Go to downloadsmacOS uses the v2rayN desktop client, so check the device chip before downloading. Choose ARM64 for Apple silicon and x64 for Intel. After the first launch, import a subscription and manage connection status and the system proxy from the menu bar and main window.
Go to downloadsv2rayNG is the main Android choice. Based on the Xray core, it supports subscriptions, QR imports, per-app proxying, and common routing modes. Choose v2flyNG when a V2Fly core is required. Recent phones generally use arm64; choose the universal package when the architecture is unclear.
Go to downloadsOn the Linux desktop, use v2rayN and choose a deb or rpm package for your distribution. Debian and Ubuntu typically use deb, while Fedora and Rocky Linux typically use rpm; also distinguish x64 from ARM64. After installation, launch it from the desktop menu and import an existing subscription.
Go to downloadsClients offer many features, but daily use starts with four groups: subscriptions retrieve configuration, routing directs traffic, DNS resolves domains, and TUN handles apps that ignore the system proxy.
Subscription links retrieve server configurations in batches; they are not the client itself. After importing one, name its group, run a manual update, and confirm that the server list is populated. Manage multiple subscriptions in separate groups to prevent updates from overwriting one another. Name filters help narrow a long list by region, protocol, or purpose. When an update fails, check that the link is complete, the group is enabled, and the system clock is accurate instead of repeatedly reinstalling the client. This structure is easier to maintain and reduces accidental selection of outdated configurations.
Read about managing subscriptions →Routing rules are usually matched from top to bottom, and the first match decides whether traffic uses the proxy, connects directly, or is blocked. Put specific domain and app rules first, with broad fallback rules later. Before editing, define the goal: direct local-network addresses, send a domain through a specific outbound, or route an app through the proxy. Change one condition group at a time and reload the configuration after saving. Clear rule order is easier to explain and makes unexpected exits easier to diagnose than a simple global switch.
See routing rules in practice →If a connection succeeds but pages do not open, domains resolve to incorrect addresses, or results vary by network, check DNS and routing together. Assign different upstream resolvers to domain groups or use encrypted queries such as DoH. Keep resolution aligned with the traffic exit: use a suitable local resolver for direct domains, and avoid resolving proxy-bound domains through the wrong exit. Start with a default server and a few domain groups, then use logs to confirm which rule handled each request.
See DNS optimization methods →Browsers usually read the system proxy directly, but some apps, command-line tools, and games do not. TUN mode can help by using a virtual network interface to capture more system traffic and pass it to the routing rules. First confirm that the regular system proxy works, then address administrator permissions, the virtual adapter, and DNS capture. Changing several variables at once makes troubleshooting harder. TUN is not the default answer for every situation; when web access and common desktop apps work, keeping the system proxy is often simpler.
Read the TUN mode guide →Establish the basic path first, then add routing, DNS, and TUN one at a time. Each step has a clear result, making problems easier to locate.
Use v2rayN on Windows, macOS, and Linux desktops; Android users can start with v2rayNG and choose v2flyNG when a V2Fly core is needed. Before downloading, confirm the platform, processor architecture, and package format. After installation, open the main client window without changing advanced options. If the desktop shows a system-component prompt, follow the installation page instructions. On Android, approve the system network permission shown during the first connection.
The first launch only needs to confirm that the client opens normally and that menus and settings are accessible. Keep the default routing and DNS at this stage instead of changing many switches before importing a configuration.
Obtain the complete subscription link from your service provider, create a subscription group in the client, paste the link, and run an update. Afterward, confirm that the server list contains entries and select one as the active server. If the list is empty, check the copied link, group status, network, and system clock first. Do not paste a subscription address into a browser search box or combine links from different sources in one record.
A server name is only a label for identification; judge availability from the connection result and logs. For the first test, use one configuration and confirm basic access before comparing others, so frequent switching does not obscure the result.
Select a server and start the client. On desktop, enable the system proxy; on Android, complete the system network authorization. Open a familiar website and confirm that DNS resolution and page loading work. A running client only means that its process has started; not every app automatically reads the proxy. If the browser works but another program does not, check whether that program follows the system proxy before configuring an in-app proxy or enabling TUN.
When something fails, check in this order: whether the subscription has content, whether a server is selected, whether the system proxy is enabled, whether DNS returns a sensible result, and whether the expected routing rule matched. Following the chain is easier than switching several modes at once.
Understanding the roles of cores, protocols, and GUI clients prevents confusion between client names, core names, and server protocols.
Project V is an open-source technology ecosystem built around network proxy protocols and tools. Early V2Ray established the foundations for configuration structures, inbound and outbound models, routing, and combinations of transports. As the community evolved, V2Fly and Xray became common branches of the core family. Both continue the configuration-driven approach to traffic handling, while differing in protocol support, transport capabilities, configuration details, and release pace.
The core handles protocol parsing, connection establishment, route matching, DNS queries, and traffic forwarding. A graphical client organizes these capabilities into subscription management, server lists, system proxy controls, logs, and settings. Therefore, v2rayN, v2rayNG, and v2flyNG are not three unrelated protocol suites. They are client shells for different platforms and core choices; VMess, VLESS, Trojan, REALITY, and other imported configurations are ultimately processed by the selected core.
This layered structure also explains why the same subscription may expose slightly different settings in different clients: the subscription provides server parameters, the client parses and displays them, and the core determines the supported features. For import failures, check protocol fields and client support first. For routing problems after connection, focus on routing, DNS, and the active core rather than judging only by the client name.
The V2Fly-maintained core continues V2Ray's architecture, including inbound, outbound, routing, DNS, and transport settings. v2flyNG follows this core path and suits Android users who need the corresponding configuration compatibility.
The Xray core is common in combinations such as VLESS, XTLS Vision, and REALITY. v2rayN and v2rayNG generally provide graphical controls around Xray capabilities, while available options still depend on the configuration and client implementation.
For Windows, macOS, and Linux, it manages subscriptions, servers, the system proxy, routing rules, DNS, and TUN in one place. Similar workflows across desktop environments make the same setup process practical on multiple computers.
It supports QR, clipboard, and subscription imports, along with per-app proxying and system network authorization. The interface is organized around mobile connection flows, and common Xray configurations can be managed from the server list.
Also designed for Android, it differs mainly by following the V2Fly core path. Choose a client based on the protocols, transports, and core compatibility required by the subscription, not only on its interface name.
From mobile permissions and protocol fundamentals to DNS routing, each article focuses on a specific problem for continued reading after the basic connection works.
A practical look at three key v2rayNG settings on Android: the system network permission on first connection, battery exceptions to prevent background disconnects, and per-app traffic routing.
Read article →Starting with TLS handshakes and encryption overhead, this guide breaks down REALITY's handshake approach and how XTLS Vision reduces repeated processing, then explains the impact on latency and throughput.
Read article →Learn how to choose resolution paths by domain, specify upstream servers, configure encrypted DoH queries, and troubleshoot using both route matches and DNS results.
Read article →