Clash Multi-Device Configuration Sync: Subscription Reuse, Override Files, and Private Storage

Separate syncable settings from device-specific settings

Clash multi-device sync does not mean copying one complete YAML file to every endpoint. Desktop and mobile operating systems, as well as different clients, handle configuration directories, network interfaces, system proxy settings, and TUN permissions differently. Overwriting the entire active configuration often leads to readable nodes but port conflicts, failed TUN startup, or mobile clients referencing file paths that exist only on a desktop.

A more reliable approach is to split the configuration into three layers: the remote subscription supplies nodes and provider-managed policies; the shared override contains custom rules, policy-group names, and common DNS logic; the device-local layer handles listen addresses, ports, the controller, TUN, network interfaces, and client state. Sync only the first two layers, while each client keeps its own local settings.

Option 1: Reuse the same subscription on every device

Subscription reuse is the most straightforward multi-device approach. Each device stores the same subscription URL, and its client periodically fetches the feed to generate a local configuration. Node additions, removals, name changes, and provider policy updates arrive with the next refresh, while ports, TUN, and system proxy state remain under local client control.

This works well when there are only a few devices and the main goal is to keep the node list consistent. Devices do not need to see one another, and no computer has to stay online. If one device fails to update, the others can continue on their own schedules.

Limits of subscription reuse

Subscription URLs commonly contain account-identifying parameters and should be treated as access credentials, not ordinary web links. Do not place them in public code repositories, screenshots, support tickets, or publicly shared documents. When a device is transferred, lost, or retired, remove the subscription from the client and rotate its credentials when the provider allows it.

Also check the service terms for concurrent connection and device-count limits. The fact that one subscription can be imported into multiple clients does not mean the server permits all of them to open a large number of connections at once. If nodes are visible but connections are refused, check the account status, concurrency limit, and node availability together.

Update cadence and failure handling

1. First refresh manually on a primary device and confirm that the subscription returns configuration content that Clash or mihomo can parse.
2. Then let the other devices update on a fixed schedule instead of sending repeated requests in quick succession.
3. After an update, check that each policy group still has members so that node-name changes have not broken hand-written policy references.
4. Keep the client's previous working configuration. If the new configuration fails to parse, roll back first, then inspect the response and field compatibility.

Subscription reuse keeps the node source consistent; it does not automatically sync manually added rules, current policy-group selections, or client preferences on each device. To standardize those, add an override layer instead of repeatedly editing the main configuration generated from the subscription.

Option 2: Use override files for shared rules and policy structure

Override files layer personally maintained configuration logic on top of subscription output. Clients that support overrides, merges, or scripted processing can append rules, modify policy groups, or replace selected DNS fields after a subscription update. This preserves remote node updates without requiring the generated file to be edited after every refresh.

The meaning of “override” varies between clients. Some merge by YAML key, some use JavaScript to process the configuration object, and others offer only simple pre- and post-processing rules. Before deployment, check the actual processing order supported by the client, especially whether arrays are appended, replaced, or merged by name. For rules, proxies, and proxy-groups, array handling directly changes the final result.

Keep shared overrides small and explicit

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - MATCH, node selection

The example above illustrates rule order only; it does not configure ports, the controller, or TUN. In practice, node selection must exactly match a policy-group name in the final configuration. Rules are matched from top to bottom, so the catch-all rule belongs at the end. If an override tool inserts rules in the wrong position, new entries may never match.

Do not confuse runtime state with configuration sync

The node currently selected in a policy group may be stored by the client in a local database or cache rather than in the YAML file. Even when two devices load identical configurations, device A may select “Hong Kong node” while device B remains on “Auto Select.” This is usually reasonable because latency differs across mobile networks, home broadband, and corporate networks. Standardize the policy-group structure, not a one-time selection state.

Option 3: Transfer configuration files over the LAN

LAN transfer is useful for temporary migrations, first-time setup, or a small number of controlled devices. For example, prepare the configuration on a computer, then send it to a phone or tablet through system file sharing, AirDrop, a USB cable, or a local file server. The data does not need to pass through a public sharing page, and the sharing service can be shut down after the transfer.

The process is easy to understand and works well for complete YAML files, rule sets, and documentation. The drawback is that future updates remain manual. As the number of devices grows, it becomes easy to end up with identical filenames containing different content, overwrite a newer configuration with an older one, or miss an update on one device. LAN transfer is therefore best treated as a distribution step, not a long-term automatic sync mechanism.

LAN transfer checklist

1. Before sending, disable automatic save conflict handling in the configuration editor and confirm that the file has been fully written.
2. Record the date and version in the filename or a note in the same directory instead of relying on config.yaml alone to distinguish versions.
3. After importing, run a configuration syntax check before enabling the system proxy or TUN.
4. Make sure the receiving device has not inherited the sender's LAN listen address, controller address, or platform-specific paths.
5. When the transfer is complete, close the temporary shared directory and delete duplicate copies from the receiving device's downloads folder.

If you serve the file over HTTP on the LAN, bind it only to an address reachable from a trusted network and limit the sharing window. Other devices on public Wi-Fi may be on the same subnet, so “LAN-only” does not automatically mean the access scope is controlled.

Option 4: Maintain shared configuration in private storage

When rules and override files need ongoing maintenance, place the shared layer in a self-managed Git repository, WebDAV, home storage device, or access-controlled object store. Devices can obtain the latest version through the client's remote-configuration support, a file-sync tool, or a manual download. This approach suits setups with more devices and a clear configuration history.

The key to private storage is not simply putting files on a remote service; it is defining credential access, version rollback, and conflict handling. If a sync tool triggers a client reload while a file is only half-written, temporary parse errors may occur. A safer workflow is to download to a temporary file, validate its syntax, and then replace the active configuration. If the client has built-in remote subscriptions, let the client handle downloading and switching; do not let another sync tool rewrite the same file at the same time.

Separate sensitive data from shared logic

A shared repository is best for rules, policy-group templates, and references to public rule sets. Subscription credentials, controller secrets, and private node authentication details should stay in a more tightly controlled location or be entered separately on each device. Even when the storage service requires login, assign accounts with least-privilege access instead of sharing administrative access across household members or devices.

If the client does not support variable substitution or external key files, do not merge everything into one YAML that remains synced indefinitely just to automate the process. Keep a base template without device credentials, then add local fields after importing it on each endpoint. This adds one step, but the failure boundary is clearer and access can be revoked for an individual retired device.

Choosing between Git, WebDAV, and home storage

Recommended workflow: maintain the subscription, shared layer, and local layer separately

For most individual users, a balanced structure is to store the subscription URL independently on each device, keep rules and policy templates in one controlled location, and leave ports, TUN, the controller, and system proxy settings local. The subscription updates the node list, shared rules have one maintenance source, and platform differences are not repeatedly overwritten by a remote file.

1. Establish a baseline device: Start with one desktop device to verify the subscription, rule order, DNS resolution, and policy-group references, confirming that the current core can load the configuration completely.
2. Extract the shared layer: Keep only cross-platform fields, and move listen ports, TUN interfaces, the controller, and local paths out of the shared file.
3. Validate on a small scale: Import the configuration on a second device first, then check the client's override semantics, array-merge behavior, and field support.
4. Record configuration versions: Handle one topic per change, such as renaming a policy group or adding a rule set, rather than sending several changes to every device at once.
5. Keep a rollback path: Save the last loadable configuration before updating. If parsing errors, DNS problems, or rule mismatches appear, restore operation first and compare the changes afterward.
6. Clean up devices regularly: Remove unused subscriptions, remote-storage credentials, and old configuration copies so retired devices cannot continue receiving updates.

Items to verify after syncing

• Whether configuration checks pass and the logs contain no unknown fields, duplicate policy names, or rule-set loading errors.
• Whether policy groups contain valid nodes and the policy names referenced by hand-written rules still exist.
• Whether DIRECT, proxy policies, and REJECT match as expected instead of all falling through to the final rule.
• Whether DNS requests are handled by the intended resolver and whether Fake-IP or Redir-Host mode is supported by the client.
• Whether the desktop system proxy and mobile VPN permissions remain controlled by local state.
• Whether enabling TUN causes routing loops, breaks LAN access, or conflicts with other VPN software.

Choose the approach based on device count and maintenance goals

With only two or three devices and a primary need for consistent nodes, start with subscription reuse; add a small override file when shared routing rules are needed. For an occasional desktop-to-phone migration, use LAN transfer and manually review platform-specific fields. When there are more devices, rules evolve over time, or changes need review, a private Git repository and controlled file storage are a better fit.

No approach should sync every aspect of runtime state. Some parts of Clash and mihomo configuration describe proxy logic, while others are tied directly to the operating system's network stack. The former can be maintained centrally; the latter must respect device differences. Defining the sync boundary clearly is more reliable than searching for one file that covers every endpoint.

The final structure can be summarized as follows: the subscription supplies nodes, overrides supply shared rules, private storage handles versioning and distribution, and local configuration handles system interfaces. Checking these four areas separately quickly shows whether the problem lies in remote updates, the merge process, file transfer, or device permissions, without repeatedly comparing multiple complete configuration copies.