Comparing Ways to Sync Clash Config Across Devices: Subscription Links, Cloud Storage, and Manual Export

Why Config Sync Matters

Clash-family clients (including the original core and Clash Meta / mihomo) describe node information, proxy groups, and routing rules in a single YAML config file. Desktop and mobile apps usually install and maintain their configs independently, so if you adjust a rule or add a node on one device, other devices won't automatically pick up that change. If you only use one device long-term, this isn't much of an issue. But as soon as you're dealing with a "computer + phone" or "personal device + home router" scenario, out-of-sync configs cause two immediate problems: first, the list of available nodes differs between devices, so one device might try to connect through a node that's already expired without you noticing; second, routing rules drift apart — for example, adding a custom rule on your computer while your phone keeps matching against the old ruleset, so the same website behaves differently on the two devices.

The bigger issue is maintenance overhead. If your subscription provider updates its node list or changes server addresses, in theory every device needs to pull the update again. Doing this manually across three or five devices is manageable, but once you're also maintaining a router, a tablet, and a spare phone, the repetitive work quickly piles up, and it's easy to forget to update one of them. Choosing the right sync method is essentially about balancing automation, privacy control, and operational complexity.

Method 1: Auto-Updating Subscription Links

This is by far the most widely used sync method. The mechanics are straightforward: instead of storing the node list directly, the client stores a subscription link (URL) and, on each refresh, requests that address to pull the latest config content and overwrite the local cache. As long as every device is configured with the same subscription link, in theory each device gets the same data after refreshing.

• Automatic update interval: most clients let you set an auto-refresh interval for subscriptions (e.g., every 24 hours), and you can also manually tap "Update Subscription" to pull the latest content immediately.
• Node and rule sync: if the provider maintains both nodes and routing rules centrally behind the link, rule changes propagate to every device automatically on the next refresh, with no manual intervention needed.
• Traffic and expiry info: some subscription links return metadata like remaining traffic or expiration date, which the client parses and displays, making it easy to check usage across devices in one place.

The advantage here is "configure once, maintenance-free afterward," which is especially useful when node information itself changes frequently. The downside is equally clear: routing rules are entirely controlled by the provider, so if you've manually added custom rules on one device, they'll likely be overwritten and lost the next time the subscription updates. If you plan to rely on subscription-link sync, it's worth maintaining custom rules as separate rule sets (rule-provider) referenced externally, rather than writing them directly into the main config returned by the subscription — that way rule edits survive subscription refreshes.

Method 2: Cloud Storage Sync of Config Files

If you prefer maintaining config files by hand, or your provider doesn't offer an auto-refreshing link, you can bring the Clash config directory under cloud storage sync. A common approach is placing the config file inside a folder your cloud storage client syncs, or using a symbolic link (symlink) to point Clash's config directory at the actual path inside the cloud folder. That way, editing the file on one device automatically pushes the change to other devices signed into the same account.

1. Determine the actual path your Clash client reads the config file from (default directories vary by client — check the client's settings for a "config file location" option or similar).
2. Copy the config file into your cloud sync folder, or set up a symlink pointing at the file inside that folder instead.
3. Confirm the cloud storage client is signed in and syncing normally on all devices; after editing on one device, check whether the others receive the update within the expected time.
4. If the client locks the config file while running — preventing the cloud service from writing to it or causing conflicted copies — quit the client before editing, then relaunch it afterward to load the changes.

The advantage of this approach is that it fully preserves custom rules, proxy group logic, DNS settings, and every other detail without being overwritten the way subscription links can be. It suits users whose rules are relatively stable, with occasional node or rule tweaks being the main change. The risk to watch for is concurrent edits: if two devices modify the same config file at almost the same time, cloud services typically generate a "conflicted copy," which requires manually comparing the two files and merging the correct version — otherwise one device might end up reading an incomplete or outdated file. Also, if the config contains sensitive fields like node passwords, weigh whether storing that in the cloud is acceptable for your privacy needs, and encrypt the sync folder if necessary.

Method 3: Manual Export and Import

The most basic and controllable approach is manually exporting the config file, then importing it on each device one by one. Most Clash-family clients offer an "export current config" or "copy config file path" feature; the resulting YAML file can be transferred via USB drive, local network transfer, or a messaging app, then loaded on the target client by selecting "import config file."

Manual export/import suits a few scenarios: very few devices (say, just one computer and one phone), infrequent updates (the config is mostly settled and rarely changes), or heightened privacy concerns where you'd rather not have your config pass through any third-party service. Its drawbacks map directly to these assumptions: as soon as device count or update frequency increases, the repetitive manual work piles up quickly, and it's easy to forget to update one device — which then means troubleshooting has to start by confirming which version of the config each device is actually running.

If you go with the manual approach, it's worth naming each exported file by date (e.g., config-20260513.yaml) and keeping a few recent versions locally. That way, if a new config introduces a rule error or formatting issue, you can quickly roll back to the last known-good version instead of rewriting everything from scratch.

# A common way to manually check config file syntax:
# Most clients perform basic validation on import, and format errors are usually flagged right there
# You can also use a text editor's YAML syntax highlighting to pre-check indentation and colons
proxies:
  - name: "node-a"
    type: ss
    server: example.your-node.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"

Comparing the Three Methods

These three approaches aren't mutually exclusive — in practice they're often combined: node information auto-refreshes via subscription link, while custom rules are synced via cloud storage or maintained manually as a separate file and referenced from the main config. Here are a few dimensions to weigh when choosing:

If your provider maintains both nodes and rules together and updates rules frequently, subscription links are the way to go to cut down on repetitive work. If your custom rules are fairly complex and you don't want them overwritten every time the subscription refreshes, consider splitting them into a separate rule-set file, distributed via cloud storage or manually, with the main config only referencing the rule-set address. If you only have one or two devices and update rarely, manual export/import is already sufficient — no need to add cloud storage or subscription mechanisms and extra complexity.

Verification Steps After Syncing

Regardless of which method you use, it's worth running a quick check after updating your config to avoid the "thought it synced but it actually didn't" scenario:

• Check that the node count and names shown in the client UI match what you expect, confirming it isn't loading a cached older version.
• Check the config file's last-modified timestamp or the subscription's last-updated time to confirm a refresh actually happened.
• Pick a custom rule you know should match, visit the corresponding site, and confirm the routing outcome matches expectations instead of falling through to the default policy group.
• If TUN mode is enabled, confirm that TUN-related settings (such as the virtual network adapter's address range or DNS hijacking settings) weren't reset to defaults after syncing — these fields are prone to being unintentionally reset during overwrite-style subscription syncs.

Common Troubleshooting Approaches

The two most common issues during syncing are: "it looks synced but the content hasn't changed," and "the client fails to start after syncing." The former is usually a caching or update-interval setting issue — check the subscription's auto-update interval in the client, or manually trigger a refresh and then compare update timestamps. The latter is often a file format issue, such as indentation errors from manual editing, an incomplete half-written file left behind by cloud sync, or different clients supporting different fields for the same config (for example, parameters for certain proxy types not yet supported in an older client version). When a client fails to start, check the specific error line number in the client log first, then trace through the YAML structure around that line for indentation and field spelling issues — this usually pinpoints the problem quickly.