Choose a platform-specific installer, then follow the English setup guide to make your first connection—from the open-source client to subscription and routing settings.
Local SOCKS Listening Port10808Local connection endpoint for apps
Allow LAN ConnectionsOff · Local access only
Enable Traffic SniffingOn · Helps match domain names
Core Settings
Domain StrategyIPIfNonMatchTry resolving when no rule matches
Log LevelwarningLog warnings and errors
Launch at StartupOff · Start manually
CancelOK
Routing Rulesrouting.rules
domain: geosite:cn outboundTag: direct
ip: geoip:private outboundTag: direct
Dual CoreXrayV2Fly
VLESSVMessTrojanShadowsocksREALITY
Common v2rayN Settings
Understand protocols, routing, and system proxy settings before adjusting individual options.
Protocol Types and Transport Settings
One client can manage configurations for VMess, VLESS, Trojan, Shadowsocks, and other protocols, but a protocol name alone does not define a complete connection setup. After importing a configuration, check the transport, TLS, server name, and other fields. REALITY is a transport security feature, not a standalone proxy protocol. Managing everything in one client makes settings easier to compare than installing a separate tool for each protocol. Whether a configuration runs still depends on the selected core and its supported features. For your first setup, keep the imported values and only change them to match the server instructions.
Routing determines which outbound handles each request; it does not change the server. Rules are usually evaluated in order, so put specific domain and LAN rules before broad ones. A matching rule uses outboundTag to select an existing outbound. Routing by domain or IP is more useful than sending every request through the same outbound when you need access to both LAN devices and remote services. Keep in mind that domain rules depend on domain information being available, while IP rules may involve DNS resolution. Change one rule at a time and retest the same destination to identify which condition is taking effect.
A subscription URL fetches a collection of configurations; it serves a different purpose from a single share link. When adding one, choose a clear group name, update that group, and check that the protocol and transport settings were recognized correctly. Subscriptions make it easier to sync changes than managing scattered links, but an update may replace entries provided by the source, so keep manually edited configurations separately. A failed subscription update does not necessarily mean an existing connection is broken: check URL access, content format, and client parsing separately. Subscription URLs may contain access credentials, so do not include them in screenshots or public support posts.
Update Current SubscriptionUpdates selected group only
Core Selection and Configuration Compatibility
The GUI client organizes configurations; the core establishes the actual connection. Depending on the configuration and client support, v2rayN can use Xray or V2Fly, but switching cores is not a general-purpose speed boost. The two share some history and configuration concepts, but their feature sets have since diverged. Specific security options, transport choices, and fields may not be interchangeable. Rather than choosing by core name alone, check the required protocol features first. Back up your configuration before switching, then review the startup log. If you see unknown fields or an unsupported transport, revisit compatibility instead of repeatedly changing ports.
Core Selection ExampleChoose for your configuration
XrayCheck required features
V2FlyCheck field compatibility
Log Levelwarning
System Proxy and App Connections
System proxy settings direct apps that follow the system rules to a local listening port. This is separate from the client's internal routing policy. Make sure the core starts successfully before enabling the system proxy, so the browser has a working endpoint. This approach is easier to manage than setting up each app individually, but some programs ignore system proxy settings and need their own configuration. TUN mode uses a virtual network interface and permissions, so it should not be confused with the system proxy. Restore the system proxy before closing the client, and update apps if you change the listening port to avoid mismatched connection settings.
v2rayN is available as a desktop edition and a classic WPF edition. The desktop edition uses a newer cross-platform interface, while the WPF edition retains the familiar classic desktop workflow. For your first install, choose a package based on your operating system architecture and the download page instructions. There is no need to run both editions just because their interfaces differ; running two clients on the same listening ports can make troubleshooting harder.
After installation, open settings and confirm the local listening endpoint before importing your configuration. When migrating an existing setup, keep the old data directory and note any custom subscription groups, routing rules, and DNS settings. Do not overwrite the old directory with a new one. Verify that the client starts and connects before removing the old installation or changing startup settings.
v2rayN installers for macOS are available for Apple Silicon and Intel processors. Check the chip or processor details in About This Mac, then choose the matching download. Packages with the same client name may not work on every device. Selecting the right architecture before addressing system permission prompts helps avoid mistaking a startup issue for a configuration problem.
The subscription, routing, and log-checking steps in the desktop guides still apply, but menus and system proxy settings may be in different places. Before connecting for the first time, check whether the system network settings point to the client's local port. If the browser cannot connect after you quit the client, first check for a proxy setting that still points to a stopped service.
v2rayNG uses the Xray core, while v2flyNG is an alternative based on the V2Fly core. Choose an app based on the core features your existing configuration requires, then select an arm64 or universal package. Most recent mainstream phones are suited to arm64. If you are unsure of your device's architecture, follow the download page guidance rather than judging by package size alone.
On first launch, connecting requires system VPN permission, which is separate from access to the subscription URL. If only some apps have problems after connecting, check per-app proxy settings and system background restrictions. Battery use also depends on signal strength, app request frequency, and connection retries; the protocol name alone is not enough to predict it. Use the system battery statistics to narrow down the cause.
The v2rayN desktop download page offers deb and rpm packages for different processor architectures. First check your distribution's package format, then confirm whether your device uses x64 or arm64. A GUI client is suited to managing subscriptions and settings in a desktop session. Check package format, desktop environment dependencies, and network permissions separately rather than treating them all as core issues.
System proxy support varies across desktop environments. If a browser connects but another app does not, check whether that app follows the desktop proxy settings; if necessary, set its local endpoint directly. When changing the listening port, also check environment variables and existing app settings so they do not keep referencing the old port.
Know the difference between the client, core, and connection configuration to troubleshoot the right layer.
From Project V to GUI Clients
Project V is an open-source ecosystem built around proxy communication tools, with V2Ray as one of its key projects. “Installing V2Ray” can mean installing a GUI client or deploying the core that handles connections; these are not the same thing. The GUI saves server settings, manages subscriptions, and generates runtime configurations. The core reads those configurations and handles inbound connections, routing, and outbound connections.
Opening the client window only shows that the GUI is running. It does not prove that the core started successfully or that an app is using the proxy. Check the full path: configuration parsing, local listening, then the app's connection settings. Separating these steps makes it easier to find the cause than repeatedly reinstalling the client, and reduces the risk of affecting existing subscriptions and custom rules.
How V2Fly and Xray Are Related
The V2Fly community continued V2Ray's development, while Xray evolved from related code and developed its own feature set. The two share some configuration concepts and protocol history, but today they are separate cores whose capabilities must be checked individually. A guide written for one core does not mean every security option, transport name, or configuration field can be transferred directly to the other.
When choosing a core, start with the server requirements, then check whether the client can generate the required settings. For specific features such as REALITY, confirm that both the core and the client interface support them. Avoid reducing core differences to a fixed speed ranking: real-world performance also depends on server load, network path, transport combination, and device resources.
What Three Open-Source Clients Do
v2rayN is an open-source desktop GUI client for managing configurations, subscriptions, routing, and system proxy settings in one place. v2rayNG is an open-source Android client that uses the Xray core and routes app traffic through the system VPN interface. v2flyNG is also for Android, but is based on the V2Fly core and suits configurations that specifically depend on its behavior.
Platform and core compatibility usually matter more than interface preference when choosing a client. A compatible configuration from the same source can be used on desktop and mobile, but local listening, app connectivity, and background behavior differ. A phone's VPN permission and a desktop's system proxy are not equivalent switches. When moving a configuration, recheck which apps are covered rather than just confirming that the server entry appears.
Open-Source Licenses and Usage
Open source means a project publishes its source code under a license that sets the terms for use, modification, and redistribution. It does not mean every related project uses the same license. The V2Fly and Xray cores typically use MPL 2.0, while each client and bundled component has its own license terms. Personal use and redistribution of modified software have different requirements; the label “open source” is no substitute for understanding the specific terms.
The client itself does not include remote connection resources ready for use. Subscription sources, server configurations, and the terms for remote services must be checked separately. V2Ray Toolbox provides download links and configuration guidance, not subscriptions or accounts. When discussing an issue publicly, redact access credentials, user identifiers, and server authentication fields from subscription URLs; remove sensitive information from logs before sharing them as well.
Four Different Things to Update
Client, core, subscription, and rule data updates each affect different things. A client update may change the interface or how configurations are generated. A core update affects connection capabilities. A subscription update syncs server entries from its source. GeoIP and GeoSite data updates affect routing based on IP and domain categories. Updating a subscription alone cannot add a feature missing from the core.
Before updating, save your current configuration and custom rules. Afterward, confirm that the core starts, then check routing for commonly used destinations. If a site suddenly uses a different outbound, consider changes to rule data as well as rule order and DNS policy. Avoid changing the core, subscription, and routing template all at once; otherwise, it is difficult to tell which change affected the result.
Compare Protocols by Connection Requirements
VMess, VLESS, Trojan, and Shadowsocks differ in authentication, configuration structure, and common deployment setups. VLESS does not provide the same encryption mechanism as VMess and is usually paired with an appropriate transport security option. Trojan is commonly used with TLS, while Shadowsocks requires the client and server to use matching encryption methods. Comparing protocol names alone can hide the fields that determine whether a connection works.
On mobile devices, background activity, connection keepalives, app request frequency, and signal conditions can all affect battery life. On desktop, checking whether an app reaches the local listening port is often more useful than switching protocols. The protocol guides explain trade-offs in these real-world contexts rather than presenting one protocol as the default for every device and server.
Common Setup Questions
Why do I still need to select a configuration after importing a subscription?
Updating a subscription retrieves and saves a collection of configurations; it does not necessarily activate one automatically. Confirm that the subscription group contains recognized entries, select the configuration you want to use, and check that the core starts successfully. Then check the system proxy or VPN connection. An entry appearing in the list does not mean app traffic is reaching the client.
No. This is a common example of a local listening port; use the port configured in your client. If the port is already in use, identify the conflicting process or change the client to another available port. After changing it, update the browser, apps, and relevant system proxy settings too, or they will keep sending requests to the old port.
Why can my browser connect when other apps still fail?
First determine whether the app is bypassing the proxy or reaching the proxy but failing to connect to its destination. Some programs ignore system proxy settings and need to be configured separately; others may use their own DNS, UDP, or network stack. Check the app's connection settings and logs before changing routing or the connection method. Do not assume every failure is caused by the subscription.
Learn what geoip.dat and geosite.dat do, how to update rule files in the client, and common ways to combine geosite: and geoip: prefix rules. Understand data categories and rule order before checking whether direct outbound routing behaves as expected.
Use built-in system commands to find processes using ports such as 10808, then change the listening port in the client and update browser and system proxy settings. Distinguish a port conflict from a remote connection failure to avoid changing settings at the wrong layer.
Learn how the built-in DNS module orders queries, how to specify DNS servers by domain, and how FakeDNS works with domain strategies. First distinguish the route used for DNS queries from the route used for application traffic, then check whether the rules are taking effect.