Android client/Xray core/Open source
Start by importing a subscription, then configure routing rules and DNS. Use v2rayNG on Android and v2rayN on desktop.
Client downloads
The desktop edition has a cross-platform interface, while the classic WPF edition keeps its familiar layout. Check system requirements before choosing, then import a subscription group. System proxy and TUN route traffic differently; you don't need both enabled.
Check About This Mac for your chip: Apple Silicon uses arm64, while Intel uses x64. After installation, test browser access through the system proxy. Set up TUN only if an app doesn't honor the system proxy.
Use v2rayNG with the Xray core by default; choose v2flyNG if you specifically need the V2Fly core. Most recent phones use arm64; choose the universal build if you're unsure. On first launch, approve the system VPN connection.
Choose a deb or rpm package to match your distribution, then check whether you need x64 or arm64. A working GUI doesn't mean every app uses the proxy: terminal tools, browsers, and desktop environments may use different proxy settings.
An incompatible package architecture can prevent installation or startup. An incompatible subscription format usually causes an import error. Identify which step failed before changing settings; repeatedly switching clients rarely helps.
Browse all clients →Settings & configuration snippets
Understand what each setting affects before changing it. These snippets illustrate configuration structure; they are not complete, ready-to-use configurations. Check the selected client and core for actual feature support.
v2rayNG provides the graphical settings; Xray handles the actual connections. With traffic sniffing enabled, the core can identify domains in supported traffic to help match domain-based routing rules. It does not decrypt app content. When troubleshooting, first check that the protocol, transport, and security settings match the server, then check Sniffing. Mux is a separate multiplexing option and isn't suitable for every protocol combination. Leave it off initially, establish a working baseline, and enable it only if needed.
{
"sniffing": {
"enabled": true,
"destOverride": [
"http",
"tls"
],
"routeOnly": true
}
}A subscription URL retrieves a set of connection profiles; a single-node share link imports just one entry. Give each source a distinct name in Subscription Group Settings so you can see which servers an update affects. Updates may overwrite edits to subscription-generated entries, so copy a profile if you need to keep changes. If the first import fails, check that the URL is complete and returns a compatible format. Choose whether to update through the proxy based on your network; don't repeatedly update every group without a reason.
Subscription Group Settings
├─ Group name: Everyday use
├─ Subscription URL: Use the subscription URL you obtained
└─ Update scope: Current group
Import a single node
├─ vmess:// → Import from clipboard
└─ vless:// → Import from clipboard
Note: These are steps in the interface, not core JSON.Routing selects an outbound for a connection; it doesn't supply missing server parameters. Rules are generally matched in order, so put specific exceptions before broad rules. This example sends private IP addresses and mainland China domains to direct. Before using it, make sure an outbound with that tag exists and the required rule data is available. IPIfNonMatch means the client resolves an IP when domain rules don't match, then continues checking; it doesn't mean every domain is resolved first. If a rule has no effect, check rule order, domain detection, and the spelling of outboundTag.
{
"routing": {
"domainStrategy": "IPIfNonMatch",
"rules": [
{
"type": "field",
"ip": ["geoip:private"],
"outboundTag": "direct"
},
{
"type": "field",
"domain": ["geosite:cn"],
"outboundTag": "direct"
}
]
}
}DNS resolves domain names to addresses; routing determines where the resulting connection goes. Check both together. This example uses a mainland China resolver for geosite:cn and another resolver for other queries. It's only a servers snippet; make sure DNS requests themselves have a reachable route. DoH encrypts DNS traffic but won't fix incorrect routing. FakeDNS maps domains to virtual addresses and requires traffic interception and sniffing to work together. For a first setup, verify standard DNS resolution before enabling extra options.
{
"dns": {
"servers": [
{
"address": "223.5.5.5",
"domains": ["geosite:cn"],
"skipFallback": true
},
"1.1.1.1"
]
}
}Per-app proxy settings first decide which apps enter the VPN; routing rules then decide how that traffic is forwarded. Proxy selected apps is useful when only a few apps need the proxy. Bypass selected apps works when most apps should use it, with a few exceptions. The same app list means the opposite in each mode, so review it before switching. Restart the VPN connection after changing the app list or mode. If a browser works but another app doesn't, first check whether that app is included, then troubleshoot DNS and the protocol.
Mode: Proxy selected apps
Selected apps:
Browser app
Apps that need the proxy
Traffic flow:
Selected apps → Android VPN → core routing
Apps not selected → Existing system network path
Note: App selection is a client setting,
not a domain condition in routing.rules.v2rayNG's VPN mode receives traffic through the Android system interface. v2rayN's system proxy mainly affects desktop apps that honor that setting. TUN uses a virtual network interface to capture a broader range of traffic and may require extra permissions and matching DNS settings; it's not simply another name for a "global proxy." The example on the right shows a local SOCKS inbound, not a TUN configuration. Start with one traffic-capture method, confirm it works, and only then introduce TUN to avoid multiple proxy tools changing routes at once.
{
"inbounds": [
{
"tag": "socks-in",
"listen": "127.0.0.1",
"port": 10808,
"protocol": "socks",
"settings": {
"auth": "noauth",
"udp": true
}
}
]
}The settings panel shows an example state, not the default for every installation. See the advanced guide for complete rules and how to combine DNS routing with custom configuration.
Explore advanced configuration →First connection: recommended steps
Start with a connection whose settings are clear and whose results you can reproduce. During initial setup, avoid changing routing, DNS, Mux, and app scope all at once; otherwise, it's hard to pinpoint the cause of a problem.
Choose an installer for your operating system and processor architecture. On Android, install v2rayNG and check the VPN mode, routing, and DNS options in Settings. On desktop, install v2rayN and confirm that the interface starts normally. When asked for permission, review why it's needed before granting it; each permission is required only for the corresponding traffic-capture method.
Installing the client doesn't give you a working server. Before continuing, prepare a subscription URL, share link, or complete server details. Subscription URLs may contain access credentials, so don't post them in public forums. If you need help, share only an error description and screenshots with authentication details removed.
For a single-node link, use Import from clipboard or scan a QR code. For a subscription URL, open Subscription Group Settings, save it, then update that group. These are different import methods. After importing, check that the server address, port, protocol, transport, and TLS or REALITY settings are complete, then select a profile as the active server.
Start with the client's standard routing setup; don't add complex rules yet. On Android, tap Connect and approve the VPN prompt. On desktop, start the core and choose the system proxy mode you need. If a subscription update returns nothing, check whether the URL returned a subscription rather than a login page. An import failure doesn't necessarily mean the server is offline.
Open a browser and visit a site you use regularly; check the client logs to confirm the request reached the core. TCPing shows whether a target port is reachable. A real connection latency test is closer to an actual proxied request, but neither result alone proves every app will work. Also check DNS resolution, page loading, and the target app.
If the connection fails, check in this order: is the client running, is traffic reaching it, is the server reachable, does DNS resolve, and does a routing rule match? Keep a verified baseline, change one thing at a time, and retest. Once the basic path works, configure per-app proxy, custom routing, or TUN so you can easily roll back.
Open-source projects & maintenance
The core handles network connections; the client organizes settings and connects to the operating system. Understanding these two layers helps you decide whether to change a parameter, update the client, or adjust system permissions.
Project V is a network proxy ecosystem represented by V2Ray. It separates inbound, outbound, routing, DNS, and transport settings so they can be combined for different network needs. V2Fly continues community maintenance of V2Ray, while Xray is a related core project that develops independently. They share some configuration concepts, but their features and parameter details don't always match.
VMess, VLESS, Trojan, and Shadowsocks are connection protocols. TCP, WebSocket, and gRPC are transport options. TLS and REALITY relate to connection security. These terms describe different layers and aren't interchangeable. Even after importing a VLESS share link, check its transport and security parameters; the protocol name alone doesn't guarantee compatibility.
v2rayN is an open-source GUI client for desktop systems, with tools for server management, subscription groups, routing, and proxy settings. v2rayNG is for Android, uses the Xray core, and integrates with the system VPN interface. v2flyNG is also for Android and uses the V2Fly core; consider it when you specifically need that core. These clients turn user settings into network configuration; they don't provide server services.
All three clients are free and open source. Each client project and included core has its own license. Read the license notices bundled with the software before modifying or redistributing it; one component's terms don't automatically apply to all dependencies. The client being free doesn't mean server resources are free. Subscription validity, data limits, and connection quality are outside the client's control.
Updating the client can change its interface, features, or bundled core. Updating a subscription refreshes server profiles; one doesn't replace the other. If the server's authentication or transport parameters change, update the relevant subscription first. If a new feature isn't recognized, check whether the client and core support it. Save any custom rules you need before updating, then check the logs and existing connections afterward—not just whether the app opens.
Routing rules, DNS addresses, and per-app lists mainly affect how this device handles traffic. Remote server reachability, certificates, and authentication depend on the server configuration. A running status only confirms that the local service started; it doesn't guarantee a successful remote connection. For timeouts, authentication failures, or DNS errors, note the error type and when it occurred, then investigate the relevant part of the connection path. Don't assume every issue is caused by the proxy mode.
Technical notes
Choose a guide for the issue at hand: understand differences between test results, work through common first-time setup problems, or learn what the main areas of the desktop client do.
Learn which part of the connection TCPing, real connection latency, and download speed tests measure, why their results can differ, and which metric to prioritize when choosing a server.
Read about testing →Answers to 10 common beginner questions, from failed subscription imports and connected-but-unreachable websites to choosing global or rule-based routing and enabling startup on boot, with quick ways to diagnose each issue.
Read the troubleshooting steps →A section-by-section walkthrough of the v2rayN main window, covering server list actions, subscription groups, log troubleshooting, settings, and the system proxy toggle.
Read the interface guide →To get started, read the beginner's guide. If you can already connect, continue with the advanced guide to routing and DNS.
Browse all articles →