For long-term multi-device maintenance, use one shared subscription source. For a few fixed nodes, use a share link or QR code. Full client backups are best for moving between identical clients. This guide separates node data, routing rules, and client preferences, with practical steps and verification methods for v2rayN, v2rayNG, and v2flyNG.
Decide Which Configuration Layer to Sync
Sync note
“Syncing a V2Ray configuration” is not a single operation. A usable client usually stores node parameters, subscription groups, routing rules, system proxy settings, and local ports at the same time. Node parameters describe the remote connection, including the address, port, user ID, transport, TLS, Reality, WebSocket path, and server name. Local settings determine how the client receives application traffic, matches domains, and selects an outbound.
Sync note
Subscription links usually distribute the node list, but they do not fully cover each device’s local policies. On Windows, v2rayN can use the system proxy and a local SOCKS port; on Android, v2rayNG or v2flyNG may enable per-app proxying. Even when both devices import the same nodes, local routing, bypass rules, and startup behavior should be configured separately.
Sync note
Before syncing, divide the goal into three parts: whether the node list must match, whether routing rules should be reused, and whether the client interface and local listener settings need to move as well. Separating these layers prevents treating one core JSON file as a universal backup and avoids assuming that subscription updates will change local rules automatically.
Remote Node Data
- Protocol
- VLESS or VMess
- Server port
- Actual values such as 443 and 8443
- Transport parameters
- TCP、WebSocket、gRPC
- Authentication fields
- User ID and flow-control parameters
Suitable for transferring between clients through subscriptions, share links, or QR codes.
Device-Local Settings
- Local port
- SOCKS 10808
- Proxy mode
- Automatic configuration or global
- Routing policy
- Direct, proxy, or block
- Application scope
- All apps or selected apps
Usually requires checking each device separately; restoring the node subscription alone is not enough.
Method 1: Maintain the Node List with One Shared Subscription Link
Sync note
When nodes are added, disabled, or reconfigured, one shared subscription link is the lowest-maintenance option. Save the same subscription address on every device and update it on each device’s schedule; node changes then need to be handled only at the subscription source. This works well for long-term node sharing across Windows, macOS, Android, and Linux, including setups that use v2rayN, v2rayNG, and v2flyNG.
Sync note
A subscription mainly syncs server entries. After importing, check the client’s active node, routing mode, and local proxy status. Subscription updates generally do not force a switch to another node. When an old node is removed, different versions may handle the current selection differently, so confirm that the active entry still exists after each update.
-
Save the subscription
Sync note
In the v2rayN main window, open 「Subscription groups」→「Subscription group settings」→「Add」, enter a group note, and paste the complete subscription address.
-
Choose the core
Sync note
Go to 「Settings」→「Preferences」→「Core type」 and choose a core that can parse the configuration for the node protocol. VLESS and Reality nodes typically use the Xray core.
-
Update the group
Sync note
Return to the main window and open 「Subscription groups」→「Update all subscriptions」. After the node list refreshes, check for additions, removals, and name changes.
-
Add the mobile client
Sync note
In v2rayNG or v2flyNG, tap 「+」 in the upper-right corner, choose 「Import subscription from clipboard」 or the corresponding subscription management option, and then run an update.
-
Verify separately
Sync note
Select the same node on each device and run a real connection latency test. After connecting, visit the target site to confirm that local routing and proxy scope behave as expected.
Recommended setup: share the node source, maintain local policies separately
Desktop (v2rayN)
- Save the shared subscription link
- Update subscription groups as needed
- Set the system proxy mode separately
- Check local ports and routing rules
Android
- Import the same subscription in v2rayNG or v2flyNG
- Confirm the active node again after updating
- Set per-app proxying for the device
- Keep the test results for mobile data and Wi-Fi
One source maintains the node list, while local listeners, routing, and app scope remain device-specific. The boundaries are clear.
Method 2: Move Fixed Nodes with Exported Files or Share Links
Sync note
If you have only one to three long-term fixed nodes and do not need a subscription source to keep updating, export share links from the desktop client and import them on another device. VLESS and VMess share links carry the key connection parameters for a single node, remain compact, and can be saved in a temporary file containing only node addresses.
Sync note
Keep in mind that “sharing a node” and “exporting a client backup” are different. A share link is designed to transfer server configuration between clients. A client backup may also contain groups, interface preferences, routing rules, and local database fields, so it is generally suitable only for restoring to the same client or a compatible version. Copying v2rayN’s complete data directory to v2rayNG or v2flyNG does not provide a reliable conversion.
Sync note
The core runtime configuration is also not the preferred exchange format. Client-generated JSON often expands into inbound, outbound, DNS, and routing objects, including the local machine’s listener address and port. For example, 127.0.0.1:10808 in a desktop configuration is a local entry point, not the remote server port.
Subscription link
RecommendedSync note
Add it once and update it repeatedly; node additions, removals, and parameter changes can be managed centrally.
Best for: two or more devices, frequently changing nodes, long-term synchronization
Share link or text file
Sync note
Transfer one node through a VLESS or VMess share URI. Import is straightforward across clients, but changes must be sent again.
Best for: a few fixed nodes, temporary moves, offline archiving
Full client backup
Sync note
Preserves more client state, but the directory structure and fields depend on the client type and version.
Best for: the same client, similar desktop environments, full-machine migration
Fields to Check When Importing Text
- Address and port: Make sure the remote address was not truncated by a line break, and that ports such as 443 and 8443 match the original node.
- Protocol and authentication: VLESS and VMess are not interchangeable, and the user ID must be preserved in full.
- Transport: TCP, WebSocket, and gRPC use different parameter structures; copying only the server address is not enough.
- TLS and server name: When TLS or Reality is enabled, the server name, fingerprint, Reality public key, and Short ID must all match.
- Path and Host: Check the path for WebSocket nodes, and import the Host value as well when it is present in the configuration.
vless://user-id@node-address:443?type=tcp&security=reality&flow=xtls-rprx-vision#Desktop-main-nodeSync note
The structure above only illustrates the parts of a share URI. For an actual import, use the complete content provided by the server or exported by the original client; do not assemble authentication fields from the example. If the node appears after import but cannot connect, first compare the transport, TLS settings, server name, and flow control instead of repeatedly changing the local proxy port.
Method 3: Transfer Between Desktop and Android with a QR Code
Sync note
A QR code is essentially a visual encoding of share text, making it suitable for moving a single node from a desktop screen to an Android device. It avoids manually copying a long link and is especially useful for VLESS Reality or VMess nodes with many query parameters. A QR code does not create an ongoing sync relationship; when node parameters change, generate and scan a new code.
Sync note
In v2rayN, select the target node first, then use 「Servers」→「Share server configuration」 or the share option in the node’s context menu to display a QR code. The final menu label may vary slightly between interface versions, but the operation should always target the selected single server, not the entire subscription group.
-
Select the node
Sync note
In the v2rayN server list, confirm the protocol, alias, and port, right-click the target entry, and open 「Share server configuration」.
-
Display the QR code
Sync note
Choose how to display the QR code, keep the window visible, and avoid saving a screen containing node credentials in a public location.
-
Scan on mobile
Sync note
In v2rayNG or v2flyNG, tap 「+」→「Scan QR code」 and add the recognized node to the local list.
-
Check the parameters
Sync note
Open the new node’s details and compare the address, remote port, transport, TLS, server name, and note to make sure nothing is missing.
-
Verify the connection
Sync note
Run a real connection latency test before starting the connection. If the latency check times out, inspect the log for handshake, DNS, or certificate-related details.
How to Verify That the Configurations Really Match
Sync note
Seeing nodes with the same name only shows that the import completed; it does not prove that both devices use the same parameters. Compare the protocol, address, remote port, and transport layer first, then test a complete proxy handshake. A regular ping reflects basic network reachability only; it does not perform a VLESS, VMess, TLS, or Reality handshake and cannot by itself confirm a successful sync.
Sync note
A repeatable check is to select the same node on both devices, record the real connection latency and connection time, and then visit the same destination. Suppose the real connection latency is 186 ms on Windows and 214 ms on Android. A difference of a few dozen milliseconds may come from Wi-Fi, mobile data, or local scheduling. If one side consistently returns a value while the other repeatedly times out, compare the node details and logs.
Sync note
Also distinguish “matching nodes” from “matching routing results.” A desktop client may connect directly to domains in mainland China and proxy everything else, while Android may proxy only selected apps. If the same website uses different exit locations on different devices, node sync has not necessarily failed; the local routing conditions or app scope may simply differ.
Node Consistency Check
- Protocol
- Both sides use VLESS
- Remote port
- 443
- Transport
- TCP
- Flow control
- xtls-rprx-vision
- Server name
- Matches the original configuration
Any difference in a key field can cause failure during the handshake.
Local Policy Check
- Local port
- 10808
- System proxy
- Enable separately per device
- DNS
- Follow the local routing design
- Rule order
- Specific rules first
- Application scope
- All apps or selected apps
Different values here do not mean the nodes differ, but they will change the final traffic path.
Sync Records Worth Keeping
- The subscription group name, date added, and last successful update time.
- The protocol, remote port, transport, and purpose note for the main nodes.
- The client name, version, and core type used on each device.
- The system proxy mode, local SOCKS port, and main routing policy.
- The node count before and after updating, along with how removed and duplicate nodes were handled.
Common Failure Points and Which Option to Choose
Sync note
If the node count drops to zero after a subscription update, first check that the correct group was updated. Then verify that the subscription address is complete, the network request succeeded, and the client can parse the returned format. Do not delete the original group immediately; keep the existing nodes and test with a new temporary group to reduce the risk of losing configuration through a mistaken action.
Sync note
If Reality or gRPC parameters are missing after importing a share link, the cause is usually the export format, client version, or core capability. Return to the original device and compare the complete node details. In v2rayN, check 「Settings」→「Preferences」→「Core type」 to confirm the selected core. The Android client version must also recognize the protocol and transport combination.
Sync note
If the QR code cannot be recognized, increase the desktop window brightness, enlarge the code, and reduce screen glare. If it scans successfully but the import fails, treat the issue as text parsing rather than camera scanning. Try using “Copy share link” and importing from the clipboard, then compare the results from both entry points.
Sync note
The final choice can be reduced to one rule: use a subscription for changing nodes, a share link or QR code for a few fixed nodes, and a full backup only when migrating an entire setup between identical clients. Whichever method you choose, verify local routing, the system proxy, and app scope on every device.
Long-Term Multi-Device Use
RecommendedSync note
Add every device to the same subscription group, update the nodes regularly, and maintain local routing and proxy modes separately.
Best for: everyday sharing across Windows, macOS, Android, and Linux
Moving a Few Nodes
Sync note
Export VLESS or VMess share links, save them as text, import them one by one, and redistribute them after changes.
Best for: one to three fixed nodes with infrequent changes
Temporary Desktop-to-Android Transfer
Sync note
Display a QR code for one node in v2rayN, then scan it with v2rayNG or v2flyNG and check the parameters.
Best for: adding a node on site when entering a long link is inconvenient