Client Selection · Setup Guide

V2Ray TutorialDownload & Setup

Your guide to v2rayN client downloads and setup. Start by choosing an open-source client, then import a subscription and configure routing to understand what each setting does.

  • VMess
  • VLESS
  • Trojan
  • REALITY

V2Ray Configuration Guide

First distinguish the client from its core, then work through subscriptions, traffic entry points, and outbound rules. Choose the section for your current issue; there’s no need to change every setting at once.

Client Interfaces and Proxy Cores

Clients such as v2rayN handle subscriptions, configuration editing, and runtime controls; the selected core actually processes connections. V2Fly continues the Project V technology lineage, while Xray has developed independently from related foundations. When choosing a client, check the server’s protocol, transport, and security settings—not just the client name. For configurations involving REALITY or XTLS Vision, confirm that the selected core supports them. Before replacing a core, keep a copy of the existing configuration and test the new setup with a known-working connection.

{
  "log": {
    "loglevel": "warning"
  },
  "outbounds": [
    { "tag": "direct", "protocol": "freedom" }
  ]
}
Read the Core Families section

Treat configuration snippets as examples for their specific sections, not as complete configurations to replace your existing setup. A connection also requires the server address, authentication details, and transport parameters, all of which must match the server. Automatically generated client settings may also vary by core. Export a backup before making changes, and don’t combine fields from different cores in one file.

Troubleshoot in a consistent order: first confirm the core starts, then verify that the local app connects to the listening port, and finally check which outbound handled the request. Change one setting at a time and record the result to distinguish a failed connection from a rule that didn’t match as expected. If one app works in a browser but another doesn’t, check how the traffic enters the client before changing the subscription.

A complete setup path covering core concepts, client installation, subscription management, routing, and ongoing maintenance.

Read the Setup Guide

V2Ray Clients by Platform

For desktop, start with v2rayN; for Android, start with v2rayNG. Identify your operating system and processor architecture before choosing an installer.

Processor architecture is a better guide to choosing an installer than a device’s appearance. On desktop, check the chip type in system information; on Android, distinguish arm64 from universal packages. Don’t assume an installer will work just because the same client runs on another device. If installation fails, check the package format and architecture first, then review the system message. That’s usually more useful than trying one file after another.

The desktop and classic WPF versions are different interface options for v2rayN, not two independent standards for server protocols. When switching interfaces, existing users should check that subscription groups, the active node, system proxy status, and custom rules have been preserved. New users can use the download page to choose a version, establish a basic connection, then add routing and traffic-capture features as needed.

Across devices, you may be able to reuse a compatible subscription source, but don’t copy every local setting. Local ports, network permissions, virtual interfaces, and system proxy behavior depend on the environment. Android clients request system permission to establish a network connection; desktop clients may also need elevated permissions to capture network traffic. When a permission prompt appears, understand which feature requires it before deciding whether to continue.

The Project V, V2Fly, and Xray Ecosystem

Understanding each project’s role makes it easier to choose a setup and troubleshoot than treating clients, cores, and protocols as the same thing.

Technology ecosystemProject V
An ecosystem of projects built around proxy cores, transport, and routing capabilities.
Connection processingV2Fly / Xray
Handle protocol processing and connection forwarding; check each project’s capabilities separately.
Graphical clientsv2rayN / v2rayNG / v2flyNG
Manage user settings, organize subscriptions, and control runtime behavior.

From V2Ray to the Core Families

V2Ray is a widely used name in the Project V ecosystem. As the projects have evolved, V2Fly has continued maintaining related core software, while Xray has followed an independent development path built on shared technical foundations. So “V2Ray client” usually describes a category of configuration tools, not a guarantee that they all run the same core. When following a guide, keep the client, core, and protocol names distinct to tell whether a setting applies.

VLESS, VMess, and Trojan are connection protocols; REALITY concerns connection security. These terms belong to different layers. A server configuration may include a protocol, transport, security layer, and additional parameters; missing any of them can prevent a connection. Choosing a client that supports a protocol is only the first step. Confirm that its active core can handle the complete set of parameters.

What Each of the Three Clients Is For

v2rayN is for desktop use, with tools to manage subscriptions, switch active profiles, and maintain routing rules. v2rayNG is for Android and uses the Xray core; v2flyNG is an Android alternative that uses the V2Fly core. All three are open source, but their interfaces, settings, and ways of integrating with the operating system differ. Follow instructions by matching the feature, not by expecting the same button labels on every device.

Having multiple cores to choose from doesn’t mean every configuration is interchangeable. One core may support extension fields that another doesn’t recognize. Even when different clients parse the same share link, check the transport parameters afterward. If you already have a working connection, keep it as a reference while testing the new configuration. This helps separate compatibility issues from local network problems and preserves a known-good way to troubleshoot.

Open-Source Licenses and User Responsibilities

Open source means the source code is available under its applicable license for users to inspect, use, and study within the license terms. It doesn’t mean every component uses the same license, or that a subscription provider and client project are the same organization. For example, Xray-core is licensed under MPL-2.0, while v2rayN uses GPL-3.0. Before redistributing or publishing modified code, review the license requirements for each project and its dependencies; don’t infer usage rights from the word “free.”

Clients, cores, and connection services have different roles. A client runs local settings, but successful connections also depend on server parameters, account status, and network conditions. Getting a client for free doesn’t include a subscription or remote service. Before installing, prepare connection details you’re authorized to use. When importing, don’t share subscription URLs, authentication fields, or screenshots showing your full configuration; that helps reduce the risk of credential exposure.

Updates and Configuration Maintenance

Client updates, core updates, subscription updates, and rule data updates are four different things. Updating a subscription refreshes the connection list; it won’t fix incompatible core fields. Updating rule data affects domain and address lists, not the client application itself. When something breaks, identify which layer changed before deciding what to update. Avoid changing several components at once, or it may be hard to trace the cause.

For routine maintenance, keep a backup of a working configuration and note the selected core, proxy mode, and custom rules. After an upgrade, test the basic connection first, then check local network access and whether direct and proxied destinations behave as expected. Logs can show whether a configuration loaded successfully, but remove subscription URLs and authentication details before sharing them. For complex rules that need ongoing maintenance, continue with the setup guide and document each rule’s purpose and conditions.

Compare the Three Clients →

Common Questions for First-Time Setup

Start with repeatable basic tests before adding rules or traffic capture. These questions can help identify what to check next.

Why do I need a subscription or connection profile after installing the client?

The client provides a local configuration and runtime interface; it doesn’t include your remote connection details. Prepare a subscription URL or share link you’re authorized to use, import it, select an active node, and start the connection. If the list is empty after importing, check the returned content and format before enabling more network features. See how to import subscriptions →

I selected a node. Why isn’t my browser using the proxy?

Selecting a node sets the connection profile, but traffic reaches the client only if the system proxy or the app’s own proxy settings are configured. First check that the core is running, then verify that the browser’s address and port match the client’s listening endpoint. If the browser has an extension that manages proxies, check whether it overrides system settings. See how to configure proxy modes →

Should I enable TUN right away?

First confirm that the node works with a standard proxy, then decide whether to enable TUN based on your apps’ needs. This separates server connection issues from local permission and interface routing issues. If the target app supports proxy settings, start with an explicit local proxy endpoint to make testing easier. To capture other traffic, follow the setup guide to check network interfaces and DNS. See the basic connection workflow →

When a connection is slow, should I switch nodes or change DNS first?

Identify which step is slow: domain resolution, connection setup, or ongoing data transfer. Compare direct and proxied access to the same destination, then test another working node with the same settings. This is more informative than changing DNS, transport, and routing all at once. Check DNS settings only if you see signs of a resolution problem; record any changes and test again. See how to verify a connection →

When reporting an issue, note the client name, selected core, affected app, and whether the problem occurred during import, startup, or access. A short error message with sensitive fields removed is more useful than simply saying “it doesn’t work.” To restore a working setup, undo changes in reverse order: revert the latest routing rule, restore the proxy entry point, then confirm system network connectivity. This helps avoid conflating separate issues.

Configuration and Troubleshooting Articles

Guides to core differences, connection speed, and startup logs. If you already have a basic setup, choose an article for your specific issue—no need to reinstall the client.