Organized download and setup paths for v2rayN, v2rayNG, and v2flyNG, with a focus on subscription import, routing, and TUN mode across common desktop and Android workflows.
The key differences between clients go beyond the installation screen: they affect how subscriptions are organized, how traffic is matched against rules, and how quickly problems can be isolated. The sections below follow the order of real-world use.
Subscription URLs deliver node parameters in bulk, while the client parses them and places them in the appropriate group. Before importing, make sure the link is complete and give each source a clear name. When updating, refresh the subscription first, then select the current node so you do not keep using an outdated list. v2rayN works well for separating multiple desktop subscriptions into independent groups, while v2rayNG and v2flyNG are better suited to a simple mobile list. Set the automatic update interval according to the provider’s update schedule; there is no need to repeatedly import the same URL by hand.
If the previous selection stops working after an update, select a node again and check its status, then see whether the subscription changed any group or node names. This preserves valid settings more reliably than deleting the entire configuration, and helps determine whether the issue comes from the subscription response or the local selection state.
The system proxy determines whether an application hands its requests to the client. Routing rules determine whether those requests are proxied, sent direct, or blocked after they enter the client. They operate at different layers and should not be conflated during troubleshooting. For regular browsers and desktop programs that follow system settings, start with automatic system proxy configuration. For more precise matching, use Bypass LAN and mainland China or Manual rules. After changing rules, test with a new connection; existing connections may continue using the previous path.
Manual rules are useful for special requirements involving domains, address ranges, and processes, but rule order affects the final result. More specific rules usually belong first, with general fallback rules later. Keeping the rule set manageable and adding entries one at a time is easier to maintain than importing a large collection of unfamiliar rules at once.
domain:geosite-cn → direct
ip:geoip-private → direct
final → proxy
When a connection fails, logs provide more useful evidence than repeatedly toggling switches. During a subscription update, check the network request, response format, and parsing result. During node connection, check DNS resolution, the handshake, transport parameters, and the remote response. If only some applications fail, return to the system proxy or TUN coverage settings. Separating failures by stage helps prevent mistaking a subscription URL problem for a node problem.
The order of timestamps in the log matters too. Clear old output, perform one deliberate action—such as updating a subscription or opening the target page—and inspect only the records generated by that action. When retries continue, address the earliest error first instead of relying on the summary in the final line.
INFO load routing rules
INFO apply system proxy
INFO subscription parsed
INFO outbound configuration ready
Use v2rayN across desktop platforms, and choose between v2rayNG and v2flyNG on Android. These platform links only take you to the relevant download section; the download page lists package types, processor architectures, and installation instructions in detail.
v2rayN is the primary choice for Windows desktops. The download page also explains the difference between the newer desktop interface and the classic WPF interface. After the first launch, follow this order: add a subscription, update the list, select a node, then configure the system proxy. This makes it easier to verify each step.
Go to downloadsOn macOS, use the v2rayN desktop client. Before choosing an installer, check whether the device uses an Apple Silicon or Intel processor; each architecture requires the corresponding file. Import the subscription after installation, then decide whether to enable TUN mode based on whether your everyday applications follow the system proxy.
Go to downloadsv2rayNG is the primary choice on Android, while v2flyNG is an alternative when you prefer its core. On most newer devices, check the arm64 package first. If you cannot confirm the architecture, refer to the universal build instructions. Both clients support subscription import and routing, but their core families and interface layouts differ.
Go to downloadsOn Linux desktops, use v2rayN. Choose deb or rpm according to your distribution’s package system, then select the file matching the processor architecture. After installation, complete subscription and proxy settings in the client first. You can then consider maintenance tasks such as launching at startup and syncing the proxy with the desktop environment.
Go to downloadsThe most common first-time setup problems usually come from doing things out of order, not from an advanced option. Import the subscription first, confirm the node and proxy mode next, and validate the result with a new network request. This quickly narrows the troubleshooting scope.
Copy the complete subscription URL, add it under the client’s subscription management, and give it a recognizable name. Save it and run an update, then confirm that selectable nodes appear. If nothing is returned, first check whether either end of the link was truncated, then review network requests and parsing messages in the log. Do not change routing or TUN settings immediately after an import failure; those options cannot repair a subscription response problem.
Choose a node from the updated group, then enable the system proxy mode that suits the current application. Browsers and most desktop applications usually read the system proxy; some programs use an independent network stack and may need their own proxy settings or TUN mode. For the first test, keep routing rules simple. Add split-routing requirements gradually after basic connectivity is confirmed.
After changing settings, close old pages or connections and send a new request. If it fails, inspect the logs generated during that action to determine whether the error occurred during DNS resolution, protocol handshake, transport setup, or system proxy takeover. Change one variable at a time and retest immediately so you know which setting affected the result.
First confirm that the URL is complete and that the device network can reach it. Then use the client log to distinguish a network error from a content parsing error. There is no need to keep switching nodes while the subscription issue remains unresolved.
View the subscription import stepsFirst check whether the program follows the system proxy. If it uses an independent network stack, review the program’s own proxy settings or consider whether TUN mode fits the current device environment.
View connection settingsExisting connections may continue using the original path. Close the active connection in the target program, send a new request, and confirm in the new log that the adjusted rule was matched.
Read the routing sectionUse v2rayN on desktop; on Android, choose v2rayNG or v2flyNG. The subscription can be the same, but client interfaces and core families may differ.
View the client listUnderstanding the boundaries between cores, clients, and subscriptions makes it easier to identify where a feature comes from. The graphical interface handles configuration and management, the core performs the actual network processing, and the subscription provides connection parameters that the client can convert into a local configuration.
Project V established an open-source ecosystem built around proxy protocols, transport methods, routing rules, and configuration structures. VMess and VLESS are protocol names within connection settings; TCP, WebSocket, and gRPC carry the data; routing rules determine which outbound handles each destination. Clients organize these fields into an operable interface, but the underlying concepts still come from the same configuration model.
“Client name” and “protocol name” are therefore not interchangeable. v2rayN, v2rayNG, and v2flyNG are graphical clients that users operate directly. VMess, VLESS, and Trojan are protocol types that may appear in node parameters. V2Fly and Xray are core families responsible for executing the configuration. When troubleshooting a connection, identify the affected layer before reinstalling anything.
V2Fly continues Project V’s community-maintained development path, evolving around protocol implementations, transport layers, routing, and inbound/outbound structures. Xray has developed its own feature set on a similar configuration model. Both can handle common subscription nodes, but their supported protocol fields, transport options, and newer capabilities are not always identical. When a provider specifies a required core, choose the client and core accordingly rather than treating an incompatible field as a failed subscription.
Inbound, outbound, and rule matching in routing configuration form the shared foundation for understanding both core families. Inbound describes how local applications hand traffic to the core; outbound describes how traffic leaves through a connection; routing selects between them. Graphical clients hide many JSON fields, but advanced options such as system proxy, TUN, split routing, and DNS still map back to these structures.
v2rayN is a desktop client for Windows, macOS, and Linux, suited to managing multiple subscriptions, switching the system proxy, editing routing rules, and viewing detailed logs. v2rayNG targets Android and commonly uses the Xray core, with an interface organized around mobile networking, VPN takeover, and subscription lists. v2flyNG also targets Android but follows the V2Fly core path, making it an option when you have a specific core or configuration preference.
The clients do not need identical interfaces. What matters more is keeping the subscription source, node parameters, and routing destinations consistent, while understanding where each client places the same feature. For example, desktop clients commonly use “system proxy” to describe how applications connect, while Android uses the system VPN interface to take over traffic. The entry points differ, but both send target requests to the local core.
These clients and cores are maintained as open-source projects, with feature discussions, bug fixes, and compatibility changes advanced by contributors from different communities. Open maintenance helps technical users understand how configurations are generated and allows protocol implementations and platform integrations to keep evolving. In practice, still pay attention to client–core compatibility, especially when new protocol fields, transport methods, or operating-system network interfaces change.
Before updating a client, record the current subscription names, proxy mode, routing choices, and TUN status. After the update, check the settings in the same order and observe the logs during one deliberate connection test. If the menus have moved between versions, use feature names and configuration meaning as your guide instead of relying only on old screenshots. This is better suited to long-term maintenance and reduces mistakes caused by interface changes.
Reusable guidance for choosing a client, completing first-time setup, and testing latency.
Compare the three clients across platform support, core family, subscription management, and routing capabilities, with selection paths for desktop and Android.
Read the full article →Verify the runtime environment, system proxy, subscription import order, startup behavior, and update interval to avoid common first-time setup omissions.
Read the full article →Explains which part of the connection each test covers and why a single latency number cannot fully represent a node’s real-world performance.
Read the full article →