Clash 配置多设备同步:手机电脑订阅与规则保持一致的可行方案

先分清:多设备要同步的其实是两类东西

谈多设备同步之前,先拆开看一台设备上的 Clash 客户端到底存了什么。配置可以分成两类:一类来自订阅,一类长在本机。

订阅下发的内容包括节点列表、代理策略组和分流规则,它们由订阅链接背后的提供方维护,提供方更新后,各端重新拉取即可拿到同一份。本机设置则完全不同:运行模式(规则、全局、直连)、混合端口、系统代理开关、TUN 模式、开机自启、界面偏好,这些全部写在各设备的本地存储里,任何同步方案都不会替你搬。

所以多设备同步的本质,是解决订阅内容的统一下发与及时更新;本机设置只能逐台配置。下面三种方案,差别就在于前者怎么落地。

方案一:订阅链接天然同步

适用场景:节点全部来自同一家订阅提供方,不维护或只维护很少的自定义规则。这是维护成本最低的方案,也是多数人的起点。

做法只有一句话:同一条订阅链接,在每台设备的客户端里各添加一次。节点、策略组、规则都来自订阅内容,提供方更新后,各端各自点一次更新即恢复一致。

1. 在订阅提供方后台复制标注为 Clash 或 Clash Meta(mihomo)的订阅链接。
2. 桌面端(Clash Verge Rev、Clash Nyanpasu 等)在配置页新建远程配置,粘贴链接并保存。
3. Android 端(Clash Meta for Android、FlClash)同样新建订阅配置,iOS 端客户端操作一致。
4. 各端把自动更新间隔设为 24 小时上下,节点与规则随提供方更新自动拉齐。

这个方案容易踩的坑:

• 客户端差异:有的客户端默认拉取通用节点列表再在本地转换,与直接下发 Clash 配置的订阅表现不同,尽量使用提供方标注为 Clash 或 mihomo 的订阅地址。
• 更新时机:各端自动更新的时刻不同,节点列表会短暂不一致,属正常现象,手动更新一次即可对齐。
• UA 模板:部分提供方按客户端标识下发不同配置模板,两台设备拿到的规则细节可能有出入,以提供方文档为准。

方案二:私有配置托管,自定义规则全量下发

适用场景:自己维护了大量自定义规则、多个策略组、DNS 段落,希望所有设备拿到逐字节一致的一份配置。

做法是把整理好的完整 YAML 配置放到一个只有自己能访问的 URL,各端把它当作远程订阅添加。此后改配置只改这一份,各端更新即生效,规则顺序、策略组结构、DNS 行为全部一致。

可行的托管方式:

• 私有 Git 仓库:GitHub 私有仓库的 raw 文件链接配合访问令牌,或私有 Gitee 仓库;改动提交后各端更新订阅即可。
• 自部署订阅转换:在自己的服务器或 NAS 上跑 subconverter 一类后端,以上游订阅加自定义规则模板输出完整 Clash 配置,地址带独立 token。
• 内网静态服务:NAS 或家用服务器用 WebDAV、简易 HTTP 服务挂出配置文件,仅家庭内网或加密隧道可达。

托管配置中按需引用远程规则集的 mihomo 片段示例:

mixed-port: 7890
dns:
  enable: true
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
rule-providers:
  my-rules:
    type: http
    behavior: classical
    url: "https://你的托管地址/rules/my-rules.yaml"
    path: ./providers/my-rules.yaml
    interval: 86400
rules:
  - RULE-SET,my-rules,Proxy
  - MATCH,DIRECT

这个方案容易踩的坑:

• 内核差异:Clash Meta(mihomo)支持 rule-providers、tun 等字段,已停止更新的原版 Clash 不识别这些键;共享配置要么按各端内核的公共子集来写,要么按内核分开维护两份。
• 凭证保护:配置内含节点服务器与密码,托管地址必须带不可猜测的访问凭证,泄露后果等同订阅泄露。
• 缓存问题:Git 平台的 raw 链接有缓存,改完立刻更新可能拉到旧版本,等几分钟或在 URL 上加版本参数。
• 路径问题:配置里引用本地规则文件的路径在各平台不一致,尽量改用 rule-providers 远程规则集,避免相对路径。

方案三:手动导出导入

适用场景:设备只有两三台、配置改动很少,或者不希望任何数据经过第三方。

桌面端客户端一般支持把当前配置导出为 YAML 文件或整份备份;手机端客户端支持从文件导入。传输走局域网互传、U 盘或加密压缩包即可。

1. 在主力设备上导出当前生效的配置文件。
2. 经局域网或加密压缩包把文件送到目标设备。
3. 目标设备客户端选择从文件导入,保存后启用。
4. 逐项核对端口、DNS 与 TUN 设置是否按预期生效。

这个方案容易踩的坑:

• 版本漂移:改了一端忘了另一端,几周后两份配置已经分叉;排障时先核对两份文件的修改时间。
• 平台差异:Android 客户端对配置字段的支持与桌面 mihomo 不完全一致,导入后先确认 DNS 与 TUN 段落真正生效。
• 授权搬不走:HTTPS 解密证书、TUN 所需的管理员或 VpnService 授权都绑定单台设备,配置文件带不过去,需要逐台重新授权。

三种方案对比与选择建议

方案	同步内容	一致性	凭证风险	维护成本	适合谁
订阅链接天然同步	提供方下发的节点与规则	高,同源自取	订阅链接需保密	最低	节点来自同一订阅、不折腾规则
私有配置托管	自定义全量配置	最高,同一份文件	取决于托管方式	中	重度自定义规则与策略组
手动导出导入	导出时刻的快照	随时间漂移	不经第三方	低,但每次手动	设备少、改动少、注重隐私

多数人的最优解是方案一打底:订阅链接解决节点与规则,本机设置逐台配好一次即可。只有当你开始维护成规模的自定义规则时,才值得上方案二;方案三留给出差应急或对隐私要求极高的场景。

同步之外,各端仍需单独处理的事

• 运行模式、混合端口、系统代理、开机自启都是本机设置,三种方案都不会同步,逐台配一次即可。
• TUN 模式按设备单独开关:桌面端需要管理员或 root 授权,Android 走 VpnService 弹窗授权,授权结果不互通。
• 各端内核版本尽量接近;跨大版本时,新字段先查 mihomo 文档再写进共享配置。
• 系统时间必须准确:订阅更新与节点 TLS 握手都依赖正确时间,偏差过大会直接失败,表现为订阅拉不下来或节点全部超时。
• 改完配置想验证效果,看客户端日志与连接面板里每条连接命中的规则,比凭感觉可靠。