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

1. Separate shared configs, node subscriptions, and client settings

Using the same subscription URL on a computer and phone does not mean every setting is synced between them. Mihomo is the core that handles proxy connections, rules, and DNS. The client imports configs, schedules updates, saves interface preferences, and requests system permissions. WebDAV backups and Git pulls are usually handled by the client or external tools—not synced automatically by the Mihomo core.

Before you begin, check what the subscription returns. A full config typically includes fields such as proxies or proxy-providers, proxy-groups, and rules. A subscription containing only node details needs to be converted by the client or referenced from another main config. Importing a node list as a complete config may leave you with nodes but none of the expected proxy groups or rules.

• Good candidates for sharing: proxy group names, routing rules, rule-set references, and node sources verified for compatibility.
• Keep these settings on each device: system proxy toggle, TUN permissions, Android per-app lists, and client window and startup settings.
• Review these individually: DNS listen addresses, inbound ports, network interface names, external controller interfaces, and local file paths.

2. How the three methods update—and when to use them

You can combine all three, but don’t let multiple tools write to the same active file. For example, keep rule source files in Git, publish the generated config through a subscription URL, and back up client preferences with WebDAV. Each type of data then has a single source of truth, making overwrites easier to troubleshoot.

3. Subscription URLs: one source, updated on each device

After importing, check the contents—not just the update timestamp

1. Get a subscription URL for Clash or Mihomo from your provider’s dashboard. Confirm that your plan allows multiple devices and simultaneous connections.
2. Import the remote URL through the config manager on both your computer and phone. Menu names vary by client; look for “Import from URL” or the equivalent remote-config option.
3. Run an update manually and check the proxy group names, number of rules, and currently active config. A successful download does not mean the client has switched to that config.
4. On both devices, enable the system proxy or grant VPN permission. Make a web request, then check the connection log for the matched rule and exit node.

As a starting point, set the client’s full-config update interval to 24 hours. This is a recommendation, not a fixed Mihomo default. Follow any frequency limits set by your provider. Android background scheduling, battery restrictions, and computer sleep can all delay updates, so refresh manually and check the result when nodes change.

Full-config updates and provider updates use separate timers

A client’s scheduled subscription download usually replaces or reimports the full config. In Mihomo, interval for an HTTP proxy-providers entry controls how often that node source is refreshed, in seconds—for example, interval: 3600 means one hour. Set update intervals for HTTP rule sets under their corresponding rule-providers entries. Changing these fields does not alter the client’s full-config update schedule.

To preserve custom rules, use an override or merge feature explicitly supported by your client. Don’t assume a rule inserted into the downloaded YAML will stick around; the next subscription update may overwrite the file. Check the order of merged rules, too—especially that the fallback MATCH rule doesn’t intercept requests before later rules can apply.

4. WebDAV: better for backup and restore than automatic two-way sync

WebDAV provides remote file access, but backing up, restoring, and continuously syncing in both directions are three different operations. A client may support WebDAV but only back up its own database, with no way to import that backup into another client. Before migrating, check that both clients support the same backup format and whether the backup includes subscription URLs and sensitive credentials.

Set up backups you can restore

1. Create a dedicated folder in your storage service. Give the sync tool an account or app password with access limited to that folder.
2. Connect using an HTTPS URL. HTTPS typically uses TCP port 443; if your service specifies another port, use the address it provides.
3. Upload a backup from your computer first, then download or restore it manually on your phone. Save the phone’s current config before restoring; don’t overwrite your only working copy.
4. After restoring, check the subscription, proxy groups, and local permissions. Confirm VPN permission and system proxy status on the destination device.

If you use an external file tool to sync YAML, download the remote file to a staging folder and verify it before importing it into the client. Don’t let the sync tool continuously write to a file the client is actively reading. This prevents an interrupted transfer or file conflict from immediately replacing the working config.

How to handle edits on both devices

Suppose you change rules on your computer at 09:00, then edit the subscription on your phone while offline at 09:10. Both devices later upload a backup with the same name. The newer modification time doesn’t prove that the backup includes the other device’s changes, and device clocks may differ. Save both copies first, compare the subscription and rules, then choose one as the primary version.

Binary or encrypted backup archives can’t be merged line by line like text files. A safer approach is to designate one device to publish backups and have the others restore them. If backups contain credentials, use the client’s encryption feature. HTTPS protects data in transit; it doesn’t mean files are encrypted on the server.

5. Private Git: track rule changes and manage credentials separately

Git is a good fit when you regularly tweak domain rules, review changes, or roll back to an earlier version. It records each text change, so you can see who changed a rule, when, and why. A private repository still has access boundaries for accounts, collaborators, and automation. Never commit node passwords, subscription tokens, or controller API keys.

Organize files before setting up sync

The layout below is one way to organize source files, not a directory convention that Mihomo recognizes automatically. Mihomo still needs to load one complete, valid config. Split files must go through an explicit assembly process; don’t assume the core will merge them for you.

proxy-config/
├── base.yaml
├── rules/
│   └── local.yaml
├── devices/
│   ├── desktop.yaml
│   └── android.yaml
├── .gitignore
└── README.md

Use base.yaml for shared structure, rules/ for rule source files, and devices/ for platform-specific differences without secrets. Keep actual subscription URLs and generated configs outside the repository. The ignore rules below apply only to the filenames used in this example; they don’t replace a pre-commit review.

# .gitignore
secrets/
private-provider.yaml
runtime.yaml
*.log

Use the same steps for every change

1. Run git pull --ff-only to get remote updates first. If Git reports divergent branches, resolve the differences instead of forcing an overwrite.
2. Edit the rules, run git diff to review the changes, and make sure no real subscription URLs or node passwords were included.
3. Generate runtime.yaml using your project’s workflow, then validate it with the Mihomo version used on the target device.
4. Once validation passes, commit the source files and push them to the private repository. Other devices can then pull, regenerate, and import the config.

mihomo -v
mihomo -t -f runtime.yaml
git diff --check
git add base.yaml rules/local.yaml
git commit -m "Update local domain routing rules"
git push

mihomo -t -f runtime.yaml tests the config, but it doesn’t confirm that remote nodes are reachable or TUN permissions are ready. If the config references relative paths or external rule files, make sure the working directory and dependencies are also in place. On Windows, use the actual core executable name; the path to a client’s bundled core depends on how it was installed.

A phone may not have Git tools or access to arbitrary directories. If there’s no reliable pull-and-deploy workflow, maintain the repository on a computer and publish the result at a controlled HTTPS URL for the phone to subscribe to. Don’t put a repository access token directly in a subscription URL just to sync configs.

6. Keep ports, TUN, and DNS settings platform-specific

“Use the same config” is better understood as sharing routing logic, not making every field identical. Desktop operating systems can use a system proxy; Android clients typically route traffic through VpnService. Their permissions, routing, and per-app controls work differently.

Check how device overrides are merged, too. Some clients replace the entire dns section; others merge mappings but append or replace the rules array. Don’t rely on the few lines shown in the override editor—inspect the final active config. Android per-app proxying also depends on installed app package names, so desktop process rules may not carry over.

7. Resolve update conflicts, roll back, and verify the active config

Rules disappear after an update

First check whether the rule lives in the remote subscription, a client override, or a temporary generated file. Then see which layer the update replaced. Add a comment to your source file, such as # profile-revision: 2026-08-23-01, to identify the release. It doesn’t affect routing; check the final config and logs to confirm it was loaded.

Works on the computer, but the phone can’t connect

Compare the active config name, update time, core version, node source, and selected proxy group. Then check the phone’s VPN permission and background restrictions. The same subscription doesn’t guarantee the same node is in use at the same time; manual selections and health-check status may be stored locally on each device. Test with the same exit node first to reduce variables.

The new config fails to load

1. Keep the failed file and error log, and note the field or line number that caused the error.
2. Switch back to the last validated config to restore connectivity. Don’t change several settings at once.
3. With Git, compare recent commits. With WebDAV, restore a separate historical copy. For subscriptions, check whether the provider offers version history.
4. After fixing the issue, test on one device before publishing to the others.

At a minimum, final verification should confirm three things: the core can load the config, requests that need a proxy match the expected policy, and requests that should go direct aren’t routed through a proxy by mistake. If shared settings include DNS or TUN changes, test name resolution and connectivity on both Wi-Fi and mobile data. A successful subscription update alone doesn’t prove the whole config is working.

8. Choose a sync method that fits how you maintain configs

• Mostly use a provider subscription: Import the same URL on both devices and set an update schedule for each. Use local overrides for custom rules and keep an exported copy.
• Mostly need to migrate or reinstall: Choose a WebDAV backup supported by your client. Verify the restore format before deciding whether to enable automatic backups.
• Mostly maintain custom routing rules: Keep text source files in private Git, validate changes before publishing, and give the phone only the ready-to-use result.

For long-term maintenance, it matters more to know where the source files live, who edits them, how changes are validated, and how to roll back than to have every device overwrite every other device in real time. Maintain shared rules centrally, handle platform permissions locally, and keep a working copy before updating so you can trace problems to the right step. For more on config fields, see Rules and Configuration. For client installation and permissions, see the Setup Guide.