Share a Clash config across desktop and mobile: subscription updates, hosting, and manual sync

Set the sync scope first: share sources, keep device settings local

Desktop and mobile devices can use the same Clash subscription, but syncing the entire client data directory is not recommended. A safer setup is to maintain proxies, proxy groups, and rules from a shared source, while configuring the system proxy, TUN, listening ports, and UI preferences separately on each device. That way, a subscription update won’t also copy desktop network interface settings to your phone.

“Shared config” doesn’t mean “shared runtime state.” The proxy selected manually on your computer, your phone’s current connection, speed test results, and traffic statistics are usually stored locally by each client. They won’t sync just because both devices use the same subscription URL. Your provider’s device, concurrent connection, and data limits still apply, so check your account terms first.

Option 1: Import the same subscription on desktop and mobile

Import it separately; don’t copy the client directory

1. Copy the Clash or mihomo subscription URL from your provider’s account page. If multiple output formats are available, choose one supported by the core on both devices.
2. Open the config manager on your computer. For example, in Clash Verge Rev, paste the URL into the link field on the Subscriptions page, import it, and select the new config.
3. Import the same URL separately on your phone. In a typical Clash for Android interface, go to Configurations → + → Import from URL, enter a name and URL, set the automatic update interval, and save.
4. Manually update on both devices once. Confirm that the proxy list and proxy groups have loaded, then enable the system proxy or VPN mode on each device.

Client versions and translations may change button labels. Look for options such as “Configurations,” “Subscriptions,” or “Import from URL.” Don’t paste a subscription URL into the HTTP proxy server field. The response may also vary by request parameters or client identifier, so the same URL doesn’t guarantee byte-for-byte identical files on both devices.

Start with a 24-hour update interval

For most personal devices, once every 24 hours is a good starting point. If the field is in minutes, enter 1440; if it’s in seconds, enter 86400. Don’t confuse the client’s subscription update interval with a provider’s interval in YAML—they update different layers of data.

Background tasks on phones are affected by battery-saving settings, network conditions, and system scheduling, so timed updates aren’t exact. After a long shutdown or sleep, update manually before deciding that a proxy is broken. The expiration date on your account page, the subscription’s last update time, and the time of the last proxy speed test are separate pieces of information.

• Full subscription: The client downloads the entire config again, potentially replacing proxies, proxy groups, and rules.
• Proxy provider: proxy-providers updates the proxy list; it doesn’t automatically replace all rules in the main config.
• Rule provider: rule-providers updates rule data, while the main config determines how those rules are referenced.

Keep custom rules after updates with persistent overrides

Editing a downloaded remote YAML file directly often means your changes will be overwritten at the next subscription update. Put rules you need to keep in a persistent override, merged config, or extension script supported by your client. Features vary by client; not every Clash-based app has the same override mechanism.

Start by adding a single rule. Update the subscription, then inspect the final effective config to verify the merge order before adding more. This mihomo-style snippet illustrates rule ordering; it is not a complete subscription you can import on its own:

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Proxy Selection

Proxy Selection must match a proxy group that actually exists in the final config. If the provider renames the group, update this reference too. Rules are evaluated from top to bottom, with MATCH last. Adding a direct-connection rule after an existing MATCH won’t have the intended effect.

Know the difference between merging a list and replacing it

• Some merge features replace the entire rules array instead of appending individual entries. After saving, check that the existing routing rules are still there.
• If your client supports “prepend rules,” adding LAN exceptions before the existing rules is usually easier to maintain than rewriting the whole list.
• Save desktop and mobile overrides separately. Don’t assume an extension script that works on desktop will run on your phone.

For complex rules that need to stay identical across devices, maintain the main config and rule sources together. If only a few device-specific exceptions are needed, separate, concise local overrides are easier to understand.

Option 2: Maintain config in a private repository and distribute it through a controlled URL

A private repository is useful for tracking rule changes, comparing config versions, and rolling back. But making a repository private doesn’t mean a client can read a raw file URL just by pasting it in. A browser’s signed-in session isn’t passed to Clash, and a web page that requires login isn’t a YAML URL you can import directly.

Use the repository for version control and the distribution endpoint for access

1. Store credential-free base rules, group structure, and notes on device differences in the repository. First make sure the files contain no proxy passwords or subscription tokens.
2. Use a controlled release process to generate the final YAML, injecting sensitive values from protected storage rather than writing tokens into repository history.
3. Serve the config over HTTPS and use an authentication method the client actually supports. If the client can’t send the required headers, download the file through a controlled process and import it locally. Don’t disable access controls just to make importing easier.
4. Update one test device first and check that the config parses and connections work, then refresh the others. Keep the last known-good config for rollback.

Raw file URLs from some hosting services may expire or return a login or redirect page. If YAML parsing fails, first check that the response is the config itself, not HTML. Logs may include the full request URL, so redact tokens and personal information before sharing them.

If you don’t need automatic distribution, you can use a private repository just to store rule versions, then have each device owner download and import the file. This removes the online distribution step, but you’ll still need to track which version each device is using.

Option 3: Export YAML and import it manually on another device

Manual sync works well when replacing a phone, testing temporarily, or working without a reliable connection. It transfers a snapshot from the time of export and may not preserve the remote subscription URL or automatic update settings. Before exporting, check whether you’re exporting the original subscription, the final runtime config, or a full client backup—these are not interchangeable.

1. Update the subscription on the source device and confirm the current config works.
2. Use the client’s config export or open-config-file feature to get the YAML. Don’t copy the entire application data directory while the app is running.
3. Transfer the file using built-in nearby sharing or another controlled file-sharing method. Avoid public share links.
4. Choose “Import from file” in the target client. Once parsing succeeds, check the proxy groups, DNS, and traffic routing settings again.
5. Record the export date, for example profile-2026-09-09.yaml. If the file is only a temporary transfer, delete it from your downloads folder and chat attachments after importing.

If you want automatic updates after a successful manual import, add the original remote subscription separately. Don’t treat a local file path as a subscription URL. Clients handle exported files differently, so don’t assume the remote source information will be carried over.

Cross-platform settings: check ports, TUN, and DNS separately

Clash config is an ecosystem format, but not every client supports exactly the same fields. Protocol support and config options can differ between the original Clash core, Clash Meta (now called mihomo), and other compatible clients. Check the version on both devices in the About or core information screen before troubleshooting; it’s more effective than reinstalling repeatedly.

Identical DNS settings don’t mean identical network conditions

When a phone switches to cellular data, its DNS upstream may not be reachable in the same way as on home broadband. If the config uses Fake-IP, check that both devices support the same enhanced-mode and filtering options. Local network name resolution also depends on the current network’s DNS service. Don’t sync a temporary Fake-IP mapping database from one device.

Android typically routes traffic through VpnService, which requires system permission; desktops may use the system proxy or TUN. If the same config produces different results, first check whether traffic is reaching the core, then check whether the same proxy is selected by the rules.

Troubleshoot mismatched results across four layers

1. Source layer: Check the subscription URL, output format, and last update time. After a failed update, a client may keep using the old config. Seeing proxies in the list doesn’t mean the update succeeded.
2. Merge layer: Compare the effective proxy groups and rules. Make sure an override hasn’t replaced the whole list, group references still resolve, and a catch-all rule isn’t matching too early.
3. Traffic routing layer: Confirm that the system proxy or TUN is enabled on desktop and VPN permission is granted on mobile. If the connection log shows no requests from the target app, troubleshoot traffic routing first.
4. Network layer: Select the same proxy on both devices and access the same destination. Record the matched rule, egress, and error logs on each. Then compare results on the same Wi-Fi and on cellular to distinguish config issues from network differences.

For routine maintenance, use a consistent process: update one device, test commonly used websites, LAN services, and DNS, then update the others once everything checks out. If something breaks, roll back the config version instead of changing proxies, DNS, TUN, and rules all at once.

The recommended approach is still to maintain each layer separately: update proxies through the subscription, manage shared rules from a traceable source, and keep device permissions and traffic routing local. For more steps to check routing and connections, see Troubleshooting. For help with fields such as proxy groups and rule providers, see the Glossary.