From choosing a graphical client to importing a subscription and checking routing and system proxy settings, follow the fields in the interface to complete setup.
CLIENTS v2rayN · v2rayNG · v2flyNGCORES Xray · V2FlyPLATFORMS Windows · macOS · Android · Linux
SETTINGS / Common Settings
Find the setting before changing it
Subscriptions, routing, system proxy, and DNS each handle a different part of the connection. When something fails, first identify which layer is involved; it’s more useful than repeatedly switching servers.
01 / SUBSCRIPTION
Subscription URLs, updates, and groups
Subscriptions make it easier to manage server lists that change over time. In v2rayN, add a name and subscription URL under “Subscription Groups,” then update the subscription. After the update, select the server you want to use from the server list. Name groups by purpose, and remember that updating a subscription and switching the active server are separate actions. Add a server manually when you only have a single set of configuration details; its alias is just for identifying it locally.
If the list hasn’t changed, check that the URL is complete, your current network can reach the subscription source, and the right group is selected. When using multiple subscriptions, check the group before filtering by keyword to avoid choosing a server with a similar name. Before removing old entries, make sure they’re no longer maintained by an active subscription.
Check in the interfaceSubscription Groups → Add → Update subscription → Select a server
02 / ROUTING
Routing mode determines where traffic goes
A working server doesn’t mean every request follows the same path. v2rayN routing rules match domains or addresses and send traffic through the corresponding outbound. For selective proxying, choose a suitable preset; use global mode only when all traffic should go through the proxy. Rules are checked from top to bottom, so before adding a custom rule, check whether an existing one already covers the same destination.
To troubleshoot how a particular site is accessed, first check the current routing mode, then inspect the matching domain rule and the final outbound. The system proxy controls which apps send requests to the client; routing determines where those requests go once they reach it. They serve different purposes and can’t replace each other.
Check in the interfaceSettings → Routing Settings → Rule Sets → Outbound Rules
03 / PROXY
Choose how apps send traffic to the client
The system proxy uses your operating system’s proxy settings to direct traffic from apps that honor them to v2rayN. After changing the setting, test it in a browser. TUN mode captures traffic at the network layer, which can help with apps that ignore system proxy settings, but typically also requires a virtual network adapter, permissions, and compatible DNS settings. These options control how apps send traffic to the client; they don’t switch the server protocol.
For your first setup, select a server, enable the system proxy, and confirm it works before trying TUN. If access problems start after enabling TUN, check its status and DNS settings first. Avoid changing routing, the core, and server parameters all at once, or it’ll be hard to tell what caused the issue.
Check in the interfaceSystem Proxy → Set system proxy / TUN Mode
04 / DNS
Check DNS and routing together
DNS translates domain names into addresses. If routing rules use domains to choose an outbound, pay attention to where and when DNS resolution happens. v2rayN lets you configure resolution separately for direct and proxied traffic. FakeDNS returns a virtual address first, then uses traffic sniffing to retain the original domain. It’s typically used when domain-based routing needs to keep working in a TUN setup.
FakeDNS isn’t required by default on every network. If a domain won’t load but accessing its address behaves differently, check DNS settings, the matching routing rule, and whether the app’s traffic is going through the proxy. Enable related features one at a time only when you need to preserve domain information, and check the results as you go.
Check in the interfaceSettings → DNS Settings → Resolution Strategy / FakeDNS
05 / CORES
Choose a core that supports your configuration
v2rayN provides the graphical interface; the selected core handles protocol processing. Xray and V2Fly both grew out of the Project V ecosystem, but their development paths aren’t identical. For example, if your configuration uses REALITY, first make sure the selected core supports its transport parameters. A field appearing in the client doesn’t mean every core can handle the associated configuration.
Before switching cores, save the server parameters you’re using and check the core name and error messages shown by the client. On Android, v2rayNG and v2flyNG follow different core paths. Choose based on the protocols and transport requirements in your subscription, not just on how similar the app names look.
Check in the interfaceSettings → Parameter Settings → Core Type / Select Core
DOWNLOAD / Choose a device
Downloads are organized by operating system
Check your operating system and processor architecture, then choose the matching package on the download page. v2rayN is the main desktop option; Android has graphical clients using two different core paths.
Use v2rayN. The download page lists a cross-platform desktop edition and the classic WPF edition. Choose the interface that suits you, then follow the installation and startup instructions.
After importing a subscription, check the selected server, system proxy status, and routing mode. If a browser works but other apps don’t, first check whether those apps use the system proxy instead of immediately changing server fields.
Use v2rayN and choose the Apple Silicon or Intel package for your device. If you’re unsure which chip you have, check About This Mac in your system settings and compare it with the architecture listed on the download page.
After the first launch, import a server and test the connection before setting up the system proxy. Don’t confuse package architecture, server protocol, and core type: they refer to the device, the configuration, and protocol handling, respectively.
Start with v2rayNG, which uses the Xray core. If you need the V2Fly core path, try v2flyNG. Both are graphical clients; use the subscription or server details you were actually given.
The download page distinguishes arm64 and universal packages. After importing, select a server and start the connection. If the subscription list has updated but the old entry is still in use, check which server is selected rather than reinstalling the app.
Use v2rayN. Choose the deb or rpm package for your distribution, then check the processor architecture. The download page lists options for common desktop hardware as well as arm64 devices.
After installation, import a subscription or server details through the graphical interface. If the client shows a connection but apps don’t work as expected, check the desktop environment’s proxy settings, client routing, and DNS separately. Changing one at a time makes the issue easier to pinpoint.
The interface and the core each have a distinct role
Understanding how Project V, V2Fly, and Xray relate makes it easier to tell whether a protocol or compatibility issue belongs in the client interface or in the core that handles the connection.
Project V: Where the ecosystem began
Project V laid the groundwork for V2Ray-related protocols and configuration methods. Since then, the community has maintained cores, graphical clients, and documentation along separate paths. “V2Ray client” may mean a graphical app with a server list and proxy controls, or it may be used loosely to refer to the core the app runs. Keeping these two layers distinct makes troubleshooting more precise.
For example, the server editor collects fields such as the address, port, user ID, and transport protocol. Clicking OK saves the configuration; the core reads those parameters when establishing a connection. A setting appearing in the window only means the interface has a place to enter it—it doesn’t prove that the current core supports it.
V2Fly and Xray: Separate development paths
V2Fly continues the community-maintained V2Ray lineage, while Xray branched from the same ecosystem and developed independently. They share some concepts and configuration conventions, but transport support, how fields are interpreted, and release schedules may differ. If your server details include VLESS, flow control, or REALITY parameters, identify the actual requirements first, then check which core the client is using.
Switching cores isn’t a universal fix for connection problems. It won’t correct a mistyped address or port, an unreachable subscription URL, or a disabled system proxy. First identify whether the issue happens during import, startup, DNS resolution, or traffic capture; then decide whether to check core compatibility.
Three clients: choose by device and configuration
v2rayN is a graphical desktop client for Windows, macOS, and Linux, with server management, subscription updates, routing, system proxy, and related core settings in one place. On Android, v2rayNG follows the Xray core path, while v2flyNG uses the V2Fly core path. All three are community-maintained, open-source graphical clients, but their interfaces and available features vary by app.
When moving between devices, check the subscription source or server details first rather than copying old toggle settings. Desktop system proxy settings and connection permissions on mobile devices are different operating system mechanisms. Server details may be similar, but the steps to start a connection depend on each app’s interface.
Open-source projects: track what actually changes
Cores and clients are maintained by their respective communities. Open source means implementations and changes can be discussed publicly; it also means the graphical interface, core, and install packages don’t have to be released at the same time. If a field appears in a different place than in a guide, search for it by name and check the core information in the client. Don’t assume a feature was removed based on a screenshot alone.
Before updating an app, note your subscription groups, routing mode, and DNS settings. If something changes after the update, review in this order: selected server → whether the core starts → whether the system proxy or TUN is active → routing and DNS results. This helps distinguish configuration changes from differences caused by the software update.
Troubleshooting: start with the symptom
No new servers after updating a subscription? Check which group you updated and whether a keyword filter is hiding entries. Then see subscription FAQs.
The client shows connected, but websites won’t load in your browser? Check the system proxy first, then routing and DNS. Follow the troubleshooting guide to check each layer.
New to the client and unsure what to do first? Follow the quick-start guide to import a configuration, select a server, and test the connection.
Not sure which Android client to choose? Check which core features your configuration requires, then see the client comparison. Don’t choose based on similar app names alone.
NOTES / Technical Notes
Explore the reasoning behind common settings
These three articles cover DNS, subscription organization, and core differences. Before changing advanced settings, check when they apply, then make adjustments in the client one at a time.