Start by choosing a client, then complete subscription import, routing, and connection checks in order. The setting names match common v2rayN and v2rayNG interfaces, while the configuration snippets use fields shared by Xray and V2Fly.
First define which traffic the client should handle, then configure routing, DNS, and subscriptions. Switch tasks on the left; the right side shows the corresponding logic and configuration fields to verify.
Send private addresses and local domains to the direct outbound first, then send all other destinations through the proxy outbound. Rules are matched from top to bottom; once the first rule matches, checking stops, so more specific rules should come first. v2rayN’s “Bypass mainland China” is a preset rule set, not a system proxy switch. The system proxy sends application traffic to the client, while the routing module chooses the actual exit. After editing, save the configuration and restart the core so old rules do not remain in the current process.
{
"domainStrategy": "IPIfNonMatch",
"rules": [
{ "ip": ["geoip:private"], "outboundTag": "direct" },
{ "domain": ["geosite:cn"], "outboundTag": "direct" },
{ "domain": ["geosite:geolocation-!cn"], "outboundTag": "proxy" }
]
}Give each subscription a recognizable note before updating its group. When several subscriptions coexist, do not guess their sources from configuration names; place work, testing, and daily configurations in fixed groups with separate filters. If the number of configurations does not change after an update, check the current group, inclusion keywords, exclusion keywords, and subscription URL in that order. Before deleting old configurations, confirm that the new entries have been parsed successfully so the currently selected item does not lose its record.
group.name = "daily"
subscription.update = true
filter.include = "VLESS|VMess|Trojan"
filter.exclude = "expired|test"
profile.keep_selected = trueFirst decide whether domains should be resolved locally or through a specified server, then set the query strategy. Replacing the server address alone usually will not fix a mismatched resolution path. If resolved addresses are sent to the wrong route, also check domainStrategy, the DNS server’s matching domains, and outbound tags. Before enabling FakeDNS, confirm that TUN is handling application traffic. For ordinary system proxy setups, keep the configuration simple and avoid having system caching, browser Secure DNS, and client DNS all participate at once.
{
"queryStrategy": "UseIP",
"servers": [
{ "address": "localhost", "domains": ["geosite:cn"] },
{ "address": "https+local://1.1.1.1/dns-query" }
]
}TUN mode receives network traffic from apps that do not follow system proxy settings. Before enabling it, exit other virtual network adapter tools, launch the client with administrator privileges, and verify the auto-route and strict-route options. If local network devices become unreachable, do not switch to global mode immediately; first check that private subnets still have direct rules. If domains resolve but connections fail, check the MTU, IPv6 path, and DNS interception scope. During troubleshooting, change one option at a time so the source of each change is clear in the logs.
tun.enabled = true
tun.auto_route = true
tun.strict_route = false
tun.mtu = 1500
route.private_network = directTraffic sniffing extracts destination domains from connections such as HTTP and TLS, allowing geosite rules to handle requests that carry only an IP address. Enable sniffing first, then limit coverage to the protocols you need; it is not a general-purpose content analysis feature. If an app behaves unexpectedly after sniffing is enabled, temporarily route its traffic directly for comparison, then narrow the match by domain or process rule. Sniffing solves route identification; it does not replace DNS configuration or system proxy settings.
"sniffing": {
"enabled": true,
"destOverride": ["http", "tls", "quic"],
"routeOnly": true
}When creating a custom outbound, assign a unique tag first and have routing rules reference it. A common base structure includes proxy, direct, and block outbounds; complex setups can add chained proxies or a specific interface, but existing tag names should not be changed repeatedly. When a tag changes, update every rule that references it. If the configuration will not start, check the field path in the core log first, focusing on protocol settings, transport parameters, and tag references instead of repeatedly switching nodes to hide a structural error.
"outbounds": [
{ "protocol": "freedom", "tag": "direct" },
{ "protocol": "blackhole", "tag": "block" },
{ "protocol": "vless", "tag": "proxy" }
]Use v2rayN on desktop platforms. On Android, choose between v2rayNG and v2flyNG based on your core requirements. Each platform entry opens the corresponding category on the download page.
Use the v2rayN desktop edition or classic WPF edition. The desktop edition uses a cross-platform interface and suits new installations; the WPF edition retains the classic Windows workflow for users who already know it. After downloading, extract or install it, then start the client and verify that the core is available.
Use v2rayN and choose the Apple Silicon or Intel installer according to your processor. Check the chip information in system details; choose arm64 for an Apple M-series chip and x64 for Intel. On first launch, grant the required permissions when prompted, then import your subscription.
Prefer v2rayNG based on the Xray core; choose v2flyNG when you need the V2Fly core. Most recent devices can use the arm64 installer; choose the universal version when you cannot confirm the architecture. After importing a subscription, select a single configuration, enable the connection toggle, and confirm the system connection prompt.
Use the v2rayN deb or rpm package. Choose deb for Debian, Ubuntu, and derivatives; choose rpm for Fedora, Rocky Linux, and other rpm-based distributions. You must also select x64 or arm64 for the device processor. After installation, complete subscription and routing setup from the graphical interface.
The client provides the graphical interface and system integration; the core handles protocols, transport, routing, and DNS. Keeping these layers separate makes it easier to determine whether an issue lies in the interface settings or the core configuration.
Project V is an open-source technology ecosystem built around proxy protocols, transport methods, and routing capabilities. V2Ray was the common early name; later community development formed two major core families, V2Fly and Xray. They share many configuration concepts, including inbounds, outbounds, routing rules, DNS servers, and transport settings, but differ in newer protocol capabilities, field extensions, and development pace.
A graphical client is not the core itself. v2rayN manages desktop subscriptions, configuration selection, system proxy, TUN, and log viewing, then calls the selected core to perform network tasks. v2rayNG and v2flyNG handle the Android interface, connection status, and configuration storage. When troubleshooting, first confirm that the client can start the core, then check whether the core can parse the configuration, and only afterward inspect the specific network path.
Xray offers broad support for features such as VLESS, XTLS, and REALITY, so v2rayNG is commonly used for configurations that require them. V2Fly continues Project V’s community maintenance path, and v2flyNG corresponds directly to its configuration model. When using only VMess, basic VLESS, standard WebSocket, or gRPC transport, the core concepts are similar; for extension fields, follow the core required by the configuration source.
Do not judge full compatibility from the beginning of a share link alone. The protocol name in the link identifies the main outbound protocol, but the connection may also depend on transport, security, server name, fingerprint, and flow-control fields. If the client reports an unsupported field after import, confirm the current core type first, then check whether the shared configuration depends on extensions from another core.
v2rayN, v2rayNG, v2flyNG, and the related cores are continuously maintained by open-source communities. Open-source licenses define the conditions for using, copying, and distributing code, while making configuration parsing, network handling, and interface behavior reviewable. For installation, still choose a file matching your platform and architecture from the clearly identified client entry; do not mix repackaged third-party versions with files released by the original project.
Client updates and core updates operate at different layers. A client update may change the interface, subscription handling, or system integration; a core update may add protocol fields or fix routing and transport issues. If an old configuration starts but a new one cannot be parsed, inspect the error field first and then decide whether the core needs updating. If an interface entry has moved, find it using the current client’s setting names instead of deleting existing configurations.
After installation, import a clearly structured configuration and start the core. Then check that the local listening port is active before enabling the system proxy or TUN. If a browser connects but command-line tools do not, the application usually is not reading the system proxy. If no applications connect, check the core startup log first. Only when some domains fail should you inspect routing and DNS. This order separates the client, core, system integration, and rule layers step by step.
The client provides the interface and manages the system proxy; the core reads the configuration and handles connections. Check the core log for startup errors and the client settings for subscription or interface issues.
View the terminology guide →First confirm that you updated the current subscription group, then check the inclusion and exclusion filters. Filters remove entries whose names do not match after the subscription is parsed.
View the import steps →Start with the system proxy for browsers and other apps that follow system proxy settings. Enable TUN when you need to handle apps that ignore proxy settings, while keeping direct rules for private subnets.
View advanced setup →Guides to proxy modes, routing databases, and core differences. Each article focuses on a specific question, making it easier to verify settings after the basic installation.
Explains how the system proxy switch and routing modes relate, traces traffic through global, bypass-mainland-China, and direct rules, and covers choices for browsers, command-line tools, and games.
Read the full articleExplains how GeoIP and GeoSite data support routing rules, covering client update locations, common category syntax, and the order for checking rules that stop working after an update.
Read the full articleExamines the branch relationships within the Project V ecosystem, compares protocol support, transport behavior, and configuration compatibility, and maps the common core combinations used by the three graphical clients.
Read the full article