Selection GuideStart with your platform, then compare cores and settings

Choosing a V2Ray client

For desktop, choose v2rayN; for Android, choose v2rayNG. Consider v2flyNG if you already use V2Fly configs or specifically need that core.

These three clients are not interchangeable options for the same platform. v2rayN focuses on desktop subscription management, system proxy settings, and routing. v2rayNG and v2flyNG are built around Android VPN permissions, per-app proxying, and background connections. Start by narrowing your options by device, then check the protocols and transport settings in your subscription. That is more useful than comparing the number of toggles.

This page compares what each client is designed to do; it does not rank connection speeds. Real-world results also depend on the server, network path, DNS, routing rules, and device. For a fair comparison, test the same subscription under the same conditions in each client.

Compare the three clients

“Ease of setup” means the effort required to import a config, connect, and set up basic traffic routing for the first time; it is not a measure of software quality. Maintenance status is described qualitatively. Check the release notes, current interface, and actual core to confirm that a setting is available.

On narrow screens, swipe the table horizontally to see all client columns.

v2rayN: Desktop subscriptions and routing

v2rayN is well suited to managing connections on a larger screen. Its server list makes it easy to review configs in batches, subscription groups help organize sources, and routing settings are easier to inspect rule by rule. If you regularly switch between work and home networks or manage multiple subscriptions, keeping everything in one place is clearer than repeatedly importing individual share links. To get started, import a subscription, select a server, and set the system proxy. You don't need to enable every advanced feature at once.

Most of the learning curve comes from choosing a network mode. The system proxy relies on apps honoring system settings, while TUN routes traffic through a virtual network adapter. They differ in coverage and troubleshooting. If an app ignores the system proxy, first check the app's own proxy settings, then decide whether TUN is needed. Turning on TUN is not a universal fix for connection issues. Also check the required permissions, components, and DNS behavior for your system.

Choosing a desktop download

On Windows, Desktop is the newer cross-platform interface, while WPF is the classic interface. If you're new, start by exploring Desktop. If you're used to WPF or rely on its existing settings workflow, keep your current config and assess migration first. For macOS, choose the build for Apple Silicon or Intel. On Linux, select deb or rpm for your distribution, then check the processor architecture. Menu locations vary by platform, so don't expect another platform's instructions to match your interface exactly.

Windows downloads · macOS downloads · Linux downloads

v2rayNG: Everyday Android connections and per-app proxy

v2rayNG is a good fit if you want to manage subscriptions, select a config, and connect from your phone. The basic workflow is short; the main thing to understand is the VPN permission requested the first time you connect. Android's VPN service lets an app route traffic—it does not provide a working server. After installing, import a valid subscription or server config, check its protocol settings, and then connect.

Per-app proxy is one of the most useful features for Android. If only certain apps need a proxy, set the app list to match your needs. After changing it, reconnect and check both included and excluded apps. Before enabling traffic sniffing, local DNS, or Mux, make sure you understand what each feature does. More toggles don't mean faster connections. Mux in particular depends on the protocol, server, and traffic type, so don't turn it on everywhere just to “optimize” performance.

Check background operation settings

If the connection drops when your phone locks, the cause may be battery optimization, background restrictions, or a network change. Check the system's battery and background settings for the client, then review its logs. Switching to a different core won't remove system restrictions. For package architecture, arm64 is the usual choice for newer mainstream devices. If you're unsure or have a different architecture, check the universal build and system compatibility notes.

v2rayNG for Android · How to import a subscription and connect for the first time

v2flyNG: An alternative when you specifically need V2Fly

The main reason to choose v2flyNG is its place in the V2Fly core ecosystem—not a guarantee that an alternative client is lighter or faster on an older phone. If your existing configs, test environment, or maintenance workflow depends on V2Fly, using a compatible client can reduce config conversion. Android newcomers without that requirement will generally find v2rayNG a more straightforward starting point, with common Xray configs that are easier to troubleshoot.

When migrating, distinguish the protocol name from the specific capabilities you need. The same protocol can use different transports, security settings, or extension fields. Successfully importing a share link doesn't mean the connection will behave identically. Full JSON configs from other cores often include core-specific fields, outbound structures, or DNS options, so they shouldn't be treated as universal subscriptions. First test one known-good config, then add routing and DNS changes gradually.

Don't judge maintenance by whether the app installs

Before choosing, check that the current build supports your device's OS and the protocols you need, and that there are enough release notes to troubleshoot changes. Starting on a phone only confirms that the app launches; it doesn't guarantee protocol support or reliable background connections. If your current setup is stable, keep a config backup and avoid changing the client, subscription source, and routing policy all at once.

v2flyNG for Android

Choose by use case

Before switching clients

1. Keep a recoverable copy of your config. Record your working servers, subscription groups, routing, and DNS settings. Backups may contain subscription credentials and server authentication details. Store them somewhere you control, and don't share a full config publicly.
2. Check the import format.Share links, subscription content, and full JSON configs are different types of input. The subscription import option does not replace the custom config import option. If the client reports an import error, check the format first, then confirm protocol support.
3. Use the same test conditions.Test with the same server, network, a similar time of day, and the same routing policy. Latency readings in a server list alone can't tell you how websites load, how fast downloads run, or how stable long-lived connections are.
4. Distinguish connection failures from traffic routing failures.If the core connects but an app can't access the network, the system proxy may not be active, the app may ignore proxy settings, or DNS or per-app rules may be involved. Check the logs and which traffic is routed before repeatedly trying different packages.
5. Restore advanced settings one at a time.Verify the basic connection first, then add routing, DNS, and traffic interception changes. Change one category of settings at a time so you can identify whether a problem comes from rule order, DNS resolution, or permissions.

If the terminology is what's making the choice difficult, start with the glossary of protocols, cores, and routing. Once the basic connection works, see the advanced guide to subscription groups, routing, and DNS for more precise traffic rules.

The takeaway: start with the platform, then choose a core