From system proxy to traffic routing, first decide which traffic to handle, then choose the corresponding client feature. The examples below illustrate configuration structure; in practice, follow the client interface and fields supported by the current core.
Understand the Difference Between a Local Listener and System Proxy
A local SOCKS inbound accepts proxy requests from applications. System proxy settings direct applications that follow the operating system’s settings to that local port. They are separate controls. For everyday browsing, start by enabling “Automatically configure system proxy.” Check PAC mode when traffic should be routed based on its destination. Terminals and browsers with their own proxy settings may use different configurations, so the menu bar status alone does not confirm that they are connected. If a page will not load, check the local port, system proxy target, and current server status one by one. This is more useful for troubleshooting than repeatedly switching servers.
Routing rules send matching traffic through a specified outbound; they do not replace the server configuration. A common order is to handle explicitly direct domains and private addresses first, then send remaining requests through the default outbound. Rules are matched from top to bottom, so a broad rule near the top may override more specific entries. Before editing, confirm that the core has loaded the relevant geodata and that every outbound tag referenced by the rules exists. If a website and an application behave differently, check whether they send requests through the same local inbound. Traffic that bypasses the client is not affected by these rules.
Keep Subscription Sources Separate from Server Selection
A subscription group stores an update source; the server list inside it is the result of an update. After adding a URL, update the subscription and confirm that servers appear in the list, then select one to use. If you manage multiple sources, give each group a recognizable name so you can tell where its entries came from. Subscription updates may change server names and order, so do not rely on list position to remember a frequently used entry. If an import fails, check that the URL is complete and returns a format supported by the client, then check your network connection. Do not import a subscription URL as though it were a single server configuration.
Subscription group: Work
Update subscription → Check server list → Select an active server
Manage subscription sources and local routing rules separately
Handle Apps That Ignore System Proxy Settings
TUN mode uses a virtual network interface to capture eligible system traffic, making it useful for applications that do not follow system proxy settings. Its scope differs from a standard system proxy, and it may require additional system permissions. Before enabling it, confirm that a regular proxy connection works, then review the TUN settings and routing options for your platform. If local network access stops working, check private-address routes, DNS, and exclusion rules first rather than changing the server protocol. When you are done, turn off TUN in the client and confirm that the operating system’s network settings have returned to the expected state.
Connection checks, in order:
Standard system proxy → DNS settings → TUN virtual interface
Local network access issues → Check private-address routing
The Client Interface and Core Have Different Roles
v2rayN provides a graphical interface for subscriptions, server selection, and proxy modes; the selected core handles protocol processing. Xray and V2Fly are related but independently maintained core families. Whether a protocol or transport setting is available depends on the core and the configuration options exposed by the client. Before switching cores, note which connection methods currently work and confirm that the target core supports the existing server parameters. Then restart the relevant services and test the connection. If startup fails, check the client logs for reported fields or process errors; they are more informative than the system proxy icon alone.
Client: v2rayN
Core selection: Xray / V2Fly
Check in order: Protocol support → Configuration fields → Startup logs
Use v2rayN on desktop. On Android, choose between v2rayNG and v2flyNG based on your core requirements. Check your operating system and processor architecture before opening the downloads for your platform.
Not sure which build to choose? The download page lists installers, architectures, and system requirements by platform. Browse all clients →
FIRST CONNECTION / 03
From Installation to Your First Connection
First, get one server working with the standard system proxy. Then adjust routing, DNS, or TUN settings. Change one type of setting at a time so you can understand the results.
01
Install and Import
Install the client for your system architecture. In subscription settings, add the URL provided by your service provider, update the subscription manually, and confirm that servers appear in the list. If you received a link for a single configuration, use the client’s link import feature instead of the subscription group option.
02
Choose a Server and Mode
Select a server as the active configuration, start the core, and enable system proxy. Test the basic connection in standard proxy mode first. If you need to handle traffic differently based on its destination, open routing settings and check the rule order and outbound tags.
03
Test the Connection and Troubleshoot
Use an application that follows system proxy settings to access the destination service, then check the client logs. If access fails, verify in order that the subscription has been updated, a server is selected, the local port is listening, and the application reads system proxy settings.
A server appears in the list, but the connection still fails? The list only confirms a successful import. You still need to select a server, start the core, and check the system proxy status. See the connection steps →
Your browser works, but your terminal cannot connect? Terminals usually need proxy environment variables configured separately. Check that they point to the local port used by the client. Learn about proxy modes →
Some sites stopped loading after you changed routing? Check domain rule order, DNS results, and the corresponding outbound. Restore the last working settings first, then adjust one item at a time. Read the routing guide →
OPEN SOURCE / 04
Project V, Cores, and Clients
The interface manages configuration; the core handles connections. Understanding this distinction makes error logs easier to interpret and helps avoid confusing client features with protocol support.
The Project V Ecosystem
Project V established the foundation for V2Ray protocols and configuration. A range of separate projects grew around it, including core implementations, graphical clients, and rule data. These projects are technically related, but the feature list of any one graphical client does not represent the capabilities of the entire ecosystem. When following setup instructions, first identify whether they cover client operations, core parameters, or connection details supplied by a server. The same terms can appear at different layers. Knowing which layer you are working with before changing settings can save troubleshooting time.
V2Fly and Xray
V2Fly continues development of the V2Ray core; Xray is another independently maintained core family in the related ecosystem. Both can handle connections, but their supported protocols, transport options, and configuration fields may differ. If a server configuration requires a particular feature, check both the client’s import method and the currently selected core. If parsing fails, note the field in the error and consult the relevant core’s documentation rather than judging compatibility by the client’s name alone. Multiple cores let you choose one that fits your configuration; they do not make a single configuration automatically compatible with every implementation.
What Sets the Three Clients Apart
v2rayN is for desktop environments on Windows, macOS, and Linux, bringing server management, subscription updates, system proxy, and routing controls together. On Android, v2rayNG uses the Xray core, while v2flyNG offers an alternative with the V2Fly core. All three are open-source projects, but their interfaces, release schedules, and feature sets differ. Choose based on your operating system, required core, and configuration needs. Even when using the same subscription across devices, check each device’s proxy mode and local rules separately.
Protocols and Update Scope
The projects use open-source licenses; refer to each project’s published information for specific terms. Licenses in the ecosystem include GPL-3.0 and MIT. Clients, cores, and rule data may be maintained on separate schedules, so updating one component does not necessarily change another’s behavior. Before making major configuration changes, keep a working setup and note the client, core, and operating system in use. These details are more useful for troubleshooting than a vague report that a connection does not work. The download page lists installers by platform, while the Advanced handbook covers configuration in detail.
To explore subscription filtering, DNS, FakeDNS, and custom outbounds, read the Advanced Handbook →
TECHNICAL NOTES / 05
Recent Technical Notes
Practical troubleshooting steps for startup failures, port conflicts, and first-time setup. Each article covers a specific, reproducible configuration scenario.