Sync Clash Config Across Multiple Devices: Subscription Links, WebDAV & Manual Export

"My config is out of sync across devices" is one of the most common tickets we see — nothing critical, but it's a constant drain: nodes work on one device and not another, rules apply here but not there. Before you go swapping nodes, let's diagnose the actual problem and pick the right fix.

Symptoms: Why Multi-Device Config Drifts Over Time

If you run Clash on a PC, phone, and tablet at once, the complaints usually boil down to three patterns:

• Nodes out of sync: your subscription just updated on the main device, but the new nodes are nowhere to be found on another device — while stale ones there have already stopped working.
• Rules don't match: you added a direct-connect rule for a site on one device, then the same site gets proxied on another — and it takes forever to remember the change never carried over.
• Sudden mass disconnects: you renewed your subscription or switched plans and only updated one device, then every other device drops connection one by one — easy to mistake for all nodes going down at once.

The root cause is simple: Clash config (Profiles) is stored as local files on each device, and clients have no idea what the others are doing. Whichever device you hit "update" on gets the latest data; the ones you didn't touch keep running the old version until nodes eventually die. There are really only two cures: make config come from a single source, or keep every device in sync on a schedule. The three fixes below match three levels of severity.

Fix #1: Distribute via a Single Subscription Link

Best for: nodes and rules mostly come from your subscription, you rarely make custom edits, and you have three or more devices. This is the lowest-maintenance option and the right call for most people.

The idea: add the exact same subscription URL on every device, then let each one auto-update on its own schedule. Since the config content lives on the subscription server, every device pulls the same data — there's no "who forgot to sync" problem by design.

Steps:

1. On each device's client, create a remote profile using the same subscription URL, and give it the same name everywhere so you can cross-check it later.
2. Turn on auto-update: Clash Verge Rev lets you set an update interval per subscription entry, and most mihomo-based mobile clients support scheduled refresh too. 24 hours is a good default — too frequent wastes requests, too sparse means node changes lag behind.
3. If the raw subscription doesn't quite fit as-is (you need custom rules or group tweaks applied everywhere), handle that once at the subscription-conversion layer, and point every device at the same converted link. Future changes only need to be made in one place.

Don't do this: never edit the config file generated by your subscription directly — it gets overwritten on the next update. Instead, make custom changes through your client's override mechanism: Clash Verge Rev has global Merge/Script overrides, while mihomo configs should keep custom sections separate from the subscription section. That way the subscription keeps updating and your changes still apply.

Fix #2: WebDAV Sync

Best for: heavy customization — hand-written rules, multiple local profiles running in parallel — where you want to edit once and have it apply everywhere.

Multi-platform clients like FlClash have built-in WebDAV sync, and some desktop clients offer a WebDAV backup option too. The idea is the same everywhere: package up your config directory and upload it to a WebDAV account, then pull it down and restore on other devices. Jianguoyun (Nutstore), Nextcloud, and Synology NAS can all serve as your WebDAV storage.

Steps:

1. Set up a WebDAV account first: for Nutstore, enable a third-party app password in security settings; for self-hosted Nextcloud, note down the server address, username, and password.
2. On your main device, enter the WebDAV details in the client and run a backup upload once.
3. On every other device, enter the same account details and run a restore/download. After that, upload again whenever you make a significant change; clients that support auto-sync can be set to run on a schedule.

Three things to watch out for:

• WebDAV syncs config files, not runtime state. After restoring, you still need to reselect the active profile, re-run latency tests, and re-confirm the proxy mode.
• Most implementations follow a "last write wins" model. If two devices make changes and sync in sequence, whichever was written first gets overwritten. Get into the habit of a fixed routine: upload right after editing, pull right before using.
• Your config contains subscription URLs and node credentials, so treat your WebDAV account with the same level of security as the proxy account itself — use a dedicated password, and turn on two-factor authentication if it's available.

After restoring, verify connectivity with one command before you rely on it:

Fix #3: Manual Export & Import

Best for: just one or two devices, infrequent changes, or a one-time migration when switching devices or reinstalling the OS. The lightest-weight option, and anyone can pull it off.

The idea: copy the config file straight from one device to another. Desktop clients usually offer an export option in the profile management page, or you can grab the YAML file directly from the config directory; mobile clients typically offer a share or export feature — transfer it over local network, cloud storage, or a cable, whatever's easiest.

Steps:

1. Export the config on the source device: for Clash Verge Rev, the config directory is usually a profiles folder under the system's app data directory, with one YAML file per subscription; clients like FlClash provide a direct export option in settings.
2. Transfer the YAML file to the target device, then choose "Import local file" in the client.
3. After importing, double-check the port settings — if mixed-port or the external controller port conflicts or differs between the two devices, change it back to match the target device's usual setup.
4. Double-check the subscription update URL: if the YAML came from a subscription update, it's just a static snapshot on the target device — you'll need to re-add the subscription link there for future updates, or repeat this process periodically.

Note

A manual export is a snapshot frozen in time. It's fine for migrating to a new device, but not for staying in sync long-term — devices will gradually drift apart again over time.

Choosing the Right Fix: A Quick Comparison

Each option suits a different situation — pick based on device count, how often you make changes, and how much you rely on a subscription:

Combining methods is common too: use a subscription link as the baseline to keep nodes fresh, and WebDAV or manual export to carry over custom rules and local configs. The two don't conflict — each handles its own part.

After You Sync: A Few Things to Keep in Mind

Once you've picked a fix, a few more notes so syncing doesn't end up making things messier:

• Keep ports consistent: try to keep mixed-port (default 7890) the same across devices, so browser proxy settings and command-line tools can use one shared config.
• Check the mode after switching devices: Rule, Global, and Direct modes are local, per-device state — they don't travel with the config. Confirm the mode first before troubleshooting anything else.
• Don't let core versions drift too far apart: newer mihomo config fields (like certain sniffing syntax) may error out on an older core. When sharing one YAML file across devices, write it to match the syntax supported by the oldest client version in use.
• TUN mode and system proxy are device-level settings: they don't travel with the config file — enable them individually on each device as needed, and don't assume turning one on applies everywhere.
• Back up before big changes: export a copy of your current config before making major rule changes. Sync mechanisms will faithfully spread mistakes to every device just as reliably as they spread fixes.

Multi-device setups aren't really a technical problem — they're an organizational one: pick one source of truth for your config, stick to an update routine, and let the client handle the rest on schedule. Once the source drifts, no amount of tooling can fix it after the fact.