V2Ray Config Sync Across Devices: Subscriptions, Exports & QR Codes

Separate server sync from full configuration migration

A server node that works on a Mac won’t necessarily give an Android device the same proxy behavior just because you copied a file. A node stores the server address, port, authentication details, and transport settings. Routing determines which requests go direct, through the proxy, or get blocked. System proxy settings and local listeners send app traffic to the client. These are separate layers.

v2rayN is available for Windows, macOS, and Linux desktops. On Android, v2rayNG uses the Xray core, while v2flyNG uses the V2Fly core. A client accepting an import format doesn’t mean its core supports every protocol and field in that format. For VLESS nodes with features such as REALITY, check the target core first; matching node names don’t guarantee compatibility.

Subscriptions, exports, or QR codes: which should you use?

“Sync” usually doesn’t mean two clients push changes to each other in real time. Reusing a subscription means each device fetches nodes from the same source. QR codes and configuration files are snapshots taken at export time. They won’t update when the source device changes, or fix themselves if the server’s authentication details change.

Reuse a subscription: import and update on each device

First check the subscription provider’s device limits, simultaneous connection limits, and data-use rules. Using the same link doesn’t combine multiple devices into one connection or bypass the provider’s restrictions. Some services return different content to different clients, so a different number of nodes doesn’t necessarily indicate a sync problem.

The menu names below are from the Simplified Chinese interface. Depending on the v2rayN desktop build, buttons may appear in menus or group panels; on Android, use the top-right menu. If your layout differs, look for “Subscription Group Settings” and “Update Subscription.” Don’t enter a subscription URL as a single-node address.

1. Save the subscription source

   Copy the full subscription URL from the service dashboard, including its query parameters. Name the group “Everyday subscription” and note which formats the provider supports. Don’t copy a link that’s truncated in the interface.

2. Add a group on desktop

   In v2rayN, open “Subscription Group” → “Subscription Group Settings” → “Add.” Enter an alias and subscription URL, then save. Return to the main window and choose the option to update all subscriptions from the “Subscription Group” menu.

3. Add a group on Android

   In v2rayNG, open the top-right menu → “Subscription Group Settings” → “+.” Enter a note and URL, then save. Return to the main screen and choose “Update Subscription” from the top-right menu.

4. Check the node details

   Select a node with the same name on both devices and compare its server address, port, protocol, and transport settings. A name is only a label; matching names don’t guarantee identical configurations. Run one manual update before setting a schedule.

5. Check how updates work

   If the subscription can be fetched directly, test it without a proxy first. Use a proxy only if the URL actually requires one, and keep a working old node available in case the update fails.

Exporting configuration: identify the file before restoring it

If you find a file named config.json, inspect its structure rather than guessing from the filename. Files containing inbounds, outbounds, and routing are typically core runtime configurations. A client backup may also include groups, subscription sources, and interface settings. These are different types of data and require different import options.

v2rayN may generate a runtime configuration from the selected node and rules. Direct edits to a generated file may be overwritten the next time you switch nodes or start the core. Save long-term changes through the client’s supported custom configuration or rule options. Before moving to another computer, use the app’s own export feature to create a backup.

• Moving between desktop systems: Quit the client before backing up its user data, and note the OS and client build. Keep the target device’s existing data until you’ve confirmed the backup is compatible.
• Moving between operating systems: Don’t overwrite the entire application directory when moving between Windows, macOS, and Linux. Certificate paths, data directories, startup items, and permissions may differ.
• Moving to Android: Prefer importing the subscription or share link again. Try a full core configuration only if the target client explicitly supports custom configuration and its core supports that file.
• External rule dependencies: Check for rule data, certificate files, and custom paths. A readable JSON file doesn’t mean those dependencies were migrated too.

After restoring, test one node before adding routing rules. If the client reports unsupported fields, check the core types and configuration formats on both ends. Don’t delete fields just to make the error go away; removing transport or security parameters can change the connection requirements.

QR code sharing: for a single node, not a backup

On desktop, use the selected node’s share or export option to get a share link or QR code. In Android v2rayNG, tap the top-right “+” → “Scan QR code,” or copy the link and choose “Import from clipboard.” Scan only content shown on a trusted device you control, then review the node details after importing.

vmess:// and vless:// are different share formats and can’t be converted by changing the prefix. QR codes typically contain authentication details. Long links can also be affected by QR density, screen scaling, and camera focus. If scanning fails, send the complete URI using a trusted local transfer method rather than retyping a long string of parameters.

1. On the source device, select one verified, working node and generate its share information. Don’t accidentally create a QR code for the subscription URL instead of a single node.
2. After importing, check the server port, UUID, transport type, TLS setting, and server name. For REALITY, also verify parameters such as the public key and short ID.
3. Test the connection on the target device independently. If the node works on the source but not the target, check protocol support and network conditions first, then verify that the entire link was copied.
4. Once you’ve verified the import, delete temporary screenshots and transfer records. If the node changes later, share it again or update it through the subscription.

Reuse routing intent; configure each device separately

When reusing routing rules, compare rule order, match fields, and outbound tags. Seeing “Bypass LAN” in both interfaces doesn’t prove the full rules match. Rules using geosite or geoip also depend on the corresponding data files on the target device. Client-specific preset names aren’t universal import formats.

The values below are examples for troubleshooting a local proxy, not defaults for every version. Use the port shown in the client’s current listening settings, and only enter it if a listener is active.

When running clients independently, 127.0.0.1 on each device points to that device. Copying a Mac’s system proxy address to another computer won’t connect it to the Mac. Sharing a proxy with other devices over a LAN is a separate setup that requires a listening address, firewall rules, and access controls; it isn’t configuration sync.

Migration checks and credential security

Verify each layer in turn. First, confirm the subscription fetch succeeds; then test the node connection; finally, check that app requests use the intended outbound according to the routing rules. A successful node test confirms only that test—it doesn’t mean the system proxy is enabled or that every app is using the proxy.

Subscription links often contain account tokens, and share URIs include the information needed to use a node. Base64 is an encoding, not encryption; QR codes don’t hide credentials either. Don’t put this information in public documents, screenshots, or online conversion tools. If you need to store it, use controlled, encrypted storage and limit access.

• Keep a recovery point before updating: Save the last working configuration and rules. Note the export date, source, and target client without putting the full address or token in the filename.
• Test before enabling automatic updates: Run a manual fetch and connection test first, then configure automatic updates. Sleep mode and background restrictions can affect when they run.
• Avoid concurrent overwrites: Don’t let file-sync tools modify a client database while it’s running. Sharing a live data directory across devices can cause overwrites, conflicts, and lost state.
• Rotate credentials after a leak: Reset the link or authentication details with the subscription provider, then update each device. Deleting a local screenshot won’t revoke credentials that have already been exposed.

Keep a short record of where nodes are updated, how to restore routing rules, and how each device handles traffic. That makes it easier to reproduce your setup on a new device and identify whether a problem is with the subscription, core, routing, or system proxy.