How to Sync Clash Configurations Across Devices: Subscription Links, WebDAV, and Manual Export

First, identify which layer needs syncing

Clash “configuration” is not a single file. Computers and phones may display the same nodes, rules, and proxy groups, but the data can come from a remote subscription or be stored in the client’s own database. Before syncing, separate the data into three layers to make the right approach much easier to choose.

Core configuration: nodes, proxy groups, rules, and DNS

Core configuration is usually a YAML file containing fields such as proxies, proxy-groups, rules, and dns. The mihomo core also supports rule-providers, proxy-providers, sniffer, and more complete TUN parameters. This layer is best distributed centrally through a subscription link.

mixed-port: 7890
mode: rule
allow-lan: false

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

proxy-groups:
  - name: Node Selection
    type: select
    proxies:
      - Auto Select
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,Node Selection
  - GEOIP,CN,DIRECT
  - MATCH,Node Selection

Client settings: system proxy, TUN, and startup behavior

Options such as “Connect on startup,” “Launch at login,” “System Proxy,” and “Allow LAN” are usually local client settings. Even when two devices import the same YAML, these switches may not sync. Enabling the system proxy on Windows does not automatically establish a VPN on Android or iOS; macOS TUN permissions cannot be copied to another device through a config file.

Runtime state: current node and latency history

The currently selected node, latest latency test, logs, and traffic statistics are usually runtime state. They may be stored in the client database or reset after a restart. Treating them as sync targets often results in “identical configs, different interfaces.” A more reliable approach is to sync the proxy-group structure and let each device test and select nodes independently.

Approach 1: Distribute everything through a subscription link

Subscription links work well for two or more devices over the long term and are the easiest way to maintain rules. Keep one master config on a server, then add the same subscription URL on each computer, phone, and tablet. When rules change, edit the source once and have every device update it.

Recommended workflow

1. Prepare the master config in a trusted subscription manager and confirm that the target core can load the YAML.
2. On a desktop client, open “Profiles” → “New Profile” or “Config” → “Subscription,” then paste the HTTPS URL.
3. On a mobile client, open “Profiles” → “Import from URL,” enter the same address, and save it.
4. Set the update interval. 1,440 minutes works for routine use; use 360 minutes when rules change frequently.
5. After the first update, check the number of proxy groups and rules, the DNS mode, and the last-updated time.

Menu names vary between clients. Some desktop apps use “Profiles” → “New” → “URL,” while some mobile apps place the entry point behind the plus button in the upper-right corner of “Profiles.” Do not judge success by “Update complete” alone: open the config details, confirm the file size is not 0 KB, and check for YAML parsing errors.

Keep device-specific differences local

Do not force every device’s local parameters into the same subscription. A desktop may need mixed-port: 7890, while a mobile device routes traffic through the system VPN interface and does not use that port. TUN interface names, routing permissions, and DNS hijacking methods also vary by platform.

A more reliable structure is to let the remote subscription handle nodes, proxy groups, rule sets, and shared DNS policy, while each device stores its own system proxy, TUN, LAN access, and startup settings. If the client supports overrides or Mixin, add only a few local parameters instead of duplicating the entire master config.

# Master config handles shared logic
mode: rule
log-level: info

rule-providers:
  private:
    type: http
    behavior: domain
    format: yaml
    interval: 86400
    url: https://config.example.net/rules/private.yaml
    path: ./ruleset/private.yaml

Limits of the subscription approach

• Requires network access: The new device must be able to reach the subscription URL during its first import, or it cannot retrieve the config.
• Updates may overwrite local edits: Direct changes to a downloaded subscription file are usually replaced by the remote version at the next refresh.
• Protect the URL itself: A subscription URL may contain an access token. Do not put it in a public repository, screenshot, or group chat.
• Clients may convert configs differently: Some clients automatically convert fields, while others parse the original YAML strictly.

Approach 2: Use WebDAV for backup and restore

WebDAV is more like saving a client snapshot than editing one YAML file in real time. Clients with WebDAV support typically upload configs, preferences, or backup packages to a remote directory, then let another device download and restore them. It works well for device replacement and migration within the same client, but cross-platform compatibility depends on what the backup contains.

Confirm exactly what the client backs up

Some clients upload only the subscription list; others also save local configs, proxy-group selections, and app settings. Some offer only manual import and export and have no WebDAV support. Before proceeding, open “Settings” → “Backup & Restore” or “Settings” → “WebDAV” and check whether the documentation covers subscriptions, overrides, rules, and local preferences.

If the backup includes the client database, it can usually be restored only to the same app or a compatible version. For example, a database created by version 2.1.0 may not be readable by another mihomo GUI client. Even when both clients use the mihomo core, their interface-layer data structures may still differ.

Recommended WebDAV workflow

1. On the first device, open “Settings” → “Backup & Restore” → “WebDAV.”
2. Enter the HTTPS server URL, username, app password, and remote directory.
3. Click “Test Connection.” After it succeeds, create a manual backup.
4. Record the backup time and file size. For example, a normal backup might be 428 KB; if the new file is only 2 KB, check whether its contents are complete.
5. Install the same client on the second device, keeping the system proxy or VPN disabled for now.
6. Connect to the same WebDAV directory, select the newly created backup, and restore it.
7. After restoring, reauthorize the VPN, TUN, or system proxy, then test rule matching.

A WebDAV URL may require the server root path or the complete directory path. For example, if the server entry point is https://dav.example.net/remote.php/dav/files/user/ and the client automatically appends the username, the resulting duplicate path may return HTTP 404. HTTP 401 usually indicates an incorrect account or app password; HTTP 403 commonly means the directory is not writable.

Prevent the two devices from overwriting each other

WebDAV does not always merge configuration conflicts. If a computer uploads at 10:20 and a phone uploads an older config at 10:23, the newest server file may actually be missing recently added rules. A safer method is to designate one primary device for uploads while other devices restore only, or create separate directories by device name.

/ClashBackup/
  desktop-main/
    backup-2026-06-20.zip
  macbook/
    backup-2026-06-20.zip
  phone/
    backup-2026-06-20.zip

If the client supports version history, keep at least the three most recent copies. A mistaken overwrite will not immediately destroy every backup. Before restoring, export the current config as well, especially when the phone already has local overrides.

Approach 3: Manually export YAML or a backup file

Manual export is the most transparent option and gives you the clearest control over what changes. It requires no remote service and works well for two devices, infrequent config changes, or offline migration. Common locations include “Profiles” → “Open Config Directory,” “Profiles” → “Export,” or the share menu beside a profile entry.

A YAML export is not the same as a full backup

Exporting YAML usually carries only the core configuration. The system proxy switch, current node, client theme, keyboard shortcuts, and TUN permissions still need to be configured on the new device. A full backup may include more app state, but it is less portable across clients.

When moving from Windows to macOS, prefer exporting a standard YAML. When switching phones within the same app, use the app’s backup package if available. Do not copy the entire runtime directory: it may contain caches, logs, database lock files, and platform-specific paths.

Run four checks before importing

• Port conflict: If mixed-port: 7890 is occupied by another program, change it to 7891 and reload the config.
• Absolute paths: C:\Users\name\rules\local.yaml cannot be used directly on macOS or Android.
• Rule files: Check that any local files referenced by rule-providers are copied as well.
• Core fields: Confirm that the target client supports options such as geodata-mode, sniffer, and tun.

After importing, do not enable full TUN immediately. Start the core first, inspect the logs for configuration-load results, and run an initial test through the system proxy. Desktop clients commonly use 7890 for the HTTP/SOCKS mixed port and 9090 for the controller, but the config is authoritative.

Preserve version details in the filename

With manual copies, the most common problem is not losing a file but losing track of which one is newest. Include the date, device purpose, and revision number in the filename, such as clash-main-2026-06-20-r03.yaml. Change one topic at a time and keep a short note in the same directory.

2026-06-20 r03
- Add DIRECT rules for LAN traffic
- Change the Auto Select test interval to 300 seconds
- Keep Fake-IP mode
- Enable TUN locally on desktop; do not write it into the mobile master config

If both devices have edited the file, do not determine which is newer by file size alone. Compare proxy-groups, rule-providers, and rules section by section. Rules are matched from top to bottom, so changing their order can directly change where traffic goes.

How to choose between the three sync methods

The three approaches are not mutually exclusive. Subscriptions provide ongoing distribution, WebDAV preserves client state, and manual exports provide offline archives—a combination that better reflects real-world use. The comparison below focuses on maintenance effort and compatibility.

Two personal devices

If you use a computer and phone only occasionally and change rules once or twice a month, manually exporting YAML is usually enough. Update the date and revision number after each change, then import the file on the other device through the system file-sharing feature. If nodes come from a service subscription, maintain only overrides and custom rules manually.

Long-term use across a computer, phone, and tablet

Make the subscription link the primary source. Keep proxy-group names consistent—for example, use “Node Selection,” “Auto Select,” and “Failover” everywhere—so the interfaces are easier to compare. Use WebDAV only for client backups, not everyday rule editing.

Frequent reinstalls or testing multiple clients

Keep a standardized mihomo YAML as the baseline, rather than treating any one graphical client’s database as the sole source. Add client-specific features through local overrides. Export manually before each upgrade, and use WebDAV to retain the three most recent restorable snapshots.

Practical ways to keep rules consistent across platforms

Standardize proxy-group names to prevent broken rule targets

The policy name at the end of a rule must exactly match a proxy-group name. The master config may contain DOMAIN-SUFFIX,example.com,Node Selection, but if the mobile client renames the group to “Manual Selection,” loading may fail or traffic may not be routed as intended. Once names are established, avoid changing them on only one device.

Keep platform differences in the override layer

Keep nodes, rules, and basic DNS logic in the shared config, and put platform-specific parameters in local overrides. Windows can retain the 7890 mixed port and system proxy; macOS can use TUN subject to client authorization; Android and iOS let the app establish the VPN interface. This prevents subscription updates from repeatedly overwriting platform settings.

Use a fixed test checklist

Run the same checks after every sync; it usually takes three minutes to catch most problems:

1. Confirm that the config update time matches expectations.
2. Check that the number of proxy groups and the default selections match.
3. Run a latency test for the Auto Select group and record the number of available nodes.
4. Open the logs and confirm there are no yaml, provider, or dns-related errors.
5. Visit one site that should use DIRECT and another that should use the proxy, then verify the matched rules.
6. Turn the system proxy or VPN off and on again to confirm it remains effective after the config reloads.

When differences appear, check the update chain first

If rules work on one device but remain outdated on another, compare subscription update times first, then check whether the remote file is cached. With an automatic interval of 1,440 minutes, recent changes will not appear immediately; click “Update” manually. If the clients still differ, check for an older local config, overrides that modify rules, and unsupported fields skipped by the target core.

A setup that works long term

For most cross-platform users, use “subscription as the master config + local platform settings + regular manual backups.” The HTTPS subscription centralizes nodes, proxy groups, rules, and shared DNS; each device controls its own system proxy, TUN, VPN permissions, and startup behavior; before a major change, export a dated YAML copy.

If the client supports WebDAV, add it as a recovery layer: upload a backup weekly or before each upgrade, keeping only the latest three to five copies. WebDAV does not merge rules and does not replace the subscription. If a subscription update goes wrong, you can still roll back to a manual file or historical backup.

The goal of syncing is not to make every device look identical, but to keep rule intent consistent: the same domains should match the same policies, proxy groups should serve the same purposes, and platform-specific parameters should stay on their respective devices. Separating the master config from local state turns multi-device maintenance from “moving the whole house” into “moving only the drawers you need.”