Xray core · Android client
v2rayNG targets Android and runs on the Xray core, with support for VMess, VLESS, Trojan, Shadowsocks and REALITY; desktop and Linux are covered by v2rayN, and subscription import, routing modes and per-app proxy each have their own settings.
Core features
v2rayNG and v2rayN use almost the same setting names, so this section breaks down the groups you adjust most often: how to pick a routing mode, what per-app proxy controls, how subscriptions update, and how protocols pair with cores. Every item maps to a setting that really exists in the client, and changes take effect immediately.
These four settings carry the same names in v2rayNG and v2rayN. Changes take effect immediately, with no client restart and no need to re-import the subscription.
v2rayNG and v2rayN share the same config structure. Below is an inbounds / outbounds / routing excerpt taken from a config file:
{
"inbounds": [
{ "protocol": "socks", "port": 10808 }
],
"outbounds": [
{ "protocol": "vless", "tag": "proxy" },
{ "protocol": "freedom", "tag": "direct" }
],
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{ "type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct" }
]
}
}
V2Fly and Xray are two core implementations of the same protocol spec, with nearly identical config field structures, so the same config usually works with either. Xray updates faster for newer features such as VLESS and REALITY, and v2rayNG uses it by default; v2flyNG carries the V2Fly core for setups that need to stay consistent with older configs.
All five protocol names appear in the client's protocol dropdown. VMess and Shadowsocks stay compatible with older configs; VLESS paired with REALITY is the newer combination with lower handshake overhead; Trojan uses a standard TLS handshake, which suits servers that already have certificates configured.
Three clients cover four platforms: on Android you can choose between v2rayNG and v2flyNG, each built on a different core, while desktop and Linux installers all come from v2rayN. A single subscription link can be reused across all four platforms.
The routing mode decides which traffic goes through the proxy, and the client offers three options: Proxy only, Bypass LAN and Global. For everyday use, pick Bypass LAN so that LAN devices, router admin pages and local services stay direct while everything else is proxied; choose Global only when all traffic must pass through the proxy, and Proxy only when you pair the client with a system-level proxy. Per-app proxy narrows the scope further to individual apps, so you can route only the browser and selected tools while everything else stays direct — useful on devices that also run internal work apps. Start on boot decides whether the connection comes back automatically after a restart. All of these live on the settings page, and no subscription re-import is needed after changing them.
The protocol defines how the client and server handshake and encrypt traffic. VMess came first and has the widest compatibility; VLESS drops the redundant checks and built-in encryption layer of VMess for a lighter handshake and lower battery drain on mobile networks; Trojan borrows the standard TLS handshake, so its traffic resembles ordinary HTTPS; Shadowsocks has the simplest structure and suits devices that are sensitive to resource use; REALITY builds on VLESS and removes the need to supply your own certificate, since the server borrows the target site's certificate to complete the handshake. As for cores, both Xray and V2Fly implement these protocols: v2rayNG uses Xray by default, v2flyNG corresponds to V2Fly, and the two share compatible config structures and subscription formats — which one you pick depends on the config your server provides.
A subscription is a URL maintained by the server; the client pulls the node list from it, so you never have to enter parameters by hand. There are three ways to import one: paste the subscription link, scan a QR code, or let the client read it from the clipboard. Once imported, you can trigger an update manually from the subscription group or turn on auto-update in settings so the client refreshes the list at a fixed interval. The node order inside a subscription is decided by the server, and the client only stores the selected node and routing rules locally; moving to a new device means importing the same subscription again to restore the node list, but local settings such as the routing mode and per-app proxy need to be checked once more on the new device.
Download options
The download page is split by platform, and each section lists the matching client and package types. Desktop is always v2rayN, while Android lets you choose between v2rayNG and v2flyNG; if you are unsure which one to grab, read the platform notes below first.
Open-source ecosystem
V2Ray's protocol specs, core implementations and graphical clients belong to separate projects. Understanding how they relate makes it easier to choose the right entry in the client's protocol dropdown and core options.
V2Ray first appeared as a proxy tool under the Project V umbrella, and the protocol specs were later split from the implementations: the specs define the handshake flow and encryption for protocols such as VMess and VLESS, while the actual connection handling is left to different cores. VMess was the early workhorse with broad compatibility, and most older configs are built on it; VLESS redesigned the handshake afterwards, removing redundant checks and the built-in encryption layer and leaving encryption to the transport layer for lower overhead; REALITY goes further by having the server borrow the target site's certificate to complete the TLS handshake, so no domain certificate of your own is needed. All of these names appear in the client's protocol dropdown, and which one you choose depends on what the server config supports.
A core is the program that actually establishes connections, parses protocols and routes traffic; every client setting is ultimately translated into a config the core can read. V2Fly and Xray are two implementations of the same protocol spec, with nearly identical config file fields, so the same config usually works with either. Xray updates faster for newer protocol features such as VLESS and REALITY, and v2rayNG uses it by default; the V2Fly core is carried by v2flyNG, which suits setups that need to stay consistent with older configs. The two cores release independently, so their update schedules are not fully in sync — when protocol behaviour differs, first check whether the cores on the server and client sides match.
v2rayN, v2rayNG and v2flyNG are all released under open-source licenses with public source code and ongoing community maintenance. v2rayN covers Windows, macOS and Linux, while v2rayNG and v2flyNG target Android; all three share the same subscription format and config structure, so a subscription link can be reused when you switch platforms without regenerating anything. The client only handles connections, protocol parsing and routing; nodes and server configs come from your own subscription source. Keeping that split in mind makes troubleshooting easier — you can tell whether a problem lies in client settings or in the subscription and network environment.
Clients and cores release independently, and their updates differ: core releases usually bring protocol implementation changes and performance shifts, while client releases focus more on the interface and settings. Subscription content is maintained by the server, so nodes can be added or removed without reinstalling the client — run one manual update from the subscription group to pull the latest list, or turn on auto-update in settings if you need the list to stay fresh over time. The update entry points have slightly different names on desktop and Android, but both support manual triggering. Before updating the client, note down your current routing mode and per-app proxy settings and check them again afterwards.
Articles
Five articles cover first-connection checks, DNS leak troubleshooting, syncing configs across devices, a protocol comparison and TUN mode; the topic tags let you jump straight to the one you need.
Explains how the TUN virtual adapter takes over traffic, then lays out the order of steps for enabling TUN in v2rayNG, handling permissions and verifying what it captures.
Read the full articleCompares the four protocols on handshake style, encryption overhead and mobile battery drain, then suggests an order for picking one based on network conditions and device type.
Read the full articleWeighs exporting a share link, copying the subscription URL and running your own sync folder against one another, and explains which settings need rechecking after switching devices.
Read the full articleFrequently asked questions
From subscription imports and routing modes to desktop package choices, start with these; more detailed troubleshooting steps are collected on the FAQ page.
First check that the subscription URL is complete and reachable, then run a manual update from the subscription group; if QR scanning fails, import again by pasting the link. If the list is still empty, check whether the subscription has expired or the URL was truncated.
For everyday use pick Bypass LAN, keeping LAN device access and router admin pages direct; choose Global when all traffic must go through the proxy, and Proxy only when you pair the client with a system-level proxy.
The interface and settings are basically the same; the difference is the core: v2rayNG uses Xray and v2flyNG uses V2Fly. Subscriptions and config formats are interchangeable, so either one works.
Windows has two entry points, the desktop edition and the classic WPF edition; on macOS pick the dmg that matches your chip, and on Linux choose deb or rpm for your distribution. See the download page for the full comparison and system requirements.