Project V ecosystem clients

V2Ray SelectClient Guides

Download v2rayN View the guides

Browse open-source client downloads, choose settings by protocol compatibility and core capabilities, and follow guides to import subscriptions and configure routing.

  • VMess
  • VLESS
  • Trojan
  • Shadowsocks
  • REALITY
Core families
XrayV2Fly
Open-source license · Core
Xray-core
MPL-2.0
v2ray-core
MIT
Graphical configuration management

Import subscriptions/Configure routing/Match cores

The diagram groups features by function; it does not imply that every combination is interoperable. REALITY is a connection security technology that must be paired with a compatible protocol, transport, and core.

Client downloadsChoose your platform first

Use v2rayN on desktop and v2rayNG as the main Android option. Choose v2flyNG when your configuration requires a V2Fly core. Package architecture, core support, and runtime permissions are separate considerations; check each one.

Windows

v2rayN · Desktop / WPF

Choose the cross-platform desktop interface or classic Windows WPF edition. Match your CPU architecture and back up subscriptions and routing before migrating.

Go to downloads
macOS

v2rayN · Apple Silicon / Intel

Check “About This Mac” to choose Apple Silicon or Intel. Start with the system proxy; enable TUN only if needed and review its additional permissions.

Go to downloads
Android

v2rayNG / v2flyNG

Use v2rayNG for Xray or v2flyNG for V2Fly. Check your device architecture, grant VPN permission, and review battery restrictions if connections drop.

Go to downloads
Linux

v2rayN · deb / rpm

Choose deb or rpm, then x64 or arm64. Command-line tools may need separate proxy settings. Before enabling TUN, check permissions, routing, and DNS.

Go to downloads

Browse all clients →

Client settingsFind guidance by feature

These are static illustrations of features, not screenshots of a specific release. The client manages configuration; the core handles connections. An option appearing in the interface doesn't mean the current core supports every combination of settings.

Check the protocol, transport, and security layer separately

VMess, VLESS, Trojan, and Shadowsocks serve different proxy configurations; changing the type label alone won't convert one into another. After importing a profile, check the server address, port, authentication details, transport, and security layer. The client and server settings must match. REALITY isn't a standalone proxy protocol that works by entering an address; it also requires a compatible core and the right parameters. Unlike tools limited to one connection type, these clients manage multiple configurations in one interface, but compatibility still depends on the core.

Explore protocol and core references →
ProtocolVLESS ▾
TransportTCP ▾
Security layerREALITY ▾
Server parametersEnter the values provided

Quick startImport, connect, verify

Installing a client is only the first step: you'll also need an existing connection profile or subscription URL. The client reads and uses those settings; it doesn't provide a server. For your first setup, follow the steps below in order and check the result at each stage. This makes it easier to tell an import problem from traffic that isn't reaching the client or a failed server connection.

  1. Import a subscription and check the active profile

    In v2rayN, open the subscription group settings, add a name and the complete URL, save, then update. In v2rayNG, open the subscription group settings, add the URL, return to the configuration list, and update the subscription. If you have a single share link that starts with a protocol name, import it from the clipboard or scan it—don't treat it as a subscription URL. Menu names may change; the key distinction is whether you're handling a subscription group or a single profile.

    After updating, check that actual entries appear in the list, then select one as the active profile. Verify that the protocol, transport, and security layer match the information you were given. Don't change authentication fields just to clear a warning. A subscription can update successfully while one of its connections remains unavailable. Conversely, a failed update doesn't necessarily make every saved profile unusable. Check these states separately.

  2. Set up traffic entry and routing

    On desktop, choose a routing mode for your needs, then enable the system proxy so applications that follow system settings can use the client. On Android, read and approve the system VPN permission when starting a connection. If an application's requests never appear in the logs, first check whether it uses the system proxy and whether the application is excluded. Don't immediately change server parameters. Traffic entry and connection settings serve different purposes; changing both at once makes troubleshooting harder.

    If you need TUN, check administrator permissions, the virtual interface, DNS, and compatibility with other network software. For an initial test, use only one traffic-capture client to avoid multiple tools changing system proxy or routing settings at the same time. In rules mode, a direct route is intentional; it doesn't mean the client has stopped running. To understand which route a site uses, check the rules and logs rather than relying on the toggle state alone.

  3. Verify requests, then make changes gradually

    After starting the client, check that the core is running, then open the application you want to test and look for connection logs. If requests appear but connections fail, check DNS resolution, the server port, authentication, and security layer parameters. If no requests appear, revisit traffic entry settings. Connectivity tests may use different destinations and workflows from real web browsing, so a successful test doesn't prove that every application is connected, and a failed test needs to be interpreted alongside the logs.

    Once basic access works, adjust routing rules, subscription update settings, or application scope one at a time, keeping the original value. When asking for help, include the client name, core, protocol, point of failure, and checks you've already tried. Hide subscription URLs and authentication details. When exiting the client, also check that the system proxy has been restored. A proxy setting left behind after an unexpected shutdown can disrupt ordinary network access.

Read the complete guide →

Project V ecosystemHow clients and cores differ

V2Ray is a familiar name in this ecosystem and its technical history, but practical use comes down to three layers: client, core, and configuration. Understanding how those layers fit together is more useful for migrating settings and troubleshooting than memorizing where a button appears in one interface.

PROJECT V

Shared roots and community development

Project V brings together components for proxy connections, transport, and routing. V2Ray is one of its widely used core projects. As the community evolved, V2Fly continued maintaining the V2Ray core, while Xray developed as an independent fork from shared code. The two retain some related concepts while developing their own features and configuration conventions. These project names don't refer to different skins of the same program.

Graphical clients sit above the cores, providing configuration editors, share-link import, subscription groups, and runtime controls. The settings you see are usually part of the client interface; the underlying core establishes connections and applies routing. As a result, similar-looking subscription entries in different clients don't guarantee identical core configurations. Whether an importer recognizes a particular field is also part of compatibility.

XRAY / V2FLY

Feature differences and configuration compatibility

Xray and V2Fly can both handle a range of proxy configurations, but supported features vary by release. When choosing a core, first check the protocol, transport, security layer, and required extensions specified by the server—not assumptions about speed based on the core's name. For features such as REALITY, confirm the implementation and parameter requirements. Don't copy an entire configuration from another core and expect every field to be interpreted the same way.

Protocol names aren't performance rankings. The same protocol can perform differently depending on network path, transport combination, device load, and server conditions. On mobile, battery life is also affected by persistent connections, background restrictions, and how traffic enters the client. A reliable approach is to check compatibility first, then compare on the same device and in the applications you actually use. For a structured comparison, read the protocol reference and narrow your options based on configuration requirements.

OPEN SOURCE

Open-source status of the three clients

v2rayN, v2rayNG, and v2flyNG are all open-source client projects. v2rayN targets desktop platforms and focuses on configuration, subscriptions, and routing. v2rayNG is for Android and primarily supports the Xray core; v2flyNG is also for Android, with a V2Fly core option. They aren't the same interface with different names: settings, import handling, and platform permissions vary, so don't assume steps transfer unchanged between them.

Open-source licenses set the terms for using, modifying, and redistributing code; they don't guarantee how software will perform in every network environment. Among the cores, Xray-core uses MPL-2.0, while the v2ray-core maintained by V2Fly uses MIT. Check the licenses for each client and its dependencies separately. When reviewing open-source information, distinguishing the client license, core license, and included dependency licenses is more precise than assigning one license to the entire download package.

MAINTENANCE

What gets updated and in what order

Client, core, subscription, and rule-data updates address different things. A client update may change the interface or how configurations are generated; a core update affects connection capabilities and how fields are interpreted; a subscription update fetches remote configurations; and updates to data such as geosite and geoip affect rule coverage. Updating a subscription doesn't upgrade every software component, and updating the client doesn't refresh remote connection settings.

If your existing setup works, record the active connection, subscription groups, routing, and DNS settings before upgrading. Read the release notes for configuration changes. After updating, verify the basic connection first, then check routing and specific applications. Avoid changing the core, rules, and traffic entry mode all at once. If an unfamiliar term comes up during migration, look it up in the quick reference. For import or connection errors, use the FAQ to find guidance by troubleshooting stage rather than assuming every issue is protocol-related.

Technical notesEcosystem, links, and routing

Build context around practical configuration questions: first understand how the software projects relate, then how import formats and routing rules work. The three articles below are listed from newest to oldest; start with the one that best fits your current question.

Advanced Setup

V2Ray Routing Rules in Practice: Using geosite and geoip

Learn how domain, ip, geosite, and geoip rules are matched, with examples of routing mainland China traffic directly and traffic outside mainland China through a proxy. Find ways to troubleshoot conflicting rules. Focus on which route a request matches—not on making the rule list longer.

Read the article →

Browse all articles →