Windows
Use v2rayN. The download page offers both the modern desktop interface and the classic WPF interface, suited to desktop environments that need system proxy, subscription management, routing, and TUN settings.
Go to Downloads
GUI Client Configuration Guides
Organized by Platform
V2Ray Tutorials Setup & Client Guides
A focused guide to v2rayN, v2rayNG, and v2flyNG downloads and setup, covering subscription imports, system proxy settings, split routing and TUN mode.
Free forever
Open source
English guides
GUI clients
- PLATFORMWindows · macOS · Android · Linux
- CLIENTv2rayN · v2rayNG · v2flyNG
- COREXray · V2Fly
- DOCUMENTDownload · Configure · Route · Troubleshoot
Configuration Coverage
Client Guides
Subscriptions
Split Routing
DNS Configuration
TUN Mode
Troubleshooting
From client selection to traffic capture
Six chapters cover the steps most often confused in everyday setup. Choose a topic to see its purpose, scope, and diagnostic approach without mixing settings from different layers.
Choose a GUI client by operating system first
For desktop use, v2rayN is the primary option, covering Windows, macOS, and Linux with centralized controls for subscriptions, routing, system proxy, and TUN. On Android, v2rayNG with the Xray core is a strong default; choose v2flyNG when the V2Fly core is required. Their interfaces and core focus differ, but the basic workflow—import a subscription, select a configuration, and start the connection—is similar. Choose based on platform and core requirements rather than repeatedly switching clients for appearance alone.
Keep subscription sources, node entries, and active configurations separate
A subscription URL retrieves a set of server configurations that can be updated. The entries created after import are the nodes the client can actually select. Updating a subscription rereads its remote content and usually does not switch the active node automatically. When managing multiple subscriptions, use descriptive group names and review added, removed, and renamed entries after each update. Server filtering only changes what appears in the list; it does not replace routing rules or change an app’s outbound path.
Map each match condition to the intended outbound path
Routing rules decide whether a connection goes direct, through a proxy, or to blocked outbound. Common conditions include domain sets, address ranges, ports, network types, and process names. Set the default outbound first, then add narrowly defined exceptions, keeping in mind that rules are usually evaluated in order. GeoSite and GeoIP provide maintainable domain and address sets, but their names must match the data files supported by the current client. When traffic is routed incorrectly, start with the first matching rule instead of piling on more rules.
Check the resolution path together with routing policy
DNS configuration determines which resolver handles a domain and which outbound path carries the DNS request itself. A page that will not load is not necessarily a node problem: the domain may have no usable result, or the result may conflict with the routing rules. Before changing DNS, record the current configuration, then check client DNS, system DNS, and browser cache separately. With FakeDNS, also confirm that traffic follows a capture path capable of recognizing the mapping; enabling only half the setup will not work.
Use virtual-adapter capture when system proxy coverage is not enough
The system proxy affects only programs that follow the operating system’s proxy settings. Some command-line tools, games, and apps with their own network stack may bypass it. TUN mode receives a broader range of traffic through a virtual network adapter and passes it to the client’s routing layer. It usually requires additional permissions and may conflict with other virtual adapters, network filters, or existing routing tables. First verify that a normal system proxy connection works, then check permissions, the adapter, DNS, and bypass rules one by one.
Start at the local entry point and narrow the fault layer by layer
Handle connection problems in a fixed order: confirm that the client core is running and that the system proxy or TUN state is as expected, then check the active node, routing matches, and DNS resolution. Log messages about listener failures, insufficient permissions, DNS failures, and connection timeouts point to different layers and should not be treated as one generic “no internet” problem. Change one variable at a time and retest; this preserves the evidence and makes the root cause easier to find than resetting everything at once.
Platform Guides
Choose a V2Ray client by device
The download page lists installation links and architecture notes for each operating system. The homepage only routes you to the right platform; it does not provide installer paths, helping prevent the wrong build from being chosen before the system and processor are confirmed.
macOS
Use v2rayN. On the download page, choose an Apple Silicon or Intel build based on the device processor. Subscription and routing workflows remain consistent with other desktop platforms after installation.
Go to DownloadsAndroid
Prefer v2rayNG with the Xray core, or use v2flyNG when the V2Fly core is required. Most newer devices suit arm64 builds; if the architecture is uncertain, check the universal-build notes.
Go to DownloadsLinux
Use v2rayN. The download page provides desktop builds in common package formats and lists separate x64 and arm64 links. Confirm the distribution’s package format and processor architecture before choosing.
Go to Downloads
Quick Start
Complete a basic connection in three steps
Build the smallest working configuration first, then handle routing, DNS, and TUN. Validating the basic connection separately from advanced settings reduces false diagnoses caused by changing several variables at once.
-
Import a subscription or single configuration
In the client’s subscription manager, add the subscription URL, save it, and run an update. If you have a single share link, use the clipboard import feature instead. After importing, check that basic details such as the protocol, address, and port appear in the list. Name subscriptions by source or purpose so multiple default names do not make updates ambiguous. At this stage, only confirm that the configuration reached the client; do not rush to change routing templates or DNS parameters.
-
Select a node and set the proxy entry point
Choose a configuration from the server list as the active node, start the client core, and enable the system proxy for the scope you need. Browsers and other programs that follow the system proxy can usually use this entry directly. If an app ignores system proxy settings, first check whether it supports a manual proxy. Move to TUN mode only when broader traffic capture is genuinely needed. Do not enable multiple traffic-capture tools before the basic connection is confirmed.
-
Verify the result and preserve troubleshooting evidence
During verification, first check the client status and logs for listener failures, insufficient permissions, or resolution errors, then test the target you need to reach. If only some apps fail, compare whether they follow the system proxy. If every domain fails to resolve, check DNS first; if only specific sites use the wrong outbound path, inspect routing rules. Change one setting at a time and record the symptoms before and after each change to identify the fault layer accurately.
Ecosystem Relationships
The Project V, V2Fly, and Xray core families
The client interface, proxy core, and configuration data are separate layers. Understanding how they relate helps identify where a feature comes from, what protocols are compatible, and what an update may affect.
Project V provides the foundation for the protocol and configuration model
V2Ray commonly refers to the proxy technology and configuration approach within the Project V ecosystem. It is not a single GUI program, but a set of capabilities organized around inbounds, outbounds, transports, routing, and DNS. The v2rayN, v2rayNG, and v2flyNG applications seen on desktop and Android devices are GUI clients; the core called by the client actually parses configurations and handles connections. Separating these layers makes it possible to diagnose interface, core, and subscription-content issues independently.
V2Fly and Xray are common core families
V2Fly continues implementations and configuration conventions associated with Project V, while Xray maintains its own feature development around a similar configuration model. Both include inbounds, outbounds, routing, DNS, and multiple transport options, but fields, protocol extensions, and defaults may differ. Whether a subscription imports correctly depends not only on its link format, but also on whether the client’s core recognizes the relevant fields. For compatibility issues, identify the core family first, then check the client’s supported range.
GUI clients turn core capabilities into an operable interface
v2rayN targets desktop platforms and centrally manages subscriptions, server lists, system proxy, routing rules, DNS, and TUN settings. v2rayNG targets Android and commonly works with the Xray core; v2flyNG follows the V2Fly core path for cases that require it. A client does not change the server-side configuration itself. It stores configurations, generates parameters the core can read, starts the process, and presents runtime status and logs.
Open-source licenses define code-use and distribution terms
Different projects in the Project V ecosystem use their own open-source licenses. These licenses set the conditions for using, modifying, and redistributing source code; it is not safe to assume every project uses the same license. When describing features, the site relies on public project code and documentation rather than applying one client’s license conclusions to every core. For redistribution or integration, read the license text included with the relevant project.
Assess updates across the client, core, and data files
A client update may change the interface, configuration generation, or replace the core; routing data such as GeoIP and GeoSite follows its own update schedule. Feature problems therefore cannot be judged from the client name alone. If routing results change after an update, check whether the core, routing data, and existing rules still match. If only the interface moved, inspect the client’s settings structure first. Keeping a readable backup of the old configuration makes differences easier to compare than overwriting everything.
Configuration Articles
Recent V2Ray Technical Guides
Focused on routing data, subscription formats, and connection troubleshooting, with each article providing diagnostic reasoning and an ordered workflow.
A Guide to Updating GeoIP and GeoSite Databases
Explains how both routing datasets work during matching and how to check data files and update results in v2rayN and v2rayNG.
Read Article →V2Ray Subscription Formats Explained
Compare the structure and uses of Base64, native JSON, and share links, including client compatibility, conversion approaches, and import considerations.
Read Article →V2Ray Is Connected but Websites Won’t Open
Check local settings, node status, routing rules, and DNS resolution in four layers instead of repeatedly changing settings across unrelated fault levels.
Read Article →