Windows
Use v2rayN to manage subscriptions, the system proxy, routing rules, and TUN. The download page offers a modern desktop interface and the classic WPF version, so you can choose based on your system and preferences.
Go to downloadsV2Ray Official Latest: v2rayN and v2rayNG Client Guide
A focused guide to desktop and Android clients, subscription import steps, and VMess, VLESS, and REALITY configuration. Choose the right platform entry point, then set up the system proxy and routing.
VMess
VLESS
REALITY
TUN
Routing
Core capabilities
From protocol connections to local routing
Clients bring subscriptions, proxy protocols, system access, and routing rules together. Understand what each layer does before changing parameters; this usually makes problems easier to isolate than repeatedly switching nodes.
VMess · VLESS · REALITY
Understand protocol parameters by layer
VMess and VLESS primarily define authentication and connection structure between the client and server. TCP, WebSocket, and gRPC belong to the transport layer, while TLS and REALITY sit in the security layer. Client interfaces often place these settings in one editor, but they are not interchangeable. After importing a subscription, keep the provider's protocol, address, port, transport, and security settings intact. Adjust only the system proxy and routing options you control locally.
When manual checks are needed, review settings in this order: protocol type, transport, security layer, then additional identifiers. This quickly shows whether the subscription is incomplete or the local entry point is disabled. VLESS is not tied to one particular transport, and REALITY is not a standalone client. Understanding the layers prevents changing one label while overlooking related parameters.
Routing
Choose the exit by domain and address
Routing rules decide whether a connection is proxied, sent directly, or blocked. They can match domains, destination addresses, ports, and network types, and are applied in the order listed by the client. There is no need to write a large rule set at the start. Begin with the client's basic mode, verify that websites and apps work, then add only the domains that genuinely need custom rules.
Routing problems often appear as some websites working while others or certain apps fail, or as local services being affected after the system proxy is enabled. Switch to a simple mode for comparison, then check DNS strategy and rule priority. Routing determines where a connection exits; it does not replace protocol parameters or improve the node's underlying network quality. Keeping these issues separate avoids ineffective changes.
System Proxy · TUN
Choose how broadly apps are covered
The system proxy works well for browsers and desktop apps that follow the operating system's proxy settings. The client listens on a local proxy port and points the system to it. TUN uses a virtual network interface to handle a broader range of connections, including programs that ignore system proxy settings. Their coverage differs, and they do not need to be enabled together. Choose the one that best matches the apps you use.
For a first setup, use the system proxy to verify the subscription and node before deciding whether TUN is necessary. Before enabling TUN, close similar network tools and review permission prompts, DNS handling, and local-network access needs. When exiting the client, confirm that the system proxy has been restored. If traffic loops or every app loses access, first check whether multiple programs are taking control of traffic instead of immediately changing the remote protocol.
Subscription
Manage remote nodes separately from local settings
A subscription URL retrieves a set of nodes and their connection parameters. After import, the client stores the node list locally and reads the subscription again during manual or scheduled updates. Node names, server addresses, and protocol parameters are usually maintained by the subscription; routing mode, local listening port, startup behavior, and interface preferences belong to the client. Keeping the two separate makes it clear which settings an update may replace.
If a subscription update fails, first confirm that the URL was copied in full, the system time is accurate, and the current network can reach the subscription source. If the update succeeds but the list is empty, the response format may not match the client. Keep manual nodes in a separate group so they do not get mixed with subscription content. Before changing clients, record local routing and port settings, then import them using the new client's supported method.
Platform guide
Choose a client by operating system
Use v2rayN on desktop platforms. On Android, choose between Xray and V2Fly kernel clients. The download page also separates packages by processor architecture and installer type.
macOS
The v2rayN desktop edition uses a cross-platform interface to manage nodes, subscriptions, and the local proxy in one app. Before downloading, check whether your device uses an Apple Silicon or Intel processor.
Go to downloadsAndroid
v2rayNG uses the Xray kernel and suits configurations that need features such as VLESS and REALITY. v2flyNG uses the V2Fly kernel and is an alternative client within that ecosystem. The download page offers arm64 and universal packages.
Go to downloadsLinux
The v2rayN desktop edition supports common Linux desktop environments. The download page provides deb and rpm packages by processor architecture, suited to users who prefer managing subscriptions and routing through a graphical interface.
Go to downloadsGetting started
From subscription import to connection testing
Keep the first setup simple. Once you have a repeatable connection workflow, adjust auto-start, TUN, and custom routing one at a time.
-
Install the client for your platform
Choose v2rayN on Windows, macOS, and Linux. On Android, start with v2rayNG or choose v2flyNG based on the required kernel. Desktop packages must match the operating system and processor architecture; Android devices use either arm64 or universal packages. After installation, launch the client normally and confirm that the main window, tray entry, or system status area is accessible before importing configuration.
-
Import the subscription and update nodes
Add the URL in subscription management, save it, and run one manual update. Once nodes appear, leave the protocol, transport, and security settings unchanged because they are usually supplied by the subscription. Test a node and check the client log for address-resolution, authentication, or timeout messages. If the list is empty, check the subscription URL and system time before switching proxy modes repeatedly.
-
Enable an entry point and verify routing
On desktop, start by enabling the system proxy; on mobile, follow the system prompt to establish the connection. Test a browser and commonly used apps, and confirm that local websites, LAN devices, and work software behave as expected. Once the basic connection is stable, decide whether to use TUN, startup launch, scheduled subscription updates, or custom routing. Change one category of setting at a time so the source of each change stays clear.
Open-source ecosystem
How Project V, V2Fly, and Xray relate
Clients, kernels, and protocols are different layers. Understanding how they relate helps you choose an app and brings troubleshooting back to the component involved.
Project V
The protocol and proxy-tool ecosystem
An open-source technology ecosystem built around proxy protocols, transport methods, routing capabilities, and client tools.
A community fork continuing v2ray-core
It retains VMess, VLESS, routing, and multiple transport capabilities, and many clients continue to use these configuration concepts.
Extending transport and security-layer capabilities
It continues to add protocol combinations and transport features within a similar configuration model, often used with v2rayN and v2rayNG.
Ecosystem history and naming
V2Ray was first widely known as a core component of the Project V ecosystem. Over time, community development formed two major kernel families: V2Fly and Xray. Today, “V2Ray client” usually does not mean one specific program; it refers to graphical apps that manage these kernels, subscriptions, and protocol configurations. v2rayN, v2rayNG, and v2flyNG operate at the client layer, handling the interface, configuration management, and system integration, while the embedded core handles connections and routing.
This layered model also explains why different clients expose similar protocol fields. VMess, VLESS, transport methods, TLS, REALITY, and routing rules come from the kernel configuration model; clients simply present them in ways suited to desktop or mobile devices. When a connection fails, first identify whether the issue involves the client interface, system permissions, kernel startup, subscription content, or the remote connection. The app name alone is not enough to determine the cause.
Kernel families and configuration compatibility
V2Fly and Xray retain many similar configuration concepts, so VMess, VLESS, inbound, outbound, and routing rules are broadly comparable. However, their feature sets and exact fields are not always identical. A transport feature available in Xray does not mean the same configuration can be passed directly to V2Fly; subscription conversion may also omit parameters the client does not recognize.
Choose a kernel based on the protocols and security layers actually present in the subscription. When REALITY or a specific XTLS combination is required, a client using the Xray kernel is usually the better fit. If the configuration explicitly targets V2Fly, use the matching kernel. Do not convert configurations simply to gain more switches. Feature compatibility, readable logs, and reliable updates matter more than the number of options shown in the interface.
Open-source licensing and auditability
These projects are maintained by the community as open source, allowing developers to review software behavior, configuration structures, and change history. The value of open source lies in discussable technical processes, reviewable implementations, and collaboration around related configuration formats. It does not replace the user's own configuration judgment: the subscription source, server deployment, system environment, and local routing still directly affect connection results.
Clients are free to use, and the community has built up protocol and kernel documentation over time. For most users, the practical approach is to start with a stable client entry point, keep the app and kernel on the same maintenance track, and read logs and the relevant protocol documentation when problems occur. For developers, a clear configuration model and reviewable implementation make compatibility differences easier to locate and issues easier to report to the right component.
Client roles and update cycles
v2rayN targets Windows, macOS, and Linux desktops, managing subscriptions, nodes, kernels, the system proxy, and routing in one place. v2rayNG targets Android and focuses on Xray kernel capabilities. v2flyNG also targets Android, but belongs to the V2Fly kernel ecosystem. They address different platform and kernel choices, so there is no need to run multiple similar clients on the same device.
Client updates and kernel updates may follow different schedules. Interface features, system compatibility, and installation methods are maintained by the client; protocol support, transport implementation, and routing behavior depend more on the kernel. If something changes after an update, first identify which layer changed, then check whether settings were migrated. Keeping the subscription URL, common routing decisions, and local port records makes migration more orderly.
Technical notes
Protocol, installation, and speed troubleshooting
Common issues explained through connection structure and troubleshooting steps, covering protocol fundamentals, client settings, and fault isolation.
Why REALITY and XTLS Vision can be fast: handshake overhead and forwarding paths explained
Understand REALITY's connection model at the TLS handshake layer, then see how XTLS Vision reduces repeated processing along the forwarding path and which connection conditions suit this configuration.
Read the full articleFirst-time v2rayN installation and setup: key points for Windows and macOS
Covers environment preparation, first-launch checks, system proxy and port settings, plus the right order for handling kernel prompts, auto-start, and browser connection issues.
Read the full articleHow to troubleshoot slow V2Ray speeds: a three-layer method for nodes, network paths, and local settings
Breaks speed issues into node response, network conditions, and local settings, explaining what latency results, protocol changes, Mux, and routing rules can reveal.
Read the full articleSelected frequently asked questions
What to check after installation
Most first-connection problems can be isolated in a consistent order: subscription content, system time, local entry point, node status, and routing rules.
Which should I choose, v2rayN or v2rayNG?
Choose v2rayN on Windows, macOS, and Linux desktops, and v2rayNG on Android. Their interfaces and system integration differ, but both work with subscriptions, nodes, proxy protocols, and routing rules. Do not use a desktop installer on a mobile device or apply one platform's interface instructions step by step to another.
What should I do if no nodes appear after importing a subscription?
Run one manual update first, confirm that the subscription URL was copied from beginning to end, then check the system date, time, and time zone. If the update reports no error but the list remains empty, confirm that the returned content uses a subscription format supported by the client. Before adding the subscription again, remove any accidental spaces at either end of the URL.
What is the difference between the system proxy and TUN mode?
The system proxy mainly affects apps that actively read the system proxy settings and is simple to configure for initial testing. TUN takes over a broader range of connections through a virtual network interface, but relies more on system permissions, DNS settings, and the state of other network tools. Verify the node with the system proxy first, then decide whether TUN is needed for your apps.
Why can a latency test pass while webpages still fail to load?
A latency result only shows that one type of probe received a response; it does not confirm that a complete webpage connection succeeded. Check whether the intended node is selected, the system proxy is active, the browser is using a separate proxy, DNS resolves correctly, and routing rules send the connection through the expected exit. See the getting started guide for detailed steps.