v2rayN
Desktop clients for Windows, macOS, and Linux, with subscriptions, servers, and routing managed in one place.
Download v2rayN View setup guide →Open-source clients · Downloads and setup guides
V2Ray Resource Hub· v2rayN client downloads and setup
Find open-source clients, downloads for multiple platforms, and Chinese-language setup guides covering everything from subscription imports to routing, DNS, and TUN settings.
v2rayNG / v2flyNG
These two Android clients use the Xray and V2Fly cores, respectively. Choose based on your existing node requirements.
Download Android clients View setup guide →Choosing an installer
Client downloads for four platforms
Check your operating system first, then your processor architecture. For desktop, start with v2rayN; for Android, look at v2rayNG first, and consider v2flyNG if you need the V2Fly core. The installer is only the starting point: your service provider must supply the server address, port, authentication details, and subscription link. Make sure any saved configuration is compatible with your chosen core.
Windows
Start with v2rayN’s desktop version, or choose classic WPF. Back up subscriptions and routing before switching.
Go to downloads →macOS
Choose v2rayN for Apple Silicon or Intel. Check About This Mac and verify the source before allowing first launch.
Go to downloads →Android
Choose v2rayNG (Xray) or v2flyNG (V2Fly). Check the CPU architecture, allow VPN access, and review battery restrictions.
Go to downloads →Linux
Choose a v2rayN deb or rpm package for x64 or arm64. Check system proxy support and TUN permissions before connecting.
Go to downloads →Configuration details to gather before installing
For your first setup, review the subscription link, node protocol, and supported client details provided by your service provider together. A subscription distributes configuration; it is not a client account. A successful import only means the contents could be parsed, not that the remote server is reachable. If you only have a single share link, import that server configuration and test the connection first. There’s no need to create complex groups yet.
If you already have a configuration on another device, don’t copy every setting over as-is. Desktop system proxy settings, Android VPN routing, and permission models vary by platform, so check each setting against your device. Start with the default routing setup and confirm a basic connection. Then migrate custom DNS, routing rules, and other advanced options one at a time to make it easier to pinpoint problems.
Client settings
Subscriptions, routing, and traffic capture
Clients turn underlying configuration into manageable settings, but menus and features can vary across platforms. The guides below follow the tasks in order: organize your server sources, choose the outbound route for requests, then select a traffic capture method based on whether your apps follow proxy settings. Select a topic to explore its configuration scenarios.
Subscriptions let you update server configurations in one place, making them useful when node details change. In v2rayN, create a subscription group, enter the link, and update it; then check the protocol, label, and availability. Check the import results in Android clients, too. Grouping by source helps prevent duplicates and accidental selection. Save manually edited configurations separately so an update won’t overwrite them. Subscriptions are easier to maintain than pasting share links one by one, but a successful parse doesn’t guarantee a connection. Select a server and test an actual request.
Routing uses conditions such as domains and IP addresses to direct requests through a proxy, directly, or to another outbound. This is useful when accessing both local resources and remote services. Start with the client’s existing rule set, then add necessary exceptions in the right place. Routing can express more specific access policies than sending all requests through the same outbound, but rule order and DNS resolution strategy affect the results. Configure DNS alongside routing. After making changes, check the logs for domain matches and actual outbound selection; don’t rely on whether a page loads to determine if a rule worked.
TUN captures traffic through a virtual network adapter, making it useful for apps that don’t follow system proxy settings. First confirm that a standard proxy connection works, then grant the required system permissions and enable TUN. Check local networking, DNS, and the target app afterward. TUN typically captures more traffic than a system proxy, but that doesn’t mean all traffic goes through a remote node; routing rules still determine the path. If connections fail, close other traffic-capture tools first, then check for interface or routing conflicts. To restore your original setup, turn off TUN and confirm the system network is back to normal.
The core handles connections and protocols; the graphical client organizes configuration and controls. v2rayN can use different cores to match your configuration. On Android, v2rayNG uses Xray and v2flyNG uses V2Fly. Checking the core is more useful than looking only at the client name when troubleshooting protocol or parameter compatibility. Before switching, review your service provider’s requirements and keep a copy of your working settings. Restart and test after switching. Cores don’t offer identical features, so don’t assume the same custom configuration will work in both.
From a basic connection to advanced setup
The order of your setup matters more than the number of options. For your first connection, confirm the server configuration, selected server, and traffic capture method, while keeping the default routing and DNS settings. Once your browser works, check whether other apps follow system proxy settings. Try TUN only if you need it. Change one setting at a time and note what happens before and after; it’s easier to find the cause than when several features are enabled at once.
System proxy and routing mode are two separate layers. The system proxy determines whether an app sends requests to the client; routing determines which outbound the client uses for those requests. If the system proxy is enabled but an app ignores system settings, changing domain routing rules usually won’t help capture its traffic. If the request reaches the client but takes the wrong route, check the rules, resolution results, and current mode.
DNS settings aren’t just about choosing a particular resolver address. First determine which domains are resolved through which route, whether DNS requests themselves go through the proxy or directly, and whether routing depends on the resolved IP. Some issues that look like an unreachable server actually stem from DNS resolution. To troubleshoot, keep a working baseline, use logs to distinguish resolution failures from connection failures, then adjust DNS or outbound settings as needed.
For FakeDNS, custom outbounds, or filtering across multiple subscriptions, read the full Advanced guide first. These features depend on other settings, and copying a snippet on its own can miss important context. Keep your stable configuration as a rollback baseline. After changes, test common websites, local resources, and the target app separately before moving on. When reporting an issue, include the error type but hide subscription links and authentication details.
Open-source core ecosystem
Project V, V2Fly, and Xray
Project V
Proxy cores and configuration ecosystem
V2Fly
How the V2Ray community is maintained
Xray
Core projects derived from V2Ray
Graphical clients pass server, routing, and DNS settings to the core that runs them.
Understand the difference between clients and cores
“V2Ray” can refer to the broader proxy ecosystem or specifically to the core software. Project V introduced a modular approach to proxying, with V2Ray as its core project. V2Fly continues community maintenance of V2Ray, while Xray grew out of V2Ray and has developed its own protocol and feature set. Understanding these relationships helps distinguish the graphical client, node protocol, and core that actually runs.
v2rayN, v2rayNG, and v2flyNG are clients designed for users. Actions such as adding a server, updating a subscription, or selecting a route are ultimately converted into configuration the core can use. A client launching successfully only confirms that its interface is running. Check the status and logs to confirm the core has started, accepted the configuration, and connected successfully. This is why two clients with similar interfaces can behave differently after switching cores.
Choosing between the three clients
For desktop devices, start with v2rayN. It supports Windows, macOS, and Linux and is designed for managing servers and subscriptions through a graphical interface. The cross-platform desktop interface and classic WPF interface have different layouts, so existing users should choose based on their workflow and system requirements, not screenshots alone. When moving between operating systems, migrate server details first, then check system proxy settings, permissions, and TUN behavior on each platform. Don’t assume environment settings from one system apply everywhere.
For Android, start with v2rayNG, which uses the Xray core. If your existing configuration specifically requires V2Fly, consider v2flyNG. Both clients offer a graphical interface, but their core features and configuration support aren’t interchangeable. For features such as REALITY, check the complete requirements from your service provider; simply changing the protocol selection isn’t enough. A share link may import successfully without the current core correctly handling all its extended parameters.
When choosing a client, ask three questions: Which operating system does your device use? Which core do your existing nodes require? How do your apps need traffic captured? The first two determine the download and compatibility; the third determines your connection settings. If those requirements are met, there’s no need to keep switching clients just because their names are similar. If one node fails, troubleshoot its configuration and network environment rather than blaming the entire client.
Open-source licensing and community maintenance
All three clients are released as open-source projects, so their code and change history can be reviewed and discussed by the community. v2rayN, v2rayNG, and v2flyNG are licensed under GPL-3.0; the V2Fly and Xray core code is licensed under MPL-2.0. Clients and the cores they call are separate software components, each with its own license. Personal use and redistribution of modified software are different cases. If you redistribute a modified version, read the applicable license and notices for each component.
Open source describes how software is developed and released; it doesn’t determine whether a network configuration is appropriate. Requests pass through your device, the server, and the destination service, so privacy and security also depend on the configuration source, connection protocols, and runtime environment. Subscription links may contain usable credentials, so protect them like account details. When asking for help, don’t share a full link, QR code, or authentication fields in a screenshot.
Community maintenance can involve the interface, core compatibility, operating system support, and bug fixes. These may each follow different release schedules, so reading release notes is more useful than simply chasing the latest version. Check whether changes affect your platform and configuration before updating. If your setup relies on custom routing or outbound rules, save your current settings and test familiar scenarios with the new combination.
Client updates and subscription updates
Client updates replace the software, while subscription updates replace or add server configurations; they solve different problems. New protocol support, interface changes, and operating system compatibility usually come from client or core updates. Changes to server addresses, authentication parameters, and server configuration usually arrive through a subscription update. Updating a subscription won’t make an old core support new features, and updating a client won’t fix an expired subscription link.
After updating a subscription, check that your groups are still there, the intended server is selected, and manually edited entries haven’t been overwritten. Entries with the same name may have different addresses or transport parameters, so check your service provider’s details if needed. If an update fails, check the link’s validity, whether your current network can retrieve its contents, and whether the client supports the returned format. Don’t delete every group before you know what went wrong.
Before updating the software, save your subscription details and custom settings. Afterward, check the active core, system proxy status, and routing mode. Settings can change after a system restart, permission change, or when multiple tools are running. A toggle that appears enabled in the interface doesn’t confirm the actual traffic path. For troubleshooting, capture logs from one specific failure and hide addresses, authentication fields, and other sensitive details.
Setup and troubleshooting guides
Recent V2Ray guides
Getting started, subscription errors, and connection timeouts each require a different troubleshooting approach. First identify whether the problem occurs during installation, configuration retrieval, or connection, then choose the relevant guide. Recording one complete attempt and the exact error is more helpful than repeatedly changing modes. Keep configurations that already work; there’s no need to wipe everything for testing.
V2Ray beginner’s guide: 10 questions answered, from choosing a client to your first connection
Start with how V2Ray and Xray are related, then learn how to choose a client, who provides subscriptions, and how system proxy settings differ from TUN. For users who have found a download but aren’t sure how to configure it, this guide builds the basics step by step before walking through a first connection.
Read the guide →V2Ray subscription update failures and parse errors: common causes and troubleshooting steps
If an update returns no results, can’t be parsed, or creates no server entries, first distinguish a retrieval failure from a content format issue. This guide checks link validity, the update path, returned content, and client compatibility to help you keep working configurations while pinpointing where the update failed.
Read the guide →V2Ray node connection timeouts: a seven-step troubleshooting guide
Start with your local network and system clock, then check client mode, node parameters, transport security, DNS, and core logs. These steps apply both to connection timeouts and to cases where the client says it’s connected but websites won’t load. Change one setting at a time to avoid losing track of the cause.
Read the guide →Keep reading based on where the problem occurs
If you haven’t installed a client yet, start with the Getting Started guide and follow the steps to import a configuration, select a server, set up traffic capture, and test the connection. If you’ve imported a configuration but requests aren’t reaching the client, check the app’s proxy settings. If requests reach the client but still fail, check the node configuration, DNS, and logs. Examples in the advanced guides need to be adapted to your own outbounds and rules; they aren’t connection details supplied by your service provider.
For a quick explanation, look up protocols, transports, cores, and client features in the Glossary. For recurring questions about how to use the software, check the Help Center. These resources provide background; for detailed instructions, follow the full steps in the Getting Started and Advanced guides. Identify the problem first, then choose where to look to avoid trying settings at random.