Windows
Choose v2rayN’s cross-platform or classic WPF edition after checking system requirements. Before upgrading, export your settings, including subscription groups and custom routes.
Go to downloads
v2rayNG · v2rayN Clients
V2Ray Mobile Client Downloads
Get clients for Android and desktop. Follow the setup guides from subscription import to routing, and learn where the Xray core fits.
Open source
Graphical setup
Documentation
Client Downloads / PLATFORM
Choose an installer for your OS
For desktop, start with v2rayN; for Android, start with v2rayNG. Check your processor architecture and package format before comparing client interfaces and core features. A subscription importing successfully does not mean every protocol combination it contains is suitable for your device.
macOS
Check About This Mac to choose the Apple Silicon or Intel build of v2rayN. After importing nodes, enable the system proxy and check apps with separate proxy settings.
Go to downloadsAndroid
Use v2rayNG with Xray, or v2flyNG with V2Fly. Check your phone’s architecture before choosing an APK, approve the VPN prompt, and review battery restrictions for background use.
Go to downloadsLinux
Choose a v2rayN deb or rpm package for x64 or arm64. Check your desktop environment; terminal apps and background services may need their own proxy settings.
Go to downloadsThe client and connection configuration are two separate things. After installing a client, you still need a working subscription URL or node parameters. The client stores settings, starts the core and manages the local proxy; a subscription provides remote connection details. The term “V2Ray subscription service” refers to the subscription provider, not a feature or account included with the installer. Before importing, check where the URL came from, how long it remains valid and which devices may use it.
Start with a setup you can reproduce. For your first configuration, import just one subscription group, choose one node and use a default routing preset or one you understand. Once you can reach the target site, add custom routing, per-app proxy settings or background operation. If something goes wrong, you can return to a known-good setup instead of guessing whether the installer, node, core and rules are compatible.
Setup / WORKFLOW
Subscriptions, routing & proxy settings
Graphical clients organize connection parameters, traffic routing and system proxy access in separate places. Updating a subscription refreshes nodes; routing rules choose between direct and proxied connections; the system proxy lets some apps send requests through the client. These work together, but none replaces another. First identify which layer you need to change, then open the relevant settings.
Here are five common settings to get started. Menu names vary slightly between clients, and a desktop system proxy works differently from Android VPN mode. To check whether a setting is working, test actual access and review the logs rather than relying on a toggle’s color. For protocol, transport or security parameters, use the complete configuration provided by your server.
Create a group, then update the subscription
A subscription URL fetches a group of nodes; it is not the same as a share link for a single node. In v2rayN, create a subscription group, enter and save the URL, then update it. In v2rayNG, open subscription settings and manage the relevant group there. After importing, check the group name, node protocols and update results. Saving a URL does not mean the nodes have been fetched. If the list is empty, check the URL’s validity, response format and connection settings used during the update instead of repeatedly reinstalling the client. Groups also keep different sources separate, making it easier to see what an update or deletion will affect.
Import from clipboardSubscription groupsUpdate subscription
View guide →
Choose direct or proxied traffic by destination
Routing determines which outbound connection handles a request; the system proxy toggle does not. Start with a preset suited to your needs, then add rules for local network addresses and specific domains. This is usually easier to maintain than stacking large numbers of rules. Xray evaluates rules in order, so a broad condition near the top can override a more specific one below. Domain rules can also depend on DNS and how traffic is identified. After making changes, test a known destination and check the logs to confirm the outbound route. GeoIP and GeoSite database contents can also affect matches, so check the referenced data along with the rules.
Routing settingsDirect / proxyGeoIP / GeoSite
View guide →
Check the protocol before choosing a core
The core parses the configuration and establishes connections. Seeing a protocol name in the interface does not mean every core supports every combination of its parameters. For configurations using VLESS and REALITY, confirm that your client and its core support the required features. The cores available in v2rayN depend on the specific release and settings; v2rayNG and v2flyNG for Android use different core lineages. Save your existing configuration before switching, then review transport, security and routing settings. The two core families share some history, but their capabilities and configuration details are not always identical. Changing a name alone does not guarantee full compatibility.
Xray-corev2fly-coreProtocol compatibility
View guide →
Send apps through the local proxy
After starting the core on desktop, you also need to direct the target apps to the local proxy. Automatic system proxy configuration works for apps that follow the system’s network settings. For software with its own proxy options, enter the same address, protocol and port as the client. The example ports illustrate how the connection works; use the values shown in your settings. A system proxy does not capture all traffic, and Android VPN mode works differently. When troubleshooting, first confirm the core is running, then check that the app uses the right endpoint. Before closing the client, check whether the system proxy has been restored so the system does not point to a local port that is no longer listening.
Automatic system proxyLocal listening portApp network settings
View guide →
Open source / ECOSYSTEM
The Project V ecosystem and its core families
Clients, cores and protocols belong to different layers. Understanding the distinction helps you choose the right download, assess compatibility and find the relevant settings.
- V2Fly
- Continues the community development of the V2Ray core.
- Xray
- A core branch with its own development direction.
- v2rayN
- Graphical configuration and management for desktop platforms.
- v2rayNG
- An Android client powered by the Xray core.
- v2flyNG
- An Android alternative powered by the V2Fly core.
- Open-source licenses
- Cores and graphical clients are licensed separately.
From Project V to two core families
Project V is an open-source ecosystem built around proxy communication tools, with V2Ray as one of its key components. V2Fly continues community development of the V2Ray core, while Xray grew from related code into an independently developed branch. They share some concepts and configuration approaches, but each adds features and changes its implementation. “Part of the V2Ray ecosystem” describes their history, but does not mean configurations are fully interchangeable.
Cores handle protocols, transport, security handshakes, routing and outbound connections. Graphical clients organize these capabilities into usable settings pages. If you see an “unsupported configuration option” or a startup error, first check which core is actually running and what it supports. Changing the interface theme or reimporting the same subscription usually will not resolve a mismatch in core capabilities.
When choosing a core, start with the parameter combination provided by the server, then check whether the client can represent it fully. REALITY is a connection security technology, not a standalone proxy protocol based on its name alone. Common configurations combine it with VLESS and a specific transport. Configurations can behave differently even when they use the same protocol name, if their transport, security or extra parameters differ.
Graphical clients and license terms
v2rayN, v2rayNG and v2flyNG are all open-source projects, but they are not three names for the same program. v2rayN is designed for desktop workflows, with management interfaces for server lists, subscription groups and connection settings. On Android, the client also relies on mobile system features such as VPN permission, background operation and app traffic selection. When moving between platforms, transfer the connection setup you need rather than copying menu locations one by one.
Licenses also need to be considered by layer. V2Fly’s v2ray-core uses the MIT License, Xray-core uses MPL 2.0, and the three graphical client projects use GPL-3.0 family licenses. Individual releases may include other dependencies, so review the license files for the relevant projects and components before using, modifying or redistributing them. Open source describes how code can be accessed and used; it does not mean client projects provide subscription services, remote servers or network access.
For everyday use, the most useful factors are your device platform, protocol requirements and the effort needed to maintain the configuration. Start with v2rayN on desktop and v2rayNG on Android. Consider v2flyNG if you specifically need a V2Fly configuration. Compare the three clients’ use cases in the client comparison; core names are not performance rankings.
Update the app, subscriptions and rule data separately
Client updates, subscription updates and rule database updates solve different problems. A client update may change the interface, fix configuration handling or add core capabilities. A subscription update refreshes node information from the server. GeoIP and GeoSite updates change the data used by routing rules. Refreshing the node list does not also update the client or its rule databases.
Before updating, note your working nodes, routing preset and custom rules, and keep a backup of any configuration you need. Afterward, test the same workflow: can the core start, can the subscription be parsed, can the app use the local proxy, and does the target site use the expected outbound route? Change one category at a time to make behavior changes easier to trace. Menu names in older guides may differ from the current interface; look for settings by what they do.
On mobile, connection quality is also affected by wireless signal, background restrictions and sleep policies; battery drain or disconnections should not automatically be blamed on one protocol. For a useful comparison, keep the device, network, target site and test duration consistent, and observe connection setup separately from sustained traffic. For help choosing a protocol, understanding core differences or working with subscription formats, read the protocol reference before changing your current setup.
From a successful connection to everyday use
After your first successful connection, test three real-world scenarios: open a target site in your browser, access a device on your local network and use a frequently used app in the background. A page loading in the browser confirms only that one request path works; other apps may use their own proxy, connect directly or resolve domains differently. If local resources such as printers or shared folders are affected, check that private addresses are routed directly instead of immediately switching all traffic to another mode.
For long-term use, a clear naming scheme for subscription groups and a small set of documented custom rules are usually easier to maintain than continually adding rule sets from unknown sources. Note the original value before making a change, then retest the same destination. If the result is unexpected, revert the latest change first and review the relevant logs. For empty subscriptions, dropped connections or incorrect routing, continue troubleshooting by category in the Help Center. The client applies the configuration; reliable day-to-day use still depends on valid parameters, suitable rules and a clear testing process.
Configuration Notes / ARTICLES
Routing rules and database updates
These three articles are listed from newest to oldest. They cover rule data sources and updates, matching syntax, and Android routing in practice. Before applying their advice, check your client and core, then match each rule’s purpose to your own settings. Do not replace all your existing rules with a complete set from another device.
geoip.dat and geosite.dat rule databases: what they do, how to update them and how to reference them
Explains the sources and structure of the two rule database files, where to update them in v2rayN and v2rayNG, how to reference geosite: categories and geoip: region codes, and how to verify changes take effect.
For cases where saved rules do not route traffic as expected. Check “how the rule references the data” separately from “whether the current data includes the destination” before deciding to update the database or change the match conditions.
Custom routing rules in Xray: domain, full, regexp, ip and geosite prefixes and match order
Explains the differences and use cases for each matching prefix, how first-match priority works from top to bottom, and practical templates for writing and editing custom rules in v2rayN.
For users adding rules for specific domains or IP addresses. Learn to check the match scope and rule order, distinguish exact domains from suffix matches and category references, and avoid broad conditions overriding precise ones.
Split routing in v2rayNG: rules for direct access to local sites and proxying international sites
Starts with routing presets, then shows how to split direct and proxied traffic by region, handle local network addresses and ad domains, avoid common misroutes, and verify that routing works as intended.
For Android users who have imported a subscription and now want to control where traffic goes. Start with a working connection, then check presets and exception rules step by step without changing nodes, DNS and routing all at once.
If you have not connected yet, follow a guide through import, selection, startup and testing. If you can already connect, read the routing and core articles that match your issue. The articles also cover failed subscription updates and the main interface, making it easier to find help based on the problem you are seeing.
View all articles →