For keeping nodes aligned across multiple devices over time, use the same subscription URL. To temporarily send one VMess, VLESS, Trojan, or Shadowsocks node to Android, a QR code is faster. Use a full configuration export only when migrating the same client and preserving its routing and interface settings. This guide covers the steps, sync scope, and post-migration checks for all three methods.
First decide whether you are syncing nodes or the entire client setup
“Syncing a V2Ray configuration” usually refers to three different needs. The first is making a computer and phone show the same server list. The second is sending the one node currently in use to another device. The third is moving the client database, routing rules, DNS, subscription groups, and interface preferences. Each requires different tools: a shared QR code is not a complete backup, and an Android client generally cannot read a desktop configuration directory directly.
Subscriptions are best for keeping a server list continuously updated. When the provider changes an address, port, UUID, transport, or TLS setting, each device can fetch the new data independently. QR codes and share links are snapshots of a node at one point in time; changes to the source node will not reach the recipient automatically. A configuration export is closer to a migration tool, preserving local rules and client state rather than creating a live sync channel.
Shared subscription URL
RecommendedEach device fetches the same node list independently, receiving ongoing updates to addresses, ports, and protocol settings without directly transferring files between devices.
Best for: long-term use and keeping node lists aligned across devices
QR code or share link
Transfers the complete connection fields for one node in a short workflow, but excludes subscription groups, routing rules, and future changes.
Best for: sending one node temporarily from a computer to an Android device
Configuration export and import
Useful for migrating between similar clients and preserving more local data; moving across clients or cores requires checking compatibility item by item.
Best for: changing computers, reinstalling an operating system, or preserving complex routing settings
Method 1: Keep node lists aligned with one shared subscription URL
A shared subscription is the lowest-maintenance option across Windows, macOS, Android, and Linux. Use v2rayN on desktop, and choose v2rayNG or v2flyNG on Android according to the required core. Each device stores only the subscription URL and group name; the server list is generated from the subscription. Updates run independently on each client: updating on the computer does not push anything to the phone, which must be refreshed in its own client.
Before you begin, confirm that the subscription URL may be used on your own devices and check the provider’s simultaneous-connection limit. Subscription URLs usually contain an account-identifying token, so treat them like credentials. Do not paste them into public chats, screenshots, or public documents. When copying, make sure no spaces or line breaks are added before or after the URL.
-
Create a group
In the v2rayN main window, open “Subscription Groups” → “Subscription Group Settings” → “Add,” enter a recognizable alias, and paste the complete subscription URL.
-
Update the subscription
After saving, open “Subscription Groups” → “Update All Subscriptions” and wait for the server list to refresh. To update only one source, run an individual update for its group.
-
Add it on Android
In v2rayNG or v2flyNG, open the top-left menu, go to “Subscription Group Settings,” tap the add button in the top-right corner, enter the same URL, and save.
-
Refresh the list
Return to the Android client’s main screen and choose “Update Subscription” from the menu. When the update finishes, check that the node names, protocols, and counts match the returned subscription data.
-
Select and test
Select one node on each device and start the connection. Do not stop at checking whether the node appears; open the logs and confirm that the core loaded the configuration successfully.
Desktop subscription group
- Client
- v2rayN 7.x
- Menu path
- Subscription Groups → Subscription Group Settings
- Update method
- Update All Subscriptions
- Suggested naming
- Differentiate by source or purpose
The group name is a local label and does not need to match exactly across devices.
Android subscription group
- Client
- v2rayNG or v2flyNG
- Entry point
- Menu → Subscription Group Settings
- Refresh action
- Update the subscription
- Core differences
- Xray or v2fly
Whether new protocols in the same subscription work depends on the selected core’s supported features.
Different node counts do not necessarily mean syncing failed. A subscription service may return different content based on client capabilities, and local keyword filters may hide entries. During troubleshooting, disable group filters first, then compare protocols, addresses, ports, and node names instead of comparing only the total count. If a subscription update times out, first confirm that the current network can reach the subscription URL. If an existing node works, try the client’s “Update via Proxy” option.
Method 2: Send one node with a QR code
A QR code is ideal when you know you need “just this one.” For example, you may have temporarily added a VLESS node on a computer and want to send it to Android immediately, or you may have many nodes in a subscription while the phone needs only one. The QR code usually contains a share URI such as vmess://, vless://, trojan://, or ss://. It can include the address, port, user identifier, transport, and TLS fields, but not the system proxy state, TUN settings, routing rules, DNS policy, or subscription update URL.
VMess share data may use an encoded structure, while VLESS, Trojan, and Shadowsocks commonly use URI parameters. You do not need to parse these strings manually; the receiving client only needs to recognize them. If scanning reports “missing parameters” or the imported node will not start, check whether the QR code was cropped, whether the node uses transport parameters unsupported by the receiving core, and whether the Reality public key, short ID, SNI, fingerprint, and other fields are complete.
-
Select the node
Select the target entry in the v2rayN server list. Make sure it is not a test configuration, an expired node, or a profile intended only for a local network.
-
Show the QR code
Right-click the target server, open “Share Server,” and choose the QR code option. Some 7.x minor releases place this entry under the sharing actions in the main menu.
-
Scan on Android
On the v2rayNG or v2flyNG main screen, tap the add button in the top-right corner, choose “Scan QR Code,” grant camera access, and point the camera at the computer screen.
-
Check the fields
Open the imported node’s edit screen and verify the address, port, protocol, transport, TLS, SNI, and remark name before saving and starting it.
After a successful scan and import, the nodes on both sides are independent copies. If you change the port, UUID, WebSocket path, or Reality settings on the computer later, the Android copy will not change. Scan again or use a subscription instead. Likewise, changing the remark name on the phone will not affect the computer. Because it is a static copy, a QR code is not suitable for long-term synchronization.
Method 3: Export a configuration to migrate the same type of client
Configuration export is useful when changing computers, reinstalling an operating system, or preserving complex local settings. Compared with a QR code, it may include the server list, subscription groups, routing rules, DNS, core selection, and interface preferences. However, “may include” does not mean every client can read the result. v2rayN, v2rayNG, and v2flyNG use different data structures and runtime environments, so a complete directory is generally suitable only for migration within the same client family.
A safer approach is to split migration into two layers: use a subscription or standard share link for the node layer, and use the client’s own backup and restore capability for the client layer. Even if the interface database format changes between major versions, you can restore the essential nodes first and rebuild a small number of routing and DNS settings manually. Do not equate Xray’s complete runtime configuration with a client backup: the former describes how the core runs, while the latter may also contain groups, update history, and interface state.
Same-client migration
- Source
- v2rayN 7.x
- Target
- v2rayN 7.x on another device
- Priority content
- Subscriptions, servers, routing
- Before migration
- Fully exit the client
Record the exact source version first, then restore on the target using the same major version.
Cross-client migration
- Source
- v2rayN
- Target
- v2rayNG or v2flyNG
- Recommended carrier
- Subscription or share URI
- Rebuild manually
- Routing, DNS, and TUN settings
Migrate standard node fields only; do not copy the desktop database directly.
Core runtime configuration
- Format
- JSON
- Typical contents
- inbounds、outbounds、routing
- Local ports
- Check again for the target device
- Purpose
- Diagnostics and advanced migration
Core JSON does not include the complete client interface state.
Local runtime parameters
- System proxy
- Enable separately on each device
- TUN mode
- Authorize separately on each device
- Log level
- Configure separately per device
- Startup behavior
- Does not migrate automatically with nodes
These parameters depend on the operating-system environment, so forcing every item to match is not recommended.
-
Record the version
On the source device, open “Help” → “About” and record the exact 7.x version of v2rayN. Also note the current selection under “Settings” → “Parameter Settings” → “Core Type.”
-
Export what is needed
Prioritize saving the subscription URL, standard share links, and any routing rules you wrote yourself. For a complete migration, use the backup entry provided by the client or copy its configuration data.
-
Stop the client
Before migrating a complete configuration, disable the system proxy and TUN, then exit the client from the system tray menu to prevent the database or configuration files from still being written.
-
Restore on the target
Restore the data in a client with the same major version. On the first launch, do not immediately take over system traffic; check the server, subscription, and routing entries first.
-
Apply settings again
Set the local listening port, system proxy, and TUN permissions for the target system, then test one node and review the core logs.
Even if macOS, Linux, and Windows all run v2rayN, do not mechanically copy every path field. Log directories, core program locations, autostart behavior, and system proxy implementations may differ. The settings worth keeping aligned are the subscription source, node parameters, and traffic-routing logic. Paths, permissions, and traffic interception tied to the operating system should be configured again on the target device.
Check four layers after migration to avoid “same node, different result”
Seeing a node with the same name on multiple devices does not mean the actual runtime configuration is identical. One common difference is that the desktop uses the Xray core while the other device uses the v2fly core; another is that the computer has TUN enabled while Android is managed through the system VPN interface. Matching node parameters only means the remote connection target is the same. It does not prove that local inbound settings, DNS, and routing policies match.
Check four layers: node fields, core capabilities, local entry points, and routing results. First confirm the remote address, port, and protocol, then verify that the core can handle the relevant transport combination. Next check the local port and traffic-interception status, and finally use real domains to verify direct-connection and proxy rules. This is easier for locating problems than repeatedly deleting and re-importing nodes.
| Check layer | Specific items | Actionable check | Common difference |
|---|---|---|---|
| Node fields | Address, port, UUID, transport, TLS | Open the edit screen and compare each field; do not compare only the remark name | An old QR code retains a port that has since changed |
| Core capabilities | Xray or v2fly | Confirm under “Settings” → “Parameter Settings” → “Core Type” | A new transport parameter is unavailable in the other core |
| Local entry point | SOCKS, HTTP, and mixed ports | Use the value shown in the local interface; 10808 is a common test value | Another program occupies the port, so the core fails to start |
| Traffic interception | System proxy or TUN | Check the status bar and core logs after startup | The node is connected, but application traffic is not entering the client |
| Routing result | Direct, proxy, and block rules | Test one direct-connection domain and one proxy domain separately | Device rule-set versions or rule order differ |
- Check the log time first: After starting the node, core loading and connection records should appear immediately. If there are no new logs at all, check whether the core has started.
- Then check port usage: If the local mixed port is set to
10808, make sure another client instance is not listening on the same port. - Then check the system proxy: A desktop client running and the system proxy being enabled are separate states. The former succeeding does not mean browser traffic has been intercepted.
- Finally check routing: Temporarily switch to global proxy mode for testing. If global mode works but rule mode does not, the issue is usually in routing or DNS rather than the node itself.
Common multi-device sync issues
In practice, most problems are not that the “Import” button failed, but that different sync scopes were treated as the same thing. Handle the following cases using the specific path first, then decide whether to import again.
The computer updated the subscription. Why does the phone still show old nodes?
Subscription updates are not pushed between devices. Open the menu in v2rayNG or v2flyNG and choose “Update Subscription.” After it finishes, check the currently selected node, because the client may not automatically switch when an old node is removed.
The scan succeeded, but startup says the configuration is invalid. Why?
Open the node edit screen and focus on the transport type, TLS, SNI, fingerprint, Reality public key, and short ID. Then confirm that the core used by the Android client supports this combination. If necessary, use an Xray capability range matching the desktop client.
Why do two devices show different node counts?
Disable keyword filters and group filters in both clients, then run a full subscription update on each. If the counts still differ, compare the subscription update times and protocol types; the subscription service may return different entries according to client capabilities.
Can I import a v2rayN configuration directly into v2rayNG?
Copying the complete configuration directory is not recommended. For cross-client migration, use a subscription, QR code, or standard share URI for the nodes, then configure routing, DNS, and connection mode separately on Android.
The node connects, but the computer and phone get different results. Why?
Check whether both sides use the same routing mode and DNS policy. On the desktop, also verify the local port under “Settings” → “Parameter Settings,” and confirm that the system proxy or TUN is actually enabled. Do not compare only the node name.
For long-term maintenance, use the subscription as the primary data source, QR codes as a temporary transfer method, and configuration exports as migration backups. Giving each method its own layer reduces repetitive editing and prevents operating-system-specific settings from being carried incorrectly to another device. After every migration, keep a check of the node, core, port, and routing layers; differences can usually be found quickly in the logs.