A complete path through client selection, subscription imports, and split tunneling for desktop systems and Android. Configuration steps match the actual settings in v2rayN, v2rayNG, and v2flyNG.
Settings are explained in the order they are used. Start with subscriptions and nodes, define the traffic scope next, then configure routing and DNS policies to avoid changing several variables at once.
Subscription groups keep node sources manageable when several providers and custom configurations are involved. v2rayN can place each subscription or self-managed configuration in a separate group and update only the selected source; v2rayNG is better suited to keeping a small set of frequently used configurations on mobile. After importing, check the group name, update time, and protocol fields, then filter by alias or address. Do not treat updating a subscription and switching the active node as the same action.
For everyday use, keep clear groups such as “Daily use,” “Temporary testing,” and “Custom configurations.” Before deleting a subscription, confirm that the active connection no longer references it. Filtering only changes which entries are displayed; it does not modify the subscription source. To permanently exclude a type of node, add keywords in the client’s server filtering rules.
View subscription management guide →Routing rules are more than a simple “global or direct” switch: they are ordered conditions evaluated from top to bottom. The client uses domains, IPs, ports, inbound tags, or process names to send traffic through a proxy, directly, or to a blocked outbound. A practical starting point is to send local network traffic and commonly used regional resources directly, apply the current proxy policy to everything else, and place blocking rules where their intent is clear.
Rule order directly affects the result. Narrower, more explicit entries usually belong first, with the catch-all rule at the end. After editing, reconnect and test separate targets that should match direct and proxied conditions. If an application behaves unexpectedly, first confirm that it is within the client’s traffic capture scope, then inspect the rules.
View routing rules in practice →The system proxy only affects programs that actively read the system proxy settings. Some command-line tools, game launchers, and apps with their own network stacks may bypass it. TUN mode uses a virtual network interface to receive a broader range of traffic, then lets the client core apply routing. It is useful when several applications need unified traffic capture, but should not be enabled blindly when the system proxy already meets the need.
Before enabling it, confirm that the client has permission to create a virtual interface, and close tools that may compete at the same network layer. After connecting, test web access first, then check the target application. If local devices become unreachable, review LAN bypass and strict routing settings. Disconnect normally before exiting the client so the system network state can be restored as expected.
View TUN mode configuration →DNS determines which address a domain resolves to first; routing rules then use that result to choose an outbound. When DNS policy and traffic direction disagree, a domain can be classified correctly while the connection still takes the wrong path. A sound setup separates local resolution, remote resolution, and query-matching conditions, while preserving enough domain information for domain-based routing.
When troubleshooting, clear system and application caches, then reconnect the client. If only a few domains fail, inspect domain rules and DNS server groups. If every domain is affected, check the query strategy, listening address, and TUN DNS capture. FakeDNS suits specific transparent-proxy scenarios and should not replace an existing setup without understanding its mapping mechanism.
View DNS optimization methods →223.5.5.5
https+local://1.1.1.1/dns-query
UseIP
v2rayN is the primary desktop entry point for Windows, macOS, and Linux. On Android, choose between v2rayNG and v2flyNG. The download page further separates system architectures and package formats.
Choose the v2rayN desktop edition or the classic WPF edition. The desktop edition uses a cross-platform interface, while WPF suits users who prefer the traditional Windows workflow. Both support subscriptions, the system proxy, routing rules, and TUN mode.
Go to downloadsUse the v2rayN desktop client and choose the Apple Silicon or Intel installer for your processor. On first launch, complete the system security confirmation and grant network permissions, then import a subscription and enable the system proxy.
Go to downloadsv2rayNG with the Xray core is the preferred choice; choose v2flyNG when the V2Fly core is required. Most modern devices use the arm64 architecture. If you cannot confirm the architecture, choose the universal installer. Subscription workflows are similar in both clients.
Go to downloadsv2rayN provides packages for common Linux distributions. Choose deb or rpm according to your package manager, then select x64 or arm64 for the processor architecture. After installation, the subscription and routing interfaces are similar to those on other desktop platforms.
Go to downloadsClient names, core names, and protocol names belong to different layers. Understanding their relationships makes it easier to choose software, read configurations, and pinpoint problems in logs.
Project V established an open-source ecosystem centered on composable network proxy capabilities. In common configurations, inbound and outbound connections, routing, DNS, transport methods, and protocol parameters all follow this modular approach. Users interact with a GUI client, but the client core handles connections, protocols, and routing. As a result, the same subscription may expose similar fields across clients, while differences in core capabilities and integration status can still produce different settings.
When reading a guide, first identify which layer contains the problem. A subscription that cannot be added usually involves client input or subscription formatting; an unrecognized protocol parameter may indicate core support; a system proxy that does not affect the target application calls for checking the operating system’s proxy mechanism; an unexpected routing result requires reviewing rule order, DNS resolution, and outbound tags. Layer-by-layer troubleshooting is more effective than repeatedly reinstalling the client.
The V2Fly community continues to maintain and extend core V2Ray capabilities, with a configuration structure focused on modular composition and compatible evolution. Xray has developed its own core implementation and feature extensions within a similar configuration model. Neither is a GUI client, and neither is synonymous with a particular protocol. They execute inbound listeners, outbound connections, rule matching, DNS queries, and transport parameters.
Many basic settings can be understood correspondingly across the two core families, but the client’s currently integrated core remains authoritative for exact fields, support, and defaults. When copying a configuration from another client, do not stop at matching protocol names. Also verify the transport method, security parameters, server name, path, fingerprint options, and routing tags.
v2rayN is the main desktop choice for Windows, macOS, and Linux, with GUI settings for subscription groups, server filtering, the system proxy, routing rules, DNS, TUN, and logs. v2rayNG targets Android and usually runs the Xray core, making it suitable for managing mobile connections through subscriptions or share links. v2flyNG also targets Android, but uses the V2Fly core and serves as an alternative when that core family is required.
All three applications continue to be maintained through open community collaboration, with code and change records available for review. Client releases and core updates do not always move in sync: after a core adds a capability, the GUI still needs parameter mapping, interaction design, and platform testing. Choose based on platform, core, and required features rather than name similarity alone.
Open-source software uses licenses to define the conditions for using, modifying, and redistributing code. For everyday users, a license primarily signals transparent provenance and clear collaboration boundaries. Teams planning custom development or enterprise deployment should read the specific license used by each project and confirm that their distribution method complies. Different clients and dependencies may use different licenses, so the terms of one component cannot be applied to the entire software stack.
Open-source status does not replace configuration review. Before importing a subscription, confirm its source and intended use. After connecting, use logs to verify the actual inbound, outbound, and routing rules in effect. When system network permissions are involved, grant only the scope the operating system requires for the client to configure the proxy or virtual network.
Client updates mainly change the interface, platform compatibility, and feature entry points. Core updates affect lower-level capabilities such as protocol implementation, routing, and DNS. Subscription updates replace or add server configurations. These tracks are related but are not the same operation. If a subscription fails to update, check its address, network, and subscription group first. If the core fails to start, inspect logs and configuration fields. Consider a client update or settings migration only when the interface itself behaves unexpectedly.
Before updating, record the current routing mode, DNS policy, and TUN status so behavioral changes can be compared quickly. Users with multiple subscriptions should update them one group at a time and observe the result, rather than changing the client, core, and every subscription simultaneously and losing a troubleshooting baseline. The Advanced Config chapter also covers custom outbounds, FakeDNS, and multi-subscription filtering.
Open the Advanced Config manual →Topics include DNS routing, connection speed, and desktop system permissions. Each article provides a check sequence by problem layer, avoiding simultaneous changes to multiple settings without a clear diagnosis.
From DNS server groups and query strategies to routing coordination, learn how to send different domains through the appropriate resolution path, then clear caches and verify that changes take effect.
Read article →Break speed problems into node status, route conditions, and local configuration, then check routing, DNS, TUN, and the target application in order to avoid unproductive switching.
Read article →Follow the system settings path to handle the first-launch restriction, then grant network access and verify the system proxy and client connection to distinguish installation issues from configuration issues.
Read article →