多平台 预计阅读 9 分钟

Mac、iPhone 与 Windows 共用一份 Clash 配置的同步方案

对比订阅链接、iCloud 文件夹与私有 Git 仓库三种同步方式，说明 Mac 与其他设备共用一份配置时的覆写与本地差异处理。

同步范围：共享规则，保留设备设置

“共用一份配置”更适合理解为共用一份配置来源，而不是让三台设备加载完全相同的最终 YAML。节点、策略组名称和分流规则可以尽量一致；本地监听端口、TUN 接管方式、控制接口与客户端偏好则应分别管理。这样更新节点时，不会顺带覆盖另一台设备的网络设置。

还要先区分内核与图形客户端。mihomo 负责解析它支持的配置、匹配规则和建立代理连接；客户端负责订阅更新、配置选择、覆写以及系统集成。不同客户端对这些功能的界面和保存方式并不相同。iPhone 上的客户端也不一定使用 mihomo，能导入节点订阅，不代表能完整执行 Clash YAML 中的规则、DNS 和策略组。

  • 适合共享：节点来源、稳定的策略组名称、域名规则，以及各端都支持的规则集。
  • 适合本地保留：mixed-port、external-controller、控制接口密钥、TUN 与网卡相关设置。
  • 需要核对：协议支持、proxy-providers、rule-providers、DNS 字段及客户端自有扩展。

三种同步方式对比

订阅链接适合持续接收上游节点更新；iCloud 文件夹适合少量设备间传递手动维护的文件；私有 Git 仓库适合需要审阅规则改动与回退的人。三者都只解决“配置如何到达设备”，不会自动同步当前连接、节点选择或系统代理开关。

方式适合内容更新动作主要限制
订阅链接节点、上游完整配置各端分别刷新订阅响应格式及字段支持可能不同
iCloud 文件夹手动维护的 YAML文件同步后重新导入或重载客户端未必持续读取原文件
私有 Git 仓库规则、模板、本地覆写样例拉取、检查、应用需要额外管理凭据与部署流程

如果主要需求是“Mac 与手机使用同一批节点”，优先尝试订阅。如果主要需求是“修改一条规则后各端一致”，先建立共同规则源，再决定用文件同步还是 Git 分发。不要为了共享节点，把每台设备的整个客户端数据目录一起复制。

订阅链接：各端导入，同源更新

导入与刷新顺序

  1. 在提供方确认订阅的输出类型：完整 Clash 配置、节点列表，还是其他客户端专用格式。
  2. 在 Mac 客户端的配置管理页面导入链接，手动更新一次，确认策略组和规则存在，再启用该配置。
  3. 在 Windows 客户端导入相同来源，检查实际响应是否一致。某些服务会按请求参数或客户端标识返回不同格式。
  4. 在 iPhone 客户端选择受支持的订阅类型，检查导入结果。若只导入了节点，规则与 DNS 需要另行配置。

三个客户端的订阅刷新是独立动作。Mac 更新成功，不会替 iPhone 完成刷新；移动端还可能受到后台执行限制。可以先把自动更新间隔设为 24 小时，遇到节点变更时再手动刷新。这是起始设置建议，具体可选间隔和后台行为以客户端为准。

避免修改被订阅覆盖

直接编辑订阅下载后的文件，下一次刷新可能丢失修改。支持覆写的客户端应把本地端口、DNS 调整和自定义规则放在独立覆写中；不支持覆写时，保留一份独立本地配置，并明确后续如何更新节点。也可以在各端支持的前提下，用节点提供器将节点更新与主配置分开。

订阅地址通常带访问令牌，应按密码管理。不要把完整链接放进公开截图、日志或公共仓库，也不要为了格式转换随意交给陌生在线服务。如果链接已经泄露，应在提供方更换令牌，然后逐台更新来源。

iCloud 文件夹：同步文件与重新导入

在 Mac 的“访达”→“iCloud 云盘”中新建专用文件夹，例如 ClashConfig，只放准备分发的配置文件。iPhone 可通过“文件”→“浏览”→“iCloud 云盘”查看；Windows 需要安装并登录 iCloud，启用 iCloud 云盘后再访问相应文件夹。

  1. 指定一台设备作为主要编辑端，先保存 shared.yaml，等待文件完成上传。
  2. 在目标设备确认文件已经下载到本地，而不是只有云端文件占位。
  3. 通过客户端的文件导入入口选择该文件，检查解析结果，再切换为当前配置。
  4. 修改后先在一台设备验证，再在其他设备重新导入或使用客户端支持的重载功能。

关键在于区分“读取原文件”和“导入副本”。有些客户端会把 YAML 复制到自己的数据目录；这时 iCloud 里的文件已经变化，客户端仍然使用旧副本。可以临时调整一个容易观察的策略组名称，重新导入后查看界面是否改变，以确认实际加载来源。

不要让两台设备同时编辑同一份 YAML。文件同步可能产生冲突副本，手动合并时又容易破坏缩进或规则顺序。建议一次只由一端编辑，保留上一份可用文件，确认接收端生效后再继续下一轮修改。

私有 Git：规则审阅与配置回退

Git 更适合保存自行维护的规则和配置结构，而不是存储账号凭据。可以按下面的目录分层；文件名属于项目约定，不会自动被 Clash 或 mihomo 识别，需要在客户端中显式导入，或由自己的生成流程组合。

clash-config/
├── shared.yaml
├── rules/
│   └── direct.yaml
├── local/
│   ├── mac.yaml
│   └── windows.yaml
└── .gitignore

其中 shared.yaml 保存共同策略组与规则，local/ 保存设备差异。含真实订阅地址和密钥的文件应排除提交；已经进入历史的秘密，后来加入忽略规则也不会自动清除，仍需更换凭据。私有仓库只是访问控制的一层，不应成为长期存放所有秘密的理由。

提交、拉取与验证

git diff -- shared.yaml rules/
git add shared.yaml rules/
git commit -m "调整直连规则顺序"

# 其他桌面设备更新工作副本
git pull --ff-only

git pull --ff-only 遇到分叉会停止，便于先处理本地修改，而不是直接生成一次不易察觉的合并。拉取成功后仍需让客户端重新加载配置。iPhone 若没有合适的 Git 工作流程，可以通过可信的文件导入方式接收发布文件，不必强行在手机上复制整套桌面开发流程。

基于 mihomo 的桌面环境，可在应用前测试最终生成文件。下面的 effective.yaml 指已经合并好共享内容与本地差异的文件；命令要求本机存在可调用的 mihomo 可执行文件。

mihomo -t -f effective.yaml

配置测试通过，表示内核接受该配置；它不代表远端节点可达，也不代表系统代理已经开启。发生问题时，可从 Git 取回上一份文件，再导入或重载。回退文件本身不会恢复系统网络设置，需要分别检查。

本地覆写：端口、TUN 与规则顺序

Mac 与 Windows 可以共享规则逻辑，但应保留各自的入口配置。以下是基于 mihomo 的桌面本地层字段片段，并非完整代理配置；示例使用混合端口 7890，控制接口仅监听回环地址 127.0.0.1:9090。

mixed-port: 7890
allow-lan: false
mode: rule
external-controller: 127.0.0.1:9090
tun:
  enable: false

这些字段应通过客户端支持的本地设置或覆写机制生效，不能假定所有客户端都按相同方式合并 YAML。尤其是列表字段：有的机制替换整段列表，有的支持前置或追加。应用后要查看最终配置，确认原有代理组和规则没有意外消失。

  • 端口：先检查 7890 是否被其他进程占用。修改端口后，终端代理环境变量和手动填写的应用代理也要同步修改。
  • TUN：桌面端涉及权限、路由和其他 VPN 的配合；iPhone 通常通过系统网络扩展建立接管，不能直接照搬桌面的 tun.stack 或网卡名称。
  • DNS：先保留各端可用的解析设置。需要共享 DNS 策略时，逐项核对支持情况，不要只因 YAML 能解析就认定行为一致。
  • 控制接口：通常没有跨设备开放的必要。若确需局域网控制，应另行设置认证与访问边界，不要把监听地址简单改成所有网卡。

自定义规则放在兜底规则之前

Clash 风格规则按顺序匹配。下面是规则片段，用于说明域名直连规则必须位于最终兜底之前；PROXY 需要是完整配置里已经存在的代理或策略组名称。

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

如果把新规则追加到现有 MATCH 后面，它通常没有机会被匹配。共享规则还应避免依赖某台设备独有的策略组名。建议各端统一保留同名组，再允许每台设备在组内选择不同节点；组名统一不要求节点选择也完全一致。

涉及公司内网域名、局域网地址或特定 Wi-Fi 的例外规则，更适合留在本地层。它们可能只在 Mac 所连接的网络有效，复制到手机蜂窝网络后未必有意义，甚至可能改变预期出口。

同步后的验收与常见问题

每次更新按“来源 → 最终配置 → 规则匹配 → 实际出口”的顺序检查，比反复重装客户端更有效。先在一台设备验证，再推广到其他设备，能够缩小故障范围。

  1. 确认来源：查看订阅更新时间、文件修改时间或 Git 提交记录，确保三端接收到的是同一轮改动。
  2. 确认配置：检查当前启用配置的名称、策略组数量，以及新增规则是否出现在最终生效配置中。
  3. 确认接管：桌面端检查系统代理或 TUN 状态；iPhone 检查客户端连接状态，并留意其他 VPN 是否冲突。
  4. 确认分流：分别访问一项预期直连和一项预期代理的服务，在连接记录中核对命中的规则、策略组与实际节点。

同一订阅，节点列表不同

先检查输出格式、客户端协议支持和本地过滤条件，再比较刷新时间。订阅服务也可能根据客户端标识生成不同内容。不要仅凭列表长度判断同步失败，更不要把含令牌的完整响应公开用于比较。

规则相同，出口仍然不同

这可能是正常结果。手动选择组的当前节点通常保存在各端本地；自动测速组则会根据各设备所在网络分别测量。Mac 连家庭 Wi-Fi、iPhone 使用蜂窝网络，即使策略组定义相同，也可能选择不同节点。需要复现问题时，应临时在各端选择同一节点，再观察差异。

文件已更新，客户端仍使用旧内容

优先检查是否导入了副本、是否启用了另一份配置，以及订阅更新后是否成功重载。先保留当前可用配置，再重新导入测试。长期使用时，推荐采用“同一订阅或规则源 + 各端本地覆写”的结构；需要追踪规则历史再加入 Git，少量手动文件交换则使用 iCloud。同步范围越明确，跨平台问题越容易定位。

端口与规则字段可继续查阅YAML 配置手册；首次导入和网络接管步骤见配置教程。

下载Clash