V2RAY CLIENTS · CONFIGURATION GUIDE
Client downloads and setup documentation for Windows, macOS, Android, and Linux, covering practical steps for subscription imports, system proxy, TUN mode, and routing rules.
PLATFORM ENTRY
The download page lists available clients, package types, and selection guidance by platform. Desktop systems use v2rayN, while Android users can choose between v2rayNG and v2flyNG based on the core they need.
DESKTOP · V2RAYN
Desktop and classic WPF editions are available. For a new installation, start with the cross-platform desktop edition. If you prefer the traditional window layout, server list, and tray menu, use the classic edition. Confirm your system architecture before installing, and keep read/write access to the client configuration directory.
Go to DownloadsDESKTOP · V2RAYN
Packages are split between Apple Silicon and Intel processors. Check the chip name in System Information, then open the matching download. On first launch, follow the system prompts to grant network configuration permission. Subscription import and active-server selection follow the same process as on other desktop platforms.
Go to DownloadsMOBILE · V2RAYNG / V2FLYNG
v2rayNG uses the Xray core and suits common protocols and routing configurations; v2flyNG uses the V2Fly core as an alternative implementation. Most recent devices can use the arm64 package; if you are unsure of the architecture, check the universal package. When connecting, the system will display a network access authorization prompt.
Go to DownloadsDESKTOP · V2RAYN
v2rayN provides packages suited to the package management systems used by common distributions. Debian- and Ubuntu-based systems generally use deb, while Fedora- and RHEL-based systems generally use rpm. x64 and arm64 packages must also be selected by processor architecture. After installation, launch it from the desktop menu, then configure subscriptions and proxy modes.
Go to DownloadsLINK INSPECTION
Check each stage from the configuration source to the exit connection. Select the current stage on the left to see which problem it addresses, where to make changes, and which parameters to verify.
SOURCE / UPDATE
A subscription URL is not generated by the client; it is a set of server details delivered by the configuration provider. Add the URL to the correct group and update it. The client parses the protocol, address, port, transport, and security settings, then creates a selectable server list. After updating, check whether the group name and node count changed before choosing an active server. If the list is empty, verify that the URL is complete, the correct group is selected, and the update log contains no errors instead of repeatedly switching proxy modes.
When multiple subscriptions are in use, create groups by source and add clear notes. This lets you update, filter, and sort them separately, preventing servers with the same name from being mixed together. Subscription changes do not automatically replace local configurations you created yourself, so manage manual and remote entries separately.
source: subscription · action: update · result: server list
INBOUND / SYSTEM
System proxy mode points the operating system's proxy address to the client's local listening port. Browsers and most desktop apps that follow system settings then send traffic through it. Its boundaries are clear and its controls are direct, making it a good default for the first connection. If the client shows as running but an app still connects directly, check that the system proxy is actually enabled, that the app is not using its own proxy settings, and that another program is not occupying the local listening port.
Restore the system proxy before quitting the client to prevent the operating system from retaining an inactive local address. Some command-line tools do not read system proxy settings and require separate environment variables or TUN instead. This is an application integration difference, not a server failure.
inbound: local socks/http · scope: system-aware applications
VIRTUAL INTERFACE / ROUTE
TUN receives traffic through a virtual network interface and can cover game launchers, command-line programs, and apps that ignore system proxy settings. It reaches more applications than system proxy mode, but also depends on the virtual adapter, routing table, DNS, and permission settings. Before enabling it, quit other tools that create virtual network interfaces and confirm that the client has permission to modify network settings. If local network access becomes abnormal, first check rules that bypass private addresses.
TUN does not mean every connection must use the same exit. Whether traffic goes direct, through a proxy, or to block is still determined by routing rules. During troubleshooting, distinguish between whether traffic entered the client and which rule matched after it entered.
capture: virtual interface · decision: routing rules · dns: coordinated
RULESET / OUTBOUND
Routing rules select an exit based on conditions such as domain, address, port, protocol, or process. Common goals are keeping LAN and local services direct, sending selected requests through a proxy, and blocking unwanted connections. Rules are usually matched from top to bottom, so specific conditions should come before general ones. After making changes, do not check only whether the client is connected; inspect which rule the target request actually matched.
Preset rules are useful for building a basic structure, but long-term use still requires understanding the meanings of the direct, proxy, and block exits. More rules do not necessarily produce more accurate results; duplicate conditions, ordering conflicts, and overly broad matches can make troubleshooting harder.
match: domain / ip / port / process · outbound: direct / proxy / block
EVENT / DIAGNOSIS
Logs are the primary evidence for locating a failure point. If the core cannot start, first look for configuration parse failures, missing fields, and port conflicts. If it starts but cannot establish a connection, check DNS resolution, the TLS handshake, timeouts, and routing matches. Record when the error appeared and what action triggered it so startup problems can be separated from issues involving a specific destination. This avoids changing multiple settings at once and losing track of what worked.
Troubleshoot in order: local listening, system integration, rule matching, then the remote connection. Change only one variable at a time and repeat the same request after each change. This preserves working configuration and makes the true failure point easier to identify than blindly reinstalling.
order: startup → inbound → dns → routing → outbound
QUICK START
Keep the first setup simple: choose the right package, import a working configuration, and complete a basic check through the system proxy. Once the basic path is confirmed, move on to TUN and more complex routing.
Use v2rayN on Windows, macOS, and Linux; Android users can choose v2rayNG or v2flyNG. Confirm the processor architecture and package format before downloading. On desktop systems, also make sure the current account can write to the configuration directory and that the client is allowed to create a local listening port. After installation, launch it normally once. Do not change firewall, DNS, and routing settings before the main interface appears.
Enter the complete URL in subscription management, give the source an easy-to-identify group name, and update it. When the server list appears, select an entry as the active server. Check that the protocol, address, port, and transport fields were parsed correctly. The subscription URL delivers configuration; the client reads and runs it. If the update fails, check the subscription operation log first instead of assuming the core is unavailable.
Start the core first, enable the system proxy, then send a test request from a browser that follows system proxy settings. If it fails, check the local port, system proxy, DNS, routing rules, and remote connection in that order. After the basic mode works, decide whether to enable TUN based on the applications you need to cover. This separates virtual adapter issues from server configuration issues and reduces interference between them.
OPEN ECOSYSTEM
The client, core, and configuration source are three separate layers. Understanding their boundaries is essential for identifying which layer is responsible for an update, compatibility issue, or failure.
Project V established a tool ecosystem around proxy protocols, transport methods, routing rules, and local inbounds. A graphical client is not the protocol itself. It turns subscriptions, server lists, system proxy settings, routing, and logs into an operable interface, then passes the resulting configuration to the core. When a user selects a server or switches modes, the client is actually reorganizing configuration and controlling the core process.
This distinction directly affects troubleshooting. A subscription that cannot update is usually a configuration-source or client network-request issue. A core that exits immediately after starting is more likely related to configuration fields, a port, or the runtime environment. If only a specific destination is unreachable, DNS, route matching, transport parameters, or remote status are more likely causes. Calling every symptom “a broken client” hides the actual failure point.
V2Fly carries forward core implementations and configuration conventions from the Project V ecosystem, while Xray extends some protocol, transport, and low-level capabilities while remaining compatible with established concepts. Both organize configuration around structures such as inbounds, outbounds, routing, DNS, and policies, but supported fields and behavior can differ by implementation. When importing a configuration, the client must convert the subscription content into a format recognized by the current core.
v2rayN manages related cores and configuration workflows on desktop platforms; v2rayNG primarily uses the Xray core; v2flyNG corresponds to the V2Fly core. When choosing a client, do not conflate the graphical interface with the core. The interface determines how you operate it, the core executes configuration and handles protocols, and the subscription supplies server parameters. The connection can work only when all three layers remain compatible.
All three clients are maintained as open-source projects, with maintainers and the community continually advancing features, configuration changes, and fixes. The practical value of open source is that implementations and changes can be inspected, discussed, and reproduced by the technical community—not that an abstract label replaces security judgment. After installing a new build, read the change notes and confirm whether the configuration directory, core selection, permissions, or system proxy behavior has changed.
Client updates and subscription updates are not the same thing. A client update changes the program and its supported capabilities; a subscription update only refreshes server configuration. When a protocol field is not recognized, determine whether the subscription is wrong, the client lacks parsing support, or the current core does not support the parameter. Layered diagnosis is more controllable than repeatedly deleting all configuration.
COMMON QUESTIONS
These questions cover configuration boundaries that are easiest to confuse during first use. The troubleshooting page contains the full categories and diagnostic paths.
No. v2rayN is a graphical client that manages subscriptions, server lists, proxy modes, routing, and logs; the core parses configuration and handles actual connections. The client can call the appropriate core based on the configuration and platform, so a successfully launched interface does not guarantee that the core is running correctly. For connection issues, check both the main interface status and the core logs.
A subscription update converts remote configuration into a server list; it does not decide which entry you should use. After the update completes, choose an active server in the correct group and then start the core. If the client offers an automatic selection strategy, first complete one manual connection test to confirm that the configuration works.
For the initial setup, start with the system proxy because its coverage and failure boundaries are easier to observe. Once browsers and other standard applications connect successfully, enable TUN if needed for command-line tools, games, or other applications. TUN involves a virtual network interface, routing, and DNS, so check permissions and interface conflicts when problems occur.
First confirm that an active server is selected. Then check whether the system proxy is enabled, whether a local listening port exists, and whether the browser uses its own proxy settings. Next inspect DNS, route matches, and remote connection logs. Checking each link in order distinguishes traffic that never entered the client, traffic sent through the wrong exit, and remote connection failures.
TECHNICAL NOTES
Articles are organized around practical tasks, with a focus on reproducible check sequences, log keywords, and configuration boundaries.
Explains where subscription URLs come from, what the core does, how system proxy differs from TUN, how to choose a server, and what tray states mean, with direct steps for each first-use question.
Read the Full Article →Covers port conflicts, configuration format, missing fields, and runtime permissions, showing how to use log order to locate problems that cause the core to exit immediately after startup.
Read the Full Article →Demonstrates grouping, keyword filters, aliases, notes, and sorting when multiple subscriptions coexist, keeping servers from different sources and purposes clearly separated.
Read the Full Article →