GUI clients · subscriptions and routing

V2Ray Client Guide Client Downloads & Setup

Download v2rayN View the Guides

Configure desktop and Android clients with subscription imports, proxy routing, and DNS settings.

VMess VLESS Trojan REALITY
Windows Android macOS Linux

Client Downloads for Four Platforms

Check your operating system and CPU architecture first, then make sure the client’s core supports your needs. The download page lists package formats and selection guidance; installation files aren’t distributed from the homepage.

Windows

 Top Pick: v2rayN

v2rayN offers desktop and classic WPF editions. The desktop edition uses a cross-platform interface, making it a good fit if you want a consistent workflow across desktop operating systems. The WPF edition retains the classic interface and suits established setups. Confirm that your system is supported, then choose the interface you prefer; switching editions is no reason to change server settings.

After the first launch, import a subscription, select a server, and then configure the system proxy. Browser access alone doesn’t mean command-line tools or every app are using the proxy. Check whether each app follows the system proxy or needs its own proxy settings. Before moving the program folder or switching devices, back up custom rules and settings in the client.

Go to Downloads →
Editions: Desktop and classic WPF versions are listed separately. Connection: Start with the system proxy; consider TUN if needed.

macOS

 v2rayN

On macOS, v2rayN downloads are available for Apple Silicon and Intel. Check the chip or processor in About This Mac and choose the matching build; don’t rely on the computer’s appearance or purchase date. The client interface, core process, and system network settings are separate layers, so confirm that the system proxy is enabled after launching the app.

When moving from another desktop device, you can usually import the subscription link again, but check local paths, listening ports, and permissions. If another network tool has changed the system proxy, quit it before testing to prevent apps from overwriting each other’s settings. After waking from sleep or switching networks, check the active server, system proxy, and DNS before rebuilding the configuration.

Go to Downloads →
Chip selection: Apple Silicon uses arm64; Intel uses x64. See the download page for specific system requirements.

Android

 Top Pick: v2rayNG

For Android, start with v2rayNG, which uses the Xray core. Consider v2flyNG if your existing setup depends on V2Fly behavior. The interfaces are similar, but their core capabilities aren’t interchangeable based on the app name alone. For combinations such as VLESS and REALITY, check the client, core, and fields in the share link; a successful import doesn’t guarantee compatibility.

Downloads are available in arm64 and universal formats. Most recent devices use arm64; check your system’s architecture if you’re unsure. The first connection requires system VPN permission. Another app using the VPN connection at the same time may displace it. If the connection drops in the background, check battery restrictions and background permissions before changing client settings; changing protocols shouldn’t be your first step.

Go to Downloads →
Download order: v2rayNG first, then v2flyNG. Configure per-app proxy and background behavior on the device.

Linux

 v2rayN

On Linux desktop, v2rayN is available in deb and rpm packages. Choose the format that matches your distribution, then select x64 or arm64. The package format determines how the app is installed; the architecture determines whether it can run. A GUI client makes subscriptions and routing easier to manage, but desktop environments handle system proxies differently. One browser’s results don’t necessarily reflect every app’s traffic.

After importing a subscription, test with an app that explicitly supports proxy settings, then check the desktop proxy and other apps. If you need to route more traffic, learn about TUN permissions and routing implications first. If startup fails, check the logs for permission errors, port conflicts, or invalid configuration fields instead of repeatedly switching servers. Keep custom rules backed up separately for easier migration and recovery.

Go to Downloads →
Package format: deb / rpm. CPU architecture: x64 / arm64. Establish a basic connection before routing more traffic.
Browse All Clients →

Subscriptions, Routing & Connection Settings

Follow the order of the client’s settings. First distinguish the input source, traffic destination, and DNS resolution path; then decide what to change. Avoid changing several groups of settings at once.

Keep Subscription Sources Separate from Local Changes

Subscriptions centralize server settings at their source; the client fetches, parses, and groups those entries. When adding one, enter a recognizable label, update it, and check the protocol fields. Keep manual servers in a separate group so they don’t get mixed in with subscription entries; local changes to subscribed servers may be overwritten by the next update. Subscriptions are convenient for ongoing sync compared with copying share links one by one, but they typically don’t migrate routing, DNS, or system proxy settings. Subscription URLs may contain credentials, so redact them before sharing when troubleshooting.

Subscription Management / Workflow
Add a subscription group
  → Enter a label and subscription URL
  → Update the current group
  → Check server settings
  → Set the active server

Manual configuration → Separate group
Custom routing → Back up separately
See How to Import a Subscription →

From Subscription Import to Connection Testing

Follow one complete setup path the first time. Get one server working with one app before adding rules, per-app settings, or a broader traffic scope.

  1. Import a Subscription and Check the Active Server

    After installing and opening the client, add a subscription group, enter a label and subscription URL, then update the group. The menus differ between desktop v2rayN and Android v2rayNG, but both require two separate actions: adding a source and fetching servers. If the list is still empty after saving the subscription URL, first check that you updated the group, then look for network or DNS errors in the logs.

    Choose a server as the active entry and check its address, port, protocol, and transport and security settings. A subscription URL, a single-server share link, and a full configuration file are different kinds of input; they can’t be added through just any import option. If you only have a QR code, first check whether it contains a single server or a subscription URL. A subscription doesn’t include every local preference, so recheck routing and DNS after moving to another device. Compare terms in the glossary.

  2. Choose a Mode and Keep the Basic Routing Rules

    On desktop, start with the system proxy and confirm that your test app honors it. On Android, approve VPN access and start the connection. For your first setup, use a basic routing preset supported by the client and avoid adding complex rules from unknown sources. If you need access to LAN devices, check the LAN bypass settings. For per-app proxy, confirm whether you’re using an allowlist or blocklist so the app you’re testing isn’t placed in the wrong group.

    Don’t run multiple tools that change the system proxy or compete for the VPN connection at the same time. If a browser works but another app doesn’t, check how that app handles proxies before replacing the subscription. Enable TUN or FakeDNS one setting at a time, after verifying the basic connection, and note the previous settings. Changing one thing at a time makes it easier to identify whether permissions, routing, or DNS caused the difference.

  3. Test Access, Then Check DNS and Logs

    After connecting, make a request from an app you actually need and check the client logs. First confirm that the core started and established an outbound connection, then check whether the app’s request entered the proxy. A successful server test only confirms the path covered by that test; it doesn’t replace testing DNS and access from your browser and apps. To verify routing, test both a destination that should connect directly and one that should use the proxy, rather than visiting just one site.

    When an error occurs, note when it happened, which mode you used, and the error type in the logs. Remove subscription URLs, user IDs, and other sensitive settings before sharing logs. Certificate errors, authentication failures, DNS issues, and port conflicts each point to different checks; reinstalling usually shouldn’t be the first step. Once the connection is stable, export a local configuration backup to keep a recovery point before making further changes. For common errors, see FAQ; the complete process is covered in the usage guide.

Read the Full Guide →

Project V and Its Core Families

The client handles the interface and configuration; the core runs the connection. Keeping these layers distinct helps explain protocol support, configuration compatibility, and changes after updates.

PROJECT V

The V2Ray Ecosystem

Shared technical roots, different paths of development.

V2FlyContinues V2Ray community development
XrayForked from V2Ray and developed independently

GUI clients generate configurations; the selected core runs them. Shared concepts don’t guarantee compatibility across all extension fields.

Ecosystem History: Shared Roots, Different Capabilities

Project V is a starting point for understanding the V2Ray ecosystem. V2Fly continues V2Ray community development, while Xray forked from V2Ray and follows its own development path. They share configuration concepts such as inbounds, outbounds, and routing, but support for protocol extensions, configuration fields, and default behavior has diverged over time. Being part of the V2Ray ecosystem describes a project’s technical roots; it doesn’t mean a configuration can be moved over unchanged.

Client names and core names don’t map one to one. The GUI handles subscriptions, generates configuration, and launches the core; the running core performs authentication, transport, and routing. When troubleshooting compatibility, record both the client and core details. Whether an option from a guide is available depends on the current interface and the active core’s capabilities, not just the menu label in a screenshot.

Choosing a Core: Start with Your Existing Configuration

If you need features such as REALITY or XTLS Vision, check that the corresponding Xray version supports them and confirm all required fields. Existing VMess and other common protocol configurations still need their transport and security settings checked; the protocol name alone doesn’t guarantee compatibility. V2Fly and Xray share some basic structures, but extensions and DNS behavior may differ. Before switching, keep a copy of the original configuration, test a minimal connection, and restore custom rules gradually once it works.

Protocols aren’t a speed ranking. Handshake design, server load, transport path, multiplexing settings, and your network all affect performance. On mobile devices, background restrictions and connection maintenance can also affect battery life. Choose based on features and compatibility first, then compare actual behavior on the same device and network. For details, see the protocol guide; there’s no need to enable every advanced option at once.

Open Source: Understand the Client and Core Separately

v2rayN, v2rayNG, and v2flyNG are open-source GUI clients. v2rayN manages desktop configurations; v2rayNG uses the Xray core, while v2flyNG offers an Android option based on V2Fly. These clients provide connection tools and configuration interfaces; installing one doesn’t automatically provide a working server configuration. You’ll need to obtain subscription or server settings separately and confirm that you’re authorized to use them.

Open-source licenses define the terms for using and redistributing code; clients and cores should be considered separately. V2Fly uses the MIT license, and Xray-core uses the MPL-2.0 license. These licenses describe the terms for using the project code; they don’t determine whether a particular configuration will work in your environment. When troubleshooting, identify whether the issue is in the interface, subscription parsing, or core execution to narrow down the cause.

Updates: Manage the App and Subscription Separately

Client updates, core updates, rule data updates, and subscription updates are separate operations. Updating a subscription refreshes server entries; it typically won’t improve the client’s ability to parse new fields. Updating the app won’t automatically fix an expired subscription URL either. When a feature is announced, first identify which layer it belongs to, then update the relevant component. Keep a recoverable local configuration on devices you use regularly rather than relying on a subscription link alone.

Before upgrading, back up custom routing, DNS settings, and manual servers. After the upgrade, test with a known-good configuration first. Once basic access, routing, and DNS all work as expected, restore other advanced settings. This site provides client downloads and Chinese-language setup guides; it doesn’t provide server subscriptions or vouch for third-party settings. Find installation details on the download page, then follow the usage guide to complete setup.

Setup Tips and Troubleshooting

Explore subscription group management, DNS routing, and Android background behavior. Each guide focuses on a specific problem, with clear setup instructions, requirements, and verification steps.

Browse All Articles →