Clash 多设备配置同步方案：订阅复用、覆写文件与私有存储

先划分配置中的可同步与设备专用部分

Clash 多设备同步并不等于把一个完整 YAML 文件复制到所有终端。桌面系统、移动系统以及不同客户端对配置目录、网络接口、系统代理和 TUN 权限的处理并不一致。直接覆盖整个运行配置，常见结果是节点可以读取，但端口冲突、TUN 启动失败，或者移动端引用了桌面端才存在的文件路径。

更稳定的做法是先把配置拆成三个层次：远端订阅负责节点与服务商下发的策略信息；共享覆写负责自定义规则、策略组命名和通用 DNS 逻辑；设备本地层负责监听地址、端口、控制器、TUN、网络接口与客户端状态。同步动作只覆盖前两个层次，设备本地层由各客户端分别保存。

方案一：在每台设备上复用同一订阅

订阅复用是最直接的多设备方案。每台设备分别保存同一个订阅地址，由各自客户端定时拉取并生成本地配置。节点增删、名称调整和服务商规则更新会随订阅刷新进入设备，而端口、TUN 与系统代理状态仍由本地客户端管理。

这种方式适合设备数量较少、主要需求是保持节点列表一致的场景。它不要求设备之间互相可见，也不依赖电脑持续在线。某一台设备更新失败时，其他设备仍可按自己的更新周期工作。

订阅复用的边界

订阅地址通常带有用于识别账户的参数，应视为访问凭据，而不是普通网页链接。不要把订阅地址写进公开代码仓库、截图、工单或公开分享文档。设备转让、遗失或退出使用时，应从客户端删除订阅，并根据服务提供方的能力更新订阅凭据。

还要注意服务条款中的并发连接和设备数量限制。同一订阅可以被多个客户端导入，不代表服务端一定允许这些设备同时建立大量连接。发生节点可见但连接被拒绝时，需要同时检查账户状态、并发上限与节点可用性。

更新节奏与失败处理

1. 先在一台常用设备上手动刷新，确认订阅返回的是 Clash 或 mihomo 可解析的配置内容。
2. 再让其他设备按固定周期更新，避免短时间内连续重复请求。
3. 更新后检查策略组是否仍有成员，防止节点名称变化导致手写策略引用失效。
4. 保留客户端上一份可用配置；新配置解析失败时，先回退，再检查响应内容和字段兼容性。

订阅复用解决的是“节点来源一致”，并不会自动同步手工添加的规则、策略组选择结果或每台设备的客户端偏好。如果需要统一这些内容，应增加覆写层，而不是反复编辑订阅生成的主配置。

方案二：用覆写文件统一规则与策略结构

覆写文件用于把个人维护的配置逻辑叠加到订阅结果之上。支持覆写、合并或脚本处理的客户端，可以在订阅更新后自动追加规则、修改策略组，或者替换部分 DNS 字段。这样既保留远端节点更新，也避免每次刷新后重新编辑生成文件。

不同客户端对“覆写”的定义并不统一。有的按 YAML 键进行合并，有的使用 JavaScript 处理配置对象，还有的只提供简单的前置与后置规则。部署前应查看客户端实际支持的处理顺序，尤其要确认数组是追加、替换还是按名称合并。对 rules、proxies 和 proxy-groups 来说，数组处理方式会直接改变最终结果。

共享覆写应保持小而明确

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - MATCH,节点选择

上例只表达规则顺序，不负责端口、控制器或 TUN。实际使用时，节点选择 必须与最终配置中的策略组名称完全一致。规则按从上到下的顺序匹配，兜底规则应放在末尾；若覆写工具把规则插入位置处理错误，新增条目可能永远不会命中。

不要把运行状态当成配置同步

策略组当前选中的节点，可能由客户端写入本地数据库或缓存，并不一定存在于 YAML 中。即使两台设备加载了相同配置，A 设备选择“香港节点”，B 设备仍可能保持“自动选择”。这通常是合理行为，因为移动网络、家庭宽带和公司网络的延迟结果不同。需要统一的是策略组结构，而不是强行复制一次性的选择状态。

方案三：通过局域网传输配置文件

局域网传输适合临时迁移、首次部署或少量受控设备。例如在电脑上整理配置后，通过系统文件共享、隔空传送、数据线文件传输或本地文件服务器交给手机和平板。数据不需要经过公开分享页面，传输完成后也可以关闭共享服务。

这种方案的优点是过程直观，适合传递完整 YAML、规则集和说明文件；限制则是后续更新仍需手动执行。设备数量增加后，很容易出现文件名相同但内容不同、旧配置覆盖新配置、某台设备遗漏更新等问题。因此局域网传输更适合作为“分发动作”，不适合作为长期自动同步机制。

局域网传输检查清单

1. 发送前关闭配置编辑器的自动保存冲突，确认文件内容已经完整写入。
2. 在文件名或同目录说明中记录日期与版本，避免只用 config.yaml 区分多个版本。
3. 导入后先执行配置语法检查，再启动系统代理或 TUN。
4. 确认接收设备没有继承发送端的局域网监听地址、控制器地址和平台专用路径。
5. 传输结束后关闭临时共享目录，并删除接收设备下载目录中的重复副本。

若通过 HTTP 在局域网中提供文件，应只绑定可信网络可访问的地址，并限制共享时间。公共无线网络中的其他终端可能与设备处于同一网段，因此“只在局域网内”并不自动等于访问范围可控。

方案四：使用私有存储维护共享配置

需要持续维护规则与覆写文件时，可以把共享层放入自主管理的 Git 仓库、WebDAV、家庭存储设备或带访问控制的对象存储中。各设备通过客户端支持的远程配置功能、文件同步工具或手动下载获取最新版本。这种方案更适合设备较多、配置有明确维护历史的场景。

私有存储的关键不是单纯把文件放到远端，而是确定访问凭据、版本回退和冲突处理方式。同步工具若在文件写入一半时触发客户端重载，可能产生短暂的解析错误。较稳妥的流程是先下载到临时文件，完成语法检查后再替换正式配置；如果使用客户端内置远程订阅，则由客户端负责下载与切换，不要再让另一个同步工具同时改写同一文件。

敏感信息与共享逻辑分离

共享仓库更适合保存规则、策略组模板和公开规则集引用。订阅凭据、控制器口令、私有节点认证信息应放在权限更严格的位置，或由每台设备单独录入。即便存储服务要求登录，也应按照最小访问范围分配账号，避免多个家庭成员或设备共用管理权限。

如果客户端不支持变量替换或外部密钥文件，不要为了追求自动化而把所有信息合并进一个长期同步的 YAML。可以保留一份不含设备凭据的基础模板，再在终端导入后补充本地字段。该方式多一步操作，但故障边界清楚，也便于在设备停用时单独撤销访问。

Git、WebDAV 与家庭存储的选择

推荐工作流：订阅、共享层与本地层分开维护

对大多数个人用户，较平衡的结构是：每台设备独立保存订阅地址；规则和策略模板存放在一个受控位置；端口、TUN、控制器与系统代理设置留在本地。这样节点列表由订阅更新，共享规则只有一个维护来源，平台差异也不会被远端文件反复覆盖。

1. 建立基准设备：先选择一台桌面设备验证订阅、规则顺序、DNS 解析和策略组引用，确认配置能被当前内核完整加载。
2. 提取共享层：只保留跨平台字段，把监听端口、TUN 网卡、控制器和本地路径移出共享文件。
3. 小范围验证：先导入第二台设备，检查客户端的覆写语义、数组合并方式和字段支持情况。
4. 记录配置版本：每次修改只处理一个主题，例如策略组改名或新增规则集，避免多项变化同时进入所有设备。
5. 保留回退入口：更新前保留上一份可加载配置。出现解析错误、DNS 异常或规则失配时，先恢复运行，再比较变更。
6. 定期清理设备：删除不再使用的订阅、远程存储凭据和旧配置副本，避免停用设备继续获取后续更新。

同步后必须验证的项目

• 配置检查是否通过，日志中是否存在未知字段、重复策略名或规则集加载错误。
• 策略组是否包含有效节点，手写规则引用的策略名称是否仍然存在。
• DIRECT、代理策略和 REJECT 是否按预期命中，而不是全部落入末尾规则。
• DNS 请求是否由预期的解析器处理，Fake-IP 或 Redir-Host 模式是否符合客户端能力。
• 桌面端系统代理与移动端 VPN 权限是否仍由本地状态控制。
• TUN 启动后是否出现路由循环、局域网访问中断或与其他 VPN 软件冲突。

按设备数量和维护目标选择方案

只有两三台设备，并且主要关心节点一致时，优先采用订阅复用；需要统一分流规则时，再增加小型覆写文件。偶尔把桌面配置迁移到手机，可使用局域网传输，但要手动核对平台字段。设备较多、规则长期演进或需要审阅变更时，私有 Git 仓库与受控文件存储更合适。

没有一种方案应该同步所有运行状态。Clash 与 mihomo 配置中的一部分描述代理逻辑，另一部分直接关联操作系统网络栈。前者可以集中维护，后者必须尊重设备差异。把同步边界划清，比寻找一个覆盖全部终端的单一文件更可靠。

最终结构可以概括为：订阅负责节点来源，覆写负责共同规则，私有存储负责版本与分发，本地配置负责系统接口。按这四项分别排查，能快速判断问题出在远端更新、合并过程、文件传输还是设备权限，而不必在多个完整配置副本之间反复比对。