Practical Windows, macOS, Android, and Linux client workflows covering subscription imports, proxy modes, split routing, and common connection problems.
PLATFORM ENTRY
Start by identifying your device platform, then choose an installer from the download page. v2rayN is the main desktop option; on Android, choose v2rayNG or v2flyNG based on your preferred core. Each platform page covers architectures, installation, and first-launch considerations.
DESKTOP
v2rayN is a practical graphical client. The download page offers both the modern desktop interface and the classic WPF interface, with guidance on when to use each. After installation, use the tray menu to set the system proxy, update subscriptions, and switch routing modes.
Go to downloadsDESKTOP
Use v2rayN's cross-platform desktop interface. On the platform page, choose an Apple Silicon or Intel package for your device, then complete system authorization on first launch. Subscription management, node testing, and split-routing controls are similar across desktop platforms.
Go to downloadsMOBILE
The usual choice is v2rayNG with the Xray core; choose v2flyNG when you need the V2Fly core. The download page lists arm64 and universal builds and explains first-connection authorization, battery-optimization exclusions, and per-app proxy settings.
Go to downloadsDESKTOP
Desktop environments can use v2rayN with either deb or rpm packages, depending on the distribution. The platform page distinguishes x64 and arm64 builds. After installation, check the desktop session, permission to write system proxy settings, and whether applications read the current proxy configuration.
Go to downloadsCONFIGURATION PATH
Stable client operation depends less on repeatedly switching buttons than on understanding the roles of subscriptions, nodes, proxy modes, and diagnostic logs. Follow these four points in order to build a repeatable configuration workflow.
SUBSCRIPTION
A subscription URL is not a single node but an updateable source of configurations. The reliable workflow is to create a subscription group in the client, update it, and confirm that the nodes appear in the right group. This keeps sources separate and prevents later updates from overwriting manual settings. If the node list does not change, first check the group being updated, the completeness of the URL, and the client logs instead of importing repeatedly.
Clients typically parse protocols, servers, ports, user identifiers, and transport parameters from subscription content. Your main job is to keep subscription sources organized and reselect an available node after updates. Group-based management is easier to maintain than pasting share links one by one and makes side-by-side testing of different routes simpler.
Subscription group → Update subscription → Select a node → Start the connection
ROUTING
Split routing determines whether a connection goes direct, through a proxy, or is blocked. Conditions can be based on domains, address ranges, network types, or process information. Start with the client's established rule sets, then add only the custom rules you need. More rules do not guarantee better results; conflicts and ordering mistakes make troubleshooting harder.
After changing rules, reload the configuration and test both a direct-access site and a site that requires the proxy. If a category of domains consistently uses the wrong exit, inspect the matched rule before changing its priority. Unlike simple tools with only a global switch, the V2Ray ecosystem lets you manage matching conditions and outbound actions separately.
domain:example.com → proxy · geoip:private → direct
PROXY MODE
The system proxy works well for browsers and desktop software that reads system settings, with an easy-to-understand scope. Some applications ignore the system proxy; in that case, enter the local listening address inside the application. TUN covers more traffic but involves a virtual network interface, permissions, DNS, and routing tables, so enable it only after the basic connection works reliably.
Troubleshoot from the smallest scope: first confirm that the client's local port is listening, then test the system proxy, and only afterward consider TUN. Changing one variable at a time quickly shows whether the issue comes from the node, application settings, or the system network layer, while avoiding port conflicts and overlapping routes caused by multiple takeover modes.
Local listener → System proxy → Application check → Enable TUN if needed
DIAGNOSTICS
An enabled connection button only shows that the client has attempted to start; it does not prove that the remote node, DNS, and routing are working. Check in order whether the configuration loaded, the local port is listening, the system proxy is active, the domain resolves, and the remote connection is established. Interpret messages such as failed to dial and rejected in the context of where they occurred.
Speed tests also need to be read by layer: connection latency, download throughput, and page-load speed measure different stages. Compare results using the same device, time, and test target before changing nodes. Recording results before and after each change is more useful than randomly switching Mux, DNS, and routing options.
Configuration loaded → Local listener → DNS → Matched route → Remote connection
QUICK START
Get the shortest path working first, then adjust split routing and advanced network settings. Keeping a clear sequence during initial setup makes it easy to return to the last verified step when something fails.
For Windows, macOS, and Linux desktops, start with the v2rayN platform download area; on Android, choose v2rayNG or use v2flyNG when the core requirements call for it. Confirm your operating system and processor architecture before downloading. After installation, configure the client from its main interface and avoid running multiple clients that use the same local port.
Add a name and URL in subscription management, save it, and run an update. Once the node list appears, choose one as the active server and perform a basic connectivity test. If the update fails, verify that the URL is complete and check whether the log reports a parse error, network timeout, or unrecognized response.
On desktop, enable the system proxy; on Android, complete system network authorization during the first connection. Then open one site expected to connect directly and another that requires the proxy, confirming that both request types behave as expected. Once the basic connection is stable, configure custom routes, app proxying, or TUN to avoid stacking multiple sources of configuration problems.
PROJECT V ECOSYSTEM
Clients, cores, and protocols are often confused with one another. Understanding their separate roles makes software selection, log reading, and compatibility checks much more straightforward.
Project V is an open-source technology ecosystem built around proxy protocols, transport methods, routing, and extensible networking components. V2Ray may refer to the earlier core, but users also commonly use the name broadly for related clients and configuration practices. In practice, the graphical client handles subscriptions, node selection, system proxy settings, and interface actions, while the underlying core parses configuration, establishes connections, and runs protocol and routing logic.
V2Fly continues the V2Ray core lineage with an emphasis on modularity, protocol implementation, and community maintenance. Xray follows a related technical path while developing its own transport and protocol features alongside compatibility with existing configurations. They are not merely different interface versions, but independently evolving core families. Whether protocol parameters in a subscription work ultimately depends on the core included with the client and its supported feature set.
v2rayN is a desktop graphical client for managing servers, subscriptions, routing rules, and local proxy settings on Windows, macOS, and Linux. v2rayNG targets Android and commonly uses the Xray core; v2flyNG also targets Android but follows the V2Fly core lineage. All three are open-source software maintained by the community, and their update pace depends on upstream core changes, platform APIs, and maintenance plans.
Open-source licenses let the community read, study, and improve the code, while configuration formats, issue discussions, and version changes can be documented publicly. For everyday users, the practical benefit is that protocol compatibility and startup errors can be investigated through client logs, core differences, and release notes instead of attributing every problem to a failed node.
Manage subscriptions, server lists, the system proxy, routing, and the core from one graphical interface. It suits desktop users who regularly switch nodes, maintain multiple subscriptions, or gradually refine split-routing rules. The cross-platform interface and classic Windows interface differ in interaction style; the download page explains each separately.
A common graphical client for Android that takes over app traffic through the system's network interface. Beyond importing subscriptions, pay attention to background operation, battery-optimization settings, per-app proxying, and system time. Protocol features and compatibility mainly follow the Xray core it uses.
Its workflow resembles other common mobile clients, but it uses the V2Fly core underneath. It suits subscriptions whose configuration matches this core lineage or situations where you need to compare behavior across cores. Check the subscription's protocol and transport parameters before choosing; do not compare interface names alone.
LATEST NOTES
Practical details on speed, cores, and Android usage. These articles focus on reproducible troubleshooting steps rather than treating a single speed test as a universal result.
Start with node load and protocol overhead, then check congestion periods, local Mux, DNS, and split-routing settings. Use controlled comparisons at each layer instead of switching several variables back and forth.
Read the full article →Compare the evolution of the two core lineages, their protocol support, and their client relationships to explain how v2rayN, v2rayNG, and v2flyNG use the underlying capabilities.
Read the full article →Walk through three key settings—first-connection authorization, background operation, and app scope—and explain why the connection may drop when the client moves to the background.
Read the full article →