Sync Clash Configs Across PC and Mobile: Subscription URLs, WebDAV, and Private Git

Syncing Clash Across Devices: Decide What to Share

To use one config on a computer and phone, first distinguish between sharing the same proxy sources, routing rules, and client state. The same subscription URL can provide both devices with the same proxies, but it won’t sync the selected proxy, system proxy toggle, or TUN permissions. WebDAV and Git transfer files; they don’t import or activate them in the client.

Clash GUI clients manage configs and connect to the system; the core reads configs, matches rules, and establishes connections. Clash Meta is now maintained under the name mihomo. Even clients using mihomo can differ in core version, config override behavior, and UI features. Sync only the config content both clients support, not the entire application data directory.

What to Share and What to Keep Local

• Good candidates to share: proxy subscription sources, proxy group names, rule order, rule-set URLs, and DNS policies supported by both devices.
• Keep local: system proxy and TUN toggles and permissions, startup settings, network interface names, log locations, and client window preferences.
• Check separately: mixed-port, external-controller, secret, and LAN listening settings. Don’t carry a desktop management interface over to a phone unchanged.

When to Use Each Sync Method

Choose a method based on what you need to sync. For proxy updates alone, a subscription URL is simplest. To keep a recoverable config copy, use WebDAV. For ongoing rule maintenance and change history, a private Git repository offers better visibility. You can combine methods, but define which location is the source of truth.

“Supports remote subscriptions” doesn’t mean “supports WebDAV sign-in” or “can read a private repository directly.” If a client can’t send authentication credentials, a protected file URL won’t work as a regular subscription URL. Before setting things up, check the current version’s subscription, file-import, and authentication features—not just the client name.

Subscription URLs: Import the Same Source on Each Device

Import and Update Steps

1. Get a subscription URL from your provider that’s compatible with the target core. Check whether it returns a complete Clash config, a proxy list, or another format. A proxy-only list needs to be assembled into a usable config by the client or a config template.
2. On both your computer and phone, add a remote config in the subscription manager and paste the same URL. Depending on the version, the UI may call this “Subscriptions,” “Configs,” or “Profiles.”
3. After downloading, select and activate the config on each device. Check that the proxy groups, rules, and proxies are all present, then enable each device’s required system integration.
4. If scheduled updates are available, start with a 24-hour interval. If proxies stop working or your provider announces changes, refresh manually and confirm the last-updated time has changed.

A 24-hour interval is a practical starting point, not a default used by every client. Mobile operating systems may restrict background tasks, so even with auto-updates enabled, open the app before important use and check when it last updated. If the devices haven’t refreshed at the same time, their proxy lists may differ briefly.

Complete Subscriptions vs. proxy-providers

When a GUI client updates a remote config, it usually fetches the entire config file again. mihomo’s proxy-providers, by contrast, define proxy providers within a config. For an HTTP provider, interval: 3600 sets a 3,600-second refresh interval. It doesn’t reload the entire client subscription every hour or sync app settings. Choose what to update based on how your config is structured.

If your remote subscription includes rules, editing the downloaded YAML directly may not last: the next update can overwrite your changes. For custom routing, use a client-supported local override, merge, or script mechanism, and check which fields it affects. If your computer and phone don’t support the same override mechanism, generate a final config on a controlled server that both can read.

WebDAV Backups: Transfer Config Files and Keep Recovery Copies

WebDAV provides remote file access, making it useful for saving a prepared config to personal storage and restoring it on another device. It transfers files; unless the client explicitly supports automatic restoration, you’ll still need to download, import, and activate the file.

One-Way Publishing Is Easier to Troubleshoot Than Two-Way Overwrites

1. Create a dedicated folder in your storage service, such as clash-config/. Use HTTPS and a dedicated app password. Give the publishing device write access and, where possible, limit reading devices to read-only access.
2. Export the YAML you want to share from your computer. Check for sensitive fields such as proxy passwords, subscription tokens, and controller keys. Include only what’s needed for your backup.
3. First upload a dated file, such as shared-2026-08-14.yaml, and keep the previous working copy. After confirming the file is complete, update the stable filename using a method supported by your storage service.
4. If your phone supports WebDAV restore, use the relevant option. Otherwise, download the file with a WebDAV-enabled file app, then import it from your proxy client’s local-file option.
5. After activation, check the rules and connection logs. If restoration fails, import the previous config rather than deleting your backups right away.

If both devices write to shared.yaml, a later upload may overwrite earlier changes. Conditional writes, locking, and conflict handling depend on the WebDAV server and client; don’t assume YAML will be merged automatically. A safer setup is to publish from your computer and read from your phone, keeping temporary proxy selections on the phone local.

Back Up Configs Separately from App Data

A full client backup may include databases, internal config IDs, and system paths, so it’s generally best restored by the same client. When moving between Windows, macOS, and Android, export a readable config file instead. For iOS, check which formats and import paths your proxy client actually supports; don’t assume it can read any mihomo config directly.

If you need to keep a credential-containing copy in remote storage, encrypt it before uploading to WebDAV. Use the encrypted file only for recovery: decrypt it on a trusted device first, then import it into the client. It can’t be fetched directly as a regular YAML subscription.

Private Git Repositories: Track Rule Versions and Device Differences

Git is useful for tracking why rules changed, which version to roll back to, and what differs between desktop and mobile configs. Keep credential-free rule source files in the repository; store subscription URLs and proxy passwords locally or in a controlled deployment environment. A private repository limits access, but it won’t automatically remove secrets from commit history.

Start with a Rule File That Contains No Proxy Credentials

This minimal config illustrates a shared structure. example.com is a documentation-only example domain. The config has no proxy nodes, so all connections go direct; it’s not a substitute for a provider subscription. Once you add real proxies, make sure the client’s merge mechanism or config-generation workflow preserves the relevant proxy groups and node definitions.

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

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

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

7890 is an example local mixed proxy port that accepts HTTP and SOCKS connections. If the port is already in use, choose an available one on your computer and make sure the system proxy uses the same port. Mobile clients may manage their own listening ports and VPN integration, so whether this field overrides a local setting depends on the client.

Keep a Local Version History

Install Git and configure your commit identity, then run the following command in the directory containing policy.yaml. This creates local history only. To sync with a private remote repository, configure SSH or an access token using the repository host’s instructions.

git init
git add policy.yaml
git commit -m "Record shared routing rules"

git diff -- policy.yaml
git log --oneline -- policy.yaml

• Store subscription credentials in a separate private local file and exclude it with .gitignore. Ignore rules don’t remove files that are already tracked.
• Review git diff before publishing and make sure only the intended rules changed. Keep desktop- and phone-specific TUN settings out of shared rule files.
• For devices that only need to read updates, use read-only deployment credentials. Don’t give every phone write access to the repository.
• To undo a shared change, use git revert to create a reversing commit, then regenerate and import the config. This preserves the change history.

Proxy clients generally don’t run git pull, and a private repository’s web page URL isn’t a raw YAML file URL. On a phone, download and import the file manually, or use a controlled deployment workflow to combine rules and subscriptions into an authenticated HTTPS config endpoint. In either case, verify that the client supports the authentication method and hide tokens from build logs.

Validate Updates: Matching Configs Don’t Guarantee Matching Connectivity

Validate on one device before publishing to the other. Change one layer at a time: first confirm the file was fetched, then that the config loaded, and finally that system integration and network behavior work as expected. This helps distinguish sync failures from core compatibility and local permission issues.

1. Check the source file: Make sure the download is YAML, not a login page. HTTP 401 usually indicates an authentication failure, 403 means access was denied, and 404 means the resource wasn’t found. Check the URL and permissions with your storage or hosting provider.
2. Check parsing: Review the client’s error log for indentation errors, duplicate fields, or unsupported protocol options. Every name referenced by a proxy group must exist, and rules are still processed in order, with the first match taking precedence.
3. Check activation: A successful download isn’t enough; confirm that the selected file has been reloaded. Whether proxy selections are restored depends on client caching and whether proxy group names remain unchanged.
4. Check system integration: On a computer, only apps that honor the system proxy will use it. Mobile platforms such as Android typically connect through a VPN interface, and the required permissions must be granted on the device.
5. Check the actual connection: Use the same test destination and compare matched rules and policies in both devices’ connection logs. A page loading confirms a successful connection, but doesn’t prove it used the intended proxy.

Even with identical proxies and rules, a computer and phone can behave differently due to Wi-Fi, cellular networks, DNS settings, or IPv6 routing. If “the computer works but the phone doesn’t,” test both on the same Wi-Fi first, then check mobile permissions, supported proxy protocols, and error logs. Avoid repeatedly overwriting the shared config.

Recommended Setups and Maintenance for Multiple Devices

Two Devices: Same Subscription, Local System Integration

Import the same subscription on your computer and phone, and check periodically that updates are working. Keep system proxy, TUN, and startup settings local to each device. If you rarely change routing rules, save a dated YAML backup before an update or major change; there’s no need to add a repository and publishing workflow.

Long-Term Rule Maintenance: Git for History, Subscriptions for Updates, WebDAV for Backups

Put credential-free rules in a private Git repository and keep proxies on the subscription. Publish validated configs through a controlled process and save recoverable copies to WebDAV. Validate and publish after rule changes, let subscriptions update on the client’s schedule, and create backups after confirming the new config works. These three update cycles don’t need to be tied together.

• After each update: Record the config source, update time, and active status. Test one direct rule and one rule expected to use a proxy.
• When changing clients or cores: Import a test copy and check support for protocols, rule sets, DNS, and TUN fields before replacing your everyday config.
• If a device is lost or retired: Revoke its WebDAV and repository credentials. If its subscription URL may have been exposed, reset it through your provider.

For basic setup steps, start with the subscription import guide. For rule order and core differences, see the rules reference and core guide. The key to syncing across devices is to establish clear sources for proxies and rules, while managing ports, permissions, and system integration separately on each device.