Clash Config Sync Across Devices: Keeping Subscriptions and Rules Consistent

First, separate what actually needs syncing across devices

Before talking about multi-device sync, it helps to break down what's actually stored on a single device running Clash. Config falls into two categories: what comes from your subscription, and what lives locally on the device.

The subscription delivers the node list, proxy groups, and routing rules, all maintained by the provider behind your subscription link. When the provider pushes an update, every client just re-fetches to get the same set. Local settings are a completely different story: run mode (Rule, Global, Direct), mixed port, system proxy toggle, TUN mode, launch on startup, UI preferences — these all live in each device's local storage, and no sync method will carry them over for you.

So multi-device sync really just means solving one problem: getting the same subscription content pushed to every device in a timely way. Local settings still have to be configured one device at a time. The three approaches below differ in how they handle the subscription side.

Option 1: Shared subscription link syncs naturally

Best for: all your nodes come from a single provider, and you maintain little to no custom rules. This is the lowest-maintenance option and the starting point for most people.

The whole approach comes down to one sentence: add the same subscription link on every device's client. Nodes, proxy groups, and rules all come from the subscription content — once the provider updates, each device just needs to hit update to fall back in sync.

1. Copy the subscription link labeled Clash or Clash Meta (mihomo) from your provider's dashboard.
2. On desktop (Clash Verge Rev, Clash Nyanpasu, etc.), create a new remote profile on the config page, paste the link, and save.
3. On Android (Clash Meta for Android, FlClash), add a new subscription profile the same way; iOS clients follow the same steps.
4. Set the auto-update interval on each device to around 24 hours so nodes and rules stay aligned as the provider updates.

Common pitfalls with this approach:

• Client differences: some clients pull a generic node list and convert it locally, which behaves differently from a subscription that outputs Clash config directly — stick to links your provider labels as Clash or mihomo.
• Update timing: auto-update times differ across devices, so the node list may briefly be out of sync — that's normal, just trigger a manual update to line them up.
• UA-based templates: some providers push different config templates based on client identity, so rule details may differ slightly between two devices — check your provider's docs to be sure.

Option 2: Private config hosting for full custom-rule delivery

Best for: you maintain a large set of custom rules, multiple proxy groups, or custom DNS blocks, and want every device to get a byte-for-byte identical config.

The approach is to put your fully assembled YAML config at a URL only you can access, then add it on each device as a remote subscription. From then on, you only edit that one file — every device picks up the change on its next update, keeping rule order, proxy group structure, and DNS behavior identical everywhere.

Viable hosting options:

• Private Git repo: a raw file link from a private GitHub repo paired with an access token, or a private Gitee repo — push a commit, then update the subscription on each device.
• Self-hosted subscription converter: run something like subconverter on your own server or NAS, feeding it your upstream subscription plus a custom rule template to output a complete Clash config, gated behind its own token.
• LAN-only static hosting: serve the config file from a NAS or home server via WebDAV or a lightweight HTTP server, reachable only over your home network or an encrypted tunnel.

A mihomo snippet referencing a remote rule set from your hosted config:

mixed-port: 7890
dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
rule-providers:
  my-rules:
    type: http
    behavior: classical
    url: "https://your-hosting-address/rules/my-rules.yaml"
    path: ./providers/my-rules.yaml
    interval: 86400
rules:
  - RULE-SET,my-rules,Proxy
  - MATCH,DIRECT

Common pitfalls with this approach:

• Core differences: Clash Meta (mihomo) supports fields like rule-providers and tun that the now-discontinued original Clash core doesn't recognize; when sharing one config, either stick to the common subset both cores support, or maintain two separate versions.
• Credential protection: the config contains node server addresses and passwords, so the hosting URL needs an unguessable access token — a leak here is just as bad as a leaked subscription link.
• Caching: raw links on Git platforms are cached, so an edit may not show up immediately — wait a few minutes or append a version query parameter to the URL.
• Path issues: local rule file paths referenced in a config aren't consistent across platforms — prefer remote rule-providers over relative paths.

Option 3: Manual export and import

Best for: you only have two or three devices, rarely change your config, or don't want any data passing through a third party.

Desktop clients generally let you export the current config as a YAML file or a full backup; mobile clients support importing from a file. Transfer it over LAN, USB drive, or an encrypted archive.

1. Export the currently active config from your primary device.
2. Transfer the file to the target device over LAN or as an encrypted archive.
3. On the target device's client, choose import from file, then save and enable it.
4. Double-check that ports, DNS, and TUN settings all took effect as expected.

Common pitfalls with this approach:

• Version drift: edit one device, forget the other, and a few weeks later the two configs have quietly diverged — when troubleshooting, check the modification time on both files first.
• Platform differences: Android clients don't support every config field the same way desktop mihomo does — after importing, confirm the DNS and TUN sections actually took effect.
• Authorization doesn't transfer: HTTPS decryption certificates and the admin/VpnService permissions TUN needs are tied to a single device and won't travel with the config file — you'll need to re-authorize on each device.

Comparing the three options and which to pick

Option	What syncs	Consistency	Credential risk	Maintenance	Best for
Shared subscription link	Nodes and rules from your provider	High — same source	Subscription link must stay private	Lowest	Nodes all from one provider, minimal rule tweaking
Private config hosting	Full custom config	Highest — one identical file	Depends on hosting method	Medium	Heavy custom rules and proxy groups
Manual export/import	A snapshot at export time	Drifts over time	No third party involved	Low, but manual every time	Few devices, infrequent changes, privacy-focused

For most people, the shared subscription link is the right foundation — it handles nodes and rules, and local settings only need setting up once per device. Only move to private config hosting once you're maintaining a substantial set of custom rules; manual export/import is best kept for on-the-road emergencies or cases with strict privacy requirements.

What still needs handling per device, beyond syncing

• Run mode, mixed port, system proxy, and launch-on-startup are all local settings — none of the three options sync them, so set them up once per device.
• TUN mode is toggled per device: desktop needs admin or root permission, Android needs a VpnService authorization prompt, and neither carries over to the other.
• Keep core versions close across devices; when crossing major versions, check the mihomo docs before adding new fields to a shared config.
• System clock accuracy matters: subscription updates and node TLS handshakes both depend on correct time — a large drift causes outright failures, showing up as subscriptions that won't download or nodes that all time out.
• After changing a config, check the client logs and the connection panel to see which rule each connection actually hit — that's far more reliable than guessing.