先确定同步范围：节点、规则还是整套设置
电脑和手机使用同一份订阅，通常只能保证两端取得相同来源的节点或配置，不能保证代理模式、当前选中节点、TUN 开关和应用分流设置完全一致。多台设备同步 Clash 配置之前，先把“远程内容”和“设备本地状态”分开。这样换手机、重装系统或更新订阅时，才不会误把本机设置当作已经备份的内容。
- 节点与订阅内容：由服务提供方生成，可能是完整配置，也可能只有代理节点。订阅更新后会重新获取远程内容。
- 个人规则与策略组：可能保存在 YAML 文件，也可能由客户端的覆写、合并或脚本功能生成，导出时要确认包含哪一层。
- 设备设置：系统代理、VPN 授权、TUN 服务权限、应用分流与本地监听地址通常需要逐台处理。
- 运行状态：策略组当前选择、连接记录和缓存不等于配置文件，是否保留取决于客户端的备份范围。
三种同步方式怎么选
| 方式 | 适用场景 | 更新方式 | 主要边界 |
|---|---|---|---|
| 订阅链接 | 电脑、手机长期使用同一节点来源 | 每台设备独立拉取 | 本地覆写与系统权限不会随链接迁移 |
| 配置文件导出 | 一次性迁移、离线转移、保留规则快照 | 修改后重新导出和导入 | 可能缺少外部规则文件与客户端数据库 |
| WebDAV 备份 | 定期留档、重装恢复、同类客户端迁移 | 手动或按客户端支持的计划上传 | 不等于跨客户端实时同步 |
三种方式可以组合，而不是只能选一个。例如，Windows 与 Android 分别订阅同一地址；个人规则保存在独立文件；每周把配置和规则备份到 WebDAV。节点更新走订阅，规则修改有记录，设备损坏后也有可恢复的副本。
订阅链接同步：每台设备独立导入
适合节点经常变化、两端需要持续更新的情况
订阅地址是远程配置入口，不是设备之间的同步通道。电脑更新成功，不代表手机已经更新；两端可能仍在使用不同时间下载的内容。先确认服务允许的设备数、并发连接数与流量额度，同一订阅被多端使用时，这些限制通常仍由服务端统一计算。
- 在原设备找到当前配置对应的订阅地址，复制完整链接。保留查询参数，不要只复制域名或路径。
- 在目标设备进入配置管理入口，选择通过 URL 导入，粘贴地址并保存。不同客户端的入口名称可能是“配置”“订阅”或“Profiles”，以实际界面为准。
- 完成首次下载，确认节点数量、策略组名称与更新时间。若仅出现节点而没有规则，检查拿到的是节点订阅还是完整配置。
- 选中刚导入的配置，再启用连接。桌面端按需要开启系统代理；手机端完成系统 VPN 授权。
- 分别执行一次手动更新，确认两端都能获取远程内容，再设置自动更新周期。
如果界面以小时为单位，可先设为每 24 小时更新一次；如果使用配置中的 proxy-providers，其 interval 通常以秒计，24 小时对应 86400。这两个入口不是同一个定时器，不能把“24”直接照搬到以秒为单位的字段。手机还可能受后台任务限制，使用前手动更新一次更容易确认状态。
同一订阅不一定适用于所有客户端
原版 Clash 与 Clash Meta（现称 mihomo）的功能范围不同，客户端还可能使用其他内核。提供方输出的配置若含有目标内核不支持的协议或字段，导入可能失败。应选择服务方明确标注适配目标客户端的订阅格式；仅把文件后缀改成 .yaml 不会完成格式转换。遇到导入问题，可先核对订阅导入步骤，再查看具体错误信息。
配置文件导出：保留一次可回滚的快照
导出 YAML 适合一次性迁移，也适合在修改规则前保留快照。但“导出配置”和“备份应用”是两种操作。前者通常只包含内核运行所需的文本，后者可能额外包含订阅记录、界面偏好和覆写文件。迁移前先看导出结果，不要仅凭文件名判断完整性。
- 在源设备手动更新订阅，确认当前配置能够正常启动。记录客户端名称、内核类型与版本，便于目标端比较功能支持。
- 使用客户端提供的配置导出或打开配置文件功能，保存为
profile-2026-10-03.yaml。另存个人覆写文件，不要只保留生成后的临时配置。 - 检查
proxy-providers、rule-providers的path。若引用本地文件，一并迁移；若依赖远程 URL，确认目标设备能下载。 - 通过可信的文件传输方式发送至目标设备，使用本地文件导入。先作为新配置测试，不覆盖原来可用的配置。
- 检查端口、局域网监听、DNS 和 TUN 设置，再进行连接测试。全部通过后，才把它设为日常使用配置。
例如，电脑的混合端口设为 7890，目标设备上却已有其他代理程序占用这个端口，导入后就可能启动失败。又如，电脑保存了某张网卡的 DNS 地址，手机换到蜂窝网络后无法访问。跨设备复制应保留规则意图，而不是把每个网络参数原样照搬。端口相关问题可对照端口排查说明处理。
WebDAV 备份：用于留档，不把备份当实时同步
WebDAV 是文件访问方式，不是 Clash 或 mihomo 内核的通用同步功能。是否能在客户端填写 WebDAV 地址、是否能加密备份、是否支持计划上传，都取决于具体客户端。没有内置入口时，可以将导出的文件放到本地备份目录，再由支持 WebDAV 的文件工具上传。
建立独立目录和恢复流程
- 在自己的 WebDAV 服务中创建专用目录，例如
clash-backups/laptop/与clash-backups/phone/。使用 HTTPS，优先创建仅用于该目录的应用凭据。 - 如果客户端支持 WebDAV，在其备份入口填写服务地址、用户名和应用凭据；若服务区分基础地址与目录路径，按服务端说明分别填写。
- 首次手动上传后，在服务端查看文件时间和大小。文件名加入设备与日期，例如
laptop-2026-10-03.zip，不要让两台设备反复覆盖同一个文件。 - 下载一份备份，在备用配置或测试环境中恢复。确认订阅、覆写和规则确实存在，不能把“上传成功”当作“恢复成功”。
- 保留最近 7 份日备份和最近 4 份周备份，或按存储空间设置类似的保留策略。升级客户端前再留一份独立副本。
应用专用备份包可能只能由同款客户端读取，甚至受备份格式版本限制。跨客户端迁移优先使用双方都支持的配置格式，再手动补齐设置。WebDAV 上的文件也不会自动改变正在运行的内核；下载、导入、选中配置以及重新加载，仍是需要明确执行的步骤。
避免双向覆盖和凭据泄露
不要让电脑和手机同时编辑一个“当前配置”文件并双向同步。两端都可能先读取旧版本，再用各自的修改覆盖对方。更稳妥的规则是指定一台设备维护个人规则，其余设备只读取；需要共同修改时，先生成带日期的新副本，确认内容后再发布。备份包若含订阅地址或节点密码，应使用客户端支持的加密备份，或先用可信工具加密再上传，并将恢复口令分开保存。
自定义规则保留：把订阅底稿与个人覆写分开
直接修改订阅下载生成的 YAML，常见结果是下一次更新后修改消失。个人规则应放在客户端明确支持的覆写、合并或脚本层，或者由自己维护完整配置，再引用节点提供器。不同客户端的覆写语法与合并顺序并不统一，不能把一个客户端的脚本直接当作另一个客户端的配置导入。
下面展示的是运行配置中 rules 的顺序示意，不是通用的覆写文件。它假设已有名为 PROXY 的策略组，示例域名用于说明写法，实际使用时应换成需要处理的域名。若采用合并功能，要确认它会前置规则，而不是把规则追加到最终的 MATCH 后面。
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- DOMAIN-SUFFIX,example.net,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXY- 顺序：规则通常从上往下匹配，先命中的规则决定去向。放在
MATCH后面的个人规则不会得到匹配机会。 - 策略组名称：
PROXY必须与当前配置中的名称完全一致。订阅改名后，需要同步调整引用。 - 外部依赖：
GEOIP需要可用的地理数据；若使用GEOSITE或RULE-SET，还要确认目标内核支持以及数据、规则提供器已准备好。 - 设备差异：Android 按应用代理列表、桌面系统代理开关不属于上述域名规则，应分别设置。
更新前后各查看一次最终生效配置，确认个人规则仍位于兜底规则之前。若客户端能显示合并结果，以合并后的内容为准，而不是只看编辑器里的覆写片段。这样既能继续接收订阅更新，也能减少每次重新补规则的工作。
迁移后验证：四项检查确认实际生效
- 配置能加载：查看日志，确认没有未知字段、找不到策略组、读取规则文件失败或端口占用提示。记录导入与更新的时间。
- 流量进入客户端：桌面用遵循系统代理的浏览器测试，手机检查 VPN 连接状态。需要接管不遵循系统代理的应用时，再按目标客户端要求配置 TUN 与权限。
- 规则命中正确：分别访问一个预期直连的站点和一个预期代理的站点，在连接列表查看规则与最终出口。测速延迟不是规则生效的证明。
- 更新后仍保留修改：手动更新订阅一次，重新检查个人规则，并重启客户端再测试，排除只在当前会话里生效的情况。
如果出现“电脑正常、手机不通”，按订阅格式、策略组选择、DNS、系统授权的顺序检查，不要立即更换全部配置。若问题只发生在某个 Wi-Fi，先比较该网络和蜂窝网络的表现，再排查本地 DNS 或网络限制。连接接管步骤可参考系统代理设置教程。
最终保留三样东西即可形成清晰的恢复链路：可重新获取节点的订阅入口、独立保存的个人规则、经过恢复验证的备份。日常更新交给各设备的订阅任务，规则只在一个维护源修改，端口和权限按设备单独配置。这样同步的是需要一致的内容，而不是不适合跨平台复制的运行环境。