V2Ray Multi-Device Configuration Sync: Comparing Subscription Links, QR Codes, and Exported Configs

Separate node syncing from client settings

“Multi-device configuration sync” usually covers two entirely different types of data. The first is server node data: address, port, user ID, VMess or VLESS parameters, TLS, REALITY, transport settings, and camouflage fields. The second is local client settings: system proxy, routing mode, DNS, log level, LAN listening, per-app proxying, and the automatic update interval. Subscription links mainly handle the first category; exported configs may cover part of the second.

Do not assume that “the node list is identical” means “the clients behave identically.” For example, desktop v2rayN commonly uses local SOCKS port 10808, while HTTP may use 10809. Android v2rayNG usually takes over traffic through the system VPN interface. Even when it offers a local SOCKS port, its scope is still different from the Windows system proxy. Copying desktop port numbers to Android does not reproduce the same traffic-routing behavior.

Option 1: Keep node lists aligned with one subscription

A subscription link is the lowest-maintenance option for multiple devices. The server gathers multiple share configs under one address, and each client periodically requests and parses the nodes. Desktop v2rayN and Android v2rayNG can save the same address independently, but each device still updates separately, selects its active node separately, and stores its own routing and system proxy state.

In v2rayN, go to “Subscription Group” → “Subscription Group Settings” to add a subscription. Enter an alias and the complete URL, save it, then select “Update all subscriptions (without proxy).” If the current network cannot reach the subscription source directly, connect to a working node first and then update through the proxy. Menu wording may vary slightly by version, but the sequence is the same: create a group, then update the nodes manually.

In v2rayNG, open the top-left menu, go to “Subscription Group Settings,” and tap the add button in the top right. Enter a note and the subscription URL. After saving, return to the main screen and choose “Update subscription” from the top-right menu. The node count should change after the update. If it remains at 0, first check whether the URL was truncated by a line break, whether the subscription group is enabled, and whether the current network can reach the address.

Automatic updates should not run too frequently. When nodes change infrequently, update once every 24 hours; update manually when you need server-side changes immediately. For example, with 60 nodes and an approximately 80 KB response per subscription update, two devices updating once a day generate less than 5 MB of subscription data per month. The real concerns are whether old nodes remain after a failed update and whether the client accidentally removes manually added standalone nodes.

Option 2: Use QR codes to migrate a small number of nodes

A QR code is useful for sending the current node to a nearby device, not for long-term synchronization. v2rayN can generate a QR code for a selected server, and v2rayNG can import it by scanning. The code usually contains one share link with the protocol, server address, port, and transport parameters; it does not include an automatic subscription update mechanism.

In practice, select the target node in the v2rayN server list and use its QR display function. On Android, open v2rayNG, tap the add entry in the top right, and choose “Scan QR code.” Do not connect immediately after scanning. Expand the configuration first and check the address, port, user ID, transport, TLS security type, SNI, or serverName field one by one.

1. Keep the number under control: Migrate one node at a time and immediately change its note after importing, such as “Office route - QR - 0627,” to avoid confusing it with a node of the same name from the subscription.
2. Verify the protocol: VMess and VLESS use different identity fields and encryption semantics. Matching server addresses alone is not enough.
3. Verify the transport: For WebSocket, check the path and Host. For gRPC, check serviceName. For REALITY, also check serverName, publicKey, and shortId.
4. Test before finishing: Run a connection test, then open a webpage to verify DNS and routing. Do not rely only on the latency shown by the client.

QR codes have limited capacity, so complex JSON configs, long certificate contents, or complete configurations with many rules are not suitable for direct encoding. Even when scanning succeeds, the client may recognize only standard fields in the node link and ignore the source client’s routing groups, split DNS, and local listening settings. A QR code is therefore best treated as a one-time node copying tool.

Option 3: Preserve complex settings with an exported config file

Exported configs are useful for backing up the same type of client or preserving manually written routing and DNS rules. They are not a universal sync format. v2rayN application settings, subscription group data, and core runtime config may be stored in separate files; the node list exported by v2rayNG is not the same as a package that can directly overwrite desktop settings. Before importing across clients, determine whether the file is a “client database,” a “collection of share links,” or a “core JSON configuration.”

Core JSON usually contains sections such as inbounds, outbounds, routing, and dns. It precisely describes how the Xray or v2fly core handles traffic, but the client interface may not be able to turn every manually written field back into an editable form. Importing a desktop-generated core config directly into Android may also bring in listening addresses and ports intended only for desktop use.

{
  "inbounds": [
    {
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "udp": true
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

The listening address 127.0.0.1 above accepts connections only from the local machine, making it suitable for a desktop local proxy. Providing a proxy to LAN devices requires separate handling of the listening policy and firewall rules. When Android takes over traffic through the system VPN, this inbound configuration cannot simply be treated as an equivalent setting. Keep the original backup when migrating files, and never overwrite a configuration that still works.

How to combine v2rayN, v2rayNG, and v2flyNG

Use v2rayN on desktop to manage subscriptions, the system proxy, and routing. On Android, use v2rayNG when you need the Xray core or newer VLESS and REALITY configurations. When nodes mainly use VMess and other configurations supported by the v2fly core, v2flyNG is also an option. All three can read standard subscriptions or share links generated by the server, but client-specific settings should not be overwritten directly across apps.

If the same subscription provides VMess, VLESS, and different transport combinations, filter by protocol or note after updating, then choose a node the current client can run correctly. Do not assume that identical node names mean identical parameters on both devices; the server may return different subscription content for different User-Agents or convert formats based on client capabilities.

• Everyday setup: Use v2rayN on Windows and v2rayNG on Android, with the same subscription URL saved on both devices.
• v2fly core setup: Use v2flyNG on Android and prioritize VMess and other configurations explicitly compatible with the v2fly core.
• Rule management principle: Maintain nodes centrally through the subscription, while storing desktop routing and Android per-app proxy settings separately. Do not aim for identical config files.
• Update order: Update the subscription first, confirm the node count, select a node and restart the connection, then check the logs and actual access results.

In a test subscription containing 48 nodes, both v2rayN and v2rayNG showed 48 nodes after updating, confirming that the node sets matched. However, after desktop routing was set to “bypass LAN” and Android was set to proxy only selected apps, the actual traffic paths differed substantially. This illustrates the key point: the subscription standardizes the entry point, while device policies should remain locally managed.

Post-migration verification and troubleshooting

After syncing, verify configuration completeness before investigating speed. Use a consistent five-step check: “count, fields, connection, routing, DNS.” This quickly distinguishes an unupdated subscription, missing node parameters, and different local client settings.

1. Check the node count: If the source device shows 36 nodes, the target should show roughly 36 after updating. A count of 0 usually indicates a failed subscription request or parsing error.
2. Spot-check three nodes: Verify the address, remote port, protocol, TLS, transport, and note for three nodes. Do not check only the first one.
3. Establish a connection: Check the core log for timeouts, certificate name mismatches, target rejections, or port conflicts.
4. Check local traffic capture: In v2rayN, confirm the system proxy mode. In v2rayNG, confirm system VPN authorization and the scope of per-app proxying.
5. Verify DNS: If a connection works but domains do not open, check the DNS configuration and routing rules. Reaching an IP address does not prove that domain resolution works.

Speed tests are useful only as a screening reference. A single latency result of 85 ms does not mean webpages, video, or large files will all work reliably. Run three consecutive tests and watch for fluctuation. For example, results of 82, 310, and 96 ms indicate brief congestion; three results between 90 and 110 ms usually suggest better stability.

A sync strategy for long-term use

A stable multi-device setup does not require every toggle to match. A better approach is to separate configuration into three layers: the subscription layer standardizes node sources, the client layer stores platform-specific ports and traffic-capture methods, and the rules layer manages routing and DNS by device use case. This way, replacing a device requires restoring only the subscription and a small number of local settings.

Perform a manual review once a month: remove retired subscription groups, confirm that update URLs still work, delete duplicate QR-imported nodes, and export a working copy of any complex rules. Label exported files with the client name and date, such as v2rayN-routing-2026-06-27.json, to avoid accidentally importing them into another client months later.

The final choice is straightforward: use one subscription when more than two devices need ongoing updates; use a QR code to share a single node temporarily; use an exported file to back up complex rules between similar clients. The methods can be combined, but do not treat a QR code as a subscription or a client’s complete config file as a cross-platform standard.