A centralized collection of v2rayN, v2rayNG, and v2flyNG clients, alongside Chinese configuration documentation and explanations of the Xray and V2Fly cores. Follow the full workflow from download and subscription import to routing rules.
CLIENT / CONFIG / ROUTING
A client is more than a button that connects. Platform selection, subscription parsing, routing decisions, and core execution each solve a different problem. Breaking the workflow into stages makes configuration errors easier to locate and prevents nodes, subscriptions, cores, and system proxy settings from being treated as the same thing.
DOWNLOAD BY PLATFORM
The home page explains the platform choices; specific packages, system architectures, and client differences are consolidated on the download page. Once you open a platform section, choose the file that matches your device architecture.
DESKTOP
For Windows desktops, choose v2rayN. The modern desktop interface suits users who want a consistent cross-platform workflow, while the classic WPF interface fits those familiar with traditional menus and tray controls. Both options appear in the same platform panel, with notes on runtime requirements, extraction directories, and first launch.
Go to DownloadsDESKTOP
On macOS, use v2rayN and confirm the processor architecture before downloading. Choose arm64 for Apple Silicon and x64 for Intel processors; a mismatch usually prevents the program from launching correctly. The platform panel also covers system proxy permissions, first launch, and the configuration directory to reduce post-install troubleshooting.
Go to DownloadsMOBILE
On Android, choose v2rayNG with the Xray core or v2flyNG with the V2Fly core. arm64 is preferred on most newer devices; if the architecture is unclear, use the universal build. Both clients support subscription updates, QR-code imports, and single share links. The main differences are their core families and protocol capabilities.
Go to DownloadsDESKTOP
On Linux desktops, use v2rayN. Choose deb or rpm according to your distribution, and select between x64 and arm64. After installation, verify the desktop session, write permissions for the configuration directory, and how the system proxy is managed. The download page puts common desktop architectures first and clearly lists other architectures as additional options.
Go to DownloadsQUICK START
For first-time use, complete the shortest working path: import a usable configuration, select a node, and enable the system proxy. Once the basic connection works, move on to routing, DNS, autostart, and other optional settings.
After copying the subscription URL, add it under subscription management in the client and run an update. If you have a single vmess, vless, or other share link, use the clipboard node import option instead of entering it in the subscription URL field. After importing, verify that the node name and protocol appear before continuing. An empty list usually means the update was not run, the URL was copied incompletely, or the client cannot currently read the subscription.
Select a configuration in the node list as the active server, then choose a system proxy mode based on the traffic you want to route. When troubleshooting, keep the rules simple: first confirm that browser traffic reaches the client, then enable routing rules gradually. If multiple network tools are running, check for local listening-port conflicts. When another program occupies the port, the core may fail to start, and logs commonly report a listening failure or an address already in use.
After starting the core and enabling the system proxy, watch the client status and logs instead of changing many settings at once. Logs show whether the configuration was loaded, DNS returned a result, an outbound was established, and whether failure occurred during the protocol handshake or local listening. Once the basic path works, configure routing, automatic subscription updates, and startup launch. Change one category of parameters at a time to make cause and effect easier to identify.
COMMON QUESTIONS
First confirm that the subscription was saved and updated manually, then check that every character at the beginning, end, and middle of the URL is intact. If the client reports a parsing error, copy the original URL again without modifying it. If the update produces no response, check the client’s network permissions and the current system proxy. Import a single share link from the clipboard rather than placing it in subscription management. See the user guide for the complete procedure.
Both are Android GUI clients; the main difference is their core family. v2rayNG focuses on the Xray core, while v2flyNG uses the V2Fly core. Choose based on the node parameters, required protocols, and compatibility with your existing configuration. If the subscription provider specifies a core, follow that requirement first. Otherwise, start with the recommended option and use logs and protocol support to decide whether a switch is needed.
Not necessarily. The connection path also includes the local listener, system proxy, DNS, routing, and outbound handshake. First check whether the core started successfully, then confirm that the system proxy port matches the client’s listening port, and read the first clear error in the logs. If no local port was created, address permissions or port conflicts first. If an outbound is established but domain resolution fails, inspect the DNS configuration instead of repeatedly changing nodes.
Subscription nodes are usually regenerated from the subscription data, so changes to their names or parameters may be replaced at the next update. To retain custom settings, copy the node as an independent entry or use the client’s subscription groups, routing rules, and preset features. Before updating, identify which fields belong to subscription data and which settings are global client configuration to avoid repeating the same adjustments.
PROJECT V ECOSYSTEM
V2Ray is often used as a shorthand for an entire toolset, but in practice it is important to distinguish the technology ecosystem, runtime core, and GUI client. Project V established a modular proxy architecture and configuration model. V2Fly continues and maintains core V2Ray capabilities, while Xray developed an independent core and additional capabilities along the same technical lineage. v2rayN, v2rayNG, and v2flyNG sit closer to the user, organizing subscription management, node selection, system proxy controls, and log viewing into graphical interfaces.
Project V’s central influence was not a particular interface, but the separation of inbound, outbound, routing, DNS, transport, and policy into composable configuration modules. GUI clients map these modules to menus, forms, and presets. This explains why different clients can use similar node parameters, and why the same subscription may expose different protocol capabilities under different cores.
You do not need to master every JSON field for daily use, but you should know which layer each setting belongs to. The system proxy determines whether application traffic enters the client; the local inbound receives connections; routing chooses the outbound; and the core executes the protocol and transport. Troubleshooting by layer is more reliable than relying only on the connection icon in the client interface.
The V2Fly core continues V2Ray’s modular design, preserving continuity in its configuration structure and many foundational concepts. The Xray core grew from related technical foundations and maintains its own implementations for protocols, transports, and flow control. They share concepts but also have fields and capabilities that cannot be swapped directly. When you see names such as VLESS, VMess, Trojan, REALITY, or XTLS Vision, verify the client core and server parameters instead of judging compatibility from the appearance of a share link.
The configuration resources on this site identify whether a field belongs to a general configuration concept, a V2Fly implementation, or an Xray extension. This supports both direct use in GUI clients and, when necessary, inspection of generated configuration files and runtime logs.
v2rayN, v2rayNG, v2flyNG, and the related cores are released under their respective open-source licenses, with client code, core code, and release schedules maintained by different contributors. GUI client updates may focus on interfaces, system proxies, subscription management, and platform compatibility, while core updates more often address protocol implementations, transports, routing, and DNS. The two update streams do not need to move in sync, so clients often provide separate core-management or core-selection controls.
The practical value of this layered structure is clear boundaries: the client handles the user experience, the core handles network execution, and the subscription distributes configuration data. When diagnosing a problem, inspect the client logs, core startup result, and subscription content separately instead of attributing every issue to one program.
Client updates, core updates, and subscription updates solve three different problems. Client updates improve platform compatibility, the interface, and configuration generation; core updates change protocol implementations and low-level behavior; subscription updates refresh the node list and its parameters. Updating a subscription does not automatically replace the client, and updating the client does not necessarily change saved nodes. Distinguishing the update target prevents irrelevant actions during troubleshooting.
Keep the adjustment order conservative for a stable configuration: preserve the current working settings, update one layer, and observe the logs. If you are only adding nodes, a subscription update is usually enough. If a protocol cannot be recognized, check core capabilities and client support. If the system proxy cannot take over, focus on client permissions and platform settings.
For Windows, macOS, and Linux, it centrally manages subscriptions, nodes, routing presets, the system proxy, and runtime logs. It suits users who need complete desktop configuration controls, multiple subscription groups, and core management.
Combines Android network services with the Xray core, supporting subscription updates, QR codes, clipboard imports, and per-app settings. It suits scenarios where subscriptions include Xray-related protocols and transport parameters.
Uses the V2Fly core as its execution layer while retaining common node-management and connection controls. It is suited to the V2Fly core path and makes it easier to compare how different cores handle similar configurations.
LATEST NOTES
These articles extend the guides across protocol fundamentals, DNS routing, and client troubleshooting. For a quick basic connection, start with the user guide; to understand fields and behavior, open the relevant topic.
Starting with TLS handshake overhead, this article explains REALITY authentication, XTLS Vision flow control, and how the two work together in the Xray core, including where that combination fits and where it does not.
Read Article →Breaks down servers, hosts, and domainStrategy, explaining how local resolution, remote resolution, routing matches, and DNS query paths affect one another.
Read Article →Check the runtime environment, directory permissions, core files, port usage, and battery optimization one by one. First identify the stage at which the program exits, then apply the corresponding fix.
Read Article →