Choose v2rayN, v2rayNG, or v2flyNG for your device, then complete the steps for importing subscriptions, selecting servers, and configuring routing. The guide also clarifies feature boundaries between desktop and Android clients, so you can choose the right software and core before installing.
The complete client, subscription, and routing workflow
Using V2Ray involves more than installation. The client manages configuration, subscriptions provide server groups, routing determines where traffic goes, and the core handles protocols, DNS, and connections. Understanding these layers makes it easier to identify whether a problem belongs to a client option, subscription content, or core configuration.
01 / CLIENT
v2rayN · v2rayNG · v2flyNG
Choose a client by platform first
Desktop access for Windows, macOS, and Linux centers on v2rayN. It brings subscription updates, server lists, system proxy settings, routing rules, logs, and core management into one graphical interface, making it suitable for maintaining multiple configurations on a desktop. The Windows page offers both a modern desktop interface and the classic WPF interface for different workflows; macOS packages are selected by processor architecture, while Linux packages are chosen by distribution format.
On Android, choose between v2rayNG and v2flyNG. v2rayNG uses the Xray core and suits configurations built around Xray protocols and features; v2flyNG uses the V2Fly core and is an alternative when that ecosystem is required. The basic workflow is similar in both apps: import a subscription or sharing link, choose a server, start the connection, and verify actual network access. The main differences concern core support and some advanced fields, not button placement.
When choosing a client, check more than the operating system. Confirm the processor architecture, package format, and core required by your configuration. The download page places these details beside each platform card, keeping package selection connected to later setup. For a first installation, complete the standard install and subscription import before enabling TUN, FakeDNS, or custom outbounds; troubleshooting is clearer that way.
A subscription URL usually returns an updateable set of server configurations. A single sharing link describes one node, while a local configuration file may include inbound, outbound, DNS, and routing rules. All three can be added to a client, but they are managed differently. Subscriptions suit server groups maintained by a provider; individual links work well for temporary additions or isolated tests; local configurations suit users who need precise field control and understand the core configuration structure.
After importing subscriptions into v2rayN, assign clear group names to each source, then update and check whether the server list is populated. With multiple subscriptions, separate groups by purpose so test servers, long-term servers, and temporary configurations do not become one mixed list. Updates generally overwrite entries generated by that subscription, so save important manual changes separately rather than relying on temporary edits to subscription entries.
A successful import does not mean a connection has been established. Select a specific server and enable the system proxy or TUN mode according to the scope of use. If the list is empty after an update, first check whether the client recognizes the subscription response format, then verify the URL and local network instead of changing every routing and DNS setting at once. Unlike simplified tools with one input field, a full client preserves groups, update logs, and node sources, making configuration changes easier to trace.
03 / ROUTING
SYSTEM PROXY · TUN · RULES
System proxy, TUN, and routing rules
The system proxy mainly affects applications that follow the operating system proxy settings, making it suitable for browsers and conventional desktop software. TUN mode uses a virtual network interface to capture a broader range of traffic, including programs that ignore system proxy settings, but it also adds DNS, route-priority, and permission variables. These are not speed modes, and they do not need to be enabled together; choose based on which applications need to be captured and whether the current system can create a virtual interface.
Routing rules decide whether traffic uses a proxy outbound, direct outbound, or blocked outbound after entering the core. Rules can match domains, IPs, ports, protocols, and process information, and their order usually affects the result. Start with a small set of clearly targeted rules: verify the default outbound first, then add LAN direct access, domain-specific routing, or application policies. Adding a large rule set at once may look complete, but makes conflicts difficult to trace.
DNS and routing must be considered together. The way a domain is resolved, whether the result enters rule matching, and which outbound sends the request can all change the final path. When a webpage fails but an IP connection works, check the client log, DNS result, and matched route separately. Reasoning through system proxy, TUN, DNS, and routing layer by layer is more effective than repeatedly switching a single “global” button when only certain apps fail, DNS behaves unexpectedly, or traffic takes the wrong path.
Application trafficProxy entryDNS and rulesTarget outbound
04 / KERNEL
PROJECT V · V2FLY · XRAY
Separating graphical clients from cores
Graphical clients and proxy cores operate at different layers. v2rayN, v2rayNG, and v2flyNG handle the interface, subscription lists, parameter organization, system integration, and runtime status; V2Fly or Xray cores parse configuration and execute protocols, transports, DNS, routing, and outbound connections. An option visible in the interface does not mean every core version uses identical fields. Conversely, a core may support a capability that is difficult to use until the client provides a matching configuration entry point.
Project V established the foundation for the V2Ray configuration model and component-based design. The V2Fly community later continued maintaining v2ray-core and related documentation, while Xray developed an independent core implementation along similar configuration lines. The two core paths share many concepts, but differ in protocol extensions, transport capabilities, field details, and version development. When converting subscriptions or migrating configurations manually, preserve the server address, port, user identifier, transport, and security parameters, then confirm that the target core recognizes each field.
For routine troubleshooting, identify the layer first. If a client cannot save a subscription, the issue is usually in the interface or input; if the core fails to start, inspect configuration parsing logs; if access fails after a connection is established, continue with the server, DNS, routing, and local network. Clear separation avoids replacing the client, core, and every rule after a single connection failure. The advanced guide covers combinations of multiple subscriptions, server filtering, FakeDNS, custom outbounds, and complex routing.
Platform links lead to the relevant download tab; choose the exact package by processor architecture and system format there. Desktop platforms use v2rayN, while Android users can choose between v2rayNG and v2flyNG based on core requirements. After installation, complete a minimal configuration check before gradually adding subscription filters and advanced network modes.
DESKTOP / WPF
Windows
Windows uses v2rayN. The modern desktop version uses a cross-platform interface for users who prefer a consistent layout; the classic WPF version retains its established structure for environments familiar with traditional menus and list management. Both support subscription updates, server switching, system proxy settings, and routing configuration.
On the download page, choose the modern desktop version or classic WPF version based on your workflow; there is no need to install both.
macOS uses v2rayN, and the processor architecture must be confirmed first. Choose the arm64 package for newer Apple Silicon devices and the x64 package for Intel Macs. Selecting the wrong architecture can prevent the app from launching, so check the processor or chip type in System Information.
If the system blocks the first launch, follow the security prompt in system settings to allow the app and confirm the required network permissions.
On Android, v2rayNG is the usual choice; its Xray core suits common subscription and related protocol configurations. Choose v2flyNG when the V2Fly core is required. Mainstream phones released after 2015 generally use arm64 packages; when the architecture is unknown or device compatibility is varied, use the universal package instead.
After installation, import a subscription and select a server before starting the connection. If background operation is restricted, check the system battery and network management settings.
Linux uses v2rayN. Debian, Ubuntu, and similar systems generally use deb packages, while Fedora and RHEL-based distributions generally use rpm packages; each format also comes in x64 and arm64 variants. Before installing, confirm the distribution's package system and the machine architecture shown by command output.
After the graphical interface starts, check desktop-session permissions, whether system proxy settings were written successfully, and the network permissions required by TUN mode.
The relationship between Project V, V2Fly, and Xray
Understanding the layers between graphical clients, proxy cores, and configuration formats is more useful for choosing and troubleshooting than memorizing software names.
CLIENT UICONFIGCORENETWORK
A / ORIGIN
Project V's component-based foundation
Project V established an important part of the early V2Ray ecosystem. Its configuration model separates inbounds, outbounds, routing, DNS, transport, and policies into composable modules. This structure lets one core handle different local entry points and remote outbounds, while graphical clients turn complex JSON fields into subscription lists, dropdowns, and rule editors. The server, routing, and DNS settings shown in v2rayN or Android clients are ultimately ways of organizing configuration that the core can read.
Component-based design also means problems should be located by layer. When a subscription URL will not update, check the input and response format first; when the core will not start, inspect configuration fields and startup logs; when connected apps still fail, examine the system proxy, TUN, DNS, and routing. Calling every symptom a “server problem” overlooks the client and local network layers.
B / CORE FAMILY
The V2Fly and Xray core paths
The V2Fly community continued maintaining v2ray-core and related components, preserving many core concepts from the Project V configuration system. Xray developed an independent implementation along a similar modular path and continues to evolve its own protocol, transport, and configuration capabilities. The two share many concepts around inbounds, outbounds, routing, and DNS, but their fields, defaults, and extensions may differ. Similar-looking configurations should not be assumed to be directly interchangeable.
The target core deserves special attention during subscription conversion. Server address, port, user identifier, and transport parameters are usually easy to map, but certain security settings, flow-control parameters, or transport extensions may apply only to a specific implementation. A conversion tool can reorganize supplied information, but cannot recreate key fields absent from the original configuration. If an imported configuration will not connect, compare the original link with the target core's supported fields one by one.
C / CLIENTS
What the three clients do
v2rayN targets Windows, macOS, and Linux desktops, handling subscription maintenance, server lists, proxy modes, routing rules, log viewing, and core invocation. v2rayNG targets Android, uses the Xray core, and manages mobile connections; v2flyNG also targets Android but uses the V2Fly core. Similar names do not mean the three share identical interface code or cores; choose according to the device platform and configuration dependencies.
Graphical clients make configuration editing easier, but do not change the underlying network logic. Subscriptions still need to return recognizable content, servers must be reachable, domain resolution remains subject to local and remote DNS policies, and routing rules still select outbounds by their match conditions. With these facts in mind, “Update subscription,” “Set as active server,” “System proxy,” and “TUN mode” map to distinct processing stages.
D / LICENSE & UPDATE
Open-source licensing and update decisions
V2Fly, Xray, and all three graphical clients are maintained with public source code, with each project released under its own open-source license. Licenses may differ across components: cores and clients are separate projects with independent release schedules. Open source makes it easier for the community to review implementations, submit fixes, and verify configuration behavior, but compatibility with the current system and subscription format still depends on release notes and the actual environment.
Before updating a client, record the current subscription groups, proxy mode, and custom rules, and check whether the new version changes the configuration directory, default core, or interface structure. If the current setup is stable, do not upgrade the client, core, and routing all at once without reading the change notes. Staged updates preserve clear comparison points: update one component, verify startup, subscription, connection, and routing, then move to the next layer.
LATEST GUIDES
Recent configuration and troubleshooting articles
These articles focus on practical issues: how proxy modes affect application traffic, the order for handling macOS installation permissions, and which fields different subscription formats must retain during conversion. Each article separates symptoms, decision criteria, and operation order so you can define the problem before changing configuration.