Choose the installer for your chip, then set up subscription imports, system proxy, and traffic routing. Fine-tune DNS and TUN afterward.
Download Clients
Start with v2rayN on desktop or v2rayNG on Android. Check your operating system first, then your processor architecture—don’t infer whether you need arm64 or x64 from a device’s appearance. The download page lists installers for each platform, with version details on the corresponding client cards.
v2rayN · Desktop / WPF
The desktop edition uses a cross-platform interface, while the WPF edition retains its classic layout. If you already have a configuration, back it up before choosing the version that suits your workflow. For a fresh install, check the download page’s system requirements, and don’t configure both versions as the system proxy at the same time.
Go to downloads Windows client→v2rayN · Apple silicon / Intel
Open About This Mac from the Apple menu. Choose arm64 if it shows an Apple chip, or x64 if it shows an Intel processor. After downloading the disk image, move the app to Applications before opening it rather than running it from the mounted image.
If macOS shows a security alert on first launch, verify the source and app name, then review the relevant notice under Privacy & Security. Start by testing browser access with the system proxy. Once the subscription and server settings are confirmed, consider enabling TUN, which requires additional permissions.
Go to downloads macOS client→v2rayNG · v2flyNG
For most phones, start with the arm64 package; if you’re unsure of the architecture, try the universal package. v2rayNG uses the Xray core, while v2flyNG is an alternative with the V2Fly core. Review Android’s VPN permission prompt before connecting, and check whether battery settings restrict background activity.
Go to downloads Android client→v2rayN · deb / rpm
Choose a deb or rpm package to match your distribution, then check whether you need x64 or arm64. Whether desktop apps follow the system proxy depends on your desktop environment. After installation, check proxy settings, the local listening port, and the app’s own network options.
Go to downloads Linux client→The client manages local settings but does not include a working subscription. Before installation, obtain a subscription URL or complete server settings that you’re authorized to use, and keep a record of their source. Subscription links often contain access credentials, so don’t post them in public comments or screenshots.
v2rayN Settings Guide
Think of “how traffic reaches the client” and “which route it takes afterward” as separate questions. The system proxy and TUN handle traffic capture; routing rules choose the outbound path; DNS determines how domain names resolve. Check settings in the order below to narrow down problems instead of enabling every option at once.
The system proxy directs apps that follow your system network settings to the client’s local port. After importing a subscription and selecting a node, choose “Set System Proxy Automatically” from the status menu, then test with a browser. “Clear System Proxy” restores the system proxy settings; “Do Not Change System Proxy” simply leaves the current settings untouched—it does not mean an existing proxy is off. Unlike configuring ports in each app, the system proxy is an easy way to get started on desktop, but it won’t cover every program. If an app still connects directly, check whether it uses the system proxy before configuring it separately or trying TUN.
System Proxy · Status Menu Options
Routing rules decide whether traffic goes direct, through a proxy, or gets blocked after it reaches the core. They do not capture app traffic into the client. For everyday use, start with the “Bypass mainland China” rules and add domain rules as needed. “Global” mode can help you check whether routing affects access, but it isn’t a fix-all for connection problems. Unlike switching a single node, routing rules let different destinations use different outbound paths. Before adding rules, check their order, domain lists, and default outbound. Reload the configuration and retest the same destination after saving; avoid changing several things at once, which can obscure the cause.
Routing Modes · Illustration
TUN captures traffic through a virtual network interface, making it useful for apps that ignore system proxy settings. Before enabling it, test the node with the system proxy, then check the permissions and core support available on your platform. TUN typically captures more traffic than the system proxy and depends more heavily on routing, DNS, and virtual network adapter settings. Other VPNs, virtual machines, and network filters can alter traffic paths, so limit other network tools during your first test. If local services become unreachable, turn off TUN to restore the baseline, then check bypass rules for private networks instead of repeatedly switching nodes.
TUN · Checks Before Enabling
Subscription groups link a source URL to a list of nodes, so each update refreshes the content from that source. Create a clearly named group, paste the complete subscription URL, then update it. Importing a URL successfully does not mean the list has refreshed. Compared with adding every node manually, groups make it easier to handle source changes and remove expired entries. Set the auto-update interval according to the source; there’s no need to check too often. If your current proxy is unavailable, try “Update Subscription (Direct Connection),” though direct access still depends on your network. Subscription links contain access credentials, so store them as private configuration data.
Subscription Groups · Settings
DNS translates domain names into addresses, and DNS requests also need a reachable network path. When configuring direct and remote DNS, check the routing outbound as well so remote lookups don’t depend on a proxy that isn’t available yet. Unlike simply changing the system DNS, core-level settings can use domain rules to determine how names are resolved, but available fields and behavior depend on the core and its configuration format. If a domain fails while its IP address works, check DNS logs, cache, and rule matches before trying DoH or FakeDNS. Change one related setting at a time, reload, and test the same domain again.
DNS · Key Concepts
The client provides the graphical interface; the core handles protocols, transport, and outbound connections. They operate at different layers. v2rayN supports multiple core configurations, but the available options vary by platform and package. Rather than relying on the client’s name, check the protocol, transport, and security settings your node requires to see whether the current core supports them. Back up your configuration before switching cores, and check whether custom routing and DNS settings need to be adjusted for a different format. If startup fails, look for configuration parsing errors instead of assuming the node is down. After an update, retest your commonly used rules rather than checking only whether the window opens.
Client and Runtime Layers
Closing the main window, minimizing it, and quitting the client may be separate actions. Check the system menu bar or tray for proxy and runtime status; a hidden window doesn’t necessarily mean the proxy has stopped. Tray menus and keyboard shortcuts make frequent actions easier than returning to the main window, though available options and labels vary by platform. Choose shortcuts that don’t conflict with the system or other apps, and test them in your desktop environment. Before quitting or switching network tools, clear the system proxy and stop any traffic capture to avoid leftover settings affecting your next connection.
Everyday Checks
Save your current working configuration before upgrading the client, moving to another computer, or changing complex rules. A backup should include subscription groups, custom nodes, routing, and DNS settings; available export options depend on the client version. Compared with keeping only a subscription URL, a full backup preserves manual changes—but it may also contain access credentials. Store backup files securely, and create a redacted copy before sharing troubleshooting details. After restoring on another platform, recheck local paths, listening ports, and system permissions rather than assuming every setting will transfer. Verify a basic connection first, then restore advanced features one at a time.
Backup Scope · Checklist
Labels in the interface may change with client updates. If a label differs, look for the relevant setting under System Proxy, Routing, Subscriptions, or Core instead of relying on a screenshot from another platform. The window illustration shows how settings relate to one another; it does not mean a working configuration is included after installation.
View Setup Guides for All Platforms →Getting Started
For your first setup, follow the shortest path: add a subscription, select a node, enable the system proxy, and test with a browser. Once the basic connection works, add custom rules and TUN. This gives you a repeatable starting point and a known-good setup to return to if later changes cause problems.
Create a group under “Subscription Groups,” enter a recognizable alias and the complete subscription URL, save it, and update. Check that configurations appear in the list, then select a node to use. If you have a share link, use the client’s import option instead of pasting it into the subscription URL field.
If the list is still empty, check the update result first: an expired URL, incompatible response, and connection timeout each need a different fix. Make sure your computer’s clock is correct, and that the copied URL has no quotation marks, spaces, or line breaks from a chat app. If the source is unreachable, compare direct and proxied update paths rather than repeatedly deleting the entire group.
After selecting a node, confirm that the core has started, then set the system proxy to “Set System Proxy Automatically.” Start with a routing preset suited to your needs. If you’re unsure whether the rules are affecting access, temporarily switch to Global mode for comparison. Global routing does not capture traffic from every app; traffic still needs to enter the client.
Keep TUN off for now to reduce variables such as permissions, virtual adapters, and other VPNs. If your browser has a proxy extension, disable it or make sure it points to the same proxy as the system settings. If your work network uses a dedicated proxy, note the existing settings so you can restore them. On Android, approve the VPN connection when prompted.
Open a browser and visit a destination you want to test while checking the client logs. Test one destination expected to connect directly and another expected to use the proxy, then compare the results with your rules. A single connectivity test or latency reading reflects only that test destination; it doesn’t replace checking actual websites, sign-ins, and app features.
If the client shows connected but web pages won’t load, check the system proxy, local listening port, routing, and DNS in order instead of reinstalling immediately. If only one app fails, check its separate proxy settings. Once everything works, save the configuration. Before quitting, clear the system proxy and stop traffic capture. Continue with the Getting Started guide for complete setup and recovery steps.
The Project V Ecosystem
Project V is a useful starting point for understanding the V2Ray ecosystem. Graphical clients organize subscriptions, nodes, and rules in an interface; cores read the configuration and establish connections; protocols such as VMess, VLESS, Trojan, and Shadowsocks define different ways of communicating. Each layer has a distinct role, so installing a V2Ray client doesn’t guarantee support for every protocol feature. Check the core, transport, and server settings as well.
The V2Fly community continues work on projects related to V2Ray, while Xray has developed its own core features and configuration system from related technical foundations. The two share some terminology, but their features have evolved differently. When following a guide, check which core it covers and compare its instructions with the current client interface. Similar names for DNS, routing, or transport security settings don’t mean you can copy them unchanged; unknown fields or unsupported combinations may cause the core to fail at startup.
v2rayN is an open-source desktop client distributed under the GPL-3.0 license, with configuration management and access to multiple cores. On desktop, distinguish the window state from the core’s runtime state and the system proxy state. The main window opening does not mean the core loaded its configuration successfully; selecting a node does not mean the system proxy points to the local listening port.
When moving to another computer, save subscriptions and routing as configuration data, but recheck app paths, permissions, and network settings for the new platform. Starting with a basic configuration and restoring custom rules afterward is usually easier to troubleshoot than transferring everything at once.
v2rayNG is an open-source Android client distributed under the GPL-3.0 license and powered by the Xray core. On Android, it captures app traffic through the system VPN interface, unlike the system proxy on desktop. Connection permissions, background restrictions, per-app settings, and conflicts with other VPNs can all affect how it works.
If the same subscription works on desktop but fails on a phone, first check the phone’s clock, current network, and core support, then review the transport settings. Don’t assume different devices have identical protocol support and defaults just because their client names are similar.
v2flyNG is an open-source Android client distributed under the GPL-3.0 license that offers another configuration option with the V2Fly core. It may be useful when comparing V2Fly behavior or working with configurations designed for it. Choose an alternative based on protocol compatibility and configuration needs, rather than installing both clients and repeatedly switching between them.
For a meaningful comparison, use the same network and settings, and make sure only one VPN connection is active. Clients may convert subscription formats differently, so after importing, check that the node details still include the fields required by the server.
Open-source licenses define the terms for using, distributing, and modifying code. Check the license for each project and included component to understand which terms apply. A client, its core, and bundled components may each have different licenses. Open source doesn’t mean licensing terms can be ignored, nor does it mean a third-party subscription service is provided by the client project. This site compiles download and setup information; the client project, subscription source, and destination websites each have separate roles.
Handle updates by layer: client updates can change the interface and configuration management; core updates may change protocol support; subscription updates refresh node information from a source; and routing resource updates affect rule matching. If something breaks, note which layer changed, keep a working backup, and restore only what’s needed. “Update Subscription” does not update the client, and you shouldn’t replace every component to fix a single node.
For cross-platform setup, see the All-Platform Guides and follow the steps for downloading, installing, importing, and testing. During troubleshooting, record the error and the steps that led to it. Before asking for help publicly, remove subscription URLs, authentication details, and private node parameters so you don’t expose reusable credentials.
Setup and Troubleshooting Notes
Choose an article based on what’s happening. For node timeouts, focus on connection settings and logs. If a browser can’t open pages, check traffic capture and DNS. If a subscription update fails, start with the source and request path. Troubleshooting these issues separately helps avoid changing settings in the wrong layer.
A step-by-step guide to diagnosing node timeouts, from your device’s clock, transport settings, TLS and SNI parameters, and core version to outbound logs.
Read the Node Troubleshooting Checklist →Check system proxy status, local ports, routing mode, DNS resolution, and browser extension conflicts in order to find out why you’re connected but can’t access the internet.
Read the Web Access Checklist →Covers common causes such as expired subscription URLs, proxy update loops, and certificate or clock issues, with recommended auto-update intervals.
Read the Subscription Update Guide →