V2Ray Multi-Device Configuration Sync: Subscription Links, Export/Import, and QR Code Migration

When a computer and an Android device connect to the same group of servers, “syncing configurations” usually means three different things: syncing nodes, syncing routing rules, and syncing client settings. They should not be treated as the same task. Subscription links are good for keeping a node list consistent, but they do not automatically copy v2rayN’s system proxy mode. QR codes work well for temporarily moving a single node, but they do not follow subscription updates. Export and import preserve more local data, although the file structure may be limited by the client and core versions.

Identify the Configuration Layers to Sync First

A node entry shown in a V2Ray client contains at least the protocol, server address, port, user ID, transport, security layer, and server name. VMess and VLESS nodes may also combine TCP, WebSocket, gRPC, TLS, or Reality. If any critical field is missing during migration, the client may complete the import but still fail to establish a working connection.

Routing is a separate layer. In v2rayN, LAN bypass, domain-based routing, and custom rules are usually generated by the client as a runtime configuration and then passed to Xray or the v2ray core. v2rayNG stores predefined rules, per-app proxy settings, and local DNS options on Android. Even when both devices use the same subscription, their node names and addresses may match while their routing behavior differs.

Method 1: Use One Subscription to Keep the Node List Consistent

The most reliable multi-device setup is to have the desktop and Android clients read the same subscription URL. The subscription server returns a collection of nodes, and each client generates its own local entries. When updates are needed, select “Update Subscription” separately on both devices instead of copying v2rayN’s database files directly to Android.

The steps below use v2rayN 7.12.5 as an example. Button locations may change between minor releases, but the target remains the “Subscription Groups” section. Copy the full URL before adding it to prevent chat apps or line breaks from truncating query parameters.

1. Create a Group

   Open v2rayN and go to “Subscription Groups” → “Subscription Group Settings” → “Add”. Enter an easy-to-recognize alias.

2. Paste the URL

   Enter the complete subscription URL in the URL field, keeping its path, question mark, and parameters intact. Confirm, then close the settings window.

3. Update Nodes

   Go to “Subscription Groups” → “Update All Subscriptions (Without Proxy)”. If the current network cannot access the subscription source directly, use the option to update through a proxy.

4. Select the Core

   Open “Settings” → “Parameter Settings” → “Core Type”. Choose Xray or the v2ray core according to the node protocols, then restart the relevant services.

5. Import on Android

   Open the side menu from the v2rayNG home screen, go to “Subscription Settings”, and add the same URL. Return and select “Update Subscription”.

Whether old nodes are removed after a subscription update depends on the client version, group settings, and subscription result. Before migrating, do not compare only the total node count. Also spot-check the server address, port, protocol, security layer, and transport. Matching node names do not prove that the underlying parameters match.

Method 2: Use Export and Import for Device Replacement and Local Backups

Without a subscription link, use the client’s share links, bulk export, or backup features. Distinguish between a “node sharing configuration” and a “runtime JSON”. The former usually starts with vmess:// or vless:// and describes one server entry. The latter contains complete sections such as inbounds, outbounds, routing, and dns for core operation, and may not be restorable as editable nodes in another graphical client.

To migrate self-managed nodes in v2rayN, select the target entries in the server list, then use the server menu to copy their share links. Keep multiple links as “one per line”, then use “Import in Bulk from Clipboard” in the target client. Do not delete the old configuration immediately after importing. First verify connectivity and compare the fields.

vless://user [email protected]:443?type=grpc&security=tls&sni=server.example#office-grpc
vmess://Encoded single-node share content

• Check that the address is still a domain name rather than an old IP accidentally substituted in its place.
• Check that the port remains 443, 8443, or the value actually used by the node.
• Check that the WebSocket path, gRPC serviceName, and Host fields are complete.
• Check the TLS server name and fingerprint parameters; do not migrate only the basic connection fields.
• Check that Chinese characters in the remarks display correctly. Garbled text usually indicates a problem during text encoding or decoding.

Method 3: Use QR Codes to Quickly Move a Small Number of Nodes

A QR code is essentially a graphical encoding of sharing text. It is useful for sending a single node from a computer to an Android device without manually entering a long user ID and query string. A QR code does not create an ongoing sync relationship: if the computer-side port, path, or security settings change, the existing Android entry will not update automatically. Scan or import it again.

1. Select a Node

   Select the target entry in the v2rayN server list, then confirm its protocol, address, port, and current availability.

2. Display the QR Code

   Open the server menu and select the option to display the sharing QR code. Leave only the QR code for the current node on screen.

3. Scan and Import

   On the v2rayNG or v2flyNG home screen, tap “+” in the upper-right corner, select “Scan QR Code”, and point the camera at the computer screen.

4. Verify the Fields

   Open the new configuration and check the alias, address, port, transport, TLS, SNI, and path fields.

5. Establish the Connection

   Select the new entry and start the connection. Test a regular webpage first, then check the client log for handshake and DNS results.

A failed scan does not necessarily mean the node is faulty. Excessive screen scaling, a QR code that is too small, monitor glare, or overly long sharing text can all reduce recognition accuracy. In testing, keeping v2rayN at 100% system scaling, using a QR code about 320 pixels wide, and holding the Android device roughly 20 cm from the screen usually produced recognition within 1 to 3 seconds.

If the QR code contains VLESS and Reality parameters, pay particular attention to publicKey, shortId, serverName, and flow. Older clients may recognize the link but ignore newer query parameters. In that case, upgrade to the client version available on the current download page and scan again instead of repeatedly changing the transport settings on the imported entry.

Once Nodes Match, Align Routing and DNS Separately

When nodes connect on multiple devices but the browsing results differ, the problem is usually not the subscription. Routing and DNS are out of sync. The desktop may bypass the LAN and commonly direct-connected domains while Android uses a global proxy; the desktop DNS may go through a proxy outbound while Android still uses system resolution. As a result, the same domain can resolve to different addresses and use different outbounds on the two devices.

A common v2rayN local listening combination is SOCKS 127.0.0.1:10808 and HTTP 127.0.0.1:10809. Use the local port values under “Settings” → “Parameter Settings” as the source of truth. These ports serve applications on the local machine and do not need to be copied to Android. If another local program is hard-coded to use 10808, confirm after replacing the device that the port is not occupied before configuring the application proxy.

• Round one: Select the same node on both devices and temporarily use similar global proxy policies to verify the node itself.
• Round two: Enable the target routing mode separately and test direct-connection domains, proxied domains, and LAN addresses.
• Round three: Check the DNS or core logs to confirm that queries are sent through the expected outbound.
• Round four: Record rule differences between the devices instead of mistaking per-app proxy settings for a missing subscription.

Checklist for Updates, Conflicts, and Failures

Once a sync setup is used day to day, the most common issues are mismatched update times, duplicate node names, and leftover old parameters. If the desktop just updated its subscription while Android still has yesterday’s list, the results will naturally differ. Repeatedly importing the same share links can also create multiple entries with identical names but different creation times.

Use stable names for subscription groups, such as “Primary Subscription” and “Backup Subscription”, rather than specific node names. The subscription content determines node changes; the group name identifies the source. Before each bulk migration, record the node count and update time, then compare them afterward to quickly spot an empty subscription, truncation, or duplicate import.

CHECK / 01

The list is empty after updating

First confirm in a browser that the subscription URL still returns content, then check whether the update must use the current proxy. Do not delete the existing group first.

CHECK / 02

Duplicate nodes with the same name

Check the node’s group and import time. Subscription nodes and manually imported nodes may coexist; keep the copy with the clearly identified source.

CHECK / 03

Works on the computer but fails on Android

Check the Android core, SNI, Reality parameters, DNS, and current network time instead of comparing only the node name.

CHECK / 04

Rules did not migrate with the node

This is a normal limitation of node-sharing formats. Export the rule source separately, or recreate routing on both devices using the same set of domains.

v2rayNG uses the Xray core and is suitable as an Android entry point for configurations such as VLESS and Reality. v2flyNG uses the v2fly core and is better suited to configurations that require v2fly-specific behavior. Both can read common share links and subscriptions, but their core support and field interpretation are not identical. Choose the client according to the node protocol before migrating; a successful import does not guarantee core support.

For long-term maintenance, use a three-layer sync strategy: the subscription link maintains nodes, each client maintains its local proxy mode, and a separate rule list maintains domain routing. When changing devices, restore the subscription first, then the rules, and finally adjust the system proxy and app scope. If one layer changes, the other devices will not need every node to be scanned and entered again.