v2rayN · v2rayNG · v2flyNG

V2Ray
Downloads & setup

Download v2rayN View guides

Download open-source clients and follow setup guides, from importing subscriptions to routing traffic, with steps for each platform.

Protocols
  • VMess
  • VLESS
  • Trojan
  • Shadowsocks
Platforms

Client downloads

Choose an installer for your operating system

Check your operating system and processor architecture before choosing an installer. Use v2rayN on desktop, start with v2rayNG on Android, or see v2flyNG if you need V2Fly compatibility.

Windows

v2rayN comes in a desktop edition and a classic WPF edition. The desktop edition uses a cross-platform interface; the classic edition suits users who prefer the original workflow. Check the runtime requirements before installing, and choose one edition rather than installing both.

Keep the app and its configuration somewhere easy to manage, and back up subscription groups and routing settings before upgrading. After launch, import a server before setting up the system proxy.

Download for Windows

macOS

v2rayN has separate installers for Apple Silicon and Intel. Check your chip under About This Mac and choose the matching build; don’t rely on the computer’s appearance or purchase date.

Pay attention to permission prompts on first launch. System proxy and virtual network interface settings may require permissions, depending on your system and the client’s instructions.

Download for macOS

Android

v2rayNG uses the Xray core, while v2flyNG is based on the V2Fly core. Most recent mainstream phones can use arm64. If you’re unsure of your device’s architecture, check the universal build notes on the download page.

Connecting prompts you to grant VPN permission. If another VPN app is already running, disconnect it first. If the connection drops in the background, check your battery optimization settings.

Download for Android

Linux

v2rayN provides deb and rpm packages for supported distributions, with separate x64 and arm64 builds. Check your distribution and device architecture, then install through your system’s package installer.

Desktop environments handle system proxy settings differently. If an app isn’t using the system proxy, check that app’s network settings before trying a different server.

Download for Linux
Browse all clients

Configuration essentials

Subscriptions, routing, and network modes

The client manages configuration; the core handles connections. Understanding these as separate layers makes it easier to find the right settings when something goes wrong.

Import subscriptions and manage groups

A subscription lets you update a set of server configurations; it isn’t a connection service provided by the client. Once you have a valid subscription URL, create a separate group for it and update the group. You can then organize servers by source without entering their settings by hand each time.

  • Create a group for each source. Give each group a descriptive name so servers from different sources don’t get mixed together. Check which group you’re updating, and you’ll know what’s affected if you delete it.
  • Check the imported servers. Saving a subscription URL doesn’t mean the servers have loaded. After updating, make sure entries appear in the list and that the selected server belongs to the group you just imported.
  • Know the difference between a subscription and a share link. A share link usually contains one server configuration; a subscription URL retrieves a collection. Choose the matching import option to avoid format detection errors.

Routing rules and outbound selection

Routing determines whether a connection goes direct or through a proxy. It’s separate from server selection: even with a proxy server selected, connections matching a direct rule still go direct. Learn the rule matching order before adding your own domain or address rules.

  • Put specific rules first. Keep precise rules, such as domain names and local network addresses, separate from broad rules. If rules overlap, check their order rather than just whether the target domain appears in the list.
  • Use global proxy as a comparison. To see whether routing rules are causing a problem, temporarily switch to proxy outbound and test again. Restore your original mode afterward; don’t treat a one-off diagnostic as a permanent setup.
  • Check DNS along with routing. DNS results can affect how address-based rules match. If only some sites are affected, check the domain rules, DNS resolution method, and runtime logs to narrow down the cause.
See routing rules in practice

Cross-platform setup and traffic routing

Desktop and Android clients can use server details from the same source, but their interfaces, permissions, and traffic routing work differently. When moving between platforms, check protocol parameters and routing intent. Don’t copy an entire configuration directory from one platform over another.

  • Start by testing the system proxy. On desktop, a browser is usually a good place to start. System proxy settings only work for apps that respect them, so this doesn’t mean every program on the device is using the proxy.
  • Enable TUN only if needed. TUN routes traffic through a virtual network interface and may involve elevated permissions, DNS settings, or routing conflicts. Get a basic connection working first, then expand the traffic being routed step by step.
  • Keep device-specific settings separate. Local listening ports, startup behavior, and battery settings depend on the device. Even when sharing a subscription, check these options on each device so local issues aren’t mistaken for subscription problems.

Choose a setup sequence for your issue

If the server list is empty, first check that the subscription URL is saved in a group, then update that group manually. If the update fails, distinguish between an unreachable URL and content that can’t be parsed. For access failures, check your network, the URL’s expiration, and access permissions. For parsing failures, check the subscription format and client support. Don’t share screenshots of logs that reveal the full subscription URL; it may contain access credentials. Once the list loads, select a server and test the connection. A successful subscription update only means the configuration was retrieved; it doesn’t guarantee every server is reachable.

See the subscription import steps

Common v2rayN settings at a glance

Confirm the current server first, then check how traffic reaches the core and which rule selects its outbound route.

This is a static illustration; the port is shown as an example. Actual setting names, locations, and ports vary by client.

Quick start

From importing a configuration to testing the connection

If you already have a working subscription, follow these steps for your initial setup. Clients don’t include servers; you’ll need to provide your own subscription or server details.

  1. Import a subscription and update the server list

    After installing and opening the client, go to subscription management, add a group, save the subscription URL, and update the group. Menu names may differ slightly between desktop and Android; the key steps are saving the source and retrieving its contents. For a single share link, choose the corresponding import option. Once imported, check that the server names, protocol types, and group look right. Don’t paste a subscription URL into the server address field.

  2. Choose a server and confirm how traffic is routed

    Select a server from the list as your connection target. On desktop, enable the system proxy as described in the guide. On Android, grant VPN permission when starting the connection. For your first test, stick with the basic routing setup. Don’t run multiple proxy apps or change DNS, TUN, and routing rules all at once. This makes it easier to tell whether a problem lies with the server, the app’s proxy settings, or a matching rule.

  3. Test a real connection and check the logs

    Open the page you want to reach and check that it loads; don’t rely solely on changes to the client icon. Connectivity tests in the server list only check specific test destinations and don’t represent how every site will perform. If access fails, first confirm that your local network is working, the right server is selected, and the system proxy is active. Then check the runtime logs for the same period. Change one thing at a time and retest; this is usually more effective than changing several settings in a row.

Read the full guide

Open-Source Ecosystem

Project V, core engines, and GUI clients

“V2Ray” is often used as an umbrella term for a group of related tools. When choosing a client, compare its platform, core engine, and configuration support instead of judging compatibility by name alone.

Project V

Project background: proxy tools and modular network processing

V2Fly
Community-maintained V2Ray core ecosystem
Xray
An independent core fork with historical ties to V2Ray
GUI clients
Manage subscriptions, routing, and local settings

This illustration distinguishes project roles; it does not imply that the projects share a unified release or management structure.

Understand core responsibilities through project history

Project V grew into an ecosystem of modular proxy tools. V2Ray’s core role is to accept connections, handle protocols, and route traffic to the configured outbound. V2Fly continues the community-maintained V2Ray ecosystem, while Xray has developed independently from a shared history. The two share concepts and some configuration formats, but their feature support, field meanings, and release schedules differ. Similar names don’t mean their configurations can be swapped freely.

The client interface and core are separate layers

v2rayN is a desktop client with a GUI for managing servers, updating subscriptions, and configuring routes; it calls the appropriate core for the selected features. v2rayNG is for Android and is primarily based on Xray; v2flyNG is based on V2Fly. All three clients are open-source software, maintained and released by their respective projects. Open source describes how the code is made available; it doesn’t replace the need to assess subscription sources, server operators, or device permissions.

Assess protocol support alongside transport and security settings

VMess, VLESS, Trojan, and Shadowsocks are common protocol names. WebSocket and gRPC are transport options, while TLS and REALITY involve different security settings. Seeing the same protocol name isn’t enough to confirm that a configuration will work. The client must recognize the subscription format, and its core must support the specific features in the configuration. Certificate names, transport paths, and other parameters must also match the server.

What open-source licenses and updates mean in practice

Clients and the cores they depend on may use different open-source licenses. When reading, modifying, or distributing code, refer to the license included with each project rather than treating one license as a shared term for the entire ecosystem. Client updates, core updates, and subscription updates are also separate operations: updating a subscription refreshes server configurations, but doesn’t add support for every new protocol feature.

Before updating a client, save your groups, routing rules, and any necessary local settings, and check notes on runtime requirements and configuration compatibility. If the issue affects only one site, start by investigating routing rules and DNS behavior. If the logs specifically report an unrecognized configuration field, check the core’s supported features. Addressing the layer where the problem occurs is more likely to produce repeatable results than updating just for the sake of it.

Advanced setup guide: subscription management, DNS, and TUN

Technical notes

Client installation and core selection

These three articles cover core compatibility, first-time installation, and how the projects relate to one another. They’re useful next reads once you have a basic connection working.

Browse all articles