Xray · V2Fly core clients

V2Ray Setup Guide

Start with choosing a client and importing a subscription, then check the actual fields for routing and DNS settings.

  • VMess
  • VLESS
  • Trojan
  • Shadowsocks
  • REALITY

CLIENT / SYSTEM

Choose a client and operating system

Check your operating system and processor architecture before choosing a client. v2rayN is the main desktop option; on Android, consider v2rayNG with its Xray core. If you need V2Fly compatibility, check which features v2flyNG supports. The client provides the interface, but protocol support depends on the selected core.

Windows

v2rayN

The desktop edition uses a cross-platform interface, while the classic WPF edition retains a familiar desktop workflow. Both work well for managing subscriptions, editing nodes, and viewing logs; choose whichever suits your preferences.

Check the system requirements before installing. If you already have a setup, export any subscription groups and routing rules you want to keep so the new environment doesn't overwrite them.

Go to downloads

macOS

v2rayN

Use the chip information in About This Mac to choose the Apple Silicon or Intel installer. Processor architecture and operating system are separate criteria; don't rely on the file extension alone.

After installation, import a working node and confirm the client can make a request before enabling the system proxy. If browsers and other apps behave differently, check whether each app follows the system proxy settings.

Go to downloads

Android

v2rayNG / v2flyNG

v2rayNG uses the Xray core; v2flyNG is an alternative based on V2Fly. Most modern devices use arm64. If you're unsure of the architecture, check your device details before trying a universal installer.

Approve the system VPN prompt when connecting for the first time. If the connection drops in the background, check battery optimization and background app restrictions; don't mistake a system process being stopped for a subscription or protocol error.

Go to downloads

Linux

v2rayN

Choose a deb or rpm package based on your distribution, and distinguish x64 from arm64. A desktop GUI client makes it easy to manage nodes in one place; you don't need to set up a command-line service just to manage subscriptions.

After installation, check your desktop environment's proxy settings and local listening port. Some apps require the proxy address to be entered separately; enabling the system proxy doesn't guarantee every process will use it.

Go to downloads

CONFIGURATION PATH

Inbound, routing, outbound.
Follow the request path through the config.

FIELDS / CAPABILITIES

Protocol, transport, and routing settings

The protocol name in a share link describes only part of the configuration. Authentication, transport, security layers, and routing rules each serve a different purpose. Use the index below to distinguish them, then check the relevant configuration reference. Don't copy an entire example from another core into your current client.

QUICK START / THREE STEPS

From subscription import to connection testing

Installing a client is only the first step. For an initial setup, use a node from a trusted source with complete settings to test the full connection path before adding complex routing rules. This makes it easier to isolate issues with the node, client settings, or app connectivity.

  1. Import a subscription and check its nodes

    Add a group in subscription management and enter the subscription URL, then save and update it. For a single share link, use the import-from-clipboard option. If the list is empty, check for extra spaces in the copied text and whether the subscription requires valid credentials; a webpage URL isn't necessarily a subscription URL.

    After importing, open a node's details and check its protocol, server address, port, and transport. The node label is just a name for identification; it doesn't indicate the actual route, availability, or encryption. If you made manual changes, note them before refreshing the subscription.

  2. Select a node and configure traffic routing

    Set the node you want to test as active, then choose a routing mode for your needs. Before enabling the system proxy on desktop, check that the local listening port isn't already in use. On Android, approve the VPN prompt. The system proxy only affects apps that follow it; this doesn't mean all traffic is routed through the client.

    For your first run, keep the rules clear and simple. If you need to switch to an access method such as TUN, check permissions, routing, and DNS behavior separately. Don't change transport, security, and routing settings all at once, or it'll be hard to tell what caused the result.

  3. Make a new request and check the logs

    Open a test page you're allowed to access and check whether the client logs show the corresponding connection. A successful TCP test only confirms that a connection can be made to a port; it doesn't prove authentication, the TLS handshake, or the full request succeeded. A real connection test and a download speed test measure different things, too.

    If the browser still can't connect, check its proxy settings first, then look in the logs for DNS resolution, connection timeouts, or handshake errors. Change one thing at a time, save and reload the config, then test with a new request. Before sharing logs for help, remove subscription URLs, credentials, and other personal information.

CORE / CLIENT / CONFIG

Understand core capabilities
before checking client settings.

PROJECT V / V2FLY / XRAY

How open-source cores and clients fit together

A search for “V2Ray” can turn up project names, core names, and client names. They refer to different layers: the project ecosystem provides the technical foundation, the core handles connections, and the GUI client organizes nodes and settings into a working configuration. Understanding these distinctions helps you judge whether a guide applies to your setup.

Project V: the shared background to the configuration model

V2Ray originated in the Project V ecosystem. Inbounds receive app traffic, routing determines where it goes, and outbounds connect to destinations. This structure keeps protocol and traffic policies separate. Many GUI clients still use these concepts, so understanding inbounds, outbounds, and routing transfers more easily across environments than memorizing a button's location in one interface.

Similar configuration structures don't mean every field is interchangeable. When reading an older guide, check which core it covers, the protocol combination, and its scope. Interface labels may change with updates, but tracking where a request enters, which rules match it, and which outbound sends it remains a reliable way to troubleshoot.

V2Fly and Xray: related projects, separate development

V2Fly continues the community development of V2Ray, while Xray grew from related code and introduced its own protocol and transport capabilities. They share a history but differ in configuration support. For example, check REALITY and XTLS Vision settings against Xray's supported features. Both cores using JSON doesn't mean one will recognize the other's fields.

If a client lets you switch cores, treat that as more than a performance choice. Recheck whether the selected core supports the node protocol, security layer, and fields such as flow. If you see an “unknown field” or unsupported protocol message, check the core selection before repeatedly changing the server address.

Three clients: separate roles for the UI and core

v2rayN, v2rayNG, and v2flyNG are all open-source GUI clients. v2rayN is for desktop use and manages nodes, subscriptions, and routing; v2rayNG runs the Xray core on Android; v2flyNG offers an alternative based on V2Fly. Subscription groups and interface preferences saved by a client aren't necessarily the same files as the runtime config read by its core.

All three clients are free to use, but they don't provide remote nodes or network service. Subscription links and node settings must come from a service you have permission to use. Choosing software, choosing a core, and choosing a connection service are three separate decisions; one name shouldn't stand in for the others.

Open-source licenses and updates: check each component

Open source means the source code is available under the applicable license terms; use, modification, and redistribution must still follow each project's license. V2Fly's main code uses the MIT License, and Xray-core uses MPL-2.0. Clients and bundled components have their own licenses. A license describes rights and obligations; it doesn't guarantee the safety of any runtime configuration.

Clients, cores, and rule data may follow different release schedules. Before upgrading, note the current core selection and back up routing and DNS settings; afterward, verify with the same test request. If only one site has a problem, check its rules and DNS resolution first. If all connections fail, troubleshoot step by step: local access, node settings, and core status.

READING / RECENT NOTES

Subscription formats and connection diagnostics

Once the basic connection works, look into format conversion, protocol differences, and test results. These three articles cover commonly confused concepts through specific fields and measurement methods. Consult them when you run into the corresponding configuration issue.

VMess vs. VLESS: UUID, alterId, and encryption basics

Compare the two protocols by authentication, timing requirements, and security layers, and learn what UUID and alterId do. First identify which layer each field belongs to, then determine which settings must come from the node provider and which aren't interchangeable.

Read the article →