Sync Clash Configs Across Devices: Subscription Links, Config Exports, and WebDAV Backups

First, decide what to sync: nodes, rules, or the full setup

Using the same subscription on a computer and a phone usually ensures that both devices get nodes or config from the same source. It does not guarantee identical proxy modes, selected nodes, TUN settings, or per-app routing. Before syncing Clash configs across devices, distinguish remote content from device-specific settings. That way, when you switch phones, reinstall an OS, or update a subscription, you won't mistake local settings for backed-up data.

• Nodes and subscription content: Provided by your service and may include a full config or just proxy nodes. Updating the subscription fetches the latest remote content.
• Custom rules and proxy groups: These may live in a YAML file or be generated through client features such as overrides, merges, or scripts. Before exporting, check which layer the export includes.
• Device settings: System proxy, VPN permissions, TUN service access, per-app routing, and local listening addresses usually need to be configured on each device separately.
• Runtime state: Current proxy group selections, connection history, and caches are not the same as the config file. Whether they are preserved depends on what the client includes in its backups.

How to choose between the three sync methods

You can combine these methods rather than choosing just one. For example, subscribe to the same URL from Windows and Android, keep custom rules in a separate file, and back up both the config and rules to WebDAV weekly. Subscriptions keep nodes up to date, rule changes stay documented, and a recoverable copy is ready if a device fails.

Sync with a subscription URL: import it separately on each device

Best when nodes change often and both devices need regular updates

A subscription URL provides access to remote config; it is not a sync channel between devices. Updating on your computer does not update your phone, which may still be using content fetched earlier. First check your provider's device limit, concurrent connection limit, and data allowance. These limits are generally enforced across all devices using the same subscription.

1. On the original device, find the subscription URL for the active config and copy the entire link. Keep all query parameters; don't copy only the domain or path.
2. On the target device, open config management, choose the URL import option, paste the address, and save. Depending on the client, this may be called “Config,” “Subscription,” or “Profiles.” Follow the labels in your app.
3. Complete the initial download, then check the node count, proxy group names, and update time. If you see nodes but no rules, check whether you imported a node-only subscription or a full config.
4. Select the newly imported config, then enable the connection. On desktop, turn on the system proxy if needed; on a phone, grant the required VPN permission.
5. Manually update each device once to confirm both can fetch remote content, then set an automatic update interval.

If the app's interval is measured in hours, start with an update every 24 hours. If your config uses proxy-providers, its interval is usually measured in seconds, so 24 hours is 86400. These are separate timers; don't enter “24” in a field that expects seconds. Phones may also restrict background tasks, so a manual update is the easiest way to confirm the setup is working.

One subscription may not work with every client

The original Clash and Clash Meta (now called mihomo) support different features, and clients may also use other cores. A provider's config may fail to import if it contains protocols or fields unsupported by the target core. Choose a subscription format that the provider explicitly supports for your client. Renaming a file with the .yaml extension does not convert its format. If import fails, first check the subscription import steps, then review the specific error message.

Export a config file: keep a snapshot you can roll back to

Exporting YAML works for one-time migration and for saving a snapshot before changing rules. But exporting a config is not the same as backing up the app. A config export usually contains only the text needed by the core, while an app backup may also include subscription records, interface preferences, and override files. Check what's in the export before migrating; don't assume it's complete based on the filename.

1. Manually update the subscription on the source device and make sure the current config starts successfully. Note the client name, core, and version so you can compare feature support on the target device.
2. Use the client's config export or open-config-file feature to save profile-2026-10-03.yaml. Save custom override files separately; don't keep only the generated temporary config.
3. Check the path values under proxy-providers and rule-providers. If they point to local files, transfer those too. If they use remote URLs, make sure the target device can download them.
4. Send the files to the target device using a trusted transfer method, then import them as local files. Test the config as a new profile first; don't overwrite one that already works.
5. Check the ports, LAN listening settings, DNS, and TUN configuration, then test the connection. Make it your everyday config only after everything checks out.

For example, the computer's mixed port may be set to 7890, but another proxy app on the target device may already be using that port, causing the config to fail at startup. Or the computer may use a DNS address tied to a network adapter that isn't reachable when the phone switches to cellular. When copying a config between devices, carry over the intent of your rules—not every network setting as-is. For port issues, see the port troubleshooting guide.

WebDAV backups: archive your files, don't treat them as live sync

WebDAV is a way to access files, not a built-in sync feature shared by Clash or the mihomo core. Whether a client lets you enter a WebDAV URL, encrypt backups, or schedule uploads depends on the client. If there's no built-in option, save exported files to a local backup folder and upload them with a file tool that supports WebDAV.

Set up a dedicated folder and a recovery process

1. Create a dedicated folder on your WebDAV service, such as clash-backups/laptop/ and clash-backups/phone/. Use HTTPS and, if possible, create app credentials that can access only this folder.
2. If your client supports WebDAV, enter the server URL, username, and app credentials in its backup settings. If the service asks for a base URL and folder path separately, follow its instructions.
3. After the first manual upload, check the file's timestamp and size on the server. Include the device and date in the filename, such as laptop-2026-10-03.zip, so the two devices don't keep overwriting the same file.
4. Download a backup and restore it to a test profile or environment. Check that subscriptions, overrides, and rules are present. An upload succeeding does not prove the backup can be restored.
5. Keep the latest 7 daily backups and 4 weekly backups, or set a similar retention policy based on available storage. Save a separate copy before upgrading the client.

A backup archive created by one app may only work with that client, and could depend on the backup format version. For cross-client migration, use a config format supported by both clients, then restore settings manually. Files on WebDAV won't change the running core automatically; you still need to download and import them, select the config, and reload it.

Prevent conflicting edits and credential leaks

Don't have a computer and phone edit and sync the same “current config” file in both directions. Each device could read an old version, then overwrite the other's changes. A safer approach is to designate one device to maintain custom rules and have the others read from it. If multiple devices need to make changes, create a dated copy first and publish it after reviewing. If a backup contains subscription URLs or node passwords, use the client's encrypted backup feature or encrypt it with a trusted tool before uploading. Store the recovery password separately.

Keep custom rules through updates: separate the subscription config from your overrides

Directly editing YAML generated by a subscription often means your changes disappear on the next update. Put custom rules in an override, merge, or script layer explicitly supported by the client, or maintain a complete config yourself and reference the node provider. Override syntax and merge order vary between clients, so don't assume a script for one client can be imported as config by another.

The example below illustrates the order of rules in a running config; it is not a universal override file. It assumes a proxy group named PROXY. The example domains show the syntax—replace them with the domains you want to handle. If you use a merge feature, confirm that it prepends the rules rather than appending them after the final MATCH.

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

• Order: Rules are usually checked from top to bottom, and the first match determines where traffic goes. Custom rules placed after MATCH won't be reached.
• Proxy group name: PROXY must exactly match a name in the current config. If the subscription renames the group, update the reference too.
• External dependencies: GEOIP needs usable geolocation data. If you use GEOSITE or RULE-SET, confirm the target core supports them and that the required data and rule providers are available.
• Device differences: Android's per-app proxy list and desktop system proxy toggle aren't controlled by these domain rules; configure them separately.

Check the final effective config both before and after an update to make sure custom rules still appear before the fallback rule. If the client can show the merged result, use that as the source of truth rather than checking only the override snippet in the editor. This lets you keep receiving subscription updates without re-adding your rules each time.

After migration: verify these four things

1. The config loads: Check the logs for unknown fields, missing proxy groups, rule files that failed to load, or port conflicts. Note when the config was imported and updated.
2. Traffic reaches the client: On desktop, test with a browser that follows the system proxy. On a phone, check the VPN connection status. To route apps that ignore the system proxy, configure TUN and permissions as required by the client.
3. Rules match as expected: Visit one site that should connect directly and another that should use a proxy. Check the connection list for the matched rule and final outbound route. A latency test alone doesn't prove that the rules are working.
4. Changes survive updates: Manually update the subscription, check your custom rules again, then restart the client and test once more to rule out changes that only worked for the current session.

If your computer works but your phone doesn't, check the subscription format, proxy group selection, DNS, and system permissions—in that order. Don't replace the entire config right away. If the issue occurs only on one Wi-Fi network, compare it with cellular first, then investigate local DNS or network restrictions. For traffic routing steps, see the system proxy setup guide.

A clear recovery plan needs just three things: a subscription URL to fetch nodes again, custom rules saved separately, and a backup that you've tested restoring. Let each device handle routine subscription updates, maintain rules in one place, and configure ports and permissions per device. That keeps the content that needs to match in sync without copying runtime settings that don't transfer well between platforms.