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

Separate configuration sync, subscription updates, and client backups first

Clash syncing across devices is not a single switch. Windows, macOS, Android, and Linux clients may all use the mihomo core, but each client stores different data. The content that actually needs syncing usually falls into three layers: nodes and rules provided remotely, YAML configuration written locally, and the client’s own UI settings and runtime state.

These three data types should not be treated as the same

• Subscription content: This includes proxy nodes, proxy groups, rules, and provider definitions. The client downloads it again through a URL, making it suitable for centralized maintenance from one remote source.
• Core configuration: This includes YAML fields such as dns, tun, sniffer, listening ports, and rule-set URLs. Supported fields may vary between core versions.
• Client state: This includes the currently selected proxy node, theme, launch-at-startup setting, system proxy toggle, window size, and log level. These are usually stored in the client database or preferences and may not be included in the YAML file.

For example, enabling the system proxy on a computer and listening on 127.0.0.1:7890 is simply a runtime setting for the desktop client. Importing the same configuration into Android does not give the phone the same system proxy state; Android takes over traffic through its VPN interface instead. Likewise, a desktop TUN interface name, excluded routes, and administrator permissions should not be copied unchanged to a phone.

Record these four baselines before syncing

1. Check the core name and version used on each device, such as mihomo 1.19.x, to avoid having an older core reject newer fields.
2. Record the mixed port, controller port, and LAN listening settings. A common mixed port is 7890, and external controllers often use 127.0.0.1:9090, but follow the values in your current configuration.
3. Check for local absolute paths in the configuration, such as Windows C:\Users\... paths or Android private directories. These paths cannot be used directly across platforms.
4. Save a working copy of the current configuration and label it with the date, device, and client version, for example home-win-2026-08-16.yaml.

Option 1: Centrally manage nodes and rules with a subscription link

Subscription links are the lowest-effort option for multiple devices. Your computer and phone each save the same URL and fetch the latest content from the server when updates are needed. This is not file-to-file replication between devices; every device reads from the same source, avoiding conflicts over which copy is newest.

Typical import workflow

Using a typical client interface as an example, desktop clients usually go to “Subscription” → “New” → “URL,” enter the subscription address, and set an update interval. Android clients commonly use “Profiles” → “＋” → “Import from URL.” Menu labels vary by client version, but the core steps are the same: save the URL, download the configuration, select it, and start the core.

1. Import the subscription on the first device, confirm that the download succeeds, and check the node count and proxy group names.
2. Switch to Rule mode and test one direct-connection site and one site that requires a proxy.
3. Import the same URL on the second device. Do not copy the cache file generated by the first device beforehand.
4. Set update intervals independently. For everyday use, updating every 1440 minutes is reasonable; if nodes change frequently, reduce it to 360 minutes. There is no need to make requests every few minutes.
5. After updating, review the client log to confirm both the response status and configuration parsing succeeded.

Subscription approach: advantages and limitations

The most common mistake is editing the YAML downloaded from a subscription directly. Many clients treat this file as a remote cache and overwrite local changes when you click “Update.” DNS, rule, or proxy-group changes that must persist should go into a client-supported override, extension script, or merged configuration. If the client offers none of these, maintain a separate configuration instead of treating the subscription cache as the master file.

Split changing content with providers

Users comfortable with YAML can keep the main configuration stable and place nodes or rules in remote providers. The structure below shows the basic relationship; replace the URL and path with locations that are actually accessible:

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

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.net/profile/nodes.yaml"
    path: "./providers/remote-nodes.yaml"
    interval: 21600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

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

interval: 21600 means the node provider is checked every 6 hours, while 86400 for rules means once per day. The provider’s local path is a cache location and should not depend on an absolute directory from one device. mihomo support for format, rule behavior, and provider fields may vary by version, so check the parsing log after import.

Option 2: Back up and restore with WebDAV

WebDAV is closer to “package client data on a remote server, then restore it on another device.” It works well for storing multiple configurations, override scripts, rule files, and some client preferences, provided both clients implement a compatible WebDAV backup format. WebDAV defines file access methods, not a single backup structure that every Clash client must use.

When WebDAV is a good fit

• Migrating the same client between two desktop devices, such as moving from an old computer to a new one.
• Preserving multiple configuration files, scripts, and client settings—not just a node subscription.
• Keeping regular restore points so you can roll back to yesterday’s or last week’s version after a bad configuration change.
• Using a remote service that supports HTTPS, separate accounts, and file version history.

If the client supports this feature, the entry is usually under “Settings” → “Backup & Restore” → “WebDAV” or “Settings” → “Data” → “WebDAV.” Enter the server address, username, password, and remote directory, then run “Test connection” before creating the first backup. The address may be the service root or a complete directory, such as https://dav.example.net/remote.php/dav/files/user/clash/; follow the server’s documentation for the exact format.

A safe first-sync sequence

1. On the primary device, disable automatic restore and manually create a remote backup with a timestamp.
2. Sign in to the WebDAV service, confirm that the file was created, and record its size. For example, a normal backup might be 2.8 MB; if it is only a few dozen bytes, check whether an error page was uploaded.
3. Install the same major client version on the second device, then configure the WebDAV connection.
4. Download the backup list first. Do not immediately enable two-way automatic sync.
5. Restore from a clearly identified point in time, restart the client, then check the subscription, rule mode, DNS, and TUN toggle one by one.
6. After confirming that the second device works normally, decide whether to enable scheduled backups.

When the connection fails, narrow down the cause using the HTTP status: 401 usually means the credentials were rejected, 403 means the account lacks directory permissions, 404 commonly indicates an incorrect path, 409 may mean the parent directory has not been created, and 507 means the remote storage is full. If the client only shows “Backup failed,” also check the WebDAV server log.

WebDAV is not real-time two-way merging

If your computer and phone both edit the same configuration and upload it under the same filename, the later upload may overwrite the earlier one. Most clients do not merge YAML field by field like collaborative editors, nor can they determine whether proxy-group and DNS changes should both be kept.

Cross-client restores require particular caution. Client A may store the configuration as YAML plus a JSON index, while Client B may use database records for configuration IDs. Even if both use mihomo, their WebDAV backups may not be compatible. When changing clients, prefer exporting standard YAML or importing the subscription again rather than restoring another client’s complete data package.

Option 3: Manually export and import YAML

Manual export is the easiest approach to understand and works best for infrequent migrations: export the configuration file from the current client, transfer it to another device over the LAN, a cable, or personal storage, then import it from the file. It does not update automatically, but every transfer is explicit and easy to archive and compare.

Standard procedure

1. In the client, open “Profiles” or “Subscriptions,” find the currently enabled item, and choose “Export” or “Open profile directory.”
2. Copy the main YAML file. If the configuration references local providers, scripts, or rule files, copy the corresponding directories as well.
3. Use a text editor to search for absolute paths, LAN addresses, and device-specific interface names.
4. Name the file with its purpose and date, for example travel-phone-2026-08-16.yaml.
5. On the target device, open “Profiles” → “＋” → “Import from file.” Check parsing errors first, then start the proxy.

Fields to check when moving between platforms

• external-controller: If set to 0.0.0.0:9090, the control interface may be exposed to the LAN. For ordinary local use, change it to 127.0.0.1:9090.
• secret: Set the control-interface token separately on each device. Avoid copying the same value to every device indefinitely.
• allow-lan: Enable this only when the computer provides a proxy for other devices; reassess it after importing on a phone.
• interface-name: Interface names vary by platform, so Windows, Linux, and Android values cannot be shared directly.
• tun: Desktop routing, DNS hijacking, and automatic interface-detection settings may not suit mobile devices.
• path: Check that providers, rule sets, and scripts do not use absolute paths that are missing on the target device.

external-controller: 127.0.0.1:9090
secret: "replace-with-device-specific-secret"
allow-lan: false

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

This configuration is useful as a checklist example, not as a recommendation to enable every option unchanged on every platform. Android clients usually run through system VPN permissions, while desktop systems may require administrator privileges to create a TUN interface. If the import succeeds but the device cannot connect, disable TUN first and test with the system proxy or in-app VPN only. Once the basic nodes work, restore the settings one at a time.

Files most often missed in a manual transfer

If proxy-providers and rule-providers in the main configuration use HTTP, the target device can usually download the cached files again. If they use type: file, the local files must be migrated too. Scripts, custom GEO data, and certificate files referenced by the configuration are not automatically embedded in the YAML.

Another common mistake is treating runtime cache as the original configuration. Files named something like cache.db, profiles.json, or state may work only with the current client. For cross-platform migration, look first for the client’s explicit “Export configuration” function instead of copying the entire application data directory.

How to choose among the three sync approaches

Recommended combination

Most users do not need to choose only one. A more stable setup is to use subscription links for nodes and shared rules, client overrides for each device’s DNS, TUN, and LAN settings, and WebDAV or manual export for restore points. If one device’s settings break, you can re-import the subscription and restore only a small set of device-specific parameters.

1. Shared layer: Nodes, proxy groups, and shared rules come from a subscription or provider.
2. Device layer: Ports, TUN, system proxy, LAN access, and the control interface are configured locally.
3. Backup layer: Before every major change, create a dated WebDAV backup or export the YAML.
4. Validation layer: After updating, check configuration parsing, DNS queries, rule matches, and actual connectivity.

For example, a Windows desktop can use mixed port 7890 with the system proxy enabled, while Android runs in VPN mode. Both devices share proxy nodes and rules without forcing them to share runtime state. The currently selected node can differ too: the computer may choose the lowest-latency node, while the phone selects another based on mobile-network stability.

Troubleshooting order when the synced setup does not work

Step 1: Confirm that the configuration parsed successfully

Check the client log first instead of blaming the nodes immediately. Messages such as field not found, yaml unmarshal, or duplicate-key warnings usually indicate an unsupported field, invalid YAML indentation, or a conflict introduced during merging. YAML should use spaces for indentation, never tabs; do not define the same field twice at the same level.

Step 2: Check remote resources

• Update the subscription manually and confirm that the URL is reachable and returns configuration content.
• Check provider download status and confirm that the cache file is not empty.
• Check the device’s system time; clock skew can affect HTTPS connections.
• Confirm that the subscription update did not overwrite local overrides and that the expected nodes still appear in the proxy groups.

Step 3: Test DNS, rules, and TUN separately

1. Temporarily disable TUN and test node connectivity using only the client’s basic proxy mode.
2. Temporarily switch to Global mode to determine whether the issue comes from the nodes or rule matching.
3. Return to Rule mode and check the log to see which rule and policy group matched the request.
4. Check DNS listening and hijacking. If a local service already occupies 53, 7890, or 9090, change the port or stop the conflicting process.
5. Enable TUN again at the end and confirm that system permissions, the default route, and automatic interface detection work correctly.

Long-term practices for multi-device maintenance

The more devices you have, the more important it is to minimize direct editing on each one. Keep shared rules under a single maintenance source and leave device-specific settings clearly local. Do not let your computer, tablet, and phone each keep a slightly different full configuration without version labels; months later, it will be difficult to tell which copy contains the latest changes.

Keep a simple version history

• Add the date and purpose to filenames. Avoid unsortable names such as “final” or “latest.”
• Record the exact fields changed each time, such as “adjusted fallback-filter” or “disabled allow-lan for Android.”
• Before a major change, keep the previous configuration and delete older versions only after the new one has run for 24 hours.
• Manage subscription, WebDAV, and control-interface credentials separately so each can be revoked independently if a device is lost.
• Run a restore test once a month to ensure that backups were not only uploaded successfully but can also be imported.

The final choice is straightforward: choose a subscription link if multiple devices only need the same set of nodes; choose WebDAV to migrate the same client completely; choose manual export for temporary copies or cross-client transfers. Advanced users who frequently edit rules should use a layered setup—remote shared configuration, local device overrides, and regular backups—for lower maintenance effort and easier diagnosis of post-sync issues.