Share Clash Configs Across Mac, iPhone & iPad: Remote Profiles and iCloud Sync

The short answer: share rules, keep device settings separate

For long-term use across Mac, iPhone, and iPad, start with one shared remote config source and device-specific local settings. iCloud Drive works for manually transferring files, while a private Git repo is useful for tracking and reverting rule changes. Each method syncs something different: an updated file does not mean the client has applied it.

“The same config” should first mean the same proxy sources, policy group names, and routing rules—not identical YAML on every device. Don’t copy macOS listener ports, TUN routes, or helper-service settings straight into an iOS client. And an iPhone or iPad app may not read Clash YAML at all.

Before syncing: check the core, config layers, and local state

Apple silicon doesn’t determine the config format

Choose an arm64 build for an Apple silicon Mac and an x86_64 build for an Intel Mac. This affects which program runs, not YAML syntax. Config compatibility depends on the core and client implementation. The original Clash, Clash Meta (now called mihomo), and iOS clients built on other cores may differ in their support for protocols, rule sets, DNS, and TUN fields.

On each device, note the client version, core version, config name, and last successful load time. Matching app versions don’t guarantee matching cores. A successful subscription update only means the download may have completed; check the parse result and which config is active.

Split the config into three layers

• Shared: Proxy sources, policy group names, domain and IP routing rules, and rule-set URLs. Keep these as consistent across devices as possible.
• Device settings: Listener ports, LAN access, TUN, DNS interception, and log level. Set these separately for each system and network.
• Runtime state: Selected proxies, latency results, and connection history. These usually live in the client’s database and won’t sync automatically with the YAML file.

For example, having a policy group called “Everyday Proxy” on every device doesn’t mean they’ll select the same proxy. To use the same exit, check the group’s current selection on each device. Automatic testing groups may also choose differently depending on Wi-Fi, cellular coverage, and when the test runs.

Method 1: Use one remote profile and update each device separately

A remote profile is usually the easiest option for everyday use: a trusted HTTPS URL serves the config, and each device fetches it separately. First check what it returns: full Clash YAML, a proxy list only, or a Base64-encoded proxy string. The latter two aren’t complete configs with rules and policy groups, so you can’t use them as-is.

Initial import and update steps

1. In the Mac client’s config manager, add a remote profile, paste in the URL, and give it a clear name, such as “Shared Apple Rules.”
2. After downloading, check the parse log and make sure the required sections are present, including proxies or proxy-providers, proxy-groups, and rules. Then set it as the active config.
3. In the iPhone and iPad clients, add the same source through the remote-config import option. If the client doesn’t support that format, use the format provided for it—don’t just change the file extension.
4. Update and reload on all three devices, then compare rule counts, policy group names, and load errors. Don’t rely on the displayed config name alone.
5. Finally, test one direct connection and one proxied connection. Check the connection logs to confirm which rules matched and which exit was used.

Menu labels vary by client—“Config,” “Profiles,” or “Subscriptions”—so there’s no single set of steps for every app. Updating a config is also separate from toggling the system proxy or VPN. Some clients require you to switch profiles or reconnect the tunnel before the new config takes effect.

Updating a full profile is different from updating proxy providers

A client’s “auto-update subscription” option usually refreshes the entire config. mihomo’s proxy-providers, on the other hand, refreshes provider contents. Even if interval: 3600 means the provider is checked every 3,600 seconds, it won’t update the main config’s rules. Likewise, updating rule-providers refreshes the relevant rule set, not the entire YAML file.

For custom rules, use a local override, merge feature, or scripting mechanism that the client explicitly supports. Editing a downloaded YAML cache directly may not stick: the next profile update can overwrite your changes. Not every client supports overrides, so check whether they apply before download, after download, or at load time.

Method 2: Sync files with iCloud Drive, then import them manually

iCloud works well when you maintain one config and occasionally send it to two other devices. It syncs files; it doesn’t validate YAML or guarantee that a client watches for file changes. When you import through the system file picker, the app may copy the file into its own sandbox. Changes to the original won’t necessarily update that copy.

Set up a clear file handoff process

1. On your Mac, open System Settings → Apple Account → iCloud → iCloud Drive and make sure syncing is enabled. Older macOS versions may label this “Apple ID.”
2. In Finder, create a Clash-Shared folder in iCloud Drive and save shared.yaml as UTF-8. Avoid editors or save options that add rich-text formatting.
3. On your iPhone or iPad, open Settings → Apple Account → iCloud → iCloud Drive and turn on Sync this iPhone or Sync this iPad.
4. Go to Files → Browse → iCloud Drive → Clash-Shared. Wait for the file to finish downloading; seeing its name isn’t enough.
5. In the client, use its local-file import option to select the YAML. Check the imported name, parse result, and active status. After editing the source file, repeat the import or refresh process.

These steps use the labels found on recent OS versions; menus may change between releases. If iCloud Drive doesn’t appear in Files, check your account and iCloud Drive settings first. Repeatedly creating new configs won’t help diagnose cloud sync.

Use a revision marker to confirm you have the latest file

You can keep a comment at the top of the YAML and check it in clients that can show the source text. It’s only for manual identification: it won’t affect routing or necessarily appear in the client’s config list.

# config-revision: 2026-09-09-r1

• Agree that only the Mac edits the master file, while the iPhone and iPad only import it. This helps avoid conflicts from simultaneous edits.
• Keep the previous working file—for example, shared-2026-09-08.yaml. Once all three devices are working, clean up older copies.
• If the app can’t keep accessing the iCloud file, reauthorize access through the system file picker or import it again. Don’t assume an old access grant will remain valid forever.

Method 3: Use a private Git repository to manage rules and rollbacks

If you frequently change routing rules, Git is useful for tracking edits, reviewing diffs, and restoring earlier versions—not for running Git automatically on iOS. A safer approach is to keep reviewable rules and templates in the repo, let the Mac fetch them and generate the final config, then deliver the result to phones and tablets by remote URL or file import.

Store rules and credentials separately

Put custom rules in rules.yaml and keep subscription URLs and locally generated files in a directory that isn’t committed. Here’s a sample .gitignore; adjust filenames to match your build process.

secrets/
runtime/
*.local.yaml
.DS_Store

.gitignore only affects untracked files; it won’t remove credentials already in commit history. If a token was committed, revoke or rotate it on the service first, then clean up the repo history. A private repo restricts access, but avoid storing long-lived subscription credentials in version history.

Review changes on the Mac, then distribute them to other devices

These commands assume the repository is already cloned, the remote is named origin, and the shared branch is main. Check the working tree, then review the remote rule changes. If you have local edits in progress, save and resolve them first rather than overwriting them.

git status --short
git fetch origin
git diff HEAD..origin/main -- rules.yaml
git pull --ff-only

After updating, inspect the generated config on your Mac and test it in the actual client. If the mihomo command-line tool is installed, validate the final file with:

mihomo -t -f runtime/shared.yaml

Passing validation means the config meets that core’s checks. It doesn’t prove that every proxy works or replace compatibility testing in the iOS client. Next, publish the config or put it in iCloud for the other devices. Remote rule sets must also use a supported behavior and file format; a regular rules snippet isn’t automatically a valid provider file of every type.

Raw file URLs in private Git repos often require authentication or involve redirects, caching, or expiring access. Don’t assume a web page URL pasted into the client will download YAML; check that it returns the file contents, not a sign-in page. If client authentication can’t be set up securely, “fetch on Mac, distribute the file” is easier to maintain.

What to keep local on Mac, iPhone, and iPad

Set clear boundaries before syncing rules to avoid cases where the Mac works but the phone loses connectivity. The snippet below shows local settings for Clash-family cores that support these fields; it isn’t a complete config with proxies and policy groups. If the client manages ports in its GUI, use the settings in its final effective config.

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

Port 7890 is an example, not a universal default. Even with the system proxy enabled on a Mac, only apps that honor that setting are affected; TUN coverage depends on routes and exclusions. Syncing a config won’t grant macOS helper-service permissions or authorize a VPN configuration on iOS.

Don’t copy DNS settings blindly, either. The same resolver may behave differently on home Wi-Fi, a corporate network, and cellular. If the shared config uses fake-ip, split DNS, or DNS interception, check that each client supports it. Confirm DNS works before checking rule matches, so a resolution failure isn’t mistaken for a broken subscription.

Rules differ after syncing? Check these five things

1. Check the source. Make sure all three devices use the same config source, format, and options. Different subscription-converter parameters can produce different proxies and rules.
2. Check that the new content arrived. Look at the last successful update, revision comment, and rule count. An iCloud file appearing doesn’t mean it has finished downloading; an HTTP 200 response can still contain an error message.
3. Check that it loaded. Verify which config is active, not just what’s listed. Some clients keep using the old config after a failed load, so check the error log.
4. Check override order. See whether a local override changes mode, DNS, policy groups, or rules. Standard rules are usually matched in order, so a broad rule near the top may take precedence over a more specific one below.
5. Check the actual exit. Compare the destination domain, matched rule, policy group, and final proxy in the connection logs. The same policy group can have different manual selections or test results on different devices.

Test the whole workflow with one small change

First update the revision comment, then adjust one precise rule for a known test domain and use a policy group that actually exists in the config. Put the rule before any broad rule that could match first and before the fallback MATCH. After updating and reloading on all three devices, start a new test connection and check the match in the logs. Existing long-lived connections may not be recreated under the new rule.

To check whether file transfer completed, compare the revision comment. To confirm routing, check the connection logs. Run these tests separately to distinguish “file wasn’t updated,” “parse failed,” and “rule order is wrong.” Remove the temporary rule when you’re done and keep the known-good version.

Before configuring, check the client formats and features on each platform in our comparison guide, then follow the quick start for your first import. If you’re already seeing connection or DNS issues, work through the troubleshooting guide one step at a time. Avoid changing the subscription, DNS, and tunnel mode all at once.