V2Ray ClientsSetup Guide

Manage subscriptions and servers by source

Subscription groups make it easier to keep servers from different sources separate. In v2rayN, add a note and subscription URL under Subscription Groups, save, update the relevant group, then select a profile from the server list. v2rayNG also supports managing sources through subscription groups. Unlike pasting share links one at a time, subscriptions can sync addresses and parameters in one place, but an update may replace existing entries. Keep manual configurations you need long term in a separate list. Test filter expressions on a small set first so you don’t hide servers you need.

Rule order determines where traffic goes

Routing rules decide whether traffic goes direct, through a proxy, or gets blocked; they don’t determine whether an app sends traffic to the client. In v2rayN, check the system proxy and routing mode separately. “Bypass mainland China” doesn’t mean every app will follow the system proxy. Rules are usually evaluated in order, so place clear exceptions such as local network addresses appropriately before handling domain and IP lists. The snippet below uses Xray-style rules and must go in the right configuration structure; a direct outbound must also exist. One rule alone cannot replace a complete configuration.

{
  "type": "field",
  "ip": ["geoip:private"],
  "outboundTag": "direct"
}

Route app traffic through a virtual network interface

TUN mode can route traffic from apps that ignore the system proxy by using a virtual network interface. It is not the same as “global routing”: TUN controls how traffic enters, while routing determines where it goes next. Before enabling TUN on desktop, check permissions, required components, and OS support. Avoid running other tools that also take over network traffic. Android usually uses the system VPN interface, so don’t apply desktop TUN instructions directly. If local network access stops working, check private address exclusions and DNS rather than repeatedly switching servers.

Distinguish DNS failures from connection failures

DNS resolves domain names to IP addresses, and the resolution path must work with your routing targets. If a page won’t load, check the logs for DNS timeouts, then see whether the server can establish a connection. Don’t paste a public DNS address into every DNS field: local, remote, and bootstrap DNS serve different purposes. The snippet below shows the minimum structure for core DNS, not a complete routing setup. Interpret v2rayNG’s “Enable local DNS” in the context of your configuration. If you use FakeDNS, make sure both the traffic entry and routing setup support it.

{
  "dns": {
    "servers": ["localhost"]
  }
}

Check core capabilities against protocol requirements

Xray and V2Fly are related but independently developed core projects, and their protocol details and configuration fields don’t fully match. In v2rayN, check the current build and settings for available core options; don’t assume any configuration can be switched between cores as-is. On Android, compare v2rayNG and v2flyNG for their different core lineages. Back up your configuration before switching, check compatibility for transport, security settings, and rule resources, then test with the same server profile. A core’s ability to import a link doesn’t mean it supports every optional parameter in that link.