V2Ray Configuration Sync Across Devices: Subscriptions, Share Links, and Backups

1. Separate Node Sync from App Settings Migration

“Configuration sync” can mean at least three things: getting the same server list on two devices, retaining subscription URLs and groups, and copying local settings such as routing, DNS, and listening ports. A subscription usually handles only the first. A share link describes a specific node, while an app backup may include more local state. Treating these as interchangeable often leads to a familiar result: the node imports, but behaves differently.

v2rayN is a desktop client. v2rayNG is an Android client using the Xray core, while v2flyNG uses the V2Fly core. They are separate apps, not different interfaces for the same app, and their configuration databases are not necessarily compatible. Even when protocol names such as VMess and VLESS match, clients and core versions may handle transport and security settings differently.

2. Share a Subscription: Add and Update It on Each Device

First, check the subscription provider’s device limit and concurrent connection policy. Importing the same URL on two devices only confirms that the URL can be read; it doesn’t mean the account allows unlimited devices. Use the HTTPS subscription URL provided by the service. Don’t mistake the web dashboard’s sign-in URL for a subscription link.

1. Add a group on desktop: In v2rayN, open “Subscription Group” → “Subscription Group Settings,” add a group, enter a label and subscription URL, then save. For easy reference, you could name it “Daily Subscription.”
2. Fetch nodes on desktop: Go back to “Subscription Group” and choose “Update current subscription (without proxy)” or the equivalent option. Labels vary slightly by version. Make sure the group you just saved is selected; saving the URL alone won’t populate the list.
3. Save the source on Android: In v2rayNG, open “Subscription Group Settings” from the side menu and add the same URL. Return to the main screen, tap the top-right menu, and choose “Update subscription.” Use v2flyNG’s own subscription settings and update controls; don’t import v2rayNG’s app data directory.
4. Compare results on each device: Check the number of nodes in the group, their labels, and a node’s server address and port. If the provider returns different content depending on the client, the counts may differ. Check format compatibility rather than importing the same list again.

If the first update fails, identify where it went wrong. An unreachable URL, a sign-in page in the response, and a subscription parsing error are different problems. If your current network can’t fetch the subscription directly, try the client’s update-through-proxy option only if you already have a working connection. Switching update methods repeatedly won’t create missing configuration when no usable node is available.

3. Share Links and QR Codes: Transfer a Snapshot of One Node

Share links are a straightforward option when you have only a few manually managed nodes or want to check whether the destination client can use a particular configuration. Common node links start with vmess:// or vless://. Subscription URLs are usually HTTPS, but the prefix alone doesn’t tell you what they contain. An HTTPS URL could also lead to a web page; check the response the client actually receives.

1. On the source device, select a node and choose the share, export share link, or QR code option from its menu. Menu labels vary by version. Export the node itself, not the subscription group’s access URL.
2. For v2rayN, choose “Server” → “Import batch URLs from clipboard.” For v2rayNG, tap “+” on the main screen and choose “Import from clipboard” or “Scan QR code.”
3. After importing, check the protocol, server address, port, user ID, transport, and TLS settings before connecting. Matching node names don’t guarantee matching settings.
4. Once you’ve confirmed the destination can connect, delete temporary transfer records and QR code images you no longer need. Don’t leave a QR code containing credentials in a shared photo album.

A VLESS node may also require settings such as the server name, flow control, or public key. WebSocket transport may need a path and Host value. If the destination client doesn’t recognize certain fields, the import may succeed but the connection can still fail. Compare the source settings with the destination’s edit screen instead of switching to a different transport at random. If the source has settings the destination lacks, first check whether that client and core version support them.

4. Importing Backups: Know What You Exported

“Export servers,” “export full configuration,” and “back up app data” sound similar but cover different things. A server share mainly contains node details. A core configuration may include inbounds, outbounds, routing, and DNS. An app backup may save the client’s groups and preferences. JSON that a core can read isn’t necessarily a backup file that restores the client’s interface and state.

When moving to a new device with the same client, use the backup and restore feature documented for your current version, and note the source version. If the version has no full backup option, don’t treat “export nodes” as a complete backup. Record subscription groups, routing choices, DNS, and ports separately. When moving between v2rayN, v2rayNG, and v2flyNG, prefer a subscription or standard share link; don’t overwrite each other’s data files.

• Before restoring: Back up existing data on the destination and check whether the restore will replace current nodes and groups. If the behavior isn’t documented, assume it may overwrite them.
• Before copying: If you’re copying settings files as described in the client’s documentation, quit the app first so its database can finish writing. Copy only the configuration files listed in the documentation, not the entire installation directory.
• After restoring: Check references to rule files, certificates, and other local files. Absolute paths from the old computer usually won’t exist on the new device.
• After verification: Only then clean up data on the old device. Protect backup files with controlled storage and access permissions; don’t place them in a public sync folder.

5. Post-Migration Checks: Separate Remote and Local Ports

If the same node produces different results, first check whether traffic is reaching the client. The desktop system proxy, Android VPN routing, split routing, and DNS are all local settings; subscriptions don’t standardize them. In particular, don’t change the server’s connection port to match another device’s local listening port.

These numbers only illustrate the different roles of the ports; they aren’t required settings. Enter the actual open port of the remote server in the node. In a browser or other local app, enter the proxy address and port that the current client listens on. Two separate devices can both listen on 127.0.0.1:10808 without conflicting. On the same computer, two processes trying to use the same listening address and port can fail to start.

1. Check the node: Select the same compatible node on both devices and check the logs for parsing, authentication, or connection errors.
2. Check traffic routing: In v2rayN, check the system proxy status. Apps with a manually configured proxy need their own settings checked too. In v2rayNG or v2flyNG, check system VPN permission and connection status.
3. Check routing rules: Check whether bypass rules are enabled and whether the test app is excluded. Android app package filters can’t be directly substituted for desktop app settings.
4. Check DNS: If only some domains fail on the same node, compare DNS and routing settings on both devices. Change one setting at a time and keep the original value so you can restore it.

6. Ongoing Maintenance: Updates, Duplicate Nodes, and Expired Credentials

With multiple devices, the most common problem isn’t the initial import; it’s one device staying on an old list. Whenever the provider changes its nodes, update each client separately, confirm the update succeeded, and select a node that’s still available. Subscription updates generally don’t sync the active node selected on desktop to Android.

Keep a migration record that doesn’t include credentials: client version, subscription group names, the date of the last successful update, and any local routing or DNS changes. When changing devices, restore the node source first, then use the record to reapply local settings. This reduces duplicate imports and helps identify whether a problem stems from the source, compatibility, or device settings.