1. Separate Shared Config from Device-Specific Settings

Sharing a Clash config between a computer and phone makes sense for node sources, proxy group names, and routing rules—not the entire client data directory. The mihomo core used by Clash Meta reads the config and handles connections; the client separately manages subscription updates, system proxy settings, VPN permissions, and config overrides. Keep these two layers distinct.

For example, Windows can route the system proxy through 127.0.0.1:7890, while Android usually uses the client to create a VPN interface and capture traffic. Even when both devices use the same rules, traffic reaches the core differently. A successful sync means the rules and node sources match while each device handles traffic correctly—not that every setting is identical.

  • Shared config: proxy-providers, proxy-groups, rule-providers, rules, and DNS policies tested on both devices.
  • Device-specific settings: mixed-port, allow-lan, tun, listen addresses, secret keys for the controller API, and local file paths.
  • Client state: the currently selected node, latency test results, logs, cache, and VPN permissions. These are not included in config sync by default.

2. How the Three Sync Methods Deliver Updates

Method How updates reach devices Key limitation Best for
Subscription URL The client fetches updates over HTTP on a schedule or on demand Manage hosted content separately from client-side overrides Frequently changing nodes, with the phone mostly reading the config
Private Git repository Pull the latest commit, then import or reload the file Requires Git tools and a separate import step Frequent rule changes that need review and rollback
WebDAV A sync tool downloads the file, then you import it into the client File conflicts and applying a config are separate issues You already have private storage and mainly edit on one device

mihomo does not automatically pull new commits from a remote Git repository or watch WebDAV for changes. Check whether your client supports each source. Even if a client offers WebDAV backups, it may only back up settings and config indexes—not treat a remote YAML file as a live subscription.

3. Subscription Hosting: One Source, Local Overrides

First, check what the subscription returns

A full Clash config can include proxies, proxy-groups, and rules; a node list may instead be intended for use with proxy-providers. Some subscriptions return encoded node links, which mihomo cannot load directly as YAML. Use the same config format on both devices—don't rely on the URL suffix alone.

  1. In the computer client’s config manager, add a remote config using the actual subscription URL provided by the service, then trigger a manual update.
  2. Import the same URL on your phone and check the proxy group names and number of rules. If they differ, check the subscription format options and whether the service returns different content based on the client identifier.
  3. Put device-specific settings in local overrides associated with the config. Don’t edit the remote file directly; the next update may replace your changes.
  4. Set an update interval on each device. For example, if supported, you could set it to 24 hours. Mobile OS background limits mean scheduled updates won’t necessarily run on time.

The client usually controls how often it fetches the top-level remote config. In proxy-providers, interval: 3600 sets that provider’s update interval to 3,600 seconds; it does not replace the client’s full-subscription update setting. Rule providers have their own update intervals, so check those separately.

Privacy and Subscription Conversion Services

Giving a remote conversion service your subscription URL may let it read your node details. A self-hosted conversion service still needs safeguards for access, request logs, and caches. Add this layer only if you need to convert formats for your devices. If the original subscription already provides a mihomo-compatible config, importing it directly is usually easier to troubleshoot.

If you host your own full config, use HTTPS and access controls, and keep sensitive URLs out of logs. Clients that support authentication headers can use dedicated credentials; if a client only accepts a URL, protect that link carefully. Revoke or rotate the token if the URL leaks. Renaming the local config does not revoke access.

4. Private Git: Versioned Rules and Rollback

Git works well for maintaining custom domain rules, proxy group structures, and device-specific overrides. Store only reviewable config source files in the repository; manage subscription tokens, node passwords, and controller API keys separately on each device. A private repository limits access, but commit history, collaborator permissions, and CI logs still need attention.

You could use the following directory layout. base.yaml holds shared logic, while two override files hold device-specific settings. Organizing files this way does not merge them automatically: the client’s override feature or your own build process still needs to produce a valid config.

clash-config/
├── base.yaml
├── overrides/
│   ├── desktop.yaml
│   └── android.yaml
└── README.md

A Minimal Update Workflow on Desktop

Run these commands in your cloned repository. First check for uncommitted changes, then pull with fast-forward only to avoid an unexpected merge commit. After pulling, generate the runtime config according to your project’s conventions and test it before loading it.

git status --short
git pull --ff-only
git log -3 --oneline

mihomo -t -f ./runtime.yaml

runtime.yaml is the complete config generated by this workflow, not a file provided by Git. The test command requires mihomo to be installed locally. If the config references local provider files, use the same working directory as the actual runtime, specifying it with -d if needed. Passing the test only means the config can be checked; it does not guarantee that every node connects.

On your phone, use a trusted Git client to pull the file, then update it through the client’s local file import option. Don’t use a regular repository webpage URL as a subscription URL. Downloading files from a private repository usually requires authentication, which your client may not support.

How to Roll Back a Broken Config

Keep the current runtime config, then review the latest rule changes. For a commit already shared with others, use git revert to create a new commit that undoes it rather than rewriting history that other devices depend on. If a sensitive subscription has entered the repository history, removing that line from the latest version won’t eliminate the exposure. Rotate the credentials first, then deal with the repository history and copies.

5. WebDAV: Separate File Transfer from Config Loading

WebDAV is a good fit if you already have a NAS or private storage. A safer workflow is to let the computer write and the phone read. If both devices edit config.yaml, one upload can overwrite the other, or the sync tool may create conflict copies. Clash clients do not merge these files.

  1. Create a dedicated config directory in your storage service and give your phone read-only credentials, if the server supports that level of access.
  2. Upload the prepared config from your computer as a versioned file, such as config-2026-09-08.yaml, then update the agreed-upon distribution file.
  3. Download the file to your phone first, then load it through the client’s local file import option. If the client has a native WebDAV config option, verify that it actually updates the config contents.
  4. Keep the previous working file. If an import fails, restore the old file instead of repeatedly overwriting your only copy.

Don’t put WebDAV usernames and passwords directly in a URL. A standard “remote subscription” field may not support the authentication WebDAV requires. For an HTTP 401 error, check the credentials and client support; don’t work around it by disabling TLS verification. For certificate errors, fix the certificate chain, hostname match, or device clock.

6. Device-Specific Overrides: Ports, TUN, and Rules

Desktop Override Snippet

This device-specific snippet is for clients that support merged overrides; it is not a complete subscription you can import on its own. On desktop, keep system proxy integration enabled and leave TUN disabled to avoid changing both traffic-capture methods during the initial sync. If the client has controls for “Allow LAN” or ports, confirm that saving them doesn’t overwrite these values again.

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
tun:
  enable: false

Set the system proxy’s HTTP address to 127.0.0.1 and its port to 7890. If another local app is using that port, change it to 7891 and update both the system proxy and any manual proxy settings in apps. Don’t change only the YAML while leaving the system proxy on the old port.

Android Override Snippet

On your phone, override only the basic settings supported by both devices and let the client handle VPN traffic capture. Android clients differ in how they create and pass TUN file descriptors, so don’t copy desktop settings such as tun.auto-route, interface names, or route exclusions without checking compatibility.

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

On startup, grant Android VPN permission and check the client’s per-app proxy list. Even with identical remote rules, apps excluded from the VPN won’t go through mihomo’s rule matching. Using port 7890 locally won’t conflict with your computer because the devices are separate.

Don’t Assume Rule Overrides Are Appended

How YAML mapping and list items are merged depends on the client. The following minimal example replaces the entire rules list and assumes the final config already has a proxy group named “Select Node.” To put a single rule at the top, use an explicit prepend-rules feature if your client provides one; don’t assume lists are concatenated.

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,Select Node

Rules are evaluated in order, so MATCH belongs at the end. This snippet only demonstrates direct connections to the LAN and a fallback; it does not include the subscription’s other routing rules, which would be lost if you replaced the list with this. Domain matching also doesn’t resolve home.arpa; local domains still need a reachable local DNS server. Since the devices may be on different networks, keep DNS upstreams and internal DNS addresses in the device-specific layer.

7. Verify Sync and Troubleshoot Common Issues

Test one device before updating the other. Don’t update the subscription, replace DNS, enable TUN, and change rule order all at once, or it’ll be hard to identify the cause if connections fail. These checks don’t rely on made-up speed test results; you can do them in the client UI and logs.

  • Same source: Confirm both devices use the same subscription or Git commit. For WebDAV, check the downloaded filename and modification time.
  • Correct merge: Check the final runtime config, not just the subscription source. Confirm the port is 7890, the mode is rule, and the overrides haven’t unexpectedly removed any proxy groups.
  • Rule matching: Visit a domain with a known rule and check the matched rule and final policy in the connection log. Don’t compare exit IP addresses alone.
  • Local network: Visit a working router admin address or internal service and confirm both LAN rules and DNS work.
  • Repeatable updates: Manually update the subscription again and confirm the device overrides remain intact and rule order hasn’t changed.

What to Check When Desktop Works but Phone Doesn’t

First check whether the Android VPN is running and whether the target app is excluded, then check for config load errors. A “policy does not exist” error usually means a proxy group referenced by a rule is missing or misnamed. If a local file can’t be read, check whether the shared config contains a desktop-only path. If the devices support different core features, note the client and core versions on each and troubleshoot the field named in the error—don’t assume compatibility based on the client’s name alone.

Choosing the Right Setup

If you only need nodes to update with the service, use the same subscription on both devices with local overrides. If you frequently change rules and need to review diffs, manage shared config source files in a private Git repository. If you already have private storage and mainly edit on a computer, use WebDAV to distribute files. You can also combine the methods: manage rules in Git, get nodes from a subscription, and keep permissions and port settings on each device. Give each layer a clear update owner so multiple sources don’t overwrite one another.