V2Ray Client Downloads

Choose your operating system, then check the processor architecture and package format. Use v2rayN on desktop; for Android, start with v2rayNG and consider v2flyNG if you need the V2Fly core.

Windows

Recommended: v2rayN

v2rayN offers Desktop and the classic WPF edition. Desktop uses a cross-platform interface, while WPF retains a familiar desktop layout. Before downloading either, check your operating system and processor requirements. Don't rely on file size alone to determine compatibility.

After installation, import an existing subscription or connection profile, select a configuration, and start the core before enabling the system proxy. The system proxy affects apps that follow your system settings; it does not route every app's traffic. For broader coverage, see the TUN guide.

Go to downloads →

macOS

v2rayN

v2rayN provides separate downloads for Apple Silicon and Intel Macs. Check your processor in About This Mac, then choose the matching architecture. The processor and package architectures must match; appearance and device year are not reliable indicators.

After installation, launch the client and import your configuration, then check the system proxy settings. If only some apps connect, check whether they follow the system proxy, whether routing selects the expected outbound, and whether DNS uses the right path. Avoid reinstalling the client before checking these settings.

Go to downloads →

Android

Recommended: v2rayNG

v2rayNG uses the Xray core, while v2flyNG uses V2Fly and may suit configurations that depend on its behavior. Most recent devices use arm64; if you're unsure of your processor architecture, check whether a universal package is suitable. Verify configuration compatibility for either client field by field.

When you connect, Android asks for permission to establish a VPN connection. This is the system interface the client uses to route traffic; it doesn't confirm that the remote server is available. On the first connection, check the client logs and per-app proxy settings. Other apps using the same system interface may conflict.

Go to downloads →

Linux

v2rayN

v2rayN offers packages for different Linux distributions. Debian- and Ubuntu-based systems typically use deb packages, while Fedora and similar distributions typically use rpm. You'll also need to choose x64 or arm64. Package format determines how software is installed; processor architecture determines whether it can run. Check both.

The desktop environment, system proxy, and autostart settings are separate components. First, connect manually from the graphical interface, then configure the app to launch at login. If the client runs but apps cannot connect, check the desktop proxy settings and each app's proxy options before looking into permissions and dependencies.

Go to downloads →

The client handles local configuration and connection management. You still need valid server details to connect; installing the app won't create a subscription or remote account.

View all clients →

Client Settings and Configuration Fields

Trace settings in the interface back to the actual configuration. Each example below shows only a snippet to explain how data flows. Client-managed settings and core fields are covered separately; these snippets are not complete connection configurations.

inbounds.json / local entry after import

Subscriptions Are Managed by the Client

Subscription import lets the client save connection profiles in bulk. Update URLs are client-managed data, not top-level fields in a standard config.json. v2rayN, v2rayNG, and v2flyNG use different menus and storage, but after importing, check the protocol, address, and transport settings in each profile. The snippet below shows a local SOCKS inbound to use with a selected profile; it is not a subscription file. It listens only on the loopback address, allowing apps on the same device to send traffic to the core through this port. Updating a subscription should not overwrite routing rules you maintain yourself.

{
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ]
}

See how to import a subscription →

routing.json / choose an outbound by rule

Rule Order and Outbound Tags

Routing sends different destinations through different outbounds; it doesn't redefine the remote connection. Rules are checked in order, so put specific rules before broad ones. This example sends private addresses to the outbound tagged direct; that tag must also appear in outbounds. v2rayN lets you manage routing in its interface, while Android clients have different presets and customization options. After editing, reload the configuration and check the destination and outbound tag in the logs. If a domain hasn't resolved, an IP-only rule may not produce the expected result.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  },
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

See the routing fields →

outbounds.json / outbound examples for routed traffic

Configure Traffic Capture Separately from Routing

TUN uses a virtual network interface to capture traffic, typically for apps that don't follow the system proxy. How v2rayN implements TUN, and what permissions or components it needs, depends on the setup. Android clients capture traffic through the system VPN interface, so desktop TUN instructions don't apply directly. There is no universal top-level tun switch in V2Ray configurations that works across cores. The snippet below shows direct and blocked outbounds that can be used after traffic is captured; it does not create a virtual network interface. Before enabling TUN, check for conflicts with other traffic-capture tools and make sure you know how to restore your network settings.

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ]
}

Read the TUN setup notes →

dns.json / built-in DNS servers

First, Find Where DNS Resolution Happens

DNS settings depend on who makes the query, which connection carries it, and how the result affects routing. The core's dns section doesn't automatically replace system DNS settings for every app. This example uses localhost to query the local resolver; it illustrates the server list structure, not a setup for every network. v2rayN and Android clients may also offer remote DNS, fake IP, or traffic-capture options, so check the generated configuration after making changes. If a domain fails but its IP works, first distinguish a DNS problem from a routing problem.

{
  "dns": {
    "servers": [
      "localhost"
    ]
  }
}

See the dns fields →

policy.json / check core support

Choose a Core Based on Protocols and Fields

Core switching is a client feature, not a universal config.json setting. v2rayN lets you select a core it supports; v2rayNG and v2flyNG are respectively built around Xray and V2Fly. Similar configuration structures don't guarantee full compatibility across protocols, transports, or extension fields. Check the server requirements before switching. The policy snippet below shows user-level settings; whether it takes effect depends on whether the relevant users use that level. When migrating, keep a working configuration and test changes one at a time. Avoid changing the core and routing simultaneously.

{
  "policy": {
    "levels": {
      "0": {
        "handshake": 4,
        "connIdle": 300
      }
    }
  }
}

Compare the cores →

Project V, V2Fly, and Xray

Distinguish the project ecosystem, connection core, and graphical client. The two endpoints negotiate the protocol, while the client passes configuration to the core. Similar names don't mean configurations are interchangeable.

ecosystem / how the components fit together

Project Background: Project V
Core Families: V2Fly / Xray
Desktop Clients: v2rayN
Android Clients: v2rayNG / v2flyNG
Configuration Structure: JSON / Inbounds / Outbounds / Routing

VMess
VLESS
Trojan
GPL-3.0

Protocol names help identify configuration requirements; they don't mean every core and transport combination will work as-is.

Project History and Component Roles

Project V is a starting point for understanding V2Ray's technical background. Proxy cores organize connections around inbounds, outbounds, and routing, while graphical clients provide subscription lists, system proxy controls, and settings interfaces. V2Fly continues development related to V2Ray, while Xray is an independently developed core branch. The two share some concepts, but their features and configuration have evolved differently. When consulting documentation, check which core it covers rather than relying on V2Ray in the title alone.

Core Families and Protocol Compatibility

VMess, VLESS, and Trojan are connection protocols; TCP and WebSocket describe transport methods; TLS covers transport security settings. Consider these layers together—a protocol name alone isn't a complete configuration. Before choosing a core, check the server's protocol, transport, security settings, and extension requirements, then make sure the client can generate the required fields. If something isn't compatible, identify the specific field rather than assuming the client failed to install.

Three Clients and Their Open-Source Licenses

v2rayN, v2rayNG, and v2flyNG are open-source graphical clients released under the GPL-3.0 license. Cores, rule data, and bundled components may have their own licenses, so a client's license label doesn't cover every dependency. Open source lets you inspect how the software works and understand its configuration, but it doesn't replace checking the server's source, subscription permissions, or system permissions. Subscription URLs may contain credentials; remove sensitive details before sharing screenshots or logs.

Updates and Configuration Migration

Client, core, subscription, and rule data updates are separate operations. A client update can change the interface and how configurations are generated; a core update can affect supported fields and connection behavior; subscription updates change connection profiles; rule updates change what matches. Before changing your setup, save a working configuration and any custom rules, then change one component at a time. Reload the configuration afterward and test DNS resolution, direct connections, and proxied connections separately to identify what changed.

A Step-by-Step Approach to Troubleshooting

After installation, first make sure the client launches. Then check that subscription profiles have all required settings, confirm the local proxy is enabled, and finally review routing and DNS. Errors in the logs point to different layers: a listener failure usually means checking for a port conflict; a handshake failure calls for checking the remote protocol and security settings; a DNS failure means tracing the DNS path. Checking each stage separately makes it easier to preserve a working setup than changing every option at once.

For terminology, start with the glossary. For step-by-step interface instructions, read the getting started guide. To check field hierarchy and JSON structure, open the configuration reference. Example ports, tags, and policies illustrate structure only; make sure they match your local settings and server details before use.

V2Ray Technical Notes

Browse by problem. Understand the configuration structure first, then work through DNS resolution and platform setup. Check each snippet against the client and core you're using.

Nov 2, 2026Platforms

Install v2rayN on Linux: deb/rpm packages and autostart

Covers desktop installation on Debian-, Ubuntu-, and Fedora-based distributions, including package formats, architecture choices, autostart, and common dependency issues. Troubleshoot installation, desktop startup, and network proxy settings separately.

Read the notes →

Oct 15, 2026Configuration

V2Ray config.json Explained: inbounds, outbounds, and routing

Explains how inbound listeners, outbound connections, and routing tags fit together. Follow JSON snippets to understand client-generated configuration and distinguish local listening settings from server connection details.

Read the notes →

Sep 27, 2026Networking

V2Ray DNS Split Routing: Separate DNS Resolution for Domains in and outside China

Explains the servers, domains, and expectIPs fields in the dns section, and how local and remote resolution relate to routing. Trace the query path first, then check whether the results are as expected.

Read the notes →

Technical notes address specific issues; see the configuration reference for complete field hierarchies and usage.

View all articles →

V2Ray Client Official Sitev2rayN Downloads and Setup

V2Ray Client Downloads

Windows

macOS

Android

Linux

Client Settings and Configuration Fields

Subscriptions Are Managed by the Client

Rule Order and Outbound Tags

Configure Traffic Capture Separately from Routing

First, Find Where DNS Resolution Happens

Choose a Core Based on Protocols and Fields

Project V, V2Fly, and Xray

Project History and Component Roles

Core Families and Protocol Compatibility

Three Clients and Their Open-Source Licenses

Updates and Configuration Migration

A Step-by-Step Approach to Troubleshooting

V2Ray Technical Notes

Install v2rayN on Linux: deb/rpm packages and autostart

V2Ray config.json Explained: inbounds, outbounds, and routing

V2Ray DNS Split Routing: Separate DNS Resolution for Domains in and outside China