Sync a Clash Subscription Across Android and Desktop

Choose what to sync first: sharing a subscription does not copy every setting

Open the client’s “Configuration” or “Profiles” page on both your phone and computer and check the active config source. If both devices download from the same subscription URL, they share the same node source. However, the selected node, rule mode, system proxy toggle, and background permissions are usually saved separately on each device.

A subscription URL is the address a client uses to fetch remote content. It may return a complete YAML config, a list of nodes, or content in another encoded format. YAML is a text format that uses indentation to represent structure. You can import content directly only if the client can parse it; a URL labeled “subscription” is not automatically compatible.

mihomo is the name of the core used after Clash Meta. It handles proxy protocols and routing rules, while the client provides the interface for importing configs, enabling system integration, and updating. Support for mihomo configs on both devices does not mean their override options or merge behavior are identical.

Option 1: Import the same subscription URL on both devices

Choose this option if you have just a phone and a computer and mainly use the provider’s rules. It requires no extra hosting server, and makes it easier to tell a download failure from a local config conflict.

1. Copy the subscription URL for Clash or mihomo from your provider’s account page. Don’t copy the account page URL from your browser’s address bar.
2. In your Android client, open “Configuration” and look for “Add,” “New,” or “Import from URL.” Paste the URL and save it. The menu name varies by client.
3. On your computer, open “Configuration” or “Profiles” and import the same URL. Once it downloads, select that config explicitly.
4. Manually update the config on each device and check the update time, node list, and proxy groups. Once everything looks right, enable automatic updates.
5. Select the nodes or proxy groups you need on each device. Unless the client explicitly supports state syncing, don’t expect a node change on your computer to carry over to your phone.

Start with a 24-hour update interval

If the setting is in hours, start with 24. If it explicitly uses seconds, 24 hours is 86400 seconds. Some clients offer only preset intervals, so choose the closest option. Follow your provider’s published update frequency; shortening the interval to a few seconds won’t fix connection problems.

When Android enters battery saver or restricts background activity, scheduled tasks may be delayed. “Update daily” does not guarantee an update at the same time every day. If nodes change, open the app and refresh manually, then check background restrictions. A computer that stays asleep can also miss scheduled updates.

This option does not sync local changes

Edits made directly to a downloaded subscription may be overwritten during the next update. Keep rules you need long-term in the client’s separate local override area, rather than editing a copy of the remote config. If the client has no override support, you can keep a local config to prevent overwrites, but you’ll need to maintain node and rule updates yourself.

Option 2: Self-host a config to manage shared rules

If you manage several devices or want to maintain work domains, proxy groups, and rule order in one place, host a shared config on an HTTPS service you control. Clients subscribe to that hosted URL, and you update the remote file. Hosting here means storing and distributing a config, not transferring files directly between your phone and computer.

Know the difference between a full config and a proxy provider

A full config typically includes fields such as proxies or proxy-providers, proxy-groups, and rules. A proxy-providers entry fetches a set of nodes as configured; its source cannot be swapped freely for a subscription response in any format.

• If your provider supplies YAML that can be used directly as a proxy provider, reference it in the shared config, then have a proxy group use that provider with use.
• If your provider supplies only a full config, first check whether it offers a node-only output. A full config cannot be used as a proxy provider file as-is.
• If you need to convert formats, do it in an environment you control. The converted protocol fields must still be compatible with the cores on both devices.

This separates node updates from shared rule updates, but adds another potential failure point: a successful main config download does not guarantee that the provider downloaded successfully too. Check their update times and logs separately when troubleshooting.

Check these three things before hosting

1. Response: Use a browser where you aren’t signed in to test whether the client URL returns config text, rather than a login page, share preview, or error page. If authentication is required, make sure the client supports that method.
2. Access permissions: Never put files containing node credentials in a public repository, and don’t include access tokens in public rule files or screenshots.
3. Caching: After publishing, manually refresh both devices and confirm the content has changed. If the old file is still returned, check the hosting service and intermediate caches instead of repeatedly changing client settings.

Option 3: Combine a shared subscription with local overrides

Open the client’s config management page and look for features such as “Override,” “Extended config,” “Merge,” or “Script.” An override applies a layer of local changes after the remote config downloads. A script override modifies the config object through an execution interface provided by the client. These are client features; not every Clash-core client includes the same scripting interface.

A reliable setup is to use the subscription for nodes and basic proxy groups, a shared override for common rules, and device-specific overrides for local differences. The client determines the actual execution order. If the product allows only one override layer, combine the changes there and document where each one came from.

Test merge behavior with a single rule first

This is an example snippet from a complete rule list, not a standalone config that can run without nodes and proxy groups. DIRECT means a direct connection; a proxy group named “Proxy” must already exist. example.com is a sample domain—replace it with a domain you actually want to route.

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,Proxy

Clash rules are usually evaluated from top to bottom, and the first matching rule determines the route. MATCH is the fallback rule, so it belongs at the end. If you append new rules after an existing MATCH, they usually won’t be applied.

Be sure to check how the rule list is merged: some interfaces replace the entire rules list, while others support prepending or appending. If the two lines above replace the whole list, the subscription’s other rules will be removed. Before using the config, open the client’s runtime config preview and inspect the result. If there’s no preview, validate it with the config checker and rules page first.

Keep these settings separate on phone and computer

• Android: Manage per-app proxy settings, VPN permissions, and background battery restrictions on the phone. Don’t copy the app list selected by package name into desktop rules.
• Desktop: Configure the system proxy toggle, startup behavior, and TUN permissions separately. TUN is a virtual network interface for capturing traffic; copying a toggle alone does not grant system permission.
• Listening port: For example, if the desktop config sets mixed-port to 7890, programs using a manual proxy should use that port too. When a phone captures traffic through a VPN, it does not need the desktop program’s proxy address.
• Controller API: Don’t expose external-controller to the public internet just to sync configs. It manages the core and is not needed to sync a subscription.

Rules disappear after an update? Trace the config generation order

If rules work on your phone but not on your computer, don’t change both devices at once. Keep the working device as a reference and check the other one step by step. Change one thing at a time to pinpoint where the config is being overridden.

1. Confirm the active config: Check the selected config name and source. Updating a config that isn’t enabled won’t change the rules currently in use.
2. Save local settings: Export your local overrides and any essential client settings. Store backups securely if they contain tokens. Don’t back up only the remote subscription content.
3. Check the remote download: First confirm that the config downloads and parses successfully. If a download fails, the client may keep using an old copy, so “the internet still works” does not prove the update succeeded.
4. Check providers: If you use node or rule providers, check their update times too. The main subscription and providers have separate update mechanisms and may not refresh at the same time.
5. Check the override result: Compare rules and proxy-groups in the final config. Make sure the full rule list wasn’t replaced and the names of referenced proxy groups haven’t changed.
6. Reload and test a new connection: Use the client’s reload or core restart feature, then test with a new connection. Existing long-lived connections may not immediately use the new rules.

A “proxy group not found” error often means the provider renamed a group while a local rule still refers to its old name. “Custom rules disappeared after an update” usually means the rules were added to the remote file or a later override replaced an earlier one. Find the final source of each field, then adjust the merge order instead of pasting the rules in again.

Post-sync checklist

Manually update both devices one last time, then test a direct-connection domain, a domain that should use a proxy, and your commonly used apps. Record the config update time, core version, and local overrides. Find the version on the “About” or core information page; don’t record only the client shell version.

If you only need to share nodes, import the same subscription on each device. Add self-hosting when you need shared rule management, and use per-device overrides when the devices have different needs. The key is to give every setting one clear place to maintain—not to keep every line of config text identical across devices.