CLIENT ROUTING / Chinese Setup Guides
A central resource for v2rayN and v2rayNG client access, subscription import steps, and routing troubleshooting, with setup instructions based on real desktop and mobile interfaces.
LINK INSPECTION
Client connection problems are rarely caused by a single switch. First confirm that the configuration reached the client, then check whether the core starts, the routing rules match, and system traffic reaches the local port. The checks below follow the real connection path, with each item tied to an actionable interface step.
INPUT / SUBSCRIPTION
Both the v2rayN desktop client and v2rayNG on Android support subscription URLs and single-node share links, but their entry points, group concepts, and update actions are not identical. After importing, check that the nodes appear in the target group, manually run a subscription update, and then select a specific node as the current server. Saving a URL in subscription settings alone does not add nodes to the main list. If an update fails, do not repeatedly remove and reinstall the client; instead, check the URL, device time, current network, and log output in order.
These guides separate “save subscription,” “update group,” and “select node” into distinct steps instead of mixing three actions together. Compared with brief instructions that only point out button locations, this order makes it clear whether a failure occurs during input, parsing, or selection, and makes configuration easier to transfer between different client interfaces.
CORE / PROTOCOL
The graphical client handles subscription management, system proxy settings, route editing, and log display. The core handles protocol handshakes, transport, and outbound connections. v2rayN works with configuration structures in the Xray and V2Fly ecosystems, v2rayNG primarily targets the Xray core, and v2flyNG offers an Android option based on V2Fly. When choosing a client, start with the platform and workflow, then confirm that the required protocol and transport combination is supported by its core.
VMess, VLESS, Trojan, and Shadowsocks are protocol-layer options, while TLS, WebSocket, and gRPC belong to security or transport combinations. A configuration cannot be judged complete by its protocol name alone. These guides identify related fields such as the address, port, user ID, transport, TLS, and serverName to reduce failures caused by changing only one setting.
MATCH / OUTBOUND
Routing is not simply a matter of dividing domains into two groups. The client checks destination domains, destination IPs, processes, or ports in rule order, then sends the first matching traffic to a proxy, direct, or blocked outbound. Rules that are too broad can override later conditions, while rules that are too narrow may miss other domains used by the same service. After editing, confirm that the rule set is enabled and the target outbound exists, then use the logs to see which rule handled each request.
A common validation method is to keep a minimal rule set first, confirm basic connectivity, and then add LAN direct access, common service groups, and custom domains one at a time. This identifies which condition changed the result. If a browser works but a terminal program does not, also check whether that program reads the system proxy instead of attributing the issue directly to routing rules.
LOG / DIAGNOSIS
A client timeout only means that the connection did not complete within the allotted time; it does not prove that the subscription or node has failed. Start by checking whether the core started successfully, then verify DNS resolution, TCP connectivity, the TLS handshake, protocol authentication, and the routing outbound. Each stage points to different fixes: an incorrect system clock can affect certificate validation, a mismatched serverName can affect TLS, and a busy port can prevent the local proxy from listening.
The troubleshooting guides organize checks as “client startup → local port → domain resolution → remote handshake → application access,” with a stopping condition for each step. Confirming one stage before moving to the next avoids introducing new variables by changing multiple switches at once and makes it easier to restore the last working configuration.
PLATFORM ENTRY
Each platform uses different installer formats and permission models. Use v2rayN on desktop systems; on Android, choose between v2rayNG and v2flyNG according to core requirements. Platform links open the corresponding tab on the download page rather than linking directly to packages from the homepage.
DESKTOP
Use v2rayN to manage subscription groups, node selection, the system proxy, and routing rules. The download page offers a next-generation desktop interface and a classic WPF interface. The former suits users who want a consistent cross-platform workflow, while the latter suits users familiar with traditional Windows menus. After installation, confirm the system architecture and follow the guide to complete the first subscription update.
Go to DownloadsDESKTOP
The v2rayN desktop client provides installers for different processor architectures. Open system information to determine whether the device uses Apple Silicon or an Intel processor; choosing the wrong architecture may prevent the package from starting. On first launch, complete the system’s app verification prompts and explicitly enable the required system proxy mode in the client.
Go to DownloadsMOBILE
v2rayNG suits users who need Xray protocol support and per-app proxying, while v2flyNG is an alternative based on the V2Fly core. On the first connection, the system asks for permission to start a local VPN service; this permission only hands app traffic to the client. To reduce background disconnections, also review battery-saving policies and add the client to the list of apps allowed to run in the background.
Go to DownloadsDESKTOP
v2rayN provides desktop installers for common software package systems. Choose deb on Debian or Ubuntu, and rpm on Fedora or Rocky Linux; also distinguish between x64 and arm64 architectures. If the browser works after connecting but terminal programs do not, configure proxy environment variables or use a suitable traffic access method.
Go to DownloadsQUICK START
You do not need to adjust every advanced option during initial setup. Build a minimal working path first, then add routing and split-tunneling rules according to the apps you need. This makes it faster to determine whether the issue lies in the configuration, node, or system traffic entry point.
STEP 01 / IMPORT
In v2rayN, open the “Subscription Groups” manager, add a subscription name and complete URL, save it, return to the main interface, and run an update. In v2rayNG, open subscription settings, save the URL, and trigger a subscription update from the menu. Afterward, check whether the node count and names changed before selecting a node as the current server. If the list is empty, review the update message and logs first rather than opening system proxy settings; the client does not yet have a usable remote configuration.
STEP 02 / CONNECT
On desktop, start the selected node first and confirm in the logs that the local proxy port is listening, then enable the system proxy according to your needs. The system proxy is usually enough for browsers and desktop apps that read system settings; terminal tools, specific apps, and programs that ignore system settings need proxy environment variables or a more complete access method. On Android, select a node, start the connection, and approve the local VPN service when prompted.
STEP 03 / VERIFY
A connection button showing “started” only means that the client workflow has begun. Open an app that actually needs network access, check whether its request appears in the client logs, and confirm that the routing rules selected the expected outbound. If no request appears, focus on the system proxy, the app’s proxy settings, or Android per-app scope. If a request appears but the handshake fails, check node fields such as the device time, address, port, TLS, and serverName.
OPEN ECOSYSTEM
Client names, core names, and protocol names often appear together, but they belong to different layers. Understanding the relationship between them makes it easier to choose a client that fits the platform, node configuration, and required features.
Project V provides the foundational context from which the V2Ray ecosystem developed. V2Ray Core built a composable configuration model around inbound and outbound connections, routing, DNS, transport, and policies. A graphical client is not the network capability itself; it turns configuration management, system integration, and runtime status into an actionable interface. Server addresses, ports, user IDs, transports, and routing rules shown in the client must ultimately be converted into configuration the core can read.
This layered structure explains why the same subscription can be imported into different clients yet produce different results because of core support, field mapping, or client release timing. During troubleshooting, first determine whether the interface failed to save the configuration, the subscription was parsed incompletely, or the core could not recognize a protocol parameter. Do not classify every problem as an unavailable node.
V2Fly continues the community-maintained direction of V2Ray Core, focusing on modular proxy capabilities and routing and transport combinations. Xray extends protocol and transport capabilities within a similar configuration model. They share concepts such as inbound and outbound connections, routing rules, DNS, and policy settings, but their supported features, field details, and release schedules are not identical. When a subscription contains a particular protocol or transport combination, confirm that the core currently used by the target client can process those fields.
Differences between cores do not mean that every user must edit complex configurations manually. In most cases, the client generates a configuration from the subscription and starts the corresponding core. Inspect the core and configuration structure only when logs report an unsupported field, subscription conversion omits a parameter, or custom routing is required. The related guides clearly distinguish client-interface steps from judgments that require core logs.
LICENSE
v2rayN, v2rayNG, v2flyNG, and the related cores are maintained as open-source projects. Open-source licenses define the basic boundaries for using, modifying, and distributing code, while community contributors can improve protocol compatibility, platform support, interface features, and bug fixes. For everyday users, the most direct value of open source is that client and core responsibilities, configuration structures, and change discussions are publicly documented rather than controlled entirely by a single closed interface.
MAINTENANCE
Graphical clients and proxy cores may follow different release schedules. Client updates usually affect the interface, subscription management, system proxy, and platform compatibility; core updates more often affect protocol implementation, transport combinations, routing, and DNS behavior. When a new protocol is not recognized, check both whether the client supports the configuration and whether its core includes the required capability. Before upgrading, save existing subscription groups and custom routing rules so settings can be restored step by step.
SELECTION
Use v2rayN on desktop platforms to manage Windows, macOS, and Linux configurations with a similar workflow. v2rayNG is commonly used on Android, while v2flyNG is an option when the V2Fly core is required. Selection should consider more than the client name: check the subscription protocols, device architecture, system permissions, and whether per-app proxying is needed. The client comparison page explains the positioning, supported platforms, and functional boundaries of all three.
COMMON CHECKS
These are four of the most common situations during first-time installation and everyday use. Each item starts with a troubleshooting direction; follow the links to the quick-start, FAQ, or troubleshooting pages for complete steps.
Saving the URL only registers the subscription source; you must also run a subscription update. If the list is still empty, check that no characters are missing from the URL, then review the system time, current network, and update logs. Some errors identify request failures, parsing failures, or unexpected response formats. Handling the reported stage is more effective than importing the same subscription repeatedly.
View Subscription Import Steps →First check whether browser requests appear in the client logs. No requests usually mean that the system proxy is disabled, the browser uses its own proxy settings, or the local listening port does not match the system configuration. If requests appear, continue with DNS, routing matches, and the remote handshake. These two cases require different troubleshooting paths.
Troubleshoot Internet Access →Many browsers read the system proxy, while terminal programs usually rely on their own settings or environment variables. Confirm the client’s local HTTP and SOCKS ports, then set proxy variables according to the tool’s supported method. If more programs need coverage, evaluate a traffic access mode suited to the operating system. Do not assume every app is connected just because the browser works.
Troubleshoot the System Proxy →A basic connectivity test reflects only part of the network conditions. A complete connection also involves protocol authentication, TLS, serverName, transport, and the routing outbound. Make a real request and inspect the core logs to identify whether the failure occurs during resolution, connection, handshake, or authentication, then check the relevant fields instead of switching through many nodes repeatedly.
Open the FAQ →RECENT NOTES
Recent articles cover protocol comparisons, TLS certificate errors, and Android background connection settings. Each article starts with a concrete symptom or configuration task and provides fields and steps that can be verified.
This comparison organizes protocol differences across encryption, transport overhead, obfuscation, and core support, with selection guidance for home broadband, mobile networks, and resource-constrained devices. Keep the protocol layer separate from transport settings such as TLS and WebSocket while reading.
Read the Full Article →For TLS errors, first verify the device’s system time, then check that serverName matches the certificate domain, followed by the relevant security options and fingerprint settings. The article explains common errors by handshake stage instead of treating certificate problems as proof that the node has failed.
Read the Full Article →Learn what first-connection authorization does, how battery-saving policies affect background connections, and how “bypass” differs from “proxy only” in per-app routing. Useful for mobile issues such as disconnections after switching apps or connections stopping after running in the background.
Read the Full Article →