Sync Clash Across Devices: Share One Subscription Between Desktop and Mobile

First, understand the difference between subscription updates, config sync, and runtime state

Importing the same subscription on a computer and phone usually gives both devices nodes from the same source. It does not sync proxy group selections, DNS settings, or app routing between them. A subscription provides remote configuration; client settings are stored locally, and active connections are temporary runtime state. Identify these three layers before deciding what to sync.

• Remote configuration: Nodes, proxy groups, rules, and possibly DNS settings returned by the subscription. The exact contents depend on the server; some links return only a list of nodes.
• Local settings: Update intervals, override files, system proxy, TUN, and app exclusion lists. Where these are stored and what can be exported depends on the client.
• Runtime state: Current proxy group selections, speed test results, and active connections. Even when a client uses profile.store-selected to save selections, that only persists them on the local device—it does not sync them across devices.

For typical home use, a practical setup is to use the same subscription source and custom rules on every device, while letting each device handle its own traffic. Configure the system proxy on Windows and grant VPN access on Android separately; there is no need to make every setting identical.

Three sync methods: what they sync and when to use them

You can combine these methods, but choose a single source of truth for each part of your configuration. For example, use the subscription to update nodes, a separate rules file to maintain routing, and WebDAV only for device migration backups. If cloud files, subscription updates, and restored backups keep overwriting the same config, it becomes hard to tell which version is active.

Method 1: Import the same subscription directly on each device

Import and update workflow

1. Get a link compatible with your target client from your subscription account page. On your computer, import it by URL from the client’s Config or Subscription page. The menu names vary between clients.
2. Check that the imported config includes usable nodes and, for rule-based routing, the required proxy groups and rules. A response containing only a node list is not a complete runtime configuration.
3. On your phone, import a compatible link from the same source, grant the VPN permission requested by the system, and check that the expected proxy groups are available.
4. Tap Update on both devices, then check the update time, node names, and whether custom rules remain in place. Finally, test the connection on each device.

You can start with automatic updates every 24 hours. This is a convenient default, not a protocol requirement. Adjust the interval if the service limits request frequency. Mobile operating systems may restrict background tasks, so setting an update schedule in the client does not guarantee downloads will run on time when the app is closed.

One account doesn't always mean one identical URL

Some services provide different subscription formats for Clash, mihomo, or other clients. You can use the same account and node source on a computer running a mihomo config and a phone using a different format, but use a compatible link for each. Don't import fields a client can't recognize just to make the URLs match.

A successful subscription update does not mean local changes have synced. Direct edits to a downloaded YAML file may be overwritten by the next update. Keep long-term rules in a client-supported override, merge, or script configuration. Feature names and merge order vary between clients.

Method 2: Sync config files through cloud storage

Cloud storage works well for transferring a specific file, but it does not automatically manage a client's internal database. Create a dedicated config folder for the YAML files and rule notes you intend to share. Don't sync the entire client data directory: databases, lock files, caches, and device-specific paths may make the files unusable elsewhere.

Follow the export, download, import, and verify workflow

1. On the primary editing device, export the config you want to share as shared-rules-2026-09-16.yaml. Including the date makes snapshots easier to distinguish.
2. Upload it to a cloud folder with restricted access and wait for the upload to finish.
3. Download the file to the other device and load it using the client's file import feature. Don't use a cloud sharing page URL as the YAML download URL.
4. Check the YAML indentation, proxy group names, and local paths, then start the config and review the logs.

Mobile file pickers often copy files into an app's private storage. Changes to the cloud copy may not update that imported file. Refreshes work only if the client explicitly supports reading a specified file or remote URL continuously. Importing a file is not two-way sync.

If you use a cloud link as a remote config URL, check its access permissions, redirects, and response content. Login and sharing pages usually return HTML, not YAML, and temporary signed links may expire. Don't make a config containing subscription credentials publicly accessible just so the client can download it.

Method 3: Back up and restore with WebDAV

WebDAV provides remote file access, but it does not understand Clash configs automatically. You can upload or restore a backup in the app only if the client implements WebDAV backup support. A regular WebDAV drive and a subscription URL are different things and cannot replace each other.

Check what's included in the backup, then restore it on the second device

• Connection details: Use the HTTPS WebDAV URL, username, and dedicated app password provided by your service. A dedicated folder for the client is recommended.
• Backup contents: Check whether the backup includes subscription URLs, config files, overrides, UI settings, and proxy group selections. “Backup complete” does not necessarily mean all data was saved.
• Restore compatibility: Restore between the same client and compatible versions whenever possible. Even if two apps both use mihomo, their backup archives may have different formats.
• Overwrite risk: Export the current config from the target device before restoring. A restore may replace local settings rather than merge individual fields.

Don't assume a backup from a Windows client will work on Android, or that an iOS client can read it. If the client has no WebDAV option, you can use an external file tool to transfer YAML, but that is still a file import workflow and won't restore app settings.

WebDAV is better suited to moving from an old computer to a new one than to keeping the selected node in sync between a phone and computer in real time. If the tool only offers upload, download, and restore, treat it as snapshot backup—not continuous background sync.

What to keep different on each platform

Clash is a name used across a config and core ecosystem, not one identical app on every platform. Whether mihomo-specific fields work depends on both the core and how the client handles them. An iOS app supporting a particular subscription format does not mean it supports every TUN, DNS, or process rule option in a desktop config.

A desktop client listening on 127.0.0.1:7890 serves local connections on that computer only. If you import the same config on a phone, 127.0.0.1 points to the phone, not the computer. Syncing a subscription across devices does not require enabling allow-lan or exposing the control interface to your local network.

Android usually routes traffic through the system VPN service; desktop clients may use the system proxy or TUN. See the system proxy guide for desktop setup and the Android setup guide for configuring traffic routing on Android.

Rule overrides: share routing logic, keep device settings separate

What works well across devices is the intent behind domain routing—for example, sending one domain direct and another through a specific proxy group. Keep ports, TUN, DNS listen addresses, and per-app routing at the device level. Align proxy group names before sharing rules that reference them, or a rule may fail to find its target group on another device.

Check rule order and target names first

The example below shows the structure of the rules section in a complete config. Proxy must match an existing proxy or policy group, and the example domains should be adapted to your needs. This is not a universal file you can paste into every client's override field.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-SUFFIX,example.net,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

Rules are usually evaluated from top to bottom, and the first match determines the policy. MATCH is the fallback rule and should be last. If a client appends new rules after an existing MATCH, connections will never reach them. Use the prepend method explicitly supported by that client.

Array merges don't always append

Some override mechanisms replace the entire rules array; others support merging at the beginning or end, while some use scripts to modify the config object. Don't copy an override file directly into a different client's override field. Move the rule content, then format it for the target client.

1. Maintain a domain rule list on the primary editing device and note which proxy group each rule uses.
2. Inject the rules on each device using its supported method, while keeping that device's traffic routing settings intact.
3. Update the subscription, then inspect the effective config to make sure the rules haven't been overwritten or placed after a fallback rule.
4. Visit a target domain and check the logs or connection details to confirm the matched rule type and final policy.

Don't blindly sync all DNS Fake-IP settings or filter lists across devices. Local network discovery, specific apps, and network conditions may require different settings on a phone. Before making changes, save the current config and use the logs to guide adjustments. Desktop DNS settings are not a universal default for every device.

After syncing: check updates, rules, privacy, and rollback

Use these four checks to verify the sync

• Same source: Confirm both devices use the same account and compatible subscription formats, not two old configs with the same name.
• Updates work: Run a manual update and check for authentication failures, timeouts, or parsing errors.
• Custom rules work: Check rule order and proxy group names, then verify the actual match in the connection details.
• Traffic routing is set up correctly: Check the system proxy or TUN on the computer, and VPN status and app exclusions on the phone.

If one device works and the other doesn't, compare the effective configs and logs before repeatedly changing subscription links. The same source can produce different parsing results if clients support different fields. If the subscription updates successfully but the target app doesn't use the proxy, check whether its traffic is reaching the core.

Treat subscription URLs like access credentials

Subscription links often contain account tokens. Sharing a full config, screenshot, cloud file, or backup may expose the URL along with it. Prefer restricted folders and dedicated app passwords. If backups support encryption, check that it covers the entire file. HTTPS protects data in transit; it does not mean the backup file is encrypted at rest.

For everyday use across devices, import the subscription directly on each one, maintain custom rules from a single source, keep readable snapshots in cloud storage, and use WebDAV to back up and restore between compatible clients. After each change, check three things: the update succeeded, the rules matched, and the device routed traffic correctly. This makes it easier to separate sync issues from network problems.