v2rayN and v2rayNG Config Sync Across Devices: Subscriptions, QR Codes, and Backups

What Each Sync Method Transfers

v2rayN is a desktop client, while v2rayNG is an Android client that uses the Xray core. The client stores nodes, subscriptions, and interface settings; the core handles the connection. Even if both clients can read the same node-sharing format, that doesn't mean their settings databases can be imported into each other.

First decide whether you need to move a server connection or the entire setup. A server connection includes the address, port, user credentials, and transport security settings. The full setup also includes DNS, routing order, app lists, startup behavior, and local listeners. Scanning a QR code alone won't migrate the latter.

Subscription Links: Import and Update on Each Device

A subscription URL usually contains access credentials. Get it from the original service account or saved subscription settings. Don't enter a node's vless:// or vmess:// share link in the subscription URL field. A subscription provides a list of nodes; a share link describes a single node.

1. Check the Subscription Source

   Open the subscription group editor on the original device and copy the full URL, including its query parameters. If the service offers multiple subscription formats, choose a node subscription format both clients can parse—not a complete ruleset intended for another config system.

2. Add a Group on Desktop

   In v2rayN, open “Subscription Group” → “Subscription Group Settings,” add a group, and enter a name and URL. Save, return to “Subscription Group,” and choose “Update All Subscriptions.” Whether to update through a proxy depends on which connections are reachable on your current network.

3. Add the Subscription on Android

   In v2rayNG, open “Subscription Group Settings” from the side menu, tap “+,” enter a name and subscription URL, and save. Return to the main screen, open the top-right menu, and choose “Update Current Group Subscription.” Make sure the newly created subscription group is selected.

4. Verify and Connect

   On each device, check the target node's server address, port, and protocol, then select it and connect. Menu labels may change between client versions; always update the group you just saved, not a manually created group with the same name.

If you need to edit a node from a subscription, export it first and put it in a separate manual group. An update may recreate the subscription entry, so don't rely on it to preserve long-term local edits. Use distinct group names, such as “Daily Subscription” and “Manually Managed,” to avoid updating the wrong group.

QR Codes and Share Links: Move a Single Node

When sending a node from a computer to a phone, a QR code avoids copying and pasting across devices. For phone-to-computer transfers, copying a share link is usually easier. Both typically carry the same node URI; a QR code can't restore fields missing from the original link.

1. In the v2rayN node list, select the target node and open the context menu's sharing or QR code option. Make sure you're exporting a node, not a subscription URL.
2. In v2rayNG, tap “+” on the main screen → “Scan QR Code.” To transfer text instead, copy the full share link, then tap “+” → “Import from Clipboard.”
3. To move a node from Android back to desktop, use the node's sharing option to copy its link. In v2rayN, choose “Server” → “Import Bulk URLs from Clipboard” on the main screen.
4. After importing, open the node editor and compare the transport, security, and identity fields. Test the new entry before deleting duplicates, and keep the working original as a fallback.

Don't assume an import is complete just because the node name matches. For VMess, check the user ID, encryption settings, transport, and TLS. For VLESS, check the user ID, Flow, and transport security. With WebSocket, also check the path and Host. With TLS, the connection address and server name may differ; don't change them to match without a reason.

• REALITY: Check the server name, public key, Short ID, and any Flow required by the server. v2rayNG uses Xray; make sure the desktop client is also using a core that supports this configuration.
• Large QR codes: Display the entire code at a larger size and avoid compressed screenshots. If scanning fails, use the original share text and check whether a messaging app added line breaks or truncated it.
• Custom configs: Complex outbounds, chained connections, and specialized transport options may not be fully represented in a standard share link. Migrate and verify them separately.

If switching to v2flyNG, which is based on the V2Fly core, check protocol support again. Don't assume a config that works in v2rayNG will also work if it depends on Xray-specific features. Seeing a node name only means the importer read some of the data; it doesn't mean the core can start that node.

Handle Routing, DNS, and Local Ports Separately

The most commonly missed part of cross-device config sync is the runtime environment. The desktop system proxy affects only apps that use the system proxy, while Android's VPN service handles traffic within its selected scope. These mechanisms work differently, so copying a setting called “Global Mode” won't make behavior identical.

When migrating routing rules, note the domain or IP match conditions, target outbound, and rule order, then recreate the equivalent rules on the other device. Don't paste an entire config containing desktop file paths, process-based conditions, or outbound tags that don't exist on the other device. Outbound tags must match an outbound in the target config; also check that any rule sets are installed or available there.

• DNS: Record how remote resolvers are reached, how domains in and outside mainland China are routed, and whether FakeDNS is enabled. Copying only the resolver address doesn't preserve the route DNS requests actually take.
• Per-app proxy: Recheck the selected-app list on the new Android device. Desktop process rules and Android app lists are different types of settings and can't be substituted for each other.
• Local ports: Suppose the desktop SOCKS listener is 127.0.0.1:10808. The same address on a phone points to the phone itself; it won't connect to the computer automatically.
• LAN sharing: This requires separate listener, access control, and firewall settings. Importing a subscription on multiple devices doesn't require opening a local proxy port. Don't expose a listener just to sync nodes.

Config Backups: Distinguish App Data from Core Runtime Files

Before backing up, note the client name, exact version, selected core, and system architecture. Check the device's About screen and core logs rather than guessing from the installer filename. An app backup and a core JSON file are different things: the former restores app state, while the latter describes the proxy config for a particular run.

1. Save Essential Details

   Save the subscription URL and share text for manually added nodes separately. Also record routing order, DNS, per-app lists, and local ports. Store sensitive fields in encrypted storage, not in a public document.

2. Back Up the App

   Use the backup or export feature available in the client version you're actually running, and check what it includes. If you need to copy data from a portable v2rayN installation, exit the app first, confirm the files have been written, and copy the actual user data directory—not just the main program.

3. Restore Data Separately

   For the same client, use its restore function. To move from desktop to Android, import the subscription and manual nodes separately, then recreate routing and other settings. Don't give v2rayNG a v2rayN database or app settings file to read.

4. Keep a Rollback Copy

   After restoring, check that the subscription URL, manual groups, and routing rules are all present, then test the connection. Don't delete data from the old device or overwrite your only backup with an empty config until everything works.

Post-Migration Checks and Common Issues

Change one variable at a time during testing. First connect to the target node using the new device's default, straightforward routing. Then restore custom DNS, routing rules, and app scope one by one. This helps distinguish node-setting problems from local policy issues instead of blaming every failure on the subscription.

• First pass: Check whether the core starts normally and whether the logs show a port conflict, unknown field, or authentication error. If the config can't be parsed, resolve field and core compatibility issues first.
• Second pass: Visit a site that needs the proxy, then one that should connect directly. Check the logs to confirm which outbound was selected. Opening one site doesn't prove the routing rules migrated correctly.
• Third pass: On Android, switch between Wi-Fi and mobile data and check app access on each. On desktop, restart the client and verify the system proxy status. Passing one test doesn't mean automatic recovery is configured.

For reliable cross-device maintenance, use the subscription source for the node list, a manual group for custom nodes, and separate runtime settings on each device. Handle subscription updates, single-node sharing, and app backups as separate tasks. When replacing a device, you'll know what to restore and which settings to verify again.