For desktop, start with v2rayN. On Android, choose v2rayNG or v2flyNG based on your node requirements. This guide distinguishes clients, cores, and protocols, compares subscription imports, system proxy settings, per-app proxying, and routing, and walks you through setup and connection checks on both platforms. If you already have a subscription but aren't sure which client to install, start with your device platform, then check the node's protocol, transport, and security settings.
Choose by platform first, then check the core family
The names are similar, but these aren't three versions of the same installer. v2rayN is a desktop client; v2rayNG and v2flyNG are Android clients. The client provides the node list, subscription management, and settings interface. The core establishes connections, parses configuration, and applies routing rules. Installing a client doesn't provide a working server—you still need a valid subscription or complete node settings.
v2rayN: the desktop pick
RecommendedSupports Windows, macOS, and Linux. Its desktop interface makes it easy to review nodes, organize subscription groups, and inspect logs. On Windows, choose the desktop or WPF version as needed. Available cores and features depend on the installer and current version.
Best for: everyday desktop use, managing multiple subscriptions, and customizing routing rules.
v2rayNG: Android and Xray configurations
Uses the Xray core family. If your configuration specifically requires Xray—especially for VLESS and REALITY settings—check support in the current version of v2rayNG and import the settings provided by your server.
Best for: a primary Android device, existing Xray nodes, and per-app proxying.
v2flyNG: Android and v2fly configurations
Uses the v2fly core family. A good fit if your existing configuration relies on v2fly features and formats. To check whether a node is compatible, verify its protocol, transport, security layer, and core version—not just whether its link imports.
Best for: Android devices with existing v2fly configurations that need to retain their core-specific behavior.
Choosing a client: use node requirements as your second filter
Rule out clients for unsupported platforms first, then check the service provider's recommended clients and minimum core requirements. If your configuration uses REALITY, check v2rayNG on Android first. Don't simply rename the protocol and try importing it into v2flyNG.
Protocols, transports, and interfaces: differences that matter
V2Ray and Xray are related core projects that evolve independently; v2fly is the community-maintained V2Ray project. VMess and VLESS are protocols, WebSocket is a transport, and TLS and REALITY are security settings. These options belong to different layers and aren't interchangeable. Even if two clients both list VMess, check the transport, TLS, path, and server requirements.
| Feature | v2rayN | v2rayNG | v2flyNG |
|---|---|---|---|
| Platforms | Windows、macOS、Linux | Android | Android |
| Core | Check the selected core and installer | Xray family | v2fly family |
| Interface highlights | Node list, groups, logs, and desktop proxy settings | Mobile configuration list, connection toggle, and per-app settings | Mobile configuration list, connection toggle, and core-specific settings |
| Subscriptions | Manage groups and choose an active node after updating | Manage subscription groups and check imported nodes after updating | Check the subscription format and core support before updating nodes |
| How traffic enters | System proxy or TUN, depending on version | Typically routes traffic through Android's VPN interface | Typically routes traffic through Android's VPN interface |
The desktop table layout makes it easier to compare multiple nodes at once, but more columns don't mean a faster connection. Android puts the connection toggle close at hand, but that doesn't mean every app uses the same route. Compatibility depends on whether the configuration matches; which requests use the proxy depends on the traffic entry point, per-app selections, and routing rules.
- For VMess: Check the address, port, user ID, encryption settings, transport, and TLS. Don't assume all three clients handle every optional parameter in exactly the same way.
- For VLESS: Also check the flow, transport, and security settings. The same protocol name doesn't guarantee that every combination will work.
- For REALITY: Check fields required by the server, such as serverName, public key, and shortId, and confirm that the client and core support them.
Importing subscriptions: updates don't guarantee full compatibility
A subscription link distributes configuration; it's not a client account or a network connection exclusive to a particular app. One subscription may provide multiple protocols or formats. Seeing the expected number of nodes after import only confirms that the client recognized some of the content—it doesn't replace a connection test.
- Create a group first. In v2rayN, open “Subscription Group” → “Subscription Group Settings” and add a name and subscription URL. Menu labels may vary slightly by version, so follow the current interface.
- Then update the subscription. Choose the update command from the “Subscription Group” menu and check the status message and number of nodes added. On Android, add the URL under “Subscription Group Settings” in the menu, then update the subscription.
- Inspect a node's settings. Compare the protocol, port, transport, and security settings with the provider's instructions. Pay particular attention to unsupported fields or fields left blank after import.
- Finally, test a real request. Select a node, connect, visit a reachable website, and check the logs. A latency test alone doesn't prove that all traffic is using the proxy.
If the desktop imports successfully but Android shows only some nodes, check the missing nodes' protocols and settings before reinstalling anything. If updates fail on both devices, check whether the link has expired, whether your network can reach the subscription URL, and whether the update request needs to go through an already working proxy.
System proxy, Android traffic capture, and routing rules
After choosing an active node in v2rayN, decide how apps will send traffic through the client. The system proxy usually works for apps that honor the system proxy settings. Apps that ignore them need separate proxy settings, or you can use TUN after considering the permissions and routing effects. TUN relies on a virtual network interface and related permissions; it isn't a universal speed boost.
These examples illustrate port roles; they aren't defaults for every version. If your local HTTP or mixed listener is set to 127.0.0.1:10808, enter that address as the browser's manual proxy. Even if the remote node port is 443, don't enter it as the browser's local proxy port. In v2rayN, check the local listener options under “Settings” → “Parameter Settings”; the exact sections vary by version.
- Android traffic capture: When you connect for the first time, Android will usually ask you to approve a VPN connection request. This VPN interface captures device traffic; it doesn't mean the node uses any particular protocol.
- Per-app proxy: Check whether the setting means “proxy selected apps only” or “bypass selected apps.” The same app list has opposite effects in these two modes. Reconnect after saving and test again.
- Routing: Once traffic reaches the core, rules use domains, IP addresses, and other criteria to choose a direct connection, proxy, or block. Rules are usually evaluated in order, so a broad rule near the top may override more specific rules below it.
- DNS: Choose a resolution method that matches your routing goals. Copying rules from another client won't necessarily reproduce its DNS behavior; check the configuration format and resolution policy on both sides.
The term “global” depends on where it appears: it may refer to which apps are captured or to the routing outbound policy. To compare two clients fairly, first configure similar traffic capture and routing rules.
Using the same setup on desktop and Android
A common setup is v2rayN on desktop and one of the Android clients chosen to match your core requirements. Connect each device to the server directly; there's no need to enable desktop LAN sharing first. You can use the same subscription on both, but local ports, per-app lists, and routing rules are device-specific and won't sync just because the subscription is shared.
Setup plan: share the subscription, configure traffic entry separately
Desktop: v2rayN
- Choose an installer for Windows, macOS, or Linux and your device architecture.
- Create a subscription group, update it, and select an active node.
- Test browser access with the system proxy first; consider TUN only if your apps need it.
- Keep a record of working settings. When editing routing, change one rule type at a time.
Android: v2rayNG or v2flyNG
- Choose a client based on whether your configuration requires Xray or v2fly.
- Add the same subscription, update it separately, and check the nodes.
- Approve the system connection request and check the per-app proxy mode.
- Test the connection on both Wi-Fi and mobile data.
The subscription content may be the same, but update timing, format filters, and local settings are independent. Test each device separately.
For a fair performance comparison, use the same server, protocol, and transport, test at roughly the same time, and disconnect the other client's active connection. Wi-Fi signal, power-saving settings, server load, and network routes all affect results. Don't attribute a single speed-test difference to the client name alone.
Four common questions after choosing a client
I already have v2rayNG on Android. Do I also need v2flyNG?
If your current subscription imports and connects successfully, there's usually no reason to install another client just because its name is similar. Consider switching only when your configuration depends on features or behavior from a different core. Disconnect the current client before testing another to avoid conflicts over Android's VPN connection.
The same node works on desktop but not on my phone. What should I check first?
First, make sure both clients have updated the subscription. Then compare the node details, including the protocol, transport, and TLS or REALITY settings. Check your phone's system time, connection permission, and per-app list. If Wi-Fi and mobile data behave differently, investigate the network environment instead of changing the server port.
v2rayN shows node latency, so why won't my browser load pages?
A latency result doesn't mean your browser is using the proxy. First check the system proxy status in v2rayN. If needed, select “Set system proxy automatically,” then check whether the browser has its own proxy settings. Next, inspect the local listener port, routing, and DNS logs one at a time.
Do I need to copy all my routing rules when switching clients?
Don't copy everything over at once. Restore the nodes from your subscription and test a basic connection first, then recreate rules in a format supported by the new client. Desktop executable paths and Android package names are different matching criteria, and per-app lists aren't directly interchangeable.
Final checks: test requests, not just the connection icon
After choosing a client, test one request that should use the proxy and another that should connect directly. Check the relevant logs or connection records. Once both requests take the expected route, add more complex rules. This makes it easier to tell node problems from local routing issues.