Find the v2rayN desktop client, the v2rayNG Android client and configuration steps in English in one place. Start by choosing the right package, then import a subscription, select a server, enable the system proxy and configure routing rules.
Interface preview: manage subscription groups, routing rules and the system proxy switch in one window.
Confirm your device and processor architecture first, then open the download page and choose the matching package. Use v2rayN on desktop; on Android, start with v2rayNG and choose v2flyNG when you need its kernel.
Use v2rayN to manage subscriptions, servers, the system proxy and routing rules. The download page also offers a modern desktop interface and the classic WPF interface, so choose based on your system and workflow.
Go to downloadsChoose an Apple Silicon or Intel package according to your device. After installation, start with subscription groups, then decide whether to enable the system proxy and minimize on startup.
Go to downloadsFor most devices, choose the arm64 package for v2rayNG; use the universal build only when you cannot confirm the architecture. Choose v2flyNG when you need V2Fly kernel behavior or already have matching configuration.
Go to downloadsChoose deb or rpm according to your distribution's package format, and distinguish between x64 and arm64 builds. After installation, import the subscription first, then check that the desktop proxy settings match the client's mode.
Go to downloadsDo not change every option at once. Start with a working basic setup, then add rules one at a time for your device, network and apps. This also makes changes easier to trace when something goes wrong.
Copy the subscription URL provided by your service provider, create a subscription group in the client and run an update. Name each group by purpose or source so multiple URLs do not get mixed into one list. After updating, confirm that servers appear before selecting one for a connection test. v2rayN is well suited to managing multiple subscription groups on desktop; v2rayNG and v2flyNG keep updates, filtering and server selection together in their mobile interfaces. Updating a subscription only syncs configuration—it does not automatically determine which route best fits your current network.
Update subscription groupSplit routing decides whether different traffic goes direct, through a proxy or to a blocked outbound. A common starting point is to send private addresses and local resources direct, while routing other requests through the proxy. Begin with the client's basic rules, then add custom domains, IP ranges or process conditions after confirming a stable connection. Rule order affects matching, so put more specific conditions first and reload the configuration after every change. Unlike tools with a single on/off switch, V2Ray clients can manage domain rules, IP rules and outbound tags within one routing model.
geoip:privategeosite:cnfinalThe system proxy routes apps that follow the operating system's proxy settings through the client, but some programs use their own network configuration. Before connecting, confirm that the client core is running, then enable the system proxy; reverse the order when stopping. Enable LAN sharing only when other devices genuinely need to connect through this machine, and check the listening address and local firewall. Desktop clients can also minimize on startup and run with the system, but keep the window visible during initial setup so you can monitor status, switch servers and read logs.
Do not rely on a single latency result when testing a connection. First update the subscription and confirm that the server configuration is complete, then run a real connection test and check whether the system proxy is enabled and the target app reads it. If every server fails, check the subscription content, device time, network permissions and core startup log first. If only some servers fail, compare their protocol parameters and route status. Start reading logs at the earliest error and distinguish parsing, handshake, timeout and remote rejection stages. Avoid changing the protocol, routing and DNS at the same time before the cause is known.
On your first run, configure only what is necessary. Once the basic connection works, move on to routing, custom DNS, TUN mode and multi-subscription filtering.
Use v2rayN on Windows, macOS and Linux; use v2rayNG on Android, or v2flyNG when you need the V2Fly kernel. Before downloading, confirm the operating system, processor architecture and package format. After the first launch, get familiar with subscriptions, the server list, logs and the system proxy entry points before changing advanced options.
Add the URL in subscription management, save it and run an update. Confirm that the server list is populated, then select the current server and test the connection. For multiple subscriptions, create a separate group for each source and use filters to control what is shown; this is easier to maintain than one large list.
Start the client core, enable the system proxy if needed, then access the network through the target app. If the connection fails, check the current server, proxy switch, the app's own proxy settings and the runtime log in order. Change one variable at a time and record the before-and-after results to shorten troubleshooting.
Clients, cores and protocols operate at different layers. Separate their roles first, then choose tools based on the platform and node configuration to avoid confusing interface features with core capabilities.
Project V is an open-source technology ecosystem built around proxy protocols, transport methods and routing. Early V2Ray introduced a unified configuration model, inbound and outbound concepts, and routing based on domain and IP matching. As community maintenance evolved, V2Fly continued maintaining v2ray-core while advancing compatibility, protocol implementations and documentation; Xray developed from similar configuration ideas into an independent core branch with new protocol capabilities and transport options.
The two core families share many fundamentals, including inbound, outbound, routing, DNS and transport-layer configuration, but not every field or feature is interchangeable. When you receive a node configuration, confirm the protocol type and server requirements before checking whether the client's bundled core supports it. The client name alone is not enough: the graphical client imports, edits and controls settings, while the core it invokes performs the connection.
v2rayN is a desktop graphical client for Windows, macOS and Linux, suited to managing multiple subscriptions, complex routing and the system proxy. It brings server lists, subscription groups, core controls, testing tools and logs into one desktop interface for users who maintain configurations over time. v2rayNG targets Android and usually works with the Xray core, with a mobile-focused flow for importing subscriptions, selecting a server, starting a connection and viewing logs.
v2flyNG also targets Android but uses the V2Fly core family. It suits users with existing V2Fly configurations, a need for matching core behavior or a desire to compare compatibility between the two core families. v2rayNG and v2flyNG differ in more than interface styling; choose based on the node protocol, configuration fields and maintenance needs. When a provider specifies a client or core, follow that guidance first.
These projects collaborate through open source, with releases coming from software projects under ongoing maintenance. Open-source licenses define the boundaries for using, modifying and redistributing code; community contributions cover bug fixes, protocol support, platform compatibility and documentation. For most users, the practical checks are whether the client is still maintained, whether its core supports the current node protocol, whether the package matches the device and whether configuration behavior changed after an update.
Client and core release cycles may differ. Client updates can change the interface, subscription handling or system proxy logic, while core updates are more likely to affect protocol, transport and routing implementation. When compatibility problems appear, first determine whether they involve the client interface, core startup, subscription content or remote service, then decide whether to update, roll back configuration or adjust rules. Do not replace the client, core and entire configuration at the same time without reading the change notes.
Start with common configuration issues, then visit the help center for complete, category-based guidance.
Confirm that the subscription URL was saved in full, then run an update manually. If the list is still empty, check the group filters, device time and the subscription response.
View subscription issues →Check that the client core is running and that the target app reads the system proxy. Apps with independent network settings require a separate check of their proxy options.
View connection issues →Latency is only one selection signal. Also consider route load, protocol handshakes, target region and real transfer performance, using a real connection test to compare results.
Understand latency and nodes →Their basic structures are similar, but protocol support and some fields differ. Check each item against the server requirements and core documentation instead of simply replacing names.
Compare the clients →Actionable decision steps for client selection, core differences, server filtering and runtime logs. These articles add detail and boundary conditions to the guides.
Compare the two cores across protocol support, configuration compatibility and maintenance cadence, then infer the right core from the node type.
Read the full article →Trace Project V's evolution, V2Fly community maintenance and the origins of the Xray branch, then locate the three clients within the ecosystem.
Read the full article →Learn how to use real connection tests, understand traffic multipliers and filter servers by target region and protocol type.
Read the full article →