Choose an open-source client for your platform, start by importing a subscription, then configure routing and connectivity.
The client manages configuration; the core handles connections. Protocol, transport, and security options must be compatible with one another.
A subscription retrieves a set of configurations, while a share link usually describes a single server. Successful import does not mean a connection has been established: select a server, confirm the routing mode, and direct the apps that need a proxy to the appropriate traffic entry point.
Think of client setup as four steps: identify your server sources, then decide how traffic reaches the core and which route it takes out.
The v2rayN desktop interface brings groups, server lists, and routing settings together; Android clients use the system VPN service to handle traffic. Interface labels may change between versions, so check what each field means rather than relying on button positions. The diagram below illustrates configuration relationships, not live connection status.
Subscription import makes it easier to manage multiple servers at once. In v2rayN, open Subscription Group Settings, enter a remark and optional URL, save the group, then update it. For a single share link, use “Import share link from clipboard.” Groups help distinguish sources and can have separate update and filter settings. After updating, make sure the servers appear in the expected group, then select an active server. Don’t include URLs containing access credentials in public screenshots. Unlike adding servers one by one, subscriptions can sync with their source, but local changes may be overwritten during the next update.
Routing rules determine which route a request uses; they do not automatically send app traffic to the client. In v2rayN’s routing settings, choose a rule set and check the order of the direct, proxy, and block conditions. geosite classifies domains; geoip classifies IP addresses. Both rely on the corresponding data files. Unlike sending all traffic through one route, rule-based routing preserves LAN access and lets you direct different traffic separately. If a site behaves unexpectedly, first check which rule matched and the DNS result, then adjust that rule. Changing the server, rules, and resolver all at once makes the cause harder to identify.
Switching cores matches a server’s protocol requirements; it does not mean you can freely swap the implementation for any server. In v2rayN settings, check which core is selected and whether it supports the protocol in use. After changing cores, restart the connection and review the startup log. Xray and V2Fly share technical roots, but their extensions and supported fields are not identical; settings such as REALITY must match the implementation. On Android, v2rayNG and v2flyNG follow different core lineages. Checking the core and server settings is more useful than relying on the client name when a configuration imports but won’t start.
The system proxy is a good first test with browsers and other apps that honor system settings, though some apps connect directly. TUN captures traffic through a virtual network interface, but coverage depends on system routes, permissions, and exclusions—it does not mean every connection uses the proxy. In v2rayN, first use the system proxy to confirm the server works, then enable TUN if your apps need it. Required components vary by platform and version. Using one traffic entry point at a time is easier to troubleshoot than enabling several traffic-capture tools at once. Restore the system proxy settings before closing the client to avoid connection problems afterward.
Use v2rayN on desktop. On Android, choose a core compatible with your server, then select the right device architecture.
Before downloading, check your operating system, processor architecture, and installation permissions. The package architecture must match the device; it is not determined by the protocol in your subscription. You can reuse compatible server settings on another device, but check system proxy, VPN permissions, routing, and DNS separately.
v2rayN offers Desktop and classic WPF versions. Desktop uses a cross-platform interface, while WPF retains the familiar Windows window-based experience. Check system requirements first, then choose the interface you prefer; there’s no need to install both just to import the same subscription.
If startup fails, check the runtime requirements and where you extracted the files. TUN requires different permissions from the standard system proxy, so start by testing with the system proxy.
v2rayN provides separate downloads for Apple Silicon and Intel. Check your chip or processor in About This Mac, then choose the matching package. Don’t infer the architecture from the interface language, device appearance, or purchase year.
When opening the app for the first time, follow the system’s security prompts to grant access. After connecting, test both browser access and access from the app you intend to use to tell whether the system proxy is working and the server is reachable.
Start with v2rayNG, which uses the Xray core; consider v2flyNG if you need a V2Fly configuration. Both offer arm64 and universal builds. Most arm64 devices should use the arm64 package; if you’re unsure, check system information or use the compatible universal build.
A system VPN permission is required before connecting. If another VPN service is already running, decide which app should handle traffic. For background disconnects, check battery optimization and background activity restrictions.
v2rayN offers deb and rpm packages for x64 and arm64. Debian-based distributions generally use deb; distributions built around RPM packages use rpm. Package format and processor architecture are separate requirements, and both must match.
After installation, check that your graphical session and dependencies are in place. Whether desktop apps honor the system proxy depends on their implementation. TUN also involves permissions and routing, so an open window alone doesn’t confirm that traffic is being captured.
Keep the defaults for your first connection, then adjust routing rules and DNS one at a time. This makes it easier to undo changes.
Have a valid subscription URL ready. In v2rayN’s Subscription Group Settings, enter a remark and URL, save, then update the group. For a single protocol link, import it from the clipboard instead; don’t treat it as a subscription URL and keep trying to update it.
On Android, use the subscription or clipboard option in v2rayNG’s Add menu. After importing, check that the server address, port, and protocol fields are complete. If the list is empty, check the update log and filter settings first.
Select the server you want to use, then check its transport and security options against the server provider’s instructions. On desktop, start by setting the system proxy. On Android, start the connection and grant system VPN permission, then choose the routing mode that fits your needs.
Server selection, routing mode, and traffic entry are three separate settings. Selecting a server without routing app traffic through the proxy may leave apps using their usual network. Enabling a traffic entry point won’t fix incorrect server settings.
Start by testing the app you want to use, then check the client log to confirm that its requests reach the core. Also test LAN resources and sites expected to connect directly to make sure routing hasn’t disrupted them. Latency tests can help narrow down server choices, but they can’t replace testing your actual apps.
If the connection fails, troubleshoot in this order: subscription update, core startup, app traffic entry, routing, then DNS resolution. Note each setting you change and retest after reverting it; switching several options at once can make the state difficult to diagnose.
Distinguish protocols, cores, and graphical clients to determine which app can handle a given configuration.
Project V is an open-source technology ecosystem for proxy communication, routing, and transport. V2Ray is one of its widely used projects. V2Fly continues community development of a related core, while Xray has grown from a shared codebase into a separate lineage. Neither is simply an older or newer replacement for the other: they share many configuration concepts, but supported fields, extensions, and default behavior can differ as each project evolves.
A graphical client turns subscriptions and settings into a configuration the core can execute. The core establishes protocol connections, applies routing, and handles outbound traffic. That’s why two servers labeled VLESS may still require different implementations depending on their transport, security settings, or extension fields. For settings such as REALITY, first confirm that the selected core supports them, then enter the public key, server name, and other values provided by the server source.
v2rayN, v2rayNG, and v2flyNG are open-source clients, but their interface and core code may use different licenses. The v2rayN and v2rayNG client projects use GPL-3.0; the V2Fly and Xray core projects use MPL-2.0. When using, modifying, or redistributing software, refer to the license included with the relevant release package. Don’t assume one license applies to every dependency.
Client updates change the interface and configuration management; core updates affect protocol capabilities; subscription updates refresh server settings. These are three different things. A successful subscription update won’t add missing core features, and upgrading the app won’t replace expired server credentials. Back up groups and custom rules before updating, then retest the connection and routing using the same steps as before. This makes compatibility changes easier to spot than changing everything at once.
Both require identity and transport settings that match the server; changing the protocol dropdown alone won’t make one interchangeable with the other. VLESS does not provide encryption on its own and is usually combined with a security mechanism such as TLS or REALITY. VMess also requires attention to system time and server requirements.
Trojan typically uses TLS and password authentication; Shadowsocks requires a matching cipher and password. Similar names or the same port don’t make protocols interchangeable. After importing, check the security settings, transport, and server instructions.
REALITY is a security mechanism, not a standalone proxy protocol on the same level as VLESS. Check the protocol, transport, and security layer together. Performance and battery use on mobile also depend on the network path, reconnection frequency, and traffic patterns—not just the protocol name.
Explore specific client questions and learn where connection tests, protocol compatibility, and network deployment differ.
An overview of ways to run the core directly on a primary or secondary router, including memory and storage requirements, transparent proxying, DNS-based routing, and trade-offs versus desktop clients.
Learn how three client tests work: handshake-only checks, full proxy connections, and throughput tests. Understand the results without choosing a server based on a single number.
Compare the two cores’ support for VLESS, XTLS, and REALITY, and learn where configuration files are compatible. Find out which servers are best suited to v2rayNG and v2flyNG.
First check that you entered a subscription URL—not a management page or a single share link. Then check the update log, group filters, and filter fields. An empty response, expired subscription, or local filter can all leave the list empty. Don’t delete all your settings; keep the group and check each item in the subscription import guide.
The system proxy only affects apps that use that setting. Some apps have their own proxy configuration; others need a different traffic entry point. Check the target app’s settings first, then consider TUN. TUN and routing rules are separate steps: capturing traffic doesn’t mean all traffic goes through the proxy. See routing and mode settings for details.
A successful TCP handshake only confirms that the address and port accept a connection; it doesn’t confirm authentication, transport, or access to the destination. Check the core log to see where the connection fails, then check DNS and matched routing rules. If only one domain fails, there’s no need to replace the whole server list right away. See the DNS setup guide to investigate how resolution and routing interact.