Client downloads · Configuration guides

V2Ray Tutorial Hub v2rayN downloads & setup

Download v2rayN View guides

Guides to client settings and core support, covering subscription imports, Routing, and protocol selection.

v2rayN configurationSubscriptions, routing, and connection modes

View configuration guides →

Client setup has three layers: subscriptions and nodes determine where you connect; the system proxy or TUN mode determines which apps use the client; routing and DNS determine how traffic is handled. Installing the client alone does not establish a working connection. First import a usable configuration and select a node, then choose how traffic enters the client. Finally, check the logs and test access to pinpoint where a problem occurs.

The panels below illustrate how settings are organized. Field names may change between client versions, so follow the current interface when configuring your client. Avoid changing subscription, transport, DNS, and routing settings all at once. Keep a known-good configuration, change one category at a time, and test the result. This makes it easier to roll back and helps distinguish node issues from app proxy issues.

Subscription group settingsInterface example
Group name
Work devices
Subscription URL
Provided by your subscription provider
Auto-update
Off; verify manually first
Update method
Manage by group

Subscriptions group nodes together, making them useful when URLs or settings change. Add a name and the full URL in a subscription group, save it, and update the group before selecting a node to use. Adding a URL alone does not establish a connection. Group subscriptions are easier to maintain than pasting share links one by one, but updates may overwrite manual edits. Keep self-hosted nodes in a separate group. Subscription URLs may contain credentials, so do not share them publicly. If an update fails, first confirm the URL is valid, then check how the update request is routed.

Protocol fields: check the combination before changing modes

VMess, VLESS, Trojan, and Shadowsocks are proxy protocols; WebSocket and similar options are transports; TLS and REALITY are security-related transport settings. These options belong to different layers. For a VLESS node, also check the transport, whether TLS or REALITY is used, and whether a flow is specified. Selecting a protocol name alone is not enough. The cards above show the field structure; they are not complete node configurations you can connect with as-is.

For VLESS, encryption is usually set to none; this does not mean you can omit the security layer. Trojan requires the correct password and server identity settings. If you encounter a certificate error, check the system time, SNI, and server certificate rather than simply allowing insecure certificates. The Shadowsocks encryption method must match the server. Methods with a year prefix may also require a specific key format, so do not assume a regular string password works with every method.

When choosing a node, use the complete parameters provided by the provider whenever possible. If entering them manually, check the address, port, user credentials, transport, and security layer in that order, then test the connection. Seeing a node name in the client only means the configuration was saved; it does not prove the core can parse every field or reach the remote server. For more on protocol trade-offs, mobile battery use, and configuration compatibility, see the protocol and core reference.

Client downloadsChoose by operating system and processor architecture

Browse all clients →

For desktop, start with v2rayN. For Android, consider v2rayNG with its Xray core; use v2flyNG when you need compatibility with V2Fly configurations. The similar app names can be confusing, but their platforms, cores, and package formats differ. Before downloading, check your operating system and processor architecture. Handle subscriptions and nodes after installation so package compatibility issues do not complicate connection troubleshooting.

The links below take you to the relevant platform section of the download page; they do not start a direct download from the homepage. The download page explains package types in one place, making it easier to compare desktop editions, classic interfaces, chip architectures, and distribution formats. You can reuse a subscription on a new device, but system proxy, permissions, and routing settings do not transfer with it and must be checked again.

Windows

 Recommended for Windows

Windows users can choose between the v2rayN desktop edition and the classic WPF edition. The desktop edition uses a cross-platform interface, while WPF retains the classic desktop experience. Check your system architecture first, then choose based on interface preference and familiarity. Package types may use different configuration directories and migration methods, so do not assume you can install one over another based on the filename alone.

On first use, launch the client and import a subscription before enabling the system proxy. Some apps do not honor system proxy settings; only then consider an in-app proxy or TUN. If your browser still uses an old port after switching clients, check for leftover proxy settings in the system configuration and make sure only the intended program is managing the traffic entry point.

Go to downloads →

macOS

 v2rayN

macOS packages are available for Apple Silicon and Intel processors. Check your chip or processor under About This Mac: choose arm64 for Apple Silicon or x64 for Intel. Prefer the package that matches your architecture rather than assuming compatibility mode is the right choice. Also check the system requirements listed on the download page before installing.

Managing subscriptions in a desktop client and granting system network permissions are separate steps. After importing a subscription, confirm the selected node, proxy entry point, and the route the app actually uses. If you enable TUN, grant the required permissions as prompted by the interface and operating system. On organization-managed devices, follow device management policies before changing network settings.

Go to downloads →

Android

 Recommended for Android

For Android, v2rayNG is the primary choice; v2flyNG is an alternative based on the V2Fly core. Most recent mainstream devices work well with arm64 packages. If you are unsure of the architecture, check the device information or consider a universal package. The app names and icons are easy to confuse, so confirm the app name before installing. After importing a configuration, check protocol support rather than assuming the two apps have identical settings.

The VpnService permission requested when starting a connection creates a local interface for capturing traffic; it does not make a subscription usable automatically. If the connection drops after the device has been idle, check background restrictions and battery optimization as well as node status. Per-app proxying lets you control which apps are included. Before configuring it, check whether the list includes or excludes the selected apps so you do not put an app on the wrong side.

Go to downloads →

Linux

 v2rayN

For Linux, see the v2rayN deb and rpm packages, available for x64 and arm64. Package format must match your distribution's package management system, and the architecture must match your processor. A downloadable file is not necessarily suitable for your system; check the download page for dependencies, desktop environment, and permission requirements before installing.

On Linux, whether the system proxy works depends on both the desktop environment and the app. If a browser connects but another program does not, first check whether that program reads proxy settings instead of immediately switching nodes. Before enabling TUN, check permissions and the scope of route takeover, especially for local networks, container networking, and existing virtual interfaces. Keep a copy of the original settings so you can restore them after making changes.

Go to downloads →

Configuration migration only reuses some settings. On a new device, check core support, the traffic entry point, and the DNS path. See the quick start guide for instructions.

The Project V open-source ecosystemChoose clients and cores separately

Explore protocol guides →
CLIENT

v2rayN · v2rayNG · v2flyNG

Subscription management, interface controls, configuration generation
CORE

Xray · V2Fly

Connection handling, protocol processing, routing

Project background: Project V and V2Ray

Project V is an open-source project ecosystem built around proxy and networking tools, with V2Ray among its best-known core names. Its value is not limited to one protocol: it brings inbound and outbound connections, routing, and transport settings together in a unified configuration structure. The “node” shown in a client is usually just the interface representation of one remote outbound. System proxy settings, local listeners, and DNS belong to other parts of the configuration, so a node name alone does not describe the whole runtime environment.

In everyday conversation, V2Ray is often used as a catch-all name for the ecosystem, so check the exact app name when downloading. v2rayN is a graphical client, not the V2Ray core itself; v2rayNG and v2flyNG are for Android. Understanding this distinction helps you tell whether a feature belongs to the client interface or the core, and whether to start troubleshooting in the client logs or the protocol parameters.

Core families: V2Fly and Xray

V2Fly continues the community development of V2Ray, while Xray grew from related code and follows its own feature roadmap. They share a background, but are maintained and developed separately; they are not two skins for the same program. Even when configuration fields look similar, transports, security mechanisms, routing options, and default behavior may differ. Choose a core based on the features your nodes require and actual compatibility, not just its name or release date.

For VLESS, Vision, and REALITY combinations, check Xray's support and verify the flow, server name, public key, and shortId provided by the server. REALITY is a security mechanism for transport, not a standalone proxy protocol at the same level as VMess or Trojan. Do not bulk-migrate an existing V2Fly configuration to another core. Test one node and its fields, then verify routing and DNS before migrating the full configuration.

Three clients: open-source interfaces and platform differences

v2rayN, v2rayNG, and v2flyNG are open-source clients with graphical tools for editing nodes, managing subscriptions, and controlling connections. Open source means the source code and license terms are available for review; it does not remove the need to assess permissions or configuration sources. Subscription providers, remote servers, and clients have different roles. Installing a client does not provide a server account or guarantee that every imported node will work.

v2rayN is for desktop platforms and lets you manage subscriptions and routing in one interface, with a choice of supported cores. v2rayNG is primarily based on the Xray core and suits Android users who need its protocol support. v2flyNG follows the V2Fly core and is an option when you need compatibility with the corresponding configurations. When moving between apps, re-import a complete share link or subscription first, then check the connection mode; do not just copy the display name from the old client.

Open-source licenses: understand use and distribution terms

Projects related to Project V, graphical clients, cores, and packaging dependencies may each use different open-source licenses. A license for one part of the ecosystem does not automatically apply to every component. Personal use, redistribution, and publishing modified versions may have different requirements; check the license file and accompanying notices for each project. “Open source” describes how software is developed and distributed; it does not guarantee anything about subscription content or remote services.

For everyday use, note the app name, platform architecture, and core, keep a record of where configurations came from, and understand the permissions requested by the client. Protect passwords, user identifiers, and subscription URLs. Redact them from screenshots when asking for help. Node addresses, SNI, and public keys serve different purposes, but you should still avoid sharing a full private configuration. Describing whether the fields match is usually enough to help diagnose an issue.

Updates: manage the client, core, and subscription separately

Client updates mainly affect the interface and configuration management; core updates affect connection behavior; subscription updates change the node list provided by the configuration provider. These updates come from different sources and have different effects. A change in node count or parameters after refreshing a subscription does not necessarily mean the client was upgraded. If a configuration stops working after a client update, that does not necessarily mean the subscription URL is invalid. Identify which layer changed before deciding whether to roll back, re-import, or adjust fields.

Before updating, keep your existing settings and note the node and routing mode in use. Afterward, test a frequently used node, then check local network access, DNS resolution, and the apps that need a proxy. Set auto-update intervals according to your provider's limits; frequent refreshes are unnecessary. If updates keep failing, stop retrying and check the URL, request path, system time, and error logs one by one. Avoid making repeated changes that make the original cause harder to trace.

Verify the connection: check each layer from entry point to server

If importing succeeds but you cannot access a site, first confirm that the intended node is selected and the core is running, then check whether the app is actually using the proxy. If a browser connects but other programs do not, check the traffic entry point. If only domain names fail, investigate DNS first. If all apps fail, revisit the node parameters and remote server reachability. A latency test only reports the result of one kind of test request; it does not prove that every protocol and app is working.

Use the glossary to distinguish subscriptions, share links, inbounds, and outbounds. For symptom-based help, see the FAQ. Record when the error occurred, what you changed recently, and which logs are relevant; this is more useful than switching protocols at random. Choose a setup that matches server support and app requirements. Consistent parameters matter more than chasing a protocol name.

Configuration guidesSubscription formats, updates, and deployment

Browse all articles →

Once the basic connection works, explore guides based on your needs. Subscription formats affect how configurations are imported; failed updates require checking the request path; router deployment involves different network roles from a desktop client. Each article focuses on one issue, helping you check whether the guidance applies before making changes and avoid mixing instructions for secondary routers, Android permissions, and desktop system proxies.

Deployment

Running V2Ray cores on routers and secondary gateways: hardware, transparent proxying, and DNS routing

An overview of running the Xray or V2Fly core directly on a primary or secondary router, covering hardware architecture and memory requirements, transparent proxy options, and DNS routing.

For readers who understand client traffic entry points and want to extend proxying to their local network. First clarify the roles of the gateway and DNS resolver, then choose where to deploy.

Read the deployment guide →
Subscriptions

V2Ray subscription formats compared: Base64 subscriptions, native JSON configs, and share link conversion

Compare the structures of Base64 subscriptions, native JSON configs, and vmess:// and vless:// share links. Learn about client compatibility and ways to convert between formats.

For users who see a format error when importing or need to move between clients. Identify the input format before converting, and watch for transport or security settings that may be lost.

Read the format guide →
Troubleshooting

Why v2rayN subscription updates fail and how to set auto-update intervals

Troubleshoot invalid subscription URLs, whether update requests use a proxy, system clock errors, and certificate issues. Includes recommended auto-update intervals and subscription group settings.

For cases where nodes still connect but subscriptions will not refresh. Test “fetching subscriptions” separately from “using nodes,” keep a working configuration, and fix the update path.

Read the troubleshooting guide →