Find the v2rayN desktop client, Android clients, and Chinese configuration guides in one place. Follow platform-specific steps for installation, subscription imports, proxy modes, and routing checks.
SYSTEM MODULES
Once subscription data enters the client, it passes through protocol parsing, routing decisions, DNS queries, and local proxy handling. Review what each module covers and what to verify when changing settings.
The routing engine evaluates conditions such as domains, destination addresses, ports, and processes, then sends each connection to the selected outbound. A common setup keeps LAN traffic and direct-connection ranges on their original path while sending everything else through the proxy. Rule order affects which rule matches, so record the current mode before making changes, test a few clear conditions first, and expand gradually. v2rayN includes preset routing modes and custom rule controls. Most users should start with a preset, then inspect domain rules, address rules, and the final fallback when a specific site takes an unexpected path.
Subscription management stores subscription URLs, requests remote content, parses nodes, and adds them to client groups. After adding a URL, run an update and check the result; saving the URL alone does not create selectable nodes. When using multiple subscriptions, label their sources clearly and check the current server-list filters so imported nodes are not hidden in another group. If an update fails, first verify that the URL is complete, the network is reachable, and the system clock is accurate before deciding whether to add it again. A share link describes one node, while a subscription is a continuously updated collection.
The protocol stack converts a node’s address, port, user identifier, transport method, and encryption-related parameters into core configuration. VMess and VLESS describe the protocol layer, while TCP, WebSocket, and gRPC belong to the transport layer; both must match the server’s specified combination. If import fails or a connection carries no data, check more than the protocol name: verify the transport type, path, hostname, and TLS fields as well. Clients usually parse standard share links, but manual edits are sensitive to stray spaces, incorrect ports, and misplaced fields, any of which can prevent the final configuration from starting.
The DNS module resolves domains to addresses and can select different DNS servers by domain category. It interacts with routing rules: a domain may be matched at different stages before and after resolution, and an incorrect lookup result can send an otherwise correct route to an unexpected outbound. After installation, keep the client defaults until basic connectivity works, then enable more complex routing. If a domain fails while its direct address works, check DNS server reachability, query mode, cache state, and whether the system proxy is affecting the application making the lookup.
The system proxy writes local HTTP or SOCKS listening addresses into the operating system’s proxy settings, allowing browsers and most desktop apps that follow system configuration to route traffic through the client. Its scope is easy to understand, and enabling or restoring it is straightforward, but some apps ignore system proxy settings and require their own configuration. When testing, confirm that the client core is running, the system proxy has switched on, and the browser has not retained an old connection. Restore the system proxy normally before quitting the client so the system does not keep pointing to a stopped local port.
TUN mode receives traffic through a virtual network interface, making it suitable for programs that do not read system proxy settings and generally giving it broader coverage. Enabling it may require network-interface or administrator permissions. Also check whether the local firewall, virtualization software, or other network tools are changing routes at the same time. For a first setup, avoid stacking multiple traffic-capture methods: disable extra network tools, confirm that TUN works on its own, and restore other components one at a time. If LAN devices become unreachable, check bypass addresses, the default route, and the scope of DNS handling.
PLATFORM ENTRY
Choose the platform for your current device first, then select the client by processor architecture and package format. The homepage provides platform navigation; files, version details, and system requirements are centralized in the download center.
desktop / x64
v2rayN is the main desktop choice. The download page offers both the newer cross-platform desktop interface and the classic WPF interface for everyday proxy use, subscription management, and routing configuration. Check your system architecture first, then choose the interface that suits your workflow.
Go to downloadsdesktop / arm64 · x64
On macOS, use the v2rayN desktop client and select an installer for Apple Silicon or Intel. On first launch, allow the app in system settings and confirm network permissions before importing a subscription and switching the system proxy, so permission issues are not mistaken for node problems.
Go to downloadsmobile / arm64 · universal
On Android, choose between v2rayNG and v2flyNG. v2rayNG uses the Xray core and is the usual first choice; v2flyNG uses the V2Fly core and can serve as an alternative when subscription compatibility calls for it. Most current devices use arm64; if you are unsure, check the universal-build notes.
Go to downloadsdesktop / deb · rpm
For Linux desktops, use v2rayN and choose a deb or rpm package for your distribution. Debian and Ubuntu systems generally use deb, while Fedora and RHEL systems generally use rpm. Also distinguish x64 from arm64, then check the desktop launcher and autostart settings after installation.
Go to downloadsOPEN SOURCE ECOSYSTEM
V2Ray-related names span several layers: the project ecosystem, core implementations, graphical clients, and protocol configuration. Separating each layer’s role makes installation and troubleshooting more straightforward.
Project V grew into an open-source ecosystem built around proxy protocols, transport methods, routing rules, and configuration formats. In everyday searches, “V2Ray” may refer to protocol capabilities, a core program, or any graphical client that reads compatible configuration. Users typically operate v2rayN, v2rayNG, or v2flyNG; the client handles the interface, subscriptions, and system integration, while the underlying core establishes connections, applies routes, and processes protocols. Treating the graphical interface and core as separate layers helps explain why client updates, core updates, and subscription updates are not the same thing.
V2Fly carries forward V2Ray core capabilities under ongoing community maintenance, while Xray has evolved independently while remaining compatible with some existing configurations. Both can handle common protocols and routing setups, but available features, field details, and release cadence may differ. Whether a subscribed node works depends not only on the client name but also on whether its selected core supports the required protocol, transport layer, and extension parameters. If import succeeds but the configuration will not start, read the first configuration error in the client log and compare it with the current core’s capabilities instead of repeatedly deleting the same subscription.
The three clients and their related cores belong to an open-source software ecosystem. Source licenses define the conditions for viewing, studying, modifying, and redistributing code. Different components may use different licenses, so follow the license text included with the relevant project when redistributing or integrating software. Open source does not mean that every third-party subscription is maintained by the client project, nor that a node service belongs to Project V. The client, core, subscription provider, and local network are separate parts of the system; troubleshooting requires confirming responsibility for each one.
Client updates mainly change the interface, platform support, and configuration management; core updates may add protocol capabilities, fix configuration parsing, or change network behavior; subscription updates retrieve a fresh node list from an existing URL. Keep these three update types separate. In normal use, first confirm that the current client starts, then update the subscription and test a known configuration. Consider upgrading the client or core only when logs identify an unsupported field or a platform compatibility issue addressed by a newer release. Record proxy modes, routing plans, and custom settings before upgrading so you can compare the changes.
QUICK ANSWERS
Understanding the difference between the client, subscription, and proxy mode before installation can prevent repeated configuration work. More categorized answers are available on the FAQ page.
01 / CLIENT
Use v2rayN first on Windows, macOS, and Linux desktops. On Android, start with v2rayNG in most cases; choose v2flyNG when the configuration specifically requires a V2Fly core path or when you need to compare the behavior of the two cores. The client name determines the interface and platform, while the selected core handles the protocols.
Read the client selection guide →02 / SUBSCRIPTION
vmess:// or vless:// usually describes a single node and creates one server entry when imported. A subscription URL returns a refreshable set of nodes that the client manages by group. With only a share link, import it directly from the clipboard; with a subscription URL, add it in subscription settings and run an update.
03 / MODE
For a first setup, start with the system proxy. Its coverage is easy to observe, and it makes it simple to verify common apps such as browsers. Evaluate TUN when a program does not read system proxy settings. Before enabling TUN, understand the changes to virtual interfaces, permissions, routing tables, and DNS handling, and avoid running multiple traffic-capture tools at once.
Review proxy mode terminology →04 / TROUBLESHOOTING
First confirm that the client core has started. Then check whether the subscription updated successfully, the intended node is selected, and the system proxy is enabled. Next, read the first clear error in the log and distinguish DNS resolution, unreachable ports, invalid configuration fields, and permission problems. Change one variable at a time; replacing the client, node, and proxy mode simultaneously makes the cause harder to isolate.
Open the troubleshooting FAQ →LATEST GUIDES
Step-by-step guides covering platform installation, share-link imports, and startup problems. Download links in each article lead to the download center, while configuration steps follow the relevant client interface.
For Debian, Ubuntu, and Fedora-based distributions, covering package formats, installation commands, desktop launcher fixes, and systemd user service setup.
Read the article →Step-by-step instructions for allowing the app in system settings, handling the first-launch prompt, and granting local network and proxy permissions while separating installation blocks from node connection problems.
Read the article →Explains the structural difference between single-node share links and subscription URLs, with clipboard import and group updates in v2rayN and v2rayNG.
Read the article →