v2rayN, v2rayNG, and v2flyNG: How to Choose Among Them

The names of these three clients are similar, but their roles are different. v2rayN targets Windows, macOS, and Linux desktops; v2rayNG and v2flyNG target Android. Their interfaces and workflows are similar, while the key difference comes from their core families: v2rayNG uses the Xray core, whereas v2flyNG uses the v2fly core. When choosing, identify the device platform first, then check the node protocols. This is usually more effective than comparing interface buttons one by one.

Step 1: Eliminate Unsupported Clients by Platform

The platform is the strongest filter. If you need to manage subscriptions, switch the system proxy, or inspect live logs on a Windows, macOS, or Linux desktop, the choice narrows directly to v2rayN. It puts server lists, subscription groups, routing settings, and core logs in one desktop window, making it suitable for mouse-and-keyboard use and for maintaining dozens of node records at once.

On Android, choose between v2rayNG and v2flyNG. Both can import subscriptions and individual share links, and both use the system VPN interface to handle selected-app or global traffic. Do not treat them as the same app with different skins simply because both names contain “NG.” When a subscription includes Xray-specific transport parameters, the core difference directly determines whether the configuration can start.

The Core Family Determines Whether Protocol and Transport Parameters Work

The client interface edits and saves the configuration, but the underlying core actually establishes the connection. v2rayN can use the Xray family through its supported core options to process common configurations; v2rayNG is likewise centered on Xray. v2flyNG switches the execution layer to v2fly, making it a better fit when the configuration source, server, and existing rules are all built around v2fly.

VMess, VLESS, WebSocket, gRPC, TLS, and Reality are not all at the same layer. VMess and VLESS are proxy protocols; WebSocket and gRPC are transport methods; TLS and Reality concern connection security and handshake parameters. A single subscription node often combines parameters from several layers, so the client must recognize the full configuration. Do not judge compatibility only by labels such as “high speed” or “new protocol” in the node name.

Version numbers should also be considered alongside protocol support. The stable environments used for the checks in this article include v2rayN 7.12.x, v2rayNG 1.10.x, and v2flyNG 1.10.x. These versions serve only as reference baselines for the paths and feature entry points shown here; they do not mean the three projects have identical core capabilities. If an older version cannot parse new fields, update the client first and then re-import the subscription instead of manually deleting unfamiliar fields.

Subscription Management Differs Mainly Between Desktop Batch Operations and Mobile Workflows

v2rayN is better suited to batch management. A typical workflow is to open “Subscription groups” → “Subscription group settings,” create a group, and enter the subscription URL, then choose “Subscription groups” → “Update all subscriptions.” After the update, nodes appear grouped in the server list, where latency testing, filtering, and sorting can narrow the choices. If you maintain work, test, and backup subscriptions, groups help prevent accidental node switches.

v2rayNG and v2flyNG focus more on short touch-based workflows. Usually, open “Subscription group settings” from the top-right menu, add the URL, return to the main screen, and choose “Update subscription.” When there are many nodes, first confirm the currently selected subscription group. “The update succeeded, but the expected nodes are missing” often simply means another group was updated.

1. Save the subscription URL first: Check that it begins with https://, and do not include line breaks or trailing spaces when copying it.
2. Run an active update next: Adding a URL alone does not generate a node list automatically; run an update once after the first addition.
3. Choose an active node: On desktop, double-click a node or set it as the active server. On Android, tap a node until it shows as selected.
4. Start the proxy last: In v2rayN, also check the system proxy mode. On Android, tap the connection button and confirm the connection status.

The Practical Difference Between Routing Rules and Local Ports

v2rayN’s advantage is the larger desktop workspace for editing routes. The common entry point is “Settings” → “Parameters,” while the system proxy mode can be switched from the tray menu or the system proxy menu in the main interface. Rules are usually matched from top to bottom, and the first match takes effect. Therefore, direct LAN access, direct access to mainland China domains, proxy rules for specific domains, and the final fallback should be arranged in a clear order.

Android app-based splitting is more direct. v2rayNG and v2flyNG can decide which apps send traffic through the proxy, which is useful when only a browser or specific tool should use it. Domain and IP rules are still handled by the core, while app-based splitting occurs before system traffic enters the core. They are not interchangeable: once an app is excluded, its domain rules will no longer pass through proxy routing.

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      }
    ]
  }
}

The structure above represents two common goals: connect private addresses directly, and also connect requests matching a specified domain set directly. Before importing a complete JSON configuration, confirm that the client is in custom configuration mode. When ordinary subscription nodes are configured automatically by the interface, do not paste the entire JSON into the node address field. The outboundTag in the rules must also match an existing outbound tag; otherwise, the logs will report that the corresponding outbound cannot be found.

• Check the v2rayN port: Go to “Settings” → “Parameters” → “Basic settings” and verify the local listening port. A common configuration uses 10808, but after changes, use the value shown in the interface.
• Check the v2rayNG port: Go to “Settings” → “Local port” and make sure the port is not occupied by another local service.
• Check the v2flyNG port: Likewise, verify the local port and splitting options from the settings page. When migrating a configuration, do not assume the old client’s port will be inherited automatically.
• Read the logs: When address already in use appears, change the local port first. For handshake timeouts, focus on the node address, network, and transport parameters.

When Is It Worth Switching from v2rayNG to v2flyNG?

For most Android users, switching clients should not be based solely on similar-looking interfaces. Migration has a cost: subscription groups, local rules, app-splitting lists, and custom DNS settings all need to be checked again. Switching is genuinely worthwhile when the configuration maintainer explicitly requires the v2fly core, or when an existing VMess configuration has a long-established behavior baseline in a v2fly environment.

Before switching, keep the subscription URL and key settings from the original client, and do not start both connections at once. Android can assign system traffic to only one connection of this type at a time. Another client showing a selected node does not mean it is transmitting data. After migration, test one node first, then gradually restore app splitting and custom routing.

Final Selection Checklist for the Three Clients

For a quick, actionable answer, consider the device platform, node protocol, and routing complexity in that order. The platform eliminates unsuitable options first, the protocol determines the core, and interface preferences come last. This order avoids repeatedly searching for features that do not exist on the wrong platform.

1. Windows, macOS, and Linux: Choose v2rayN. It is suited to desktop subscription groups, batch node management, system proxy switching, and detailed log troubleshooting.
2. Android with VLESS, Reality, or newer Xray parameters: Choose v2rayNG, and check that the node details are complete after the first import.
3. Android with configurations maintained on the v2fly core: Choose v2flyNG, paying particular attention to VMess, transport, TLS, and routing fields.
4. Need app-based splitting: Choose between v2rayNG and v2flyNG according to the core requirement, then configure the app list in Settings.
5. Need many domain, IP, and geosite rules: Prefer v2rayN on desktop for editing, sorting, and reviewing match logs.

After choosing a client, keep the first connection test minimal: import one subscription, select one node, keep the default routing, open the logs, and visit one target site. Once the basic connection works, add custom DNS, app-based splitting, and complex routing. Change one variable at a time so the logs can identify whether the problem comes from the node, core, port, or rules.