Clash Config Sync Across Devices: Subscriptions, Private Hosting, and Local Overrides

Define what to sync: proxies, rules, and device settings

Syncing Clash across devices does not mean copying the entire client directory. Proxy credentials, routing rules, and system proxy settings belong to different layers. Importing a desktop config unchanged on a phone can lead to unsupported fields, port conflicts, or TUN startup failures. A safer approach is to share proxy sources and routing intent while keeping network adapters, listening ports, and system integration device-specific.

First, distinguish the client from the core. Desktop clients using mihomo may support the same core fields, but config merging, background updates, and script execution are handled by the client. Other cores or mobile proxy apps may accept some Clash-format settings without fully supporting mihomo configs. The YAML examples in this article use mihomo as a reference; before importing, check which core and fields your target client supports.

Option 1: Import the Same Subscription URL on Each Device

If two or three devices use the same provider, a subscription URL is usually the lowest-maintenance option. Add the same URL on each client’s subscription or config screen, then update and enable it. This syncs the content each device retrieves from the provider; it does not transfer settings directly between clients.

Check config updates and runtime status separately

1. Import the subscription on your computer first. Confirm that the proxy list, groups, and rules work, then import it on your phone and tablet.
2. Check the subscription update settings on each device. If the client allows it, set the check interval to 24 hours. This is a maintenance recommendation, not a universal Clash default.
3. Whenever the provider changes its proxies, update each device manually and confirm that the subscription is still enabled.
4. On the connections screen, check the rule that actually matched and the egress path. A config marked “update successful” is not enough.

Updating a subscription does not sync the proxy currently selected in a group. Your phone may keep its own selection even if you choose a proxy in a particular region on your computer. Connection history and system proxy and TUN toggles are usually saved separately too. To keep routing policy consistent across devices, use the same automatic selection group design in the config, but remember that latency measurements will still vary with each device’s network.

Key limitation: update timing depends on the client

Mobile apps may be suspended by the system in the background. Even with a 24-hour update interval, there is no guarantee the config will be fetched at a specific time. A sleeping computer or unreachable subscription server can also delay updates. When retiring an old proxy, allow time for devices to transition and run an update manually with the mobile app open.

Also check your provider’s device limit, concurrent connection limit, and account terms. Sharing a subscription does not mean it can be distributed without limits. Subscription URLs often contain access tokens, so anyone with the URL may be able to retrieve proxy details. Treat it like an account credential.

Option 2: Host YAML Privately and Manage Rules Centrally

If you have many custom rules or need to review config changes, store the config source in a private repository and distribute it to devices through a controlled HTTPS endpoint. The repository tracks versions; the download endpoint handles authentication. They are not interchangeable. A private repository’s web page usually returns a login screen, so it cannot be used directly as a YAML subscription URL.

Full configs versus standalone rule sets

When hosting a full config, devices should receive a usable file containing proxies, groups, and rules. For a standalone rule set, reference it from the main config with rule-providers, then call it from rules. A rule set by itself cannot be enabled as a complete subscription.

Here’s a local example of a rule set’s structure. First, place the rules file at rules/shared-direct.yaml in the core’s working directory. The contents follow. example.com is a reserved example domain used to demonstrate the rule format; replace it with a domain relevant to your use case before deployment.

payload:
  - DOMAIN-SUFFIX,example.com

Add the following snippet to the main config, keeping the existing proxies and groups. This example assumes an existing group named “Proxy Selection”. If your group has a different name, use its exact name in the last line.

rule-providers:
  shared-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/shared-direct.yaml

rules:
  - RULE-SET,shared-direct,DIRECT
  - MATCH,Proxy Selection

rules are evaluated from top to bottom, with the final MATCH rule acting as the fallback. This list illustrates the order; do not use it to replace all the existing rules in your subscription. To use an HTTP rule provider, set type: http and specify a real download URL, cache path, and interval. For example, interval: 86400 sets the update interval to 86,400 seconds, or 24 hours. It controls rule provider updates, not full subscription updates.

Access controls and rollback copies

• Test the download endpoint in each target client and confirm it returns YAML, not a login page, redirect, or error.
• If custom authentication headers are required, first check whether the client and its download method support them. Being logged in through a browser does not mean the client can access the file.
• Keep the repository focused on rules and generation logic. Manage proxy passwords, subscription tokens, and controller secrets separately.
• Keep a verified previous version for every release so you can fall back to a local copy if config parsing fails.

A private repository does not guarantee that secrets stay private. If credentials are committed, deleting the file later will not remove them from version history. If you commit a secret by mistake, revoke or rotate it first, then address the history. Never post a download URL containing a token in a public issue or screenshot.

Option 3: Apply Local Overrides After Subscription Updates

Local overrides work well when you want proxies to follow the upstream subscription while keeping device settings unchanged. The client usually fetches the subscription first, then builds the final runtime config by merging settings or running a script. However, “override” is not a standard protocol supported by every Clash client. Check the actual client for file format, merge order, and scripting support.

On desktop, maintain the following device settings in the client’s merge-config or override feature. This snippet listens only on the local machine’s mixed proxy port; it does not set the system proxy or enable TUN.

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

If the client manages listening ports centrally, change them in its settings first to avoid conflicts between the UI and override file. Mobile VPN routing and the desktop system proxy are different mechanisms; there’s no need to force desktop port settings onto a phone just to “sync” them.

List merging is where things most often go wrong

rules, proxies, and proxy-groups are all lists. Depending on the client, a merge may replace an entire list or support prepending, appending, or script-based processing. Don’t assume that adding two local rules will preserve the thousands of existing ones. After making changes, inspect the final runtime config to make sure the original lists have not been cleared accidentally.

• Place custom direct-connection rules where they can match, usually before the final MATCH rule.
• Any group referenced by a new rule must exist. Group names must match exactly, including spaces and capitalization.
• Review the DNS config as a whole. Changing only enhanced-mode does not ensure that DNS routing works the same way on every platform.
• Keep TUN device names, route exclusions, and permission settings local to each device. Avoid applying settings across operating systems.

Update timing and maintenance effort compared

For one computer, one phone, and one tablet, start with a shared subscription for proxy updates, then keep separate local listening settings on the computer. Introduce a hosted rule set only when shared rules need frequent changes. This adds maintenance only where needed, without requiring a config-generation service from day one.

If all three devices are in the foreground, manually updating them is usually easier to verify than waiting for scheduled tasks. That does not guarantee a fixed sync time in seconds. Actual timing includes at least four parts: publishing, client scheduling, downloading, and reloading. Record when updates actually happen rather than comparing only the configured check intervals.

Deploy and troubleshoot: test the same connection

Five checks for your first rollout

1. Record your environment. Note the client name and version, plus the core name and version for each device. Avoid vague labels like “latest version.”
2. Save the previous config. Export a working config and note the currently selected groups. Store backups as files containing credentials.
3. Update one device at a time. Start with the computer, then move to the phone. Check each device’s download time and active config; don’t change every device at once.
4. Inspect the runtime config. Check mode, rule order, and referenced group names to confirm that the override made it into the final config.
5. Test a real connection. Visit the same domain on each device and compare the matched rule, group, and final proxy in the connection logs. Then test a site that should connect directly.

Same config, different routing results?

First, make sure all devices are in rule mode. Global mode does not route traffic using the same rule list. Next, check that app traffic is reaching the core: a desktop browser may use the system proxy while other apps do not, whereas a phone may route traffic through a VPN. Then compare DNS results, rule provider caches, and the current group selection.

The update succeeded. Why are the old rules still there?

Troubleshoot in this order: downloaded file → active config → merge result → core runtime config. Common causes include updating a subscription that is not enabled or a local override restoring old rules in the final step. Full subscriptions and HTTP rule sets may also have separate caches, so check the rule provider status after updating the subscription.

How can you roll back and keep useful troubleshooting details?

First save the error text and failed version, then switch back to the last working config. If the changes involved TUN or the system proxy, restore the relevant device settings too, so the system does not keep pointing at an inactive listening port after the client exits. For subsequent changes, modify one layer at a time: verify the proxy source, then shared rules, and finally enable local overrides. The goal of syncing across devices is to make routing policies traceable and device differences explainable, not to make every file identical character for character.