Desktop and mobile clients for Windows / macOS / Android / Linux
Organized around real-world configuration workflows, this guide covers free open-source clients, Xray and V2Fly cores, and subscription imports and routing rules, with verifiable steps from platform selection through connection testing.
Use v2rayN as the primary desktop entry point, then choose between v2rayNG and v2flyNG on Android based on core requirements. Each platform link opens the matching tab on the download page.
Choose either the cross-platform desktop edition of v2rayN or the classic WPF edition. The desktop edition suits users who want a consistent interface, while the WPF edition fits environments that prefer the traditional tray and window workflow.
v2rayN offers desktop packages for different processor architectures. Check your chip architecture in the system information before downloading, then use the matching entry to avoid installing an incompatible package.
v2rayNG uses the Xray core and suits configurations with VLESS, REALITY, and more. v2flyNG uses the V2Fly core and is an alternative client for users who prefer the native Project V implementation.
The v2rayN desktop edition supports common deb and rpm package formats, with entries for multiple processor architectures. Confirm your distribution's package system and device architecture before choosing the matching file.
Client usability depends on more than a successful installation. You should verify that subscription content parses correctly, routing rules match as expected, and the system proxy takes control of the intended applications.
In v2rayN, open subscription group settings, add a group name and subscription URL, save it, and update the current group. Groups are easier to maintain over time than pasting share links one by one: when server-side content changes, update only the relevant group instead of rebuilding every configuration. After importing, check that the client recognizes the entries and that protocol, address, port, and transport fields are present. If an update fails, avoid clicking repeatedly; check URL validity, update mode, format compatibility, and local network status in that order.
Routing rules match connections in their listed order, so more specific rules should come before the fallback rule. A common setup sends private addresses, mainland China IPs, and mainland China site domains through the direct outbound, while unmatched traffic goes through the proxy outbound. Here, direct and proxy are outbound tags, not button labels. After changing rules, reload the configuration and test destinations that meet different matching conditions. With sniffing enabled, the client can identify the target domain from the connection, allowing geosite rules to participate; the actual result still depends on the inbound protocol and the application's connection method.
{
"domain": ["geosite:cn"],
"outboundTag": "direct"
}
{
"ip": ["geoip:private", "geoip:cn"],
"outboundTag": "direct"
}Connection testing should cover four layers: the core, inbound port, system proxy, and application requests. First confirm that the Xray or V2Fly core starts, then check that the local SOCKS listening port matches the settings. Enable automatic system proxy configuration and verify that the target application actually uses it. If a browser works but other programs do not, the issue is usually the application's own proxy policy. If no applications can connect, inspect core logs, subscription fields, and transport parameters one by one. The warning log level preserves important anomalies without flooding the diagnosis with routine messages.
This quick workflow builds a basic configuration you can verify. On first use, avoid changing many advanced parameters at once. Establish a complete chain across subscriptions, routing, and the system proxy first, then adjust DNS, Mux, or more specific rules as needed.
Download the client for your operating system and processor architecture. After installation, open subscription group settings, enter a group name and valid subscription URL, then update the group. If you use a single share link, first confirm that the client supports the relevant protocol and transport combination. A successful import only means the configuration reached the client; it does not prove that the connection parameters work. Check the protocol, server address, port, transport layer, security layer, and core support.
For everyday use, start with rule mode: send private networks and traffic matching geosite or geoip conditions through direct, and use proxy for everything else. When all applications that respect the system proxy need to use the proxy outbound, switch to a global-related mode, while remembering that some applications may ignore system settings. v2rayN's “Automatically configure system proxy” writes the system proxy parameters; the local listening port is determined by the client inbound configuration. The two must correspond.
Select a configuration and start the client. First check that the core is running normally, then verify the system proxy status. When a connection fails, use warning or error messages to investigate DNS resolution, protocol fields, certificate dates, transport paths, and port conflicts. Do not change several parameters at once, or it will be difficult to identify the cause. A safer approach is to change one variable at a time, reconnect, and record the result until the problem can be reproduced clearly or the fix is confirmed.
Clients, cores, and protocols operate at different layers. Understanding each layer's role helps assess configuration compatibility and prevents graphical options from being confused with underlying protocol implementations.
Project V established a network tools ecosystem based on the V2Ray configuration model. Its central idea is to separate inbound, outbound, routing, DNS, policy, and transport settings into relatively independent modules, then connect them through rules. VMess was an early representative protocol; the ecosystem later expanded with VLESS, Trojan, Shadowsocks-compatible implementations, and multiple transport methods. Structures such as inbounds, outbounds, and routing in configuration files remain important entry points for understanding how these cores work.
V2Fly continues Project V's community maintenance direction, and V2Ray Core is often referred to as the v2fly core. It retains a modular configuration model while evolving around protocol support, transport components, routing resources, and cross-platform operation. v2flyNG uses this core family and suits Android users who need the V2Fly implementation path. Choosing V2Fly does not mean using only VMess; supported protocols depend on the client's built-in core and configuration fields.
Xray evolved from a closely related configuration system and offers more focused implementations around VLESS, XTLS, and REALITY. v2rayN and v2rayNG commonly use the Xray core, so the same subscription often has broadly similar field handling across these clients. However, system proxy behavior, VPN takeover, DNS handling, and background operation differ between desktop and mobile platforms. A shared core does not mean every setting is interchangeable.
The core parses configuration, establishes connections, applies routing, and handles data transport. The graphical client manages subscriptions, edits parameters, toggles the system proxy, displays logs, and manages the core process. When something fails, first determine whether the issue belongs to the interface or the core. For example, a subscription button that cannot parse content usually indicates a subscription format or client parsing issue; an invalid-field error after startup points more toward configuration structure or core compatibility; if only some applications fail, check the system proxy or the application's own settings.
v2rayN is a graphical client for Windows, macOS, and Linux that manages subscription groups, server configurations, routing rules, DNS, the system proxy, and cores such as Xray. The cross-platform desktop and Windows WPF editions differ in interface technology and tray behavior, but both center on importing configurations, selecting a server, choosing a proxy mode, and checking logs.
v2rayNG integrates the Xray core into an Android client. It can import common share links and subscription content, then route application traffic through the system-provided VPN interface. It suits mobile devices using VLESS, REALITY, VMess, Trojan, or Shadowsocks configurations; routing, per-app proxying, and DNS behavior should be configured with Android's system limitations in mind.
v2flyNG uses the V2Fly core and offers another open-source client option on Android. Its interface approach is similar to v2rayNG, but the underlying core family differs. If a subscription depends on Xray-specific fields, verify compatibility first. For configurations within V2Fly's supported range, follow the same import, connection, and log-checking workflow.
Related projects collaborate through public source code and open-source licenses, while clients and cores generally follow independent release schedules. Client updates may focus on the interface, subscription parsing, system integration, and compatibility; core updates may involve protocol implementations, routing resources, transport components, security fixes, and configuration fields. They do not always release in sync, so when investigating a new protocol or field, confirm both that the client can pass the configuration and that the core implements the required capability.
Configuration provided by subscription services also changes on its own schedule. Updating the client does not automatically fix an invalid subscription, and updating a subscription does not change local program capabilities. A clearer maintenance practice is to track client updates, core changes, and subscription edits separately, then identify which layer changed most recently when an issue appears. This reduces blind reinstalls and repeated configuration overwrites while preserving a path for rollback and diagnosis.
Actionable checks for protocol fundamentals, subscription failures, and platform permissions. Each article explains how parameters relate before presenting a practical troubleshooting sequence.
Starting with TLS handshake overhead, this article explains how REALITY handles handshakes, how XTLS Vision reduces repeated processing, and the conditions required for them to work together in the Xray core. It also distinguishes protocols, security layers, and flow-control parameters instead of judging performance by names alone.
Read the article →A practical order for checking URL validity, update methods, Base64 content, share-link formats, and client support. Learn why repeatedly clicking update rarely fixes format or compatibility issues, and how to distinguish network failures from parsing failures.
Read the article →Covers the allow-through process in Privacy & Security, quarantine handling, and checks for when the system proxy does not take effect. The steps distinguish app launch permissions from network proxy permissions, making it easier to identify which system layer generated the prompt.
Read the article →