Client downloads and configuration guides
A focused guide to the v2rayN desktop client, Android clients, and Chinese configuration workflows. From subscription imports to system proxies, routing, and core selection, each step follows the actual settings and explains what it does.
Platform Downloads
v2rayN is the primary choice for desktop systems, while Android users can choose between v2rayNG and v2flyNG. The download center lists options by CPU architecture, package format, and client interface.
Use v2rayN to manage subscriptions, server lists, system proxy settings, and routing rules. The download center includes both the modern desktop interface and the classic WPF interface, so you can choose the one that fits your workflow.
Go to DownloadsUse the v2rayN desktop interface to manage subscriptions, proxies, and routing. In the download center, first check whether your device uses an Apple Silicon or Intel processor, then choose the matching installer.
Go to Downloadsv2rayNG uses the Xray core and supports common protocols and routing configurations; v2flyNG uses the V2Fly core as an alternative core ecosystem. arm64 is usually the preferred architecture on modern devices.
Go to Downloadsv2rayN provides installer formats for common desktop distributions and separates x64 from arm64 builds. After installation, subscriptions, cores, routing, and system proxy settings can all be managed from one interface.
Go to DownloadsCore Settings
The feature links follow the order used in real configuration work. Select a tab below to see what each setting does, where to find it, and which boundaries are easy to confuse.
Subscriptions
Subscriptions import a set of nodes provided by a service into the client, where they can be updated, filtered, and switched within one group. When adding one for the first time, make sure the link is complete and give the group a recognizable name. Automatic updates suit subscriptions whose nodes change often, but the interval should not be too short. If a request fails, first check whether the link is still reachable and whether the update request needs to use the current proxy.
v2rayN lets you manage update behavior separately for each subscription group instead of applying one policy to all groups. Be aware of overwrite behavior for manually edited nodes: a later subscription update may replace the local copy with content delivered by the server. Important custom settings are better saved separately than edited directly in subscription-generated entries.
Traffic Routing
Routing rules determine whether a class of requests uses a direct connection, a proxy, or a blocked exit. A common approach is to handle clearly defined LAN and regional domain sets first, then send unmatched traffic to the default exit. Rules are usually matched in order, so specific conditions should come before broader ones. Reload the configuration after changes to avoid processing connections with outdated rules.
v2rayN's graphical settings work well for maintaining common rules; for complex cases, inspect the routing section of the generated configuration. geosite matches domain sets, geoip matches address sets, and network limits matching to TCP or UDP. Routing is not a replacement for system proxy mode: they control traffic at different stages, from entering the client to choosing an exit inside the core.
Core Management
The graphical client collects, transforms, and manages configuration, while the core handles protocols, transports, and routing. Xray and V2Fly share common ecosystem origins, but each maintains its own features and compatibility path. When using REALITY, XTLS, or a protocol-specific extension, first confirm that the selected core supports the relevant fields; even ordinary configurations should not be judged compatible by name alone.
Stop the current connection before switching cores, then confirm that the client has recognized the core files before starting the configuration again. If startup fails after the switch, check field-parsing messages in the log first rather than repeatedly changing nodes. On Android, the client type usually determines the primary core: v2rayNG favors Xray, while v2flyNG is based on V2Fly.
Proxy Control
When the system proxy is enabled, applications that follow the operating system's proxy settings send requests to the client's listening port. This controls how traffic enters the client; it does not mean every application will connect automatically. Some applications use their own network stack or ignore system settings. In those cases, check the application's proxy configuration or choose another interception method supported by the platform.
Global, rules, and bypass modes describe how the client handles traffic after receiving it. For everyday browsing, rules mode is usually the best starting point, sending clearly matched destinations according to routing conditions. During diagnosis, switch modes briefly to determine whether the issue lies with the node, rules, or system proxy entry point. Restore the system proxy state before closing the client to reduce the chance that later applications keep using an old port.
Getting Started
Complete the shortest configuration path first, then add automatic updates, routing rules, and core changes step by step. This makes it easier to identify which layer contains a problem.
Open subscription group management, create a new group, and paste the complete V2Ray subscription link. Choose a name that reflects its purpose so you can quickly identify it alongside other groups. Save it and run one manual update to confirm that server entries are generated correctly. If the list is empty, do not change routing or the core first; return to the subscription layer and check the link, access requirements, and response format.
During the first import, keep the default update policy and verify only three things: the link can be read, the client can parse it, and the list contains entries. Set an automatic update interval after the connection works. This keeps subscription retrieval, proxy, and scheduled-task issues from being mixed together.
Select the entry you want to use in the server list, set it as the active configuration, and start the core. Then enable the system proxy according to the applications you want to cover, starting with rules mode for everyday traffic. The system proxy controls whether an application sends requests into the client; routing rules control which exit handles those requests after they enter the core. Check them separately.
If an application does not respond, first confirm whether it follows the system proxy. If only certain domains are affected, check the routing match order. Do not repeatedly change the core, subscription, and rules before confirming that the entry point works; otherwise, multiple configuration changes can obscure the cause in the logs.
After connecting, check the client log to confirm that the core loaded the configuration and that there are no field-parsing errors, port conflicts, or routing-format errors. Then test with an application that follows the system proxy, and separately verify that direct and proxied routes behave as expected. Logs record configuration-processing results and are more useful for diagnosis than the interface status alone.
Once the basic connection is stable, enable long-term settings such as automatic subscription updates and startup launch. Change one variable at a time, and reload the configuration after modifying routing or the core. Keep a working configuration as a separate copy so you can quickly return to a verified baseline when adding rules later.
Open-Source Ecosystem
Clients, cores, and configuration formats operate at different layers. Understanding their roles makes it easier to assess protocol compatibility, feature differences, and the impact of updates.
Project V established a technical ecosystem built around a configuration-driven network core. As community maintenance paths evolved, V2Fly continued the V2Ray core and related components, while Xray developed its own feature branch around a similar configuration model. They share many concepts, including inbounds, outbounds, routing, transports, and DNS, but this does not mean every field, protocol extension, or runtime behavior is always identical.
“V2Ray client” is therefore usually a broad label for an ecosystem category, not a guarantee that a client uses one fixed core internally. To assess a feature, check the client's graphical management capabilities, the features of its bundled core, and the protocol fields used by the subscription. Client names alone cannot fully explain real-world compatibility.
v2rayN primarily manages desktop server lists, subscription groups, system proxies, routing settings, logs, and cores. After configuration is completed in the interface, the client prepares a runtime configuration that the core can read, then Xray or V2Fly handles the connection. An “Started” status only confirms the process state; protocol handshakes, DNS queries, and routing matches still need to be assessed with core logs.
The practical benefit of this layered design is that configuration management and network processing can evolve independently. A client update may change the interface, subscription parsing, or configuration generation, while a core update may affect protocol support, transport implementation, and field validation. When diagnosing an issue after an update, first identify which layer changed before restoring settings, switching cores, or correcting subscription content.
v2rayN targets Windows, macOS, and Linux desktops. It suits workflows that require centralized management of multiple subscriptions, editable routing rules, system proxy switching, and detailed logs. System proxy behavior and installer formats vary by desktop platform, but the concepts of subscriptions, servers, and cores are largely consistent; when migrating, recheck local paths and platform permissions.
v2rayNG targets Android and primarily uses the Xray core, with an interface organized around mobile network changes, subscription updates, routing, and connection control. v2flyNG also targets Android but offers a different configuration path through its core choice. Both are graphical clients maintained by open-source communities. Choose based on the subscription protocols, core requirements, and configuration habits—not by treating different names as simple interface variants of the same app.
Open-source projects let communities inspect code, discuss implementation, and maintain features over time. For everyday users, the practical value is that configuration behavior and issue reports can be analyzed by technical communities, while clients and cores can release fixes independently. Open-source status does not replace sensible version selection, permission management, and configuration review; choose the appropriate software entry for the device and the task.
Before updating, review the functional changes, keep the existing configuration, and verify three basics: subscription parsing, core startup, and system proxy behavior. If the current setup is stable and no specific feature is needed, learn what changed before scheduling the update. If new protocol fields depend on a particular core, consider both the client's ability to generate the configuration and the core's support. The guides on this site organize setup steps and troubleshooting around this layered model.
Selected FAQs
Identify whether the issue is in the subscription, core, system proxy, or routing layer before checking the relevant settings.
First confirm that the subscription link is complete and still reachable. Then check whether the update request needs a proxy and whether the response uses a subscription format the client can parse. Changing system proxy mode or routing rules usually cannot fix a subscription retrieval problem before the list is generated. Follow the Getting Started guide to verify the import sequence.
First check the core log to confirm that the configuration loaded successfully, then verify whether the target application follows the system proxy. If other applications connect and only one fails, inspect that application's network settings. If no applications connect, check the system proxy port and the client's listening status. Follow the Troubleshooting guide by symptom for the full process.
The system proxy determines whether an application sends requests to the client; global or rules mode determines how the client chooses an exit after receiving them; individual routing rules match domains, addresses, and network types. These concepts operate at different stages. During diagnosis, do not confuse “the application never entered the client” with “the routing choice was unexpected.”
Consider switching when the configuration uses a specific protocol extension, the core log reports an unsupported field, or you need to verify core compatibility for a feature. For ordinary connection issues, check the subscription content, time settings, system proxy, and routing first. Stop the current connection before switching, reload the configuration afterward, and use the logs to confirm the active core and field-parsing results.
Guide Updates
The article section expands on configuration principles, selection criteria, and deployment boundaries not covered on the home page. It is suited for further reading after the basic connection is working.
Breaks down the structure, client support, and conversion boundaries of three common formats, explaining where to begin when an import fails.
Read the Full Article →Compares main-router and bypass-router deployment, covering transparent proxying, DNS handling, device scope, and performance constraints.
Read the Full Article →Maps the two core maintenance paths and explains how protocol features and configuration fields correspond across the three graphical clients.
Read the Full Article →