Manage addresses, updates, and server filters separately.
v2rayN · Routing rules− □ ×
Match criteriaOutbound
geosite:category-ads-allblock
geoip:privatedirect
geosite:cndirect
Routing rules
Choose an outbound route based on domains and addresses.
v2rayN · DNS settings− □ ×
Remote DNShttps://1.1.1.1/dns-query
Direct DNSlocalhost
Domain strategyIPIfNonMatch
DNS settings
Check both the DNS server and the path requests take.
v2rayN · TUN mode− □ ×
Enable TUNEnabled
System proxyClear system proxy
Stackgvisor
TUN mode
Route system traffic through the client; check permissions and the network stack first.
Platforms and packages
Client downloads
For desktop devices, start with v2rayN; for Android, see v2rayNG. Check your operating system and processor architecture before choosing a package. The package format determines how to install it, while the core determines protocol and transport support—check these separately.
For your first setup, start with a standard system proxy. Import an existing subscription, select a server, and confirm the core starts before checking whether app traffic passes through the client. Once the basic connection works, adjust routing and DNS one setting at a time so you can identify the cause of any issue.
Downloading a client and configuring a connection are separate steps. Installing a client does not create a working server entry; subscription URLs, node parameters, and credentials must come from a service configuration you already have. The example address here only illustrates where a field goes—it cannot establish a connection.
The desktop version uses a cross-platform interface, while the classic WPF version retains a familiar Windows layout. Both manage server lists, subscription groups, and connection settings. Choose based on your system requirements and preferences; there’s no need to rebuild your subscriptions just because the interface differs.
After installing, check the local listening port before setting up the system proxy. If a browser works but another app cannot connect, check whether it reads the system proxy or has its own proxy settings. Finding where the traffic enters is usually more useful than repeatedly switching nodes.
Before enabling TUN, check administrator permissions and other networking tools. If network behavior doesn’t return to normal after you quit the client, check whether the system proxy still points to a local port that is no longer running.
Choose the Apple Silicon or Intel download based on your device’s processor. Find the chip name in your system information: Apple Silicon uses arm64, while Intel uses x64. Choosing the right architecture avoids uncertainties from compatibility layers and makes it easier to troubleshoot startup issues using the download page’s instructions.
After launching the client, check the proxy settings for the active network service separately. Switching Wi-Fi, using an external network adapter, or connecting another networking tool may change which service is active. The client’s button state alone can’t confirm that every app is using the proxy.
If macOS shows a security alert, verify the package source and read the alert, then follow the download page’s instructions. Don’t disable system-wide security just to launch an app.
v2rayNG uses the Xray core and supports common Android subscription and connection workflows. v2flyNG is an alternative built on the V2Fly core. Choose based on the requirements of your existing node configuration, not on how similar the client names look. The download page lists both options in this order.
Most modern devices use arm64. If you’re unsure of the architecture, check system information or choose a universal package. After importing a subscription, you’ll need to authorize the system VPN connection the first time you connect. This system-level entry point routes app traffic through the client, unlike a desktop system proxy.
If the connection drops when the screen locks, check battery optimization and background activity restrictions. Also check whether another app is using the VPN connection slot, then determine whether the client was stopped in the background or the server connection failed.
Choose a deb or rpm package to match your distribution’s package manager, then select x64 or arm64. The desktop environment, system dependencies, and network permissions all affect setup. After installation, confirm the interface launches and the core loads before configuring how traffic is routed.
Not every app reads the desktop environment’s system proxy settings. Some require a local HTTP or SOCKS proxy to be configured separately. If your browser works but other programs don’t, start by checking each app’s proxy settings.
TUN involves a virtual network interface, routing tables, and permissions. If your device already uses container networking, virtual machines, or other tunneling tools, record the existing settings and check after each change that local networking and the default route still behave as expected.
Start with the key fields, then review their effects. These are partial examples, not complete files you can drop in to replace a client configuration. Field names in the graphical interface can vary by platform and core; check the actual logs and generated configuration when setting things up.
Subscription groups keep addresses, remarks, and update behavior together, making them useful for managing multiple sources. Name a group, add its address, and update it; then confirm the server entries appear in the expected group. Filter keywords support regular expressions, but results depend on node names. A filter that’s too narrow can make the updated list look empty. Group updates are easier to maintain than adding nodes one by one, but they may overwrite manual edits. Manage custom entries you need to keep separately, and check what an update will affect before proceeding.
Routing rules direct traffic to direct, proxy, or block outbounds; they don’t increase server bandwidth. Rules are usually evaluated from top to bottom, so specific conditions should come before broad ones. This example sends a domain-ads list to a block outbound. It requires the resource file to contain that list and the configuration to define the corresponding outbound tag. Routing by domain and address lets you preserve direct access to local resources, unlike sending all traffic down the same route. After making changes, check the logs for actual matches instead of inferring that the rules are correct from whether a page loads.
DNS settings depend on both the resolver and the outbound route used for DNS queries. Remote lookups are commonly sent through a proxy, while direct traffic needs a resolver that returns suitable results. The domain strategy in this example is used for routing decisions; it doesn’t mean every request is immediately resolved to an IP address. Core-level DNS is closer to routing logic than changing system DNS alone, but you still need to check whether apps perform their own lookups. When troubleshooting, distinguish between a domain that won’t resolve, an unreachable resolver, and an address that resolves but can’t be reached before changing settings.
Enable TUN:Yes
System proxy: Clear system proxy
Stack: gvisor
Permissions: Administrator privileges
TUN receives traffic through a virtual network interface, making it useful for apps that don’t read system proxy settings. It changes where traffic enters the client; it won’t fix node parameters or DNS issues. Before enabling it, confirm a standard proxy connection works, then check administrator permissions, the network stack, and existing virtual adapters. TUN covers more traffic than a system proxy, so pay closer attention to routing conflicts and local network access. If something goes wrong, turn TUN off to restore your baseline, keep the logs, and test one change at a time. Don’t replace nodes and rules simultaneously.
Multiple cores help support different protocols, transports, and configuration fields; they aren’t a universal speed boost for the same node. To check compatibility, consider the protocol, transport, and security layer together. Seeing VLESS alone doesn’t mean every core can handle the configuration. This example shows only the outbound protocol; a real connection also needs complete server parameters. Checking core support is often a more direct way to diagnose startup errors than switching graphical clients. Save a working configuration before switching, then review the logs to confirm the target core loaded it correctly.
These settings depend on one another: subscriptions provide server entries, the core loads connection parameters, routing selects the outbound, DNS resolves domain names, and the system proxy or TUN determines how app traffic reaches the client. Follow this chain when troubleshooting; it’s easier to preserve useful information than by resetting everything at once.
When reading configuration examples, distinguish client options from core fields. Subscription remarks and filter keywords are for managing settings; routing rules and DNS snippets are generated by the client or passed to the core. Treating interface labels as JSON fields can make a configuration fail to parse. For the full setup workflow, see the Deep Dive.
Clients and cores
The Project V open-source ecosystem
V2Ray is a network proxy tool in the Project V ecosystem, with a core focused on protocol handling, transport, and routing. The apps people use day to day—v2rayN, v2rayNG, and v2flyNG—provide interfaces for working with those cores. They bring server parameters, subscription updates, and launch controls together, so configuration doesn’t have to rely entirely on manual editing.
This separation explains a common issue: the client can open normally while the core fails to start. The graphical interface manages configuration; the core reads it and establishes connections. One working component doesn’t mean the other is working. When an error occurs, first determine whether it comes from the interface, configuration generation, or core output before changing node parameters.
V2Fly and Xray: shared roots, separate compatibility checks
V2Fly continues the community’s work on V2Ray, while Xray developed as a separate core branch from related code. They share some concepts and usage patterns, but protocol features, transport capabilities, and configuration details don’t always match. When comparing V2Ray cores, focus on specific fields and features rather than treating the entire ecosystem as interchangeable software.
A node name is just a remark; it can’t describe all connection requirements. For a VLESS configuration, also check the transport, security settings such as TLS or REALITY, and whether the parameters match the server. Before choosing a client, find out which core capabilities your existing configuration needs. If your current connection is stable, there’s no need to migrate just because another branch has a newer-sounding name.
Three clients: choose by platform and configuration needs
v2rayN is designed for desktop use, with server lists, subscription groups, routing management, and options for multiple cores. It suits users who want to organize connections in one graphical interface. Its cross-platform interface makes the workflow more consistent across desktop devices, but system proxy behavior, permissions, and network adapter handling still depend on the operating system. Don’t assume every platform behaves identically.
v2rayNG is designed for Android, uses the Xray core for connections, and receives app traffic through the system VPN interface. Key tasks include importing subscriptions, selecting an active node, configuring per-app routing, and managing background restrictions. v2flyNG also targets Android but uses the V2Fly core. It’s an alternative when your configuration fits that core’s capabilities, not a tool for converting every node to another protocol.
All three clients are maintained as open-source projects. Open source means the code and changes can be discussed and reviewed; free client software is a separate matter from server resources. The clients don’t provide subscriptions or determine server performance. For speed, data limits, or node-region issues, check the client settings and your existing service configuration separately.
Open-source licenses: terms for using the code
Open-source licenses govern how code may be used, modified, and distributed. The V2Ray core maintained by V2Fly and the Xray core use MPL 2.0; the v2rayN, v2rayNG, and v2flyNG clients use GPL-family licenses. Clients and cores are separate projects. If you distribute software or modify code, read the license for each project involved rather than relying on the client’s name alone.
For everyday users, this helps clarify where software comes from and where responsibilities lie: the community maintains the clients, while each core follows its own development schedule. This site organizes English-language download and setup information. Examples in the guides explain what settings do; they don’t guarantee the same result for every node, route, or environment.
Update method: preserve a baseline, then verify changes
Client updates can change the interface, configuration generation, or bundled components; core updates can change protocol handling and field support. The two are related but don’t follow a single synchronized version scheme. This homepage focuses on choosing and using clients. The download page lists installation options and current releases so you can check the platform and package format in one place.
Before updating, note the core, active node, routing setup, and local listening port you currently use, and save any essential configuration. After updating, test a basic connection with a node that worked before, then check subscription updates, routing, and DNS. If anything changes, find the earliest error in the logs and determine whether a configuration field changed, permissions changed, or the app isn’t using the new proxy entry point.
Don’t change the client, core, server, and TUN settings all in the same test. Each change adds uncertainty when identifying the cause. Keep a known-working baseline and change one thing at a time to make results easier to reproduce and restore normal operation.
Four common topics in configuration guides
Subscription update fails. First check that the address hasn’t been truncated, then review the request status and response in the logs. If you already have local nodes, test subscription import separately from whether those connections work. See subscription update troubleshooting for steps.
Browser works, other apps don’t. First check which proxy entry point the app uses. A system proxy doesn’t capture all network traffic. If you need broader coverage, check permissions and the network stack in the TUN mode guide.
Domains fail, but IP addresses connect. Start by checking the DNS route, returned results, and domain-based routing strategy. Connecting by IP doesn’t prove your DNS settings are correct. Use the DNS settings guide to distinguish resolution failures from connection failures.
Import fails despite matching protocol names. Check the transport, security layer, and parameter format. Some details are encoded in the link; others come from the subscription. The same protocol name doesn’t guarantee identical configurations. Read the VLESS glossary entry, then compare core support.
Configuration guides and troubleshooting
Quick-start guides cover the steps to follow; in-depth articles explain the network behavior behind them. For a complex issue, identify where traffic stops first, then choose the relevant article. Don’t conflate router deployment, core compatibility, and node speed tests.
Don’t want to install a client on every device? This article outlines how to run a core directly on an OpenWrt bypass router, covering gateway and DNS settings, transparent proxying, and traffic-splitting rules.
Why can three speed tests on the same node produce such different results? This article explains what handshake tests, real requests through a proxy, and bandwidth tests measure—and how to interpret them.
Both are part of the Project V ecosystem, but the two core branches make different trade-offs in protocol support, transport, and configuration fields. This article compares their key differences and explains how to choose between v2rayNG and v2flyNG.