Sync Clash Configs Across Devices: Subscriptions, Cloud Storage, and Local Overrides

Separate Shared Config from Device-Specific Settings

When using Clash on a PC and phone, the parts you usually want to share are the node sources, proxy group names, and routing rules—not the entire client data directory. Windows system proxy settings, Android VPN routing, and Linux routing permissions all work differently. Copying every file from one device to another can bring along incompatible network interface names, listen addresses, and runtime state.

It also helps to distinguish the client from the core. The client imports subscriptions, schedules updates, generates config, and manages system proxy settings. The Clash or mihomo core reads the final config and handles traffic. Client features such as “override,” “merge,” and “scripts” are not universal config fields that every core can read directly.

Option 1: Import the Same Subscription URL on Every Device

Subscription links are a straightforward way to keep nodes up to date and work well across mobile and desktop. Each client fetches the same URL and keeps its own copy; changes made on one device do not automatically appear on the others. Check the provider’s terms for device limits and how concurrent connections are counted.

Import and Update Steps

1. Check the subscription’s output format. A full Clash YAML usually includes nodes, proxy groups, and rules. A nodes-only subscription needs the client or local config to provide the rest. Don’t rely on the URL suffix alone to identify the format.
2. On each device, look for an option like “Import from URL” in subscription settings. The label varies by client. Preview the config after importing to make sure it isn’t a web page, sign-in prompt, or error message.
3. Enable scheduled updates on each device. For example, set the desktop client to update every 24 hours. On phones, background activity must also be allowed; a scheduled time does not guarantee the update will run.
4. Run a manual update, check the node count, proxy group names, and update time, then activate the config. Seeing a subscription in the list does not mean the core has switched to it successfully.

A full subscription config generated by the server may be replaced on update. If you edit rules directly in the downloaded copy, those changes may disappear the next time it updates. Keep long-term custom rules in a local override layer supported by the client, or in a config source you maintain yourself.

Subscription Updates Don’t Sync Your Selected Node

A select proxy group with the same name can use node A on your phone and node B on your PC. Some cores support profile.store-selected to save selections on the local device, but that does not sync them across devices. Automatic test groups also depend on the local network, so different results on home broadband and mobile data are normal.

Subscription URLs usually contain access credentials. Don’t post the full URL in a public repository, screenshot, or public support request, and don’t submit it to an unfamiliar online converter. If it leaks, reset the URL with your provider and update it on every device. Deleting a local file does not revoke access through the old URL.

Option 2: Sync Config Source Files with Cloud Storage

Cloud storage works well for custom YAML, rule files, and change notes, especially when syncing between two desktop devices. Keep a separate “config source” folder rather than syncing the client’s live data directory. That directory may contain caches, logs, databases, lock files, and client-specific metadata.

Use One Editing Device to Prevent Conflicting Changes

You can create a folder structure like the one below in cloud storage. The filenames describe each file’s purpose; clients aren’t expected to recognize them automatically. Check separately which file the client needs to import and whether it copies the file into its own directory.

clash-config-source/
  shared-rules.yaml
  desktop-source.yaml
  mobile-source.yaml
  change-notes.txt

1. Choose one PC to edit the source files. Other devices should only read or import them, preventing conflicting copies when changes are made offline.
2. After making changes, validate the YAML and rule targets on the editing device, then wait for the cloud upload to finish.
3. On the receiving device, confirm the download is complete, then reimport or reload the config. A file appearing in the cloud folder does not mean the client has loaded its new contents.
4. Keep the previous working version and notes about each change. To roll back, restore the source file and reload it in the client.

Cloud storage share links often open a preview page or require a sign-in, so they can’t necessarily be used as subscription URLs. The client needs a URL that serves the config directly; if that isn’t available, import the local file instead. When you import a file on a phone through the system file picker, the client may save a one-time copy, so later cloud updates won’t be picked up automatically.

Restrict Access to Sensitive Configs

A full config may contain node passwords, subscription credentials, and access keys for external control interfaces. Limit access to the cloud folder and disable public sharing when it’s no longer needed. Keep backups separate from day-to-day distribution: a long-term backup should not automatically become the live config that every device reads.

Option 3: Subscription Plus Local Overrides

Overrides are useful when nodes need to follow subscription updates but ports, DNS settings, or rules need to stay in place. The client fetches the subscription, applies its own merge or script logic to generate the final config, then passes it to the core. Override options, formats, and execution order vary by client, so a merge file from one client may not work if imported unchanged on another device.

Keep Device-Specific Settings Local

The example below shows partial settings for a desktop device, not a complete, runnable subscription. It contains no nodes or proxy groups. Use it in a client override interface that supports merging these top-level fields, or merge it into a full config manually.

mixed-port: 7890
allow-lan: false
bind-address: 127.0.0.1
mode: rule
log-level: info

mixed-port: 7890 accepts HTTP and SOCKS proxy connections on the same port. If another program on your device is using 7890, change it to 7893 and update the system proxy or app proxy that points to that port. allow-lan: false disables LAN access; it does not enable proxy sharing across devices.

If your phone routes traffic through the system VPN interface, you usually don’t need to copy the PC’s system proxy port settings. Check Android per-app proxy settings and background battery restrictions, as well as the desktop TUN toggle and administrator permissions, on each device separately.

Don’t Assume Rule Lists Are Automatically Merged

YAML is a data format, not a standard override algorithm. One client may replace the entire list with local rules, while another offers a “prepend rules” feature. Check how merging works before adding rules. Otherwise, you could replace the subscription’s full routing list with just two rules and lose everything else.

# Rule order example only; PROXY must be defined in the final config
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

The example sends example.com and its subdomains to PROXY, and all other connections to DIRECT. It is not a general-purpose routing setup. Add rules before any catch-all rule that would match them first. If the final config only has a proxy group called “Node Selection,” you can’t reference PROXY unless it exists.

Cross-Platform Compatibility: Check the Core, DNS, and TUN

A YAML file loading in a desktop client does not guarantee that every field is supported on mobile. Clash and mihomo don’t have identical capabilities, and clients may trim or regenerate config. If loading fails, note the client and actual core versions on each device, then check the first parse error. Comparing app names alone isn’t enough.

• Node protocols: Check that the target core supports each node type in the subscription. If a node type is missing on one device, it may be a compatibility issue rather than a sync problem.
• DNS listeners: For example, 127.0.0.1:1053 listens on the local device. Copying this setting alone won’t make the operating system send DNS queries to port 1053 or set up DNS routing on a phone.
• TUN and network interfaces: Don’t share hard-coded interface names or device-specific routes. Configure TUN permissions, route setup, and DNS hijacking for each target operating system.
• File references: Local paths used by proxy-providers or rule-providers must be readable on the target device. Copying the main config without its referenced files can still cause loading or update failures.

If you only need to share node sources, each platform can use its own main config and import nodes through a compatible proxy-providers setup. Providers require a specific content format; don’t assume any full subscription YAML will work just by placing its URL in url. Check the subscription’s output format and the target core’s parsing requirements first.

After Syncing, Verify the Active Config

The goal isn’t for every file to be identical; it’s for the parts you want to share to match while device-specific settings remain intact. The source config, override file, and client-generated runtime config may all be different files. When troubleshooting, start with the client’s final config preview or the file actually loaded by the core.

1. Check the input: Manually update the subscription and note the update time and node count. For cloud storage, confirm the file has downloaded completely and reimport it.
2. Check the structure: Review proxy group names, rule targets, and the catch-all rule. If the logs report a missing proxy group or YAML parse error, fix the config structure first.
3. Check traffic routing: On desktop, confirm the system proxy or TUN is enabled. On mobile, check the VPN connection and whether the apps that need a proxy are included.
4. Check the connection: Visit a domain that needs to be routed and check the connection log for the matched rule, proxy group, and actual node. A successful speed test doesn’t replace testing a website.
5. Check that changes persist: Update the subscription again and restart the client. Make sure custom rules are still there and device-specific ports are still correct to catch changes that get overwritten on update.

Three Common Config Sync Problems

Choose a Sync Method for Your Devices

When sharing nodes between a phone and PC, start with the same subscription and update each device separately, keeping local traffic-routing settings. For custom rules shared between two desktop devices, store the source files in cloud storage and designate one editor instead of syncing the runtime directory. If subscriptions update frequently but you need to keep custom rules, use a subscription with local overrides and define the rule-list merge order.

When adding a device, follow this order: import the source, set device-specific options, check the final config, then test the connection. Keeping nodes and rules traceable while leaving ports, TUN, and permissions device-specific is easier to maintain than forcing every file to match exactly.