Three Ways to Sync V2Ray Configurations Across Devices: Subscription Links, Export and Import, and QR Code Sharing

Define the Configuration Scope Before Syncing

“Syncing a V2Ray configuration” can mean three different types of data. The first is server parameters, including the address, port, user ID, transport, TLS, SNI, Reality public key, and Flow. The second is client management data, including subscription groups, node notes, sorting, and update intervals. The third is device-local settings, including the system proxy, routing rules, DNS, log level, LAN listening, and local inbound ports.

These three sync methods cover the data differently. Subscriptions mainly manage server lists, QR codes usually carry only one node, and same-client backups may include groups and app settings. Even when two devices import exactly the same node, the system proxy switch, routing mode, and local ports will not become identical automatically.

Before migrating, record the currently active node, routing mode, and local listening port. 10808 is a common example, not a fixed port for every version or device. If another application is already using the same port, the client will report a listening failure when starting the core. Change the local port instead of modifying the remote server port.

Option 1: Manage Nodes Centrally with a Subscription Link

Subscription links work best when nodes are added or removed, domains change, or parameters need regular updates. Once both devices save the same subscription URL, each retrieves the list from the same source. When server parameters change, update the subscription source once instead of rescanning QR codes on every device.

Subscriptions are not pushed in real time. v2rayN and v2rayNG update according to their own schedules, and you can also refresh them manually. If one device shows new nodes while the other does not, compare the last update time first, then verify that the subscription URLs match exactly. Trailing spaces, incomplete query parameters, and expired access credentials can all produce different results.

1. Add the Subscription

   In v2rayN, open “Subscription Groups” → “Subscription Group Settings” → “Add”, enter an alias and the complete subscription URL, then save.

2. Refresh the List

   Return to the main screen and choose “Subscription Groups” → “Update All Subscriptions”. Wait for the node list to rebuild, then select a node and run a real connectivity latency test.

3. Import on Android

   In v2rayNG, open the top-right menu and go to “Subscription Settings”. Add the same URL, return to the main screen, and choose “Update subscriptions”.

4. Check the Core

   On desktop, open “Settings” → “Parameter Settings” → “Core Type” to verify the node's core. On Android, v2rayNG uses the Xray core to process supported node protocols.

5. Configure Routing Separately

   Choose the routing mode, DNS, and local proxy behavior separately on each device. Subscriptions generally do not overwrite these client-side options.

Option 2: Export and Import for Migration and Offline Backups

Export and import are useful when replacing a device, backing up before a reinstall, or when two devices cannot access the subscription source at the same time. Distinguish between an “application data backup” and a “single-node export”. An application data backup is intended for the same client and may include subscriptions, groups, and preferences; a single-node export usually creates VMess or VLESS share links, which are better for transferring server parameters between clients.

Do not treat v2rayN's complete data directory as a universal import file for v2rayNG. Their interface settings, routing storage, and runtime environments differ. For cross-platform migration, prefer a standard share link or the same subscription URL. Use client-generated backup data only when restoring between the same client and similar versions.

After importing, compare the protocol, address, remote port, user ID, transport layer, and security parameters one by one. For VLESS + Reality, also verify SNI, Public Key, Short ID, Fingerprint, and Flow. For VMess + WebSocket + TLS, check the Host, path, and TLS server name. A single missing field can appear as a connection timeout or handshake failure.

• Before restoring to the same client, close the current connection so the running core does not continue using the old configuration file.
• After importing data containing multiple nodes, deduplicate them by note or address before running latency tests.
• If the old device uses custom routing rules, export the rule content separately and record the rule order.
• Keep the old device configuration for a while after migration. Clean it up only after confirming that subscription refreshes and automatic startup both work normally.

Option 3: QR Codes for Sharing a Single Node Nearby

A QR code typically encodes a share URI as an image. After the desktop client displays it, the Android client reads the VMess or VLESS share information and creates a node. This avoids manually entering a long user ID and works well for temporarily sending a verified node to another device.

A QR code is more like “copying one node” than continuously syncing it. If the source device later changes the address, port, or Reality parameters, the target device will not update automatically. Use a subscription when nodes change frequently; QR codes are more direct for fixed nodes, temporary tests, or in-person handoffs.

1. On the v2rayN main screen, select the target node and open the share QR code from the server-related menu.
2. In v2rayNG, tap “+” in the top-right corner, choose QR code scanning, and grant the camera permission required for this session.
3. Do not delete the original node immediately after importing. Compare the note, address, port, transport, and TLS fields first.
4. Start the new node and run a real connectivity test. Complete the switch only after confirming that web requests are going through the proxy.

Scanning may fail if the QR code is too dense, the screen reflects light, or its edges are cropped after zooming. Increase the desktop screen brightness, restore the full QR border, and keep the camera parallel to the screen. If it still cannot be recognized, use “Copy share link” and “Import from clipboard” instead; the transferred node content matches the QR code.

Fields to Check When v2rayN and v2rayNG Interoperate

Standard protocol fields are usually interoperable, but clients may handle default values differently. For example, when a share link does not explicitly specify a Fingerprint, different versions may use different defaults. Complex routing, chained proxies, and custom core configurations also cannot be fully represented by a single share link. Successful import only means the data was parsed; it does not mean every connection requirement is satisfied.

Core capabilities also affect the result. v2rayNG uses the Xray core and is suitable for importing supported VLESS, Reality, and VMess configurations. When v2flyNG uses the v2fly core, choose protocol and transport combinations that the core actually supports. If a node contains specific Xray extension fields, matching addresses and ports alone do not prove that both sides are equivalent.

During testing, separate “node connectivity” from “system traffic capture”. First check the core log for an established outbound connection, then confirm that the desktop system proxy or Android connection switch is enabled. If the core successfully listens on 127.0.0.1:10808 but the browser still connects directly, the issue is usually with the system proxy, the browser's separate proxy settings, or routing rules—not the subscription sync itself.

Common Sync Problems and Troubleshooting Order

Keep the troubleshooting order fixed: “Was the data imported, did the core start, is the node reachable, and is traffic being captured?” Do not repeatedly change DNS and routing before confirming the node fields, or you will introduce multiple variables at once. Change one setting at a time, reconnect, and record the result to identify whether the difference comes from the subscription content or the device environment.

Choose a Sync Strategy by Use Case

A practical daily setup is “subscriptions first, exported backups second, and QR codes for temporary nodes”. Subscriptions keep the server list updated; same-client backups preserve groups and local preferences; QR codes quickly validate an individual node. They are complementary tools for centralized maintenance, complete migration, and instant transfer.

• One desktop device and one Android device: add the same subscription on both, then configure routing and DNS separately.
• Preparing to reinstall the desktop system: save the v2rayN client data and additionally record the current Core Type, local port, and automatic startup setting.
• Testing a new node temporarily: import it into v2rayNG with a QR code first, then verify the protocol fields and network path.
• Updating multiple devices in bulk: do not rescan each device; use a subscription group that can be managed centrally.
• A node includes Reality or a specific Flow: verify the Xray-related fields after import instead of checking only whether the node names match.

After syncing, perform at least three checks: refresh the subscription once, restart the client once, and switch networks once. The refresh test confirms that the subscription credentials still work; the restart test confirms that the configuration was saved persistently; the network-switch test can reveal DNS issues, port conflicts, or route restrictions that exist only on one LAN. Once all three pass, the multi-device configuration is ready for repeatable use.