Clash 多设备配置同步：订阅、覆写与私有仓库方案

在 Windows、macOS、Linux 与移动设备之间使用 Clash 或 mihomo 时，真正需要同步的通常不止一份 YAML。代理节点可能来自订阅，规则来自远程规则集，策略组属于个人偏好，而端口、TUN、局域网访问和 DNS 监听地址又与设备环境有关。如果直接复制客户端的整个数据目录，很容易把缓存、运行状态、数据库和平台专属字段一起带到另一台设备，最终出现端口冲突、配置无法加载或本地修改被覆盖。

更稳定的做法是先划分配置层级：把会持续更新的远程数据交给订阅或 Provider，把跨设备一致的规则与策略放进可审阅的基础配置，再把端口、TUN、DNS 和局域网参数留在设备覆写层。订阅链接、覆写文件和私有仓库不是互相排斥的三选一方案，它们分别解决数据分发、设备差异和版本管理问题。

先确定同步边界：配置源、设备参数与运行数据

多设备同步的第一步不是选择工具，而是确认哪些内容应当拥有同一个权威来源。建议把 Clash 配置拆成以下四类：

• 远程资源：代理节点订阅、代理 Provider、规则 Provider。这类内容由远端维护，客户端按设定周期刷新。
• 共享逻辑：策略组名称、规则顺序、域名规则、区域分流与兜底策略。这些内容适合进入基础 YAML 或版本仓库。
• 设备参数：mixed-port、控制端口、局域网监听、TUN 开关、网卡选择和部分 DNS 监听参数。这些内容应按设备维护。
• 运行数据：日志、缓存、连接记录、Geo 数据下载结果、Provider 缓存和客户端数据库。它们应由各设备自行生成。

客户端的“配置目录”往往同时包含上述多种数据，因此不宜直接通过网盘双向同步整个目录。两台设备同时运行时，数据库和状态文件可能被反复覆盖；不同操作系统还会写入不同路径、权限和换行格式。需要迁移时，应导出明确的 YAML 或客户端提供的备份文件，而不是把正在使用的数据目录当作共享文件夹。

方案一：订阅链接负责节点同步

订阅链接最适合解决“多台设备获得同一批节点”这一问题。每台设备分别导入同一个订阅地址，再由客户端按周期更新。这样不必手动复制节点列表，节点名称、地址或可用状态发生变化时，各设备可以独立获取新内容。

但订阅本身通常只提供代理条目，或者提供一份由服务端生成的完整配置。若服务端完整配置中包含策略组和规则，客户端更新时仍会以远端内容为准。为了避免本地定制被覆盖，可以保留一份未经修改的订阅配置，再通过客户端支持的合并、脚本或覆写功能增加设备规则。不同客户端对“覆写”“合并配置”和“预处理脚本”的实现并不统一，迁移客户端前应先确认其处理顺序。

对于 mihomo 配置，还可以把节点源声明为 proxy-providers，让共享基础配置只引用远程 Provider。下面的结构展示了更新周期、缓存路径与健康检查之间的关系：

proxy-providers:
  primary:
    type: http
    url: https://sub.example.net/profiles/team-laptop.yaml
    path: ./providers/primary.yaml
    interval: 21600
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

proxy-groups:
  - name: 手动选择
    type: select
    use:
      - primary
    proxies:
      - DIRECT

interval 控制 Provider 拉取间隔，健康检查间隔则用于检测其中的代理，并不等同于重新下载订阅。缓存路径应保持为当前设备的本地路径，不需要放进同步仓库。示例域名仅用于说明结构，实际使用时应填写自己的订阅地址，并根据网络环境选择可访问的测试地址。

订阅凭据的隔离方式

订阅 URL 往往带有可用于访问资源的凭据，应按敏感信息处理。不要把真实订阅地址写进公开仓库、截图、故障日志或可公开分享的配置片段。多设备使用时，可在每台客户端本地保存订阅地址，共享仓库只维护不含凭据的策略与规则。若服务端支持为不同设备签发独立地址，分别使用设备级凭据更便于停用单台设备的访问。

还要注意，普通 Clash 客户端未必能够直接读取需要 Git 登录态的私有仓库地址。浏览器能够打开某个私有文件，并不代表内核发起 HTTP 请求时也带有相同认证信息。短期有效的下载地址在到期后同样会导致自动更新失败，因此订阅分发端应提供适合客户端长期拉取的访问方式。

方案二：用覆写文件保存设备差异

覆写层适合处理“规则基本相同，但系统参数不同”的情况。例如桌面电脑需要 TUN 接管部分不读取系统代理的程序，办公设备只启用系统代理，家庭设备则允许局域网访问。把这些差异硬塞进同一份 YAML，会导致每次同步后都要手动改回本机参数。

可以把共享基础配置保持为中性状态，再为每台设备维护简短的差异文件。逻辑上可按下列方式拆分：

profiles/
  base.yaml
overrides/
  windows-desktop.yaml
  macbook.yaml
  linux-shell.yaml
rules/
  local-direct.yaml
  service-routing.yaml

Windows 桌面覆写可以启用 TUN 并指定自动路由，Linux 命令行环境可能只需要固定的混合端口，macOS 则根据所用客户端和系统权限决定是否启用 TUN。allow-lan、bind-address 和外部控制器监听地址也应视为设备参数，因为它们会改变局域网中的可访问范围。

mixed-port: 7890
allow-lan: false

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

覆写并不意味着任意 YAML 都能自动叠加。不同客户端可能采用浅合并、深合并、脚本处理或字段替换；数组尤其容易产生差异。例如一份覆写里的 rules 数组，可能完全替换基础配置中的规则，而不是追加到末尾。策略组数组也可能按整体替换处理。第一次建立同步流程时，应使用少量测试规则确认实际合并结果，再迁移完整配置。

DNS 配置也需要区分共享项与设备项

DNS 的规则逻辑可以共享，例如是否使用 Fake-IP、哪些域名进入排除列表、哪些规则集用于分流；但监听地址、局域网 DNS 服务和系统 DNS 接管方式与设备环境有关。移动热点、家庭局域网和公司网络可能存在不同的内部域名解析需求。如果所有设备同步同一个 nameserver 与监听设置，一台设备正常并不能证明另一台也适用。

使用 TUN 时，还要确认客户端内核版本和平台权限是否支持相应字段。mihomo 的扩展配置不应直接交给只兼容旧版原始 Clash 字段的客户端。跨平台同步前，先确定各客户端实际使用的内核，再决定共享配置采用哪一组字段。

方案三：私有仓库管理共享配置与修改历史

当配置包含较多自定义规则、多个设备覆写和长期维护的脚本时，私有 Git 仓库比反复发送 YAML 更容易追踪变化。仓库的主要价值是记录“谁修改了哪一段逻辑、为什么修改、出现问题时回退到哪里”，而不是直接替代订阅服务。

建议仓库只保存可审阅的源文件，不提交客户端运行目录。可纳入版本管理的内容包括基础 YAML、设备覆写、规则文本、生成脚本和使用说明；应排除日志、缓存、数据库、真实订阅地址以及客户端自动下载的 Provider 文件。

clash-config/
  profiles/
    base.yaml
  overrides/
    desktop.yaml
    laptop.yaml
    server.yaml
  rules/
    private-network.yaml
    work-services.yaml
  scripts/
    build-config.js
  README.md
  .gitignore

如果团队或家庭成员需要共享同一套规则，可以在仓库中约定策略组名称。例如规则只能引用 手动选择、自动选择 和 DIRECT，设备覆写不得随意改名。这样新增规则时不会因为某台设备缺少目标策略组而加载失败。

私有仓库中的配置可以通过两种方式部署。第一种是在每台设备上拉取仓库，再由本地脚本把基础层和设备层合成为最终 YAML；第二种是在受控环境生成最终配置，再发布到客户端可访问的分发地址。前一种便于本地调试，但要求设备具备 Git 和生成环境；后一种更适合只负责导入订阅的客户端，但需要妥善管理分发权限。

避免仓库与客户端双向争夺修改权

应明确仓库和客户端谁是权威源。若规则以仓库为准，就不要在客户端生成的最终配置中长期手改；需要调整时回到源文件修改、测试并重新生成。若某台设备临时增加规则，应先记录为本地实验，确认有效后再合并到共享层。否则客户端中的改动可能在下一次拉取或生成时消失，而仓库也无法解释这次差异来自哪里。

YAML 锚点可以减少同一文件内的重复内容，但锚点不能自然跨越多个独立文件。配置拆分后的组合方式仍依赖客户端覆写功能或外部生成步骤。不要仅凭文件扩展名判断它们能否直接合并。

固定更新顺序：先远程资源，再覆写，最后验证

多设备同步最常见的问题不是配置写错，而是更新顺序不一致。一台设备先更新订阅再应用覆写，另一台设备先覆盖完整配置再更新订阅，最终得到的策略组和规则可能不同。建议为所有设备采用同一流程：

1. 确认当前权威源。检查本次要修改的是订阅、共享基础配置还是设备覆写，避免直接编辑生成结果。
2. 拉取共享配置。从私有仓库获取最新基础层和规则文件，先处理版本冲突。
3. 更新远程资源。刷新代理 Provider 与规则 Provider，确认地址仍可访问。
4. 应用设备覆写。加入本机端口、TUN、DNS 监听和局域网参数。
5. 执行配置测试。使用客户端的配置检查或内核测试功能确认 YAML 语法、策略组引用和规则目标有效。
6. 重新加载并验证流量。分别测试直连域名、代理域名、DNS 查询和不读取系统代理的应用。
7. 提交有意保留的修改。只有确认属于共享逻辑的变化才进入仓库；临时端口与本地路径保留在设备层。

更新过程中不建议让多台设备同时向同一个网盘文件写入结果。Git 可以处理文本版本，但客户端数据库和生成文件通常不适合合并。需要在另一台设备继续修改时，应先完成提交和推送，再在目标设备拉取，避免两边都基于旧版本编辑同一段规则。

同步冲突与加载失败的定位方法

订阅更新后自定义规则消失

先确认自定义规则是否直接写在订阅生成文件中。如果是，更新时被远端完整配置覆盖属于预期结果。把规则迁移到客户端支持的覆写层，或者维护独立基础配置并通过 rule-providers 引用规则。还要检查覆写执行顺序：某些客户端在订阅更新后自动重新应用覆写，另一些客户端需要手动重新生成配置。

同一份配置在一台设备可用，另一台无法启动

优先检查内核类型、字段支持和本地资源。原始 Clash、Clash Meta 与 mihomo 对扩展字段的支持范围不同；TUN 还依赖系统权限和平台网络栈。随后检查端口是否占用、本地路径是否存在、外部控制器地址是否冲突。不要急于删除规则，因为规则通常不会导致监听端口创建失败。

策略组提示找不到代理或 Provider

检查 use 引用的 Provider 名称是否与 proxy-providers 中完全一致，并确认 Provider 已成功下载。若共享配置使用固定策略组名称，设备覆写不应把它们改名。YAML 对缩进敏感，Provider 被缩进到错误层级时也可能表现为引用不存在。

规则命中结果在设备之间不同

先比较最终加载配置，而不只是比较仓库源文件。不同设备可能使用不同版本的规则 Provider 缓存，也可能在覆写时替换了整个 rules 数组。确认规则顺序相同，特别是范围较大的域名规则、GEOIP 规则和末尾 MATCH 兜底。Clash 通常按规则自上而下匹配，较早命中的规则会决定后续流量去向。

私有仓库地址在浏览器可打开，客户端更新失败

这通常与认证方式有关。浏览器保存了登录状态，而 Clash 内核的 Provider 请求没有相同凭据。检查地址是否依赖网页会话、临时授权或跳转页面。客户端需要能够直接取得 YAML 内容，并收到正常的 HTTP 响应；返回登录页面时，即使状态看似成功，也会因为内容不是有效 YAML 而解析失败。

三种方案的组合建议

只有两三台个人设备、规则改动较少时，可以采用“订阅链接加客户端覆写”：节点由订阅更新，端口和 TUN 留在各设备，自定义规则放进客户端明确支持的覆写配置。这种方式维护成本较低。

需要长期维护大量规则时，可以采用“订阅 Provider、共享基础配置、设备覆写”三层结构。基础配置负责策略组与规则顺序，Provider 负责节点和远程规则，设备覆写负责平台差异。最终配置由客户端合并或本地脚本生成。

多人协作或设备数量较多时，再加入私有仓库管理基础配置、规则和生成过程。仓库不保存真实订阅凭据，也不承担客户端缓存同步。每次修改经过拉取、测试、提交和部署，设备只消费与自身对应的最终配置。

无论选择哪种组合，都应避免同时存在多个权威源。节点由订阅维护，规则由仓库维护，设备参数由本机覆写维护；每一类内容只在一个位置编辑。边界清楚后，多设备同步就从“复制整份配置”转变为“按层更新并验证”，订阅更新、规则迭代和平台差异也更容易独立处理。