Sync v2rayN and v2rayNG Across Devices: Subscriptions, Share Links, and Backups

First, know the difference: syncing nodes does not sync client settings

v2rayN is a desktop GUI client, while v2rayNG is an Android client powered by the Xray core. They can use compatible node settings, but they do not share a settings database. Subscription updates typically refresh the server list; they do not copy system proxy, TUN, per-app proxy, or all DNS settings.

Before migrating, sort your settings into three layers. The first is server connection details, the second is traffic routing rules, and the third is how each device connects. Even with the same first layer, two devices can get different results. That does not necessarily mean the subscription has failed.

Choosing a method: subscriptions, share links, or backups

If your subscription limits the number of devices or simultaneous connections, check the provider's terms first. Being able to import one subscription on two devices does not mean unlimited devices can connect at once. Treat subscription links as sensitive: they often contain access tokens, so they are not public download links.

Import the subscription on both devices: same source, separate updates

These steps use common Chinese-language interfaces. Menu labels may vary by version. If you cannot find the exact label, look for subscription group management rather than entering the subscription URL in a single server's address field. A subscription is usually an HTTPS URL; text starting with vmess://, vless://, trojan://, or ss:// is usually a node share link.

1. Check the subscription format

   Choose a subscription format from your provider that works with v2rayN or v2rayNG. If the provider gives each client a different URL format, use the corresponding URL for the same account. The two URL strings do not have to match exactly.

2. Add a group on desktop

   In v2rayN, open “Subscription Group” → “Subscription Group Settings” from the main window. Add a group, enter a note and subscription URL, then save. Go back to “Subscription Group” and select “Update All Subscriptions.” If the first update fails, check whether the update option runs through the proxy or directly.

3. Add a group on Android

   In v2rayNG, open “Subscription Group Settings” from the side menu, tap “+”, enter a name and URL, and save. Return to the main screen and use the subscription update option in the top-right menu. If you can update the selected group or all groups, check that the right group is selected first.

4. Check the connection settings

   Once both updates succeed, select the same node on each device and compare the protocol, server address, and port. Matching names do not guarantee matching settings. Also check transport, TLS, and SNI; for REALITY, verify the public key and Short ID too.

5. Make updates part of your routine

   Update each device separately and note when you did it. If you want automatic updates, check whether your current version supports them and what triggers them. Android background restrictions may affect scheduled updates, so manually update and verify after important changes.

Do not edit a subscription node and expect the change to stick. Some update methods rebuild subscription entries and can overwrite manual edits. For testing, copy the node to a separate manual group and note the changes. Use the subscription source as the reference for the official settings.

Share links and QR codes: move a node, not the whole setup

To move one node from desktop to phone, select it in v2rayN and use the right-click menu to export a share link or display a QR code. In v2rayNG, tap “+” on the main screen and choose “Scan QR Code” or “Import from Clipboard.” To move a node the other way, share it from the node menu in v2rayNG, then in v2rayN choose “Servers” → “Import bulk URLs from clipboard.”

• Copy the entire text: Keep the whole line, including its protocol prefix. Line breaks, truncation, or automatic character substitutions in chat apps can corrupt the settings.
• If scanning fails, try the text link: QR codes for long links are dense. If enlarging the code and turning up screen brightness do not help, send the original link through a trusted private channel instead.
• Check security settings after import: VLESS nodes do not always use REALITY, and a Trojan node's name does not tell you all its TLS settings. Use the source config fields as your reference; do not disable certificate verification just to get a connection.
• Subscription vs. snapshot: A single-node link usually does not retain the subscription's update relationship. If the source changes its port, re-import the link or edit the node on the other device.

Backups and migration: restore on the same client, rebuild across clients

Backups and share links serve different purposes. A share link carries connection settings; a client backup may include groups, routing, and preferences. A core runtime config is simply data generated for the core to read and may not include GUI management details. Do not assume a JSON file is a complete backup just because it is JSON.

1. Note versions before migrating: Record the client version, core and core version, and installation method. Take screenshots of routing and DNS settings without credentials. When restoring, start with the same client version so you do not mistake version differences for a damaged backup.
2. Fully exit the desktop client: Stop the connection, then quit v2rayN from the system tray. For a portable installation, back up the user data the program actually uses, not just the main executable. Data locations vary by installation method, so check the client documentation and local folders.
3. Use supported Android options: If your version of v2rayNG offers a config export or backup option, use it and check what it includes. If it only supports sharing nodes, treat the process as “migrate nodes, then rebuild settings”—do not mistake a node export for a full backup.
4. Keep the existing data before restoring: Back up the target device's current config before restoring a copy. Test one node and one routing rule first, then enable the rest in stages once they work. Do not overwrite both devices at once and troubleshoot afterward.

Store backup files encrypted and keep the decryption password separate. If you use cloud storage, do not let two running clients read and write to the same database directory. Concurrent writes, lock files, and platform differences can corrupt the data. Syncing a backup made after closing the client is safer than syncing a live data directory.

Routing and ports: keep the intent consistent, not device-specific settings

A PC browser uses the system proxy, while Android apps connect through a VPN, so traffic enters the clients differently. The system proxy affects only apps that honor it; Android per-app proxy settings determine which apps enter the VPN. First confirm that traffic reaches the client, then compare routing. Otherwise, identical node settings still will not produce a meaningful comparison.

These ports are examples, not defaults for the current version; some configs use a mixed inbound port. Check the actual listening port shown under “Settings” → “Parameter Settings” or the equivalent page in your client. Entering 127.0.0.1:10808 on a phone points to the phone itself, not the PC. When each device runs its own client, their local port numbers do not need to match.

• Align the routing intent: For example, send local domains and LAN traffic directly, and handle other destinations according to the chosen policy. Check rule order one by one instead of comparing mode names such as “bypass mainland China.”
• Align rule data: If you use geosite:cn or geoip:cn, make sure both clients support those rules and have the required data. Different rule data versions can produce different matches.
• Verify DNS separately: Check where DNS queries go, how domain matching works, and whether resolved IPs are used for IP rules. A shared node subscription does not sync these settings.
• Keep platform-specific settings separate: Desktop app paths, Android package names, and VPN exclusion lists do not map directly to one another. Set them up again on the target platform.

Migration checks and common questions

Do not rely on latency test numbers alone. On the same network, use the same selected node on both devices to open the same HTTPS page, then test a destination that should connect directly. Finally, check the apps that need the proxy. A working connection, correct routing, and correct app access are three separate checks.