Clash Multi-Device Configuration Sync: Subscription URLs, WebDAV, and Manual Export Compared

Separate three types of data: configuration, backups, and runtime state

Clash “sync” is not a single universal switch. Subscription URLs distribute remote configuration, WebDAV usually stores client backups, and manual export handles one-time file migration. Each method covers different data, and none guarantees an identical runtime environment on every device.

Proxy nodes, proxy groups, domain rules, rule-set URLs, and baseline DNS policies are the parts best suited to cross-device sharing. The system proxy toggle, TUN permissions, launch-at-startup setting, currently selected node, latency results, logs, and UI preferences are local device state and should be managed separately on each device.

Option 1: Distribute configuration centrally with a subscription URL

A subscription URL is the lowest-maintenance approach. The primary configuration lives on the server or subscription converter; each device stores the same address and fetches updates on a schedule. When the source changes, edit it once and refresh each device.

Standard import workflow

1. In the desktop client, open “Configuration” or “Profiles” and choose “Import from URL.”
2. Paste the subscription URL, name the configuration—for example, “Daily Rules”—and download it.
3. In a Clash Meta-based Android client, open “Configuration” → “New Configuration” → “URL” and enter the same address.
4. Set the auto-update interval to 1,440 minutes. If you adjust rules frequently, use 360 minutes, but polling every few minutes is unnecessary.
5. After refreshing, check the proxy groups, rule count, and update time, then make this configuration active.

Menu names vary slightly between clients, but the essential actions are the same: save the URL, fetch the YAML, and enable the downloaded configuration. If the client offers both “local configuration” and “remote configuration,” choose the remote option or source changes will not be fetched automatically.

Limits of subscription sync

A remote subscription usually overwrites direct local edits to that configuration file. For example, a rule added temporarily on a phone may disappear after the next refresh. Long-term rules should be added to the subscription source or layered through the client’s Merge, Mixin, or override script features.

Override support is not completely interchangeable. Rule providers, rule-set formats, and some DNS fields supported by mihomo may not be recognized by older Clash cores. When generating configurations for different clients, stick to commonly supported base fields and separate platform-specific options.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

The basic structure above works across most mihomo clients, but ports, LAN access, and DNS behavior should still be adjusted per device. Phones generally do not need an open LAN port; a desktop acting as a home gateway may need LAN access enabled, with the listen address and firewall scope restricted.

Option 2: Store full backups with WebDAV

WebDAV is better understood as “upload a backup and restore it when needed” than as real-time collaboration. Clients that support it package the configuration, overrides, and some preferences into a remote directory. Another device can download the backup, but the clients usually need to be from the same product family and support a compatible format.

For example, an Android client’s backup may include an app database, configuration indexes, and local files that a desktop client cannot parse directly. Even when two clients use the mihomo core, their surrounding application data structures may be completely different. The safest use of WebDAV is restoring between similar devices running the same client—not syncing arbitrary Clash clients.

Recommended directory structure and naming

Do not let multiple devices continually overwrite the same file. Split directories by client and device, and include the date in each filename:

clash-backups/
├── android-phone/
│   └── backup-2026-08-11.zip
├── android-tablet/
│   └── backup-2026-08-11.zip
└── desktop/
    └── backup-2026-08-11.zip

When configuring WebDAV, first create a dedicated directory in the cloud, then open “Settings” → “Backup & Restore” or “Settings” → “WebDAV” in the client. Enter the server address, username, password, and remote path in order. After uploading, open the remote directory immediately and confirm that the file timestamp and size have changed.

Create a local snapshot before restoring

1. Record the name and update time of the configuration currently in use.
2. Export a local backup first so an older remote file cannot overwrite newer settings.
3. Check which device and client version produced the remote file.
4. After restoring, fully quit the client and start it again.
5. Check the subscription URL, override rules, DNS mode, and TUN toggle—do not inspect only the node list.

When two devices both upload automatically, the most common problem is that the last writer overwrites the previous backup. WebDAV itself usually does not understand Clash configuration or merge it field by field. If a phone uploads at 9:00 PM and a tablet at 9:05 PM, the latter may simply replace the former.

Option 3: Manual export and import

Manual migration is the most transparent and easiest to audit. It works well when changing devices, making a temporary copy of a stable configuration, moving to a client without WebDAV support, or removing sensitive fields before import. The drawback is that every change requires another export, so consistency is not automatic.

Do not copy only one YAML file

A simple configuration may contain only one YAML file, but complex setups can also reference rule sets, scripts, and local certificates. Before exporting, search for these fields: rule-providers, proxy-providers, script, tls, and path. If a field points to a local relative path, migrate the referenced file as well.

profiles/
├── main.yaml
├── providers/
│   ├── proxy.yaml
│   └── direct.yaml
└── rules/
    ├── private.yaml
    └── streaming.yaml

After importing on another device, do not overwrite the original configuration immediately. Load it under a name such as “Migration Test” and confirm that the client can parse it. A “file not found” message usually means an external file is missing; “field not found” or “unsupported field” more often indicates an incompatible core version or configuration format.

Manual migration checklist

1. Confirm that the target client uses a mihomo-compatible core and check its core version.
2. Run configuration validation after importing the YAML to catch indentation and field errors.
3. Open the proxy groups and confirm that the node count matches the source device.
4. Switch the mode to “Rules” and check that the final fallback rule is MATCH.
5. Visit one direct-connection site and one proxied site, then review the rule matches in the connection log.
6. Enable the system proxy or TUN only at the end, so an invalid configuration does not take over the entire network.

Manual export has another advantage: you can remove fields that do not suit the target device before migrating. For example, external-controller: 127.0.0.1:9090, LAN listening, and fixed paths from a desktop configuration are usually unnecessary on a phone. Android VPN and TUN permissions must also be granted again by the system; copying the configuration cannot bypass authorization.

Five settings most likely to conflict across platforms

1. Ports and the system proxy

Desktop clients commonly use 7890 for the mixed HTTP/SOCKS port and 9090 for the controller port, but the actual values depend on the client’s current settings. When copying a configuration to a computer that already runs proxy software, 7890 may be occupied. Close the conflicting application or change the mixed port to an unused value such as 7891 or 7892, then update the system proxy settings accordingly.

2. TUN mode

TUN is a device-level capability. Windows may require a service installation or administrator privileges for first-time activation; macOS requests network-extension authorization; Android creates the tunnel through the system VPN interface. The same YAML can include TUN parameters, but authorization, routing tables, and excluded-app lists do not sync through a subscription.

3. DNS and Fake-IP

Fake-IP lets the core obtain domain information earlier and apply rules, but some LAN device discovery, printing services, and special apps may need to be added to the filter list. Phones and home computers use different networks, so do not blindly copy every filter entry. If LAN domains fail to resolve, first compare the result with Fake-IP disabled, then adjust fake-ip-filter.

4. Local paths

Windows paths may include drive letters, while Android and macOS use different app directories. Absolute paths in a configuration are therefore prone to fail during cross-platform imports. Prefer remote URLs for rule files; when a local file is required, use a relative path under the client’s configuration directory.

5. Node selection and proxy-group state

Some clients remember the last selected node for each proxy group, but that state may be stored in a local database rather than in the YAML. After syncing a configuration, it is normal for the phone and computer to select different nodes. Mobile networks and fixed broadband also have different latency, so test each one and choose accordingly.

How to choose among the three options

With only two or three devices and configuration that mainly comes from a remote subscription, using the same URL is simplest. If you need to preserve client preferences, override scripts, and configuration history, add WebDAV backups alongside the subscription. For a device replacement or cross-client migration, use manual export as a controlled intermediate format.

The safer combination is “subscription first, backup second, manual export as a fallback.” Use the subscription for routine updates; save WebDAV snapshots weekly or before major changes; use manual export for core upgrades, device replacement, and recovery. Even if a remote backup is overwritten, the core configuration can still be retrieved from the subscription.

Complete a ten-minute post-migration check

1. Confirm that the configuration update time, node count, and proxy-group count match the source.
2. Check the client log for YAML parse errors or failed rule-set downloads.
3. Run one latency test for a direct node and one for a proxy node, and record the actual usable results.
4. Open a site that should connect directly and confirm that it matches DIRECT or the appropriate direct-connection group.
5. Open a site that should use a proxy and confirm that it matches the intended rule and proxy group.
6. Switch between Wi-Fi and mobile data and verify that DNS and TUN can both reconnect.
7. Restart the client and confirm that the intended configuration remains selected and the auto-update interval is still correct.
8. Restart the device and check that the system proxy, persistent VPN, or startup behavior matches the device’s needs.

If nodes appear normally after refreshing the subscription but no websites open, check DNS, the system proxy port, and TUN conflicts first instead of repeatedly importing the configuration. If only some domains fail, inspect rule matches and DNS query results in the connection log to determine whether the issue is resolution, rule matching, or node connectivity.

The key to multi-device sync is not copying more files, but defining what the subscription maintains, what belongs in a client backup, and what must be configured again per device. With those boundaries clear, phones, computers, and tablets can share the same rule logic while retaining their own network permissions and runtime settings.