Windows
Use v2rayN to manage desktop subscriptions. The download page distinguishes the cross-platform desktop edition from the classic WPF edition, so choose based on your preferred interface and operating environment.
Go to downloads
Client Downloads · Protocol Configuration Guide
V2Ray Community Client Downloads
From open-source clients to subscription imports, choose a download for your device, match protocol and security settings to the server, then configure the system proxy and routing.
- Protocol / Security Layer
- VMess
- VLESS
- Trojan
- Shadowsocks
- REALITY
Choose a client by platform
For desktop, start with v2rayN; for Android, start with v2rayNG. If you need compatibility with V2Fly core configurations, consider v2flyNG. The client manages configurations, while connection support depends on both the core and the server. Before downloading, check compatibility rather than guessing from the protocol name alone.
macOS
Choose v2rayN, then check your chip type in About This Mac. Apple Silicon and Intel require different downloads.
Go to downloadsAndroid
For most users, choose v2rayNG with the Xray core. If you need compatibility with V2Fly configurations, see v2flyNG and check your device architecture.
Go to downloadsLinux
v2rayN provides a desktop GUI for configuration. Choose the deb or rpm package for your distribution, then check whether your processor is x64 or arm64.
Go to downloadsDifferent download options for the same client do not mean different service plans. After installing a client, you will need to provide your own authorized server configuration or subscription link. This site provides client downloads and configuration guides, not ready-to-use proxy nodes. If you already have a subscription, check the provider's client requirements before choosing software for your platform.
Moving from another client? Keep a copy of your existing configuration and routing rules. Test with one known-working configuration before importing the rest of your subscriptions. Migrating every group, changing DNS, and enabling a virtual network adapter at once makes problems harder to isolate. The download page explains installation options and architecture differences; the tutorials cover the recommended setup sequence.
Protocols and Configuration Boundaries
Check protocol settings and identify the traffic entry point
A successful import only means the configuration was recognized; it does not guarantee that the connection can be established. Subscription retrieval, outbound handshakes, routing decisions, and traffic capture are separate steps. When troubleshooting, change one variable at a time.
Make sure the subscription URL is reachable
Updating a subscription fetches remote configuration; it does not establish a proxy connection. Save the complete URL in a subscription group, then choose an update method based on your network. If you already have a working connection, try fetching through the proxy. If the list is empty, check whether the link has expired and whether the response contains configuration data before checking protocol fields. Subscription groups make ongoing updates easier than importing individual share links, but updates may overwrite remotely managed entries. Save a copy before making manual changes.
If you don't have a working connection yet, don't rely on “Update through proxy” as your only way to fetch a subscription.
A protocol name is not a complete connection setup
VMess, VLESS, Trojan, and Shadowsocks are different proxy protocols. TLS and REALITY are security layers, not interchangeable protocol names. Start by checking the complete server settings, then confirm that your client core supports that specific combination. Checking the address, port, authentication, transport, and security options layer by layer is more useful for diagnosing a failed handshake than comparing protocol names alone. If your current setup works, there is no need to change multiple fields just to use a different protocol name.
REALITY settings must match the server. Switching the security layer to TLS won't fix an incorrect public key.
First check which rule matches the request
Routing rules determine whether requests handled by the core go direct, through a proxy, or get blocked. They do not automatically route every app through the core. Start with a preset that fits your needs, then add rules for specific exceptions and check their order. Split routing preserves access to your LAN and makes it easier to handle different traffic needs than sending every destination through the same outbound. Whether domain rules work also depends on DNS and how destinations are identified. If one site has a problem, check which rule matched before rebuilding all your subscriptions.
A broad rule may match a request first. After adding an exception, check its position and the default outbound.
Capture traffic from apps that ignore the system proxy
The system proxy mainly affects apps that honor system proxy settings. TUN uses a virtual network adapter to capture traffic that matches routing rules, making it useful for apps that don't follow the system proxy. First verify the configuration with a standard proxy, then enable TUN and check the required permissions, DNS, and adapter routes. TUN captures more traffic than setting a proxy in a browser alone and operates closer to the system network layer. If you run other networking tools at the same time, disable them one by one to test. Make sure your local network works again after exiting the client.
TUN does not send all traffic through a proxy. Routing rules still determine the outbound path.
From Installation to Verification
A three-step sequence for importing subscriptions
Confirm where the configuration came from, test the connection, then expand traffic capture. This sequence works for first-time setup and for creating an easy-to-troubleshoot baseline when migrating configurations. Client menus may change, but the dependencies between these three steps remain the same.
-
Install the client and save a subscription group
Open the download page for your device and choose the package for your processor architecture. Use v2rayN on desktop and v2rayNG on Android. After launching the client for the first time, check that it opens and the core starts, then go to subscription management and add a group. Paste the complete subscription URL from your provider and give the group a recognizable name.
A subscription link may differ from a regular webpage URL. Login pages, documentation pages, and pages that require interactive verification usually can't be imported as subscriptions. When copying the link, avoid including extra spaces, line breaks, or punctuation added by a chat app. Subscription URLs may contain access credentials, so don't post the full link in public comments or screenshots while troubleshooting.
Save the group, update it, and check that recognizable configurations appear in the list. If you only have a single share link, use the appropriate import option rather than pasting it into the remote subscription URL field. See Subscription Setup and Import for details.
-
Choose a configuration and set the traffic entry point
Choose a configuration from the imported list as your active outbound and check that the address, port, and protocol are complete. In v2rayN, start by testing with the system proxy. If you have a manual proxy configured in your browser, check whether it uses the system proxy or still points to a fixed port. Having both entry points configured can leave the browser using an old configuration even after the client has switched.
When connecting on Android, confirm the system prompt to allow the VPN connection. This permission allows the client to create a local traffic tunnel; it does not mean the remote service is reachable. If you use per-app routing, check that your test app is included. A connection icon in the system status bar does not prove that the subscription is valid or that the remote handshake succeeded.
For now, use a clear routing preset and hold off on complex exceptions. See Importing a Subscription into v2rayN for desktop, or Importing a Subscription into v2rayNG for Android.
-
Test real requests, then adjust split routing
Test a request that should use the selected outbound, and confirm that direct access and LAN access still work as expected. Connectivity tests in the client, browsing in a browser, and requests from other apps cover different scenarios. Success in one does not prove that other apps use the same traffic entry point or DNS path.
If the connection fails, first determine whether the subscription couldn't be fetched, the core failed to start, the remote handshake failed, or the request never reached the client. When reviewing logs, keep the error type and sequence of events, but hide subscription URLs, authentication fields, and personal network details. If you changed routing or DNS, record the original settings and restore them one at a time. This is more effective than repeatedly reinstalling the client.
Once standard proxy mode works, enable TUN or configure per-app routing if needed. After exiting the client, check that the system proxy has been reset so other apps don't keep sending requests to a local port that is no longer listening. For more help, see Troubleshooting. There's no need to change the protocol, core, and routing all at once.
Open-Source Ecosystem and Maintenance
Project V, V2Fly, and Xray
V2Ray is the name of an ecosystem and a useful starting point for understanding how protocols and cores relate. GUI clients, connection cores, remote services, and subscription providers each have different roles. Separating these layers helps you determine where a feature is configured and what an update may affect.
CLIENTv2rayN / v2rayNG / v2flyNG
Subscription management, interface, and configuration organization
COREXray / V2Fly
Protocol implementation, connection handling, and routing
Project V: From Protocol Suite to Configuration Model
Project V is built around V2Ray and organizes network connections through inbound and outbound traffic, transport, and routing. VMess is one of its best-known protocols, but V2Ray is not limited to VMess, and related clients are not all the same program. When a GUI offers several protocol options, it generally means the client can generate different configurations for its underlying core; it does not mean every combination works with your server.
For everyday use, the key idea is layering: a local app passes requests to an inbound, routing rules choose an outbound, and that outbound connects to a remote service using the agreed protocol and security layer. A mismatch at any layer can make a site appear unreachable. Choose protocols based on the complete configuration, not on whether a name sounds newer when considered apart from the server setup.
V2Fly and Xray: Related, but not freely interchangeable
V2Fly continues community development of V2Ray, while Xray grew from related code into a separate core. They share configuration foundations but have distinct features and parameters. When using VLESS, REALITY, or specific flow-control combinations, check support in the exact core you plan to use. Recognizing a protocol with the same name does not guarantee that another core supports every server-side extension.
Subscription imports may also go through the client's own format parser and configuration conversion. Even clients using similar cores may handle share-link fields, defaults, or transport options differently. Before switching cores, check the protocol combination required by your provider and keep a copy of the original configuration. For VMess compatibility, time synchronization requirements, and protocol differences, see the VMess Protocol Reference.
Three Clients: GUI Management and Core Selection
v2rayN is for desktop platforms and provides a GUI for managing subscription groups, active configurations, system proxy settings, and routing. It can use supported cores. v2rayNG is for Android and uses the Xray core; v2flyNG is an Android alternative that uses the V2Fly core. When choosing an Android client, check server requirements and configuration compatibility first, then consider interface preferences. The two clients are not simply the same installer with different names.
All three clients are released under the GPL-3.0 license. Open-source licenses set the terms for using, modifying, and distributing code, but they do not determine whether a subscription source or remote service is trustworthy, or how it behaves on your network. Cores have their own licensing terms; for example, the core code for V2Fly and Xray uses MPL-2.0. If you redistribute software, review the licenses and notices for each component rather than relying on the client name alone.
Updates: Check the Client, Core, and Subscription Separately
Client updates may change the interface, import logic, and configuration generation. Core updates affect protocol implementation. Subscription updates replace remotely provided configuration. These updates address different issues. Upgrading the client usually won't restore an expired subscription, and repeatedly updating a subscription may not help if the core doesn't recognize a field. Identify which layer is causing the problem before choosing a fix.
Before updating, back up subscription groups, manual outbound settings, and custom routing rules, and note which core is in use. After the update, test with a configuration that you already know works before trying new features. On mobile devices, also check background activity limits and battery-saving settings. Battery use depends not just on the protocol, but also on the number of connections, DNS requests, signal strength, and app behavior, so protocol names alone can't predict a fixed power consumption ranking.
Release Notes and Configuration Guides
Recent technical articles
Choose articles based on the issue you're facing. For a first install, check directories, permissions, and proxy mode. For subscription update problems, distinguish URL accessibility from content parsing. Router deployments require separate consideration of device resources and network topology, so desktop client instructions may not apply.
First-Time v2rayN Setup: Essential Windows and macOS Settings and Common Pitfalls
Covers the essentials for first launch: extraction directory, runtime requirements, core selection, system proxy mode, and local port. Start with a basic configuration you can verify before moving on to extra features or migration.
Read article →Running the Xray Core on a Router or Secondary Router: Deployment Overview and Hardware Selection
Understand the roles of the main router and secondary router, then check processor architecture, memory, and configuration migration. Learn how running a core directly differs from selecting a configuration in a desktop GUI client.
Read article →v2rayNG Subscription Update Failed? Common Causes and Auto-Update Interval Settings
Troubleshoot update failures by checking link accessibility, proxy update options, and background restrictions. Learn how to choose an auto-update interval and where to find the related settings in v2rayNG and v2rayN.
Read article →