Mac、iPhone、iPad 共用一份 Clash 配置:远程订阅与 iCloud 同步方案

先给结论：共用规则来源，保留设备差异

Mac、iPhone、iPad 要长期使用同一套 Clash 配置，优先选择同一个远程配置来源，加上各设备的本地设置。iCloud 云盘适合人工传递文件，Git 私有仓库适合管理规则变更与回退。三种方法同步的对象不同，不能把“文件已经更新”直接当成“客户端已经应用”。

这里的“同一份”首先指节点来源、策略组命名和分流规则一致，不要求每台设备的最终 YAML 逐字相同。macOS 的监听端口、TUN 路由与辅助服务设置，不宜原样搬进 iOS 客户端；iPhone 与 iPad 使用的客户端，也未必能直接读取 Clash YAML。

同步前检查：内核、配置层与本地状态

Apple 芯片架构不决定配置格式

Apple 芯片 Mac 应选择 arm64 构建，Intel Mac 选择 x86_64 构建；这一差异影响程序运行，不会自动改变 YAML 的语法。真正决定配置兼容性的是内核与客户端实现。Clash 原版、Clash Meta（现称 mihomo）以及使用其他内核的 iOS 客户端，对协议、规则集、DNS 和 TUN 字段的支持可能不同。

建议在每端记录客户端版本、内核版本、配置名称和最近一次成功加载时间。应用版本相同也不代表内核相同；更新订阅成功，只说明下载阶段可能完成，仍要查看解析结果和当前启用配置。

把配置拆成三个层次

• 共享内容：节点来源、策略组名称、域名与 IP 分流规则、规则集地址。多端应尽量保持一致。
• 设备设置：监听端口、局域网访问、TUN、DNS 接管和日志等级。根据系统和网络环境分别设置。
• 运行状态：当前选中的节点、测速结果、连接记录。它们通常属于客户端数据库，不会随 YAML 文件自动同步。

例如，各设备都存在名为“日常代理”的策略组，不代表它们会自动选中同一个节点。若希望出口一致，需要在每台设备上核对策略组的当前选项；自动测速组也可能因 Wi-Fi、蜂窝网络和测试时刻不同而得到不同结果。

方案一：同一个远程订阅，各端独立更新

远程订阅最适合日常使用：由一个受信任的 HTTPS 地址提供配置，每台设备分别获取。首先确认它返回的是完整 Clash YAML、仅节点列表，还是 Base64 节点串。后两者不能不经处理就当成带规则和策略组的完整配置。

首次导入与更新顺序

1. 在 Mac 的客户端配置管理界面新增远程配置，粘贴订阅地址，使用容易区分的名称，例如“苹果设备共享规则”。
2. 下载后检查解析日志，确认 proxies 或 proxy-providers、proxy-groups、rules 等所需内容完整，再将其设为当前配置。
3. 在 iPhone、iPad 的客户端中，通过其远程配置导入入口添加同一来源。若不支持该格式，改用来源方提供的对应格式，不要只改文件扩展名。
4. 在三台设备分别执行一次更新和重新加载，核对规则数量、策略组名称与加载错误。不要只比较配置显示名称。
5. 最后测试直连与代理各一条连接，并在连接记录中核对实际命中的规则及出口。

不同客户端的菜单可能叫“配置”“Profiles”或“订阅”，不存在适用于全部应用的统一操作路径。系统代理或 VPN 开关与配置更新也是两个动作：下载新文件后，部分客户端仍需要切换配置或重新连接隧道才会使用新内容。

完整订阅更新与节点提供器更新不是一回事

客户端的“自动更新订阅”通常更新整个配置；mihomo 的 proxy-providers 则更新节点提供器内容。即使提供器的 interval: 3600 表示每隔 3600 秒尝试更新，它也不会替你修改主配置里的 rules。同样，rule-providers 更新的是对应规则集，不等于重新下载整个 YAML。

需要自定义规则时，优先使用客户端明确支持的本地覆写、合并或脚本机制；直接编辑下载缓存中的 YAML，下一次订阅更新可能会覆盖修改。覆写功能并非各端都有，使用前要验证它是在下载前、下载后还是加载时生效。

方案二：iCloud 云盘同步文件，手动导入客户端

iCloud 适合自己维护一份配置、偶尔向另外两台设备分发的情况。它同步文件，不负责检查 YAML，也不保证客户端会监视文件变化。通过系统文件选择器导入时，应用可能复制一份到自己的沙盒，之后源文件变化并不会自动更新该副本。

建立明确的文件交接流程

1. 在 Mac 打开「系统设置」→「Apple 账户」→「iCloud」→「云盘」，确认同步已开启；较旧系统的名称可能显示为“Apple ID”。
2. 在 Finder 的「iCloud 云盘」内创建 Clash-Shared 文件夹，保存 UTF-8 编码的 shared.yaml。避免用会添加富文本格式的编辑方式保存。
3. 在 iPhone、iPad 打开「设置」→「Apple 账户」→「iCloud」→「云盘」，开启“同步此 iPhone”或“同步此 iPad”。
4. 进入「文件」→「浏览」→「iCloud 云盘」→ Clash-Shared，等待文件实际下载完成，而不只是看见文件名。
5. 在客户端使用本地文件导入功能，选择该 YAML；确认导入后的名称、解析结果和启用状态。再次修改源文件后，按同样流程重新导入或刷新。

上述路径按近年系统的常见命名说明，具体入口会随系统版本调整。如果「文件」里看不到 iCloud 云盘，先检查账户与云盘开关，不要通过反复新建配置来排查云端同步。

用修订标记确认是否拿到新文件

可以在 YAML 顶部保留一行注释，方便在支持查看原文的客户端中核对。该注释只供人工识别，不改变规则行为，也不保证会出现在客户端列表里。

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

• 约定只在 Mac 编辑主文件，iPhone 与 iPad 只负责导入，减少同时修改产生的冲突副本。
• 保留上一份可用文件，例如 shared-2026-09-08.yaml；确认三端正常后，再整理旧副本。
• 若应用无法持续访问云盘文件，使用系统文件选择器重新授权或重新导入，不要假设旧的访问权限永久有效。

方案三：Git 私有仓库管理规则与回退

如果经常调整分流规则，Git 的价值在于记录每次变化、审阅差异并恢复旧版本，而不是让 iOS 自动运行 Git。更稳妥的做法是：仓库只保存可公开审阅的规则与模板，Mac 负责获取和生成最终配置，手机和平板通过远程地址或文件导入接收结果。

规则与凭据分开保存

建议将自定义规则放在 rules.yaml，将实际订阅地址和本地生成文件放到不提交的目录。以下是可采用的 .gitignore 内容；文件名应与实际生成流程一致。

secrets/
runtime/
*.local.yaml
.DS_Store

.gitignore 只影响未被跟踪的文件，不会删除已经进入提交历史的凭据。若令牌曾被提交，先在服务端撤销或轮换，再处理仓库历史。私有仓库可以限制访问，但仍应避免把长期有效的订阅凭据放进版本记录。

在 Mac 审阅变更，再分发给其他设备

下面的命令假定仓库已经克隆、远程名为 origin、共享分支为 main。先确认工作区状态，再查看远程规则差异；本地有未完成修改时，先保存并处理，避免直接覆盖。

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

更新后先在 Mac 上检查生成配置，并用实际客户端加载测试。若已安装 mihomo 命令行程序，可对最终文件运行配置检查：

mihomo -t -f runtime/shared.yaml

检查通过表示配置能够通过该内核的校验，不代表所有代理节点都能连接，也不能替代 iOS 客户端的兼容性测试。随后再发布配置或放进 iCloud，让其余设备更新。远程规则集还要满足客户端支持的 behavior 与文件格式，普通规则片段不能自动视作任意类型的规则提供器文件。

Git 私有仓库的原始文件地址经常需要认证，或存在跳转、缓存和访问期限。不要假设把网页地址粘贴到客户端就能下载 YAML；应确认返回的是文件正文，而不是登录页。无法安全地完成客户端认证时，保留“Mac 获取、文件分发”的流程更容易维护。

哪些设置应留在 Mac、iPhone 与 iPad 本地

同步规则之前先固定边界，可以减少“Mac 正常、手机断网”的情况。下面是一段面向支持这些字段的 Clash 系内核的本地设置片段，不是包含节点和策略组的完整可用配置；客户端若从图形界面管理端口，应以其最终生效配置为准。

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

端口 7890 在这里是示例值，不是所有客户端的固定默认值。即便 Mac 开启系统代理，也只会影响遵循该设置的应用；TUN 的接管范围则受路由与排除项影响。同步配置不会替你完成 macOS 辅助服务授权，也不会在 iOS 上代替 VPN 配置授权。

DNS 更不宜盲目复制。家用 Wi-Fi、公司网络与蜂窝网络可能对同一个解析服务表现不同；如果共享配置包含 fake-ip、分流解析或 DNS 接管设置，应分别检查各端支持情况。先保证解析可用，再检查规则命中，避免把解析失败误判为订阅失效。

同步后规则不一致：按五个检查点排查

1. 确认来源相同。检查三端是否订阅同一个配置来源、同一个格式与同一组选项。订阅转换的输出参数不同，节点与规则也可能不同。
2. 确认拿到新内容。查看最后成功更新时间、修订注释及规则数量。iCloud 显示文件不代表下载完成；远程接口返回 HTTP 200 也可能只是错误说明文本。
3. 确认已经加载。核对当前启用的配置，而不是只看配置列表。加载失败时有些客户端会保留旧配置继续运行，应查看错误日志。
4. 确认覆盖顺序。检查本地覆写是否改变 mode、DNS、策略组或规则。常规规则通常按顺序匹配，前面的宽泛规则可能先于后面的精确规则生效。
5. 确认实际出口。在连接记录里比较目标域名、命中规则、策略组及最终节点。同一策略组在不同设备上可以有不同的手动选择或测速结果。

用一次小变更验证整个链路

先更新修订注释，并在配置中调整一条已知测试域名的精确规则，使用配置里真实存在的策略组。将该规则放在会提前匹配的宽泛规则之前、兜底 MATCH 之前。三端更新并重新加载后，发起新的测试连接，再核对命中记录；已有长连接未必会按新规则重新建立。

如果只想确认文件传递是否完成，比较修订注释即可；要验证分流生效，则必须查看连接记录。两种测试分开进行，才能区分“传输没更新”“解析失败”和“规则顺序错误”。测试结束后撤回临时规则，保留成功版本。

开始配置前，可先到横向评测确认各平台客户端的格式与功能，再按快速上手完成首次导入。已经出现连接或解析异常时，结合排查手册逐项检查，避免同时更换订阅、DNS 和隧道模式。