3 Ways to Keep Clash Configs in Sync Across Devices: Subscriptions, WebDAV, Manual Export

Why multi-device configs drift apart

It's now common to access the network from a Windows PC, an Android phone, an iPad, and even a macOS laptop at the same time. The Clash clients installed on each device operate independently — config files, node lists, and rule sets are all stored locally, with no built-in awareness of each other. If you tweak a routing rule on your PC, your phone won't automatically pick it up; if you add a new subscription on your phone, your PC won't see it either. Over time, proxy behavior on different devices gradually "drifts": the same site loads fine on the PC but not on the phone, or one device keeps connecting to a node that expired long ago.

The root cause isn't a software bug — it's how config data is stored in the first place. Clash-family clients (whether built on the original Clash core or the Clash Meta / mihomo core) save configs as local files, typically a YAML config.yaml containing proxy nodes, rule sets, group policies, and more. Since the file lives on local disk, it has no cross-device reach by default — you need an extra mechanism to move it to other devices, or have multiple devices read from the same source.

The three sections below cover the most common approaches, organized by "how often the config changes" and "how much manual work is involved": centralized subscription links, built-in WebDAV backup/sync, and manual config export. These aren't mutually exclusive — many people combine all three, using subscriptions for day-to-day nodes, WebDAV as a full-machine safety net, and manual export for an offline archive copy.

Option 1: Centralized subscription links

Subscription links are the most common sync method today. The idea is simple: a service provider hosts a remote URL that describes a node list (sometimes rules too) in a fixed format; the Clash client periodically requests that URL and parses the response into a local config. As long as multiple devices are pointed at the same subscription link, they should in theory end up with the same set of nodes.

1. Add the same subscription link on every device's client

   The wording differs slightly between clients, but the flow is basically the same: find the "Subscriptions," "Profiles," or similar entry, paste the link, then download or import it.

2. Set an auto-update interval

   Most clients support scheduled subscription refreshes, commonly defaulting to every 24 hours. You can shorten the interval, or just tap "Update" manually each time you open the client.

3. Verify node counts and groups match

   After updating, it's worth opening the node list on two devices side by side to confirm the counts and group names line up, so parsing differences don't leave a device missing some nodes.

The advantage of subscription links is being "lightweight": no extra software, no local storage overhead, and updates are passive and automatic, needing almost no manual intervention. The limitation is just as clear — subscriptions usually cover only nodes and some rules; personalized settings like custom routing rules, DNS settings, or TUN mode parameters typically aren't included and stay maintained locally instead. In other words, subscriptions keep nodes consistent — not the entire config.

Option 2: Built-in WebDAV backup sync

Some mainstream clients (for example, Clash Verge Rev and other desktop clients built on the mihomo core) include a built-in WebDAV backup feature that packages the full config file, subscription list, and UI preferences and uploads them to a WebDAV server, so they can be downloaded and restored on other devices from the same address. Compared to subscription links, WebDAV backup works at a coarser granularity — essentially a "full-machine snapshot" — and can restore a more complete config state than a node list alone.

1. Prepare a WebDAV service address

   This can be a self-hosted WebDAV service or a cloud storage service that supports the WebDAV protocol. Note down the address, username, and password.

2. Enter the WebDAV info in the client's backup settings

   Find the "Backup," "Sync," or "WebDAV" section, fill in the address and credentials, then run "Upload Backup" once to confirm there are no errors.

3. Run "Download and Restore" on another device

   Enter the same account info in the client on another device, choose "Restore from WebDAV," wait for the download to finish, then restart the client for the config to take effect.

The benefit of the WebDAV approach is convenient "bulk relocation" — especially handy when setting up a new device or after reinstalling the OS, letting you skip reconfiguring everything item by item. But it has a natural limitation: it usually only works between desktop clients that support the feature, and mobile clients (Android, iOS) may not support the same WebDAV backup format, so cross-platform restores need to confirm the target client is compatible with the backup file structure first. Also, backups are snapshots triggered manually or on a schedule, not real-time sync — if you forget to re-backup after making changes, restoring will still bring back an older version.

Option 3: Manual config export and import

The most basic but also most direct approach is copying config.yaml or a client-exported config package straight to another device. Most clients offer an "Export Config" or "Open Config Folder" entry that lets you locate the locally saved YAML file, transfer it via USB drive, LAN sharing, or a cloud sync folder, and then load it on the target device using that client's "Import Config" feature.

1. Locate the config file

   In the client's settings, find "Open Config Folder" or a similar entry — you'll usually see the currently active YAML file along with subscription cache files.

2. Copy the file to the target device

   Use any transfer method (LAN share, cloud storage, USB cable) to place the file somewhere accessible on the target device.

3. Import it on the target client

   Use "Import Config from File," select the file, wait for the client to finish parsing, and check that nodes and rules load correctly.

This method doesn't rely on any network service and works offline, making it a good fit for setups with heavily hand-tuned configs where you'd rather not depend on a third-party WebDAV service. It's also commonly used for one-off config migrations or offline archiving. The downside is just as plain: it's entirely manual, changes don't propagate to other devices automatically, and it's easy to miss an update once you have several devices. Different clients also support YAML fields to slightly different degrees — some desktop-only group policy fields may not parse correctly on mobile clients, so it's worth double-checking everything after import.

Choosing between the three: quick reference

In practice, all three are often combined rather than chosen exclusively. A fairly reliable setup: rely on subscription links to keep nodes fresh day to day, run a periodic WebDAV backup as insurance against losing the config unexpectedly, and manually export a YAML archive before any major change. With three layers of protection stacked together, there's always a fallback if one layer fails.

Troubleshooting after syncing

Even with a solid approach in place, you might still run into a config that "doesn't seem to take effect" after syncing. Here are a few common things to check:

• Confirm the client actually reloaded the config. After importing or updating a config, some clients require you to manually tap "Apply" or restart the core before it takes effect — not every field hot-reloads automatically.
• Check whether the subscription parsing got cut off. If the subscription response is too large or contains fields the client doesn't support, parsing may fail partway through, leaving the node list looking "short." Check the client's logs or update history to confirm the actual error.
• Verify system-level settings like TUN mode carried over with the config. TUN mode involves a virtual network adapter and the system routing table; some clients store this setting in app-level preferences rather than the YAML config file, so syncing just the config file won't carry the TUN toggle state — check it separately on the new device.
• Watch for rule syntax differences between mobile and desktop. If a rule set references a local file path (rather than a remote rule-set URL), that path is likely to break once moved to another device. Prefer remote rule sets over local file references to reduce path dependencies during migration.

Summary

Config inconsistency across devices is, at its core, a mismatch between "local files" and "multiple devices." Subscription links handle automatic sync at the node level, WebDAV backup provides full-machine snapshot-style migration, and manual export is the most basic but most controllable offline option. None of them is a universal fix — combining them based on how often you use each device, how many devices you have, and how much you rely on custom rules is what actually keeps proxy behavior consistent across the board.