To use the same nodes on desktop and Android, add the same subscription separately in v2rayN and v2rayNG. For a one-off node transfer, use a share link or QR code; for custom core configs, consider importing a file. Subscriptions generally update nodes only—they do not sync system proxy settings, Android VPN permissions, DNS, or full routing policies. This guide explains those boundaries and how to verify your setup after an update.
What Syncs: Matching Nodes Doesn't Mean Matching Behavior
“It works on my computer, but not after importing it on my phone” doesn't necessarily mean the node failed to copy. A node config defines the remote address, port, protocol, authentication, transport, and TLS parameters. Client settings determine how traffic is handled locally, how domains are resolved, and which outbound route is used. Check these two layers separately.
v2rayN is a desktop client, while v2rayNG is an Android client built on the Xray core. They can exchange node links in formats both support, but their client databases, window settings, and Android app proxy lists are not interchangeable config files. V2flyNG uses the V2Fly core, so a successful import alone does not guarantee compatibility with Xray-specific features.
| Config item | Subscription or node share | Across devices |
|---|---|---|
| Server and authentication settings | Usually included | Verify node details after updating |
| Transport and TLS settings | Depends on the share format and parser | Check fields such as SNI and path individually |
| Routing and DNS | Usually not included in standard node subscriptions | Configure and test on each device |
| Local listening port | Not synced by standard node sharing | Use each device's local settings |
| System proxy and app list | Not included | Enable separately on desktop and Android |
Choose a Method: Subscriptions for Ongoing Sync, QR Codes for One-Off Transfers
Decide what you need to maintain before choosing how to transfer it. For ongoing sync, use a stable config source that each device can update independently. For a one-off transfer, a snapshot of one node is enough. Full config files are better suited to users familiar with core config structures. Mixing methods without tracking the source can leave you with nodes that share a name but have different settings.
Same subscription link
RecommendedSave the same source on both devices and update each one separately. If the source changes its server addresses, there's no need to resend nodes one by one. Updates aren't pushed in real time and don't sync local routing settings.
Best for: ongoing use, multiple nodes, and regular maintenance
Share links and QR codes
Serialize the current node and send it to another device. A QR code is simply another way to carry the text. The imported node reflects its settings at that moment and won't track future changes to the original.
Best for: testing one node, one-off transfers, and in-person sharing
Config file import
Useful for preserving custom outbounds, routing, and DNS, but distinguish a client backup from a core JSON config. A readable file isn't necessarily compatible with the device's paths or supported fields.
Best for: custom core configs, migrating within the same client, and offline backups
Share Subscriptions: Add and Update Separately on Each Device
Before using a subscription, check that the provider allows multiple devices and whether it limits the number of simultaneous connections. The same subscription link may grant access to one account, so don't forward it to others. It differs from a single-node share link beginning with vmess:// or vless://: the former retrieves a set of configs, while the latter describes one node directly.
-
Organize your sources
Store subscription links, source notes, and last-updated dates in a secure location. Use the same group name on both devices, such as “Daily subscription.” Put manually added nodes in a separate group to keep temporary test configs out of the subscription list.
-
Add on desktop
In v2rayN, open “Subscription Group” → “Subscription Group Settings,” add a group, and fill in “Remarks” and “Address.” Save, then go to the “Subscription Group” menu and select “Update All Subscriptions (Without Proxy).” Some versions let you update the current group only, which is useful for refreshing just the source you added.
-
Add on Android
In v2rayNG, open the side menu and select “Subscription Group Settings” → “+”. Enter the same subscription URL and a name, then save. Return to the main screen, open the top-right menu, and select “Update Subscription.” Wait for the node list to refresh, then choose the node that corresponds to the one on desktop.
-
Handle timeouts
If a direct update fails, first make sure an existing node can access the internet. In v2rayN, try “Update All Subscriptions (Through Proxy).” In v2rayNG, look in “Settings” for “Update Subscription Through Proxy,” enable it, start the connection, and try again. The option's location varies by version, so check your current UI.
-
Verify the results
Compare the number of nodes on both devices, then open the same node's edit screen and check its address, remote port, protocol, transport, and TLS settings. Finally, test the connection on each device. Matching node names help with identification but don't replace checking the parameters.
A subscription update may rebuild the node list. Changes made directly to a subscribed node's address or transport settings may be overwritten by the next update. To keep a change long term, copy the node to a manual group and note why you changed it; keep the original subscription group as a reference. Automatic updates depend on client settings and background execution, so don't assume the phone updated while asleep.
QR Code Transfers: Nodes Only, Not the Runtime Environment
QR codes are a convenient way to transfer a single, verified node from desktop to Android. In v2rayN, select a node, right-click to open the sharing options, then show its QR code or copy the share link. In v2rayNG, tap “+” → “Scan QR Code” to scan it from the screen, or use “Import from Clipboard” to import copied node text. To transfer from Android to desktop, use the node's sharing menu, then in v2rayN select “Servers” → “Import Batch URLs from Clipboard.”
- Check the QR code after scanning: QR codes for long links are dense, so display them at a larger size with clear space around all four edges. Don't crop the edges in a screenshot. If scanning fails, use the original text instead of retyping authentication details.
- Match the transport settings: WebSocket path and Host, the TLS server name, and VLESS flow-control parameters can all affect connectivity. VMess share encoding also differs from VLESS link parameters, so don't just swap the protocol prefix.
- Check REALITY separately: If you're using REALITY, make sure the target core supports it and verify fields such as the server name, public key, short ID, and fingerprint. V2Fly and Xray have different feature sets; don't treat this config as a general-purpose option for V2flyNG.
- Avoid duplicate nodes: Scanning the same code again may add another entry rather than replace the old one. Compare the details first, then remove the outdated snapshot. Don't bulk-delete nodes based on their names before checking them.
File Migration: Distinguish Client Backups from Core JSON
“Export config” can mean three different things: node share text, a client-specific backup file, or JSON for the core to run. Only the first is generally suitable for exchanging nodes between clients. The second is mainly for restoring the same client; the third requires checking the full runtime environment. Don't copy the entire v2rayN program data directory to v2rayNG.
In v2rayNG's “+” menu, look for “Import Config File.” Before importing a custom core config, back up your working settings and confirm that the target core supports the file format. Custom configs may not use the routing setup generated by the standard node UI. Check the generated config and logs to see whether later changes to DNS or routing options in the UI actually take effect.
| Field or resource | Migration risk | What to do |
|---|---|---|
inbounds | A desktop local inbound isn't an Android VPN interface | Adapt the config to the target client's runtime |
routing | A rule references a nonexistent outbound tag | Check each outboundTag |
dns | Resolution paths don't match the current network | Test on both Wi-Fi and mobile data |
| Logs and certificate paths | Desktop absolute paths don't exist on Android | Remove unnecessary file output or use an accessible path |
| Category data files | Category names or data versions differ | Confirm the data required by the rules is available |
The outbounds in core JSON may contain authentication details; client backups may also include subscription URLs. Store backups somewhere access-controlled. Test one node before restoring the rest, so if something breaks after changing nodes, DNS, and routing, you can identify the cause.
Sync Routing: Align Policies, Keep Device-Specific Settings
A more practical goal across devices is to send the same kinds of traffic through the same kinds of routes—not to make every setting identical. The desktop system proxy affects only apps that honor it. v2rayNG typically receives traffic through Android's VPN interface and may let you choose which apps to include. These are two different traffic entry points, not a single switch you can copy between devices.
For example, if a desktop app is configured to use 127.0.0.1:10808, it connects to a listening port on that computer. Entering the same address on your phone won't connect it to the computer; the phone's loopback address points back to the phone itself. When the phone runs in VPN mode, you don't need to enter the desktop system proxy port in the Wi-Fi proxy settings.
- Write down the policy goals. List which domains should use the proxy, which local network addresses should connect directly, and which requests should be blocked. Don't start by copying the client's entire internal config.
- Check rule order. Core routing rules are usually evaluated in order. A broad rule placed too early can override later exceptions. Check specific domain rules and the default outbound on both devices.
- Check category data.
geositeandgeoiprules depend on local data files. The same rule name can produce different matches if the underlying data differs. - Check DNS. Note which route handles DNS requests and when domains are resolved. Rules based on IP categories also depend on the domain resolution strategy, so comparing DNS server addresses alone isn't enough.
- Keep platform-specific settings. Configure desktop app proxy settings and the Android app list separately. Test local network services on their own to avoid sending local traffic through a remote proxy by mistake.
For more on how routing and DNS work together, see DNS settings in the user guide. For help setting up a subscription, see the subscription import tutorial. After migration, test one destination that should use the proxy, one local network service, and one test destination explicitly set to be blocked. Check the logs to confirm the actual route.
FAQ: What to Check After Importing
Why do the devices show different numbers of nodes for the same subscription?
Manually update the same group on both devices and check for errors. Then verify that the subscription URL is complete, no filters are enabled, and the source doesn't return an unsupported node format. If the lists still differ, check whether the source returns different content depending on the requesting client. Don't start by repeatedly scanning QR codes to add nodes.
The QR code imported successfully, but the phone still won't connect. Why?
Open the node editor and check the address, port, transport, TLS, and flow-control settings. Then start v2rayNG, confirm it has Android VPN permission, and check the core logs. If the logs report an unknown field or unsupported flow control, check the target core and its version rather than changing the subscription source.
Why did my manual changes disappear after updating the subscription?
An update may regenerate subscribed nodes using the source's data. Copy any nodes you want to customize into a manual group, make your changes there, and test them; keep the original config in the subscription group. Give the two versions different names to avoid selecting the wrong one.
Why didn't my routing rules come across when I imported the config on my phone?
Standard node sharing doesn't include full routing or DNS settings. Configure each device from your policy checklist, then check outbound tags and category data. If you need to migrate core JSON, first verify that the target core supports it, then handle inbounds, log paths, and device-specific settings.
Is the subscription enough after reinstalling the client?
A subscription can usually restore the nodes provided by its source, but not manual nodes, app lists, or local rules. Before migrating, save the subscription source, share text for manual nodes, and your policy notes separately. A backup for the same client can help, but you'll still need to recheck system proxy settings or VPN permissions after restoring.
A reliable maintenance setup uses subscriptions as the source for nodes, manual groups for exceptions, policy notes for routing and DNS, and device-specific settings for handling traffic. Change one layer at a time and test it before moving on. This keeps nodes consistent between v2rayN and v2rayNG while making it easier to tell whether a problem comes from the source, protocol compatibility, or the local runtime environment.