多平台 预计阅读 13 分钟

Clash 多设备配置同步方案对比:订阅链接、WebDAV 与手动导出

电脑与手机各维护一份配置容易改乱。本文对比订阅链接集中下发、WebDAV 备份恢复、配置文件手动导出三种同步思路的适用场景,并给出跨平台保持规则一致的实操建议。

先分清要同步的是哪一层

Clash 的“配置”并不是单一文件。电脑和手机看起来都显示节点、规则与代理组，但这些内容可能来自远程订阅，也可能保存在客户端自己的数据库里。开始同步前，先把数据拆成三层，后面选择方案会清楚很多。

核心配置：节点、代理组、规则与 DNS

核心配置通常是 YAML 文件，包含 proxies、proxy-groups、rules、dns 等字段。mihomo 内核还支持 rule-providers、proxy-providers、sniffer 与更完整的 TUN 参数。这一层最适合通过订阅链接集中下发。

mixed-port: 7890
mode: rule
allow-lan: false

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

proxy-groups:
  - name: 节点选择
    type: select
    proxies:
      - 自动选择
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,节点选择
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

客户端设置：系统代理、TUN 与启动行为

“启动时连接”“开机启动”“系统代理”“允许局域网连接”等开关，通常属于客户端本地设置。即使两台设备导入同一个 YAML，这些开关也未必同步。Windows 上启用系统代理，不代表 Android 或 iOS 会自动建立 VPN；macOS 的 TUN 权限也不能通过配置文件复制到另一台设备。

运行状态：当前节点与延迟记录

当前选中的节点、最近一次测速结果、日志与流量统计多为运行状态。它们可能写入客户端数据库，也可能在重启后重置。把这些状态当作同步目标，容易得到“配置一样，界面却不一样”的结果。更稳妥的做法是同步代理组结构，让每台设备自行测速并选择节点。

方案一：用订阅链接集中下发

订阅链接适合两台以上设备长期使用，也是维护规则最省力的方式。服务器保存一份主配置，电脑、手机和平板分别添加同一个订阅地址。规则变化后只修改源端，再让各设备执行更新。

实际操作顺序

  1. 在可信的订阅管理端准备主配置，确认 YAML 可被目标内核载入。
  2. 在桌面客户端进入「配置」→「订阅」或「Profiles」→「New Profile」，粘贴 HTTPS 地址。
  3. 在移动端进入「配置」→「从 URL 导入」，填写同一地址并保存。
  4. 设置自动更新间隔。日常使用可设为 1440 分钟；规则变化频繁时可设为 360 分钟。
  5. 首次更新完成后，检查代理组数量、规则数量、DNS 模式与最后更新时间。

不同客户端的菜单名称会有差异。例如部分桌面端使用「配置」→「新建」→「URL」，部分移动端把入口放在「配置」右上角的加号中。判断是否成功不能只看“更新完成”，还应打开配置详情，确认文件大小不是 0 KB，并查看是否出现 YAML 解析错误。

把设备差异留在本地

同一个订阅中不宜强制写入所有设备的本地参数。桌面端可能需要 mixed-port: 7890，移动端则通过系统 VPN 接口接管流量，不会使用这个端口。TUN 的网卡名称、路由权限与 DNS 劫持方式也有平台差异。

较稳的结构是让远程订阅负责节点、代理组、规则集和通用 DNS 策略；系统代理、TUN 开关、局域网访问和启动行为由各设备自己保存。如果客户端支持覆写或 Mixin，可在本地只补充少量参数，而不是复制整份主配置。

# 主配置负责通用逻辑
mode: rule
log-level: info

rule-providers:
  private:
    type: http
    behavior: domain
    format: yaml
    interval: 86400
    url: https://config.example.net/rules/private.yaml
    path: ./ruleset/private.yaml

订阅方式的限制

  • 依赖网络可达：新设备首次导入时必须能访问订阅地址，否则无法取得配置。
  • 更新可能覆盖本地编辑：直接修改已下载的订阅文件，下次刷新通常会恢复为远程版本。
  • 链接本身需要保护：订阅 URL 可能包含访问令牌，不应放进公开仓库、截图或群聊记录。
  • 客户端转换行为不同：某些客户端会自动转换字段，另一些会按原始 YAML 严格解析。

方案二：用 WebDAV 做备份与恢复

WebDAV 更像“保存客户端快照”，而不是实时编辑同一份 YAML。支持 WebDAV 的客户端通常会把配置、偏好设置或备份包上传到远程目录，再由另一台设备下载恢复。它适合换机和同客户端迁移，但跨平台兼容性取决于备份内容。

先确认客户端到底备份什么

有的客户端只上传订阅列表，有的会同时保存本地配置、代理组选择与应用设置，还有的仅提供手动导入导出，并没有 WebDAV 功能。操作前应打开「设置」→「备份与恢复」或「设置」→「WebDAV」，查看说明中是否包含订阅、覆写、规则与本地偏好。

若备份包包含客户端数据库，它通常只能恢复到同一应用或兼容版本。例如版本 2.1.0 生成的数据库，未必能被另一款 mihomo 图形客户端读取。此时即使两端都使用 mihomo 内核，界面层的数据结构仍然可能不同。

推荐的 WebDAV 操作流程

  1. 在第一台设备进入「设置」→「备份与恢复」→「WebDAV」。
  2. 填写 HTTPS 服务器地址、用户名、应用专用密码和远程目录。
  3. 点击“测试连接”，确认返回成功后执行一次手动备份。
  4. 记录备份时间和文件大小。例如正常备份为 428 KB，若新文件只有 2 KB，应先检查内容是否完整。
  5. 在第二台设备安装相同客户端，先保持未启用系统代理或 VPN。
  6. 连接同一 WebDAV 目录，选择刚生成的备份并恢复。
  7. 恢复后重新授权 VPN、TUN 或系统代理，再测试规则匹配。

WebDAV 地址可能要求填写服务器根路径，也可能要求填写完整目录。例如服务端入口为 https://dav.example.net/remote.php/dav/files/user/，客户端若再自动拼接用户名，就可能得到重复路径并返回 HTTP 404。HTTP 401 通常表示账号或应用密码错误，HTTP 403 则常见于目录没有写入权限。

避免两台设备互相覆盖

WebDAV 不一定提供配置冲突合并。如果电脑在 10:20 上传，手机在 10:23 又上传一份旧配置，服务器上的最新文件可能反而缺少刚修改的规则。更安全的方式是指定一台主设备负责上传，其他设备默认只恢复；或者按设备名建立目录。

/ClashBackup/
  desktop-main/
    backup-2026-06-20.zip
  macbook/
    backup-2026-06-20.zip
  phone/
    backup-2026-06-20.zip

若客户端支持保留历史版本，建议至少保留最近 3 份。一次错误覆盖不会立即破坏所有备份。恢复前也应先导出当前配置，尤其是手机端已经存在本地覆写时。

方案三：手动导出 YAML 或备份文件

手动导出最直观，也最容易控制变更范围。它不依赖远程服务，适合只有两台设备、配置改动很少，或需要离线迁移的情况。常见入口为「配置」→「打开配置目录」「配置」→「导出」或配置条目右侧的分享菜单。

YAML 导出与完整备份不是一回事

导出 YAML 通常只能带走核心配置。系统代理开关、当前节点、客户端主题、快捷键和 TUN 权限仍需在新设备上重新设置。完整备份可能包含更多应用状态，但跨客户端可移植性更低。

如果目标是从 Windows 迁移到 macOS，优先导出标准 YAML；如果是在同一手机应用之间换机，可优先使用应用提供的备份包。不要直接复制整个运行目录，因为目录中可能混有缓存、日志、数据库锁文件和特定平台路径。

导入前做四项检查

  • 端口冲突：mixed-port: 7890 若被其他程序占用，可改为 7891 后重新载入。
  • 绝对路径：C:\Users\name\rules\local.yaml 无法直接用于 macOS 或 Android。
  • 规则文件：检查 rule-providers 引用的本地文件是否一并复制。
  • 内核字段：确认目标客户端支持 geodata-mode、sniffer、tun 等选项。

导入后先不要立即打开全局 TUN。可以先启动内核，在日志中检查配置载入结果，再用系统代理完成基础测试。桌面端常用 HTTP 与 SOCKS 混合端口为 7890，控制器端口常见为 9090，但实际值以配置为准。

用文件名保留版本线索

手动复制最常见的问题不是文件丢失，而是分不清哪个更新。建议文件名包含日期、设备用途和修订号，例如 clash-main-2026-06-20-r03.yaml。每次只改一个主题，并在同目录保存简短记录。

2026-06-20 r03
- 新增 DIRECT 局域网规则
- 调整自动选择测试间隔为 300 秒
- 保持 Fake-IP 模式
- 桌面端本地启用 TUN，移动端不写入主配置

若两台设备分别修改过文件，不要只按文件大小判断新旧。可逐段比较 proxy-groups、rule-providers 和 rules，尤其注意规则从上到下匹配，顺序变化可能直接改变连接去向。

三种同步方式如何选择

三种方案并不冲突。订阅负责持续下发，WebDAV 负责恢复客户端状态，手动导出负责离线留档，是更接近实际使用的组合。下面按维护成本与兼容范围进行对比。

方式 适合设备数量 主要同步内容 跨客户端能力 典型用途
订阅链接 2 台以上 节点、代理组、规则、通用 DNS 较好，受内核字段影响 长期集中维护
WebDAV 1 至 3 台 订阅列表、客户端设置或备份包 一般，常要求同一客户端 换机与恢复
手动导出 1 至 2 台 单份 YAML 或完整备份 YAML 较好，备份包较低 离线迁移与留档

个人两台设备

电脑与手机使用频率都不高、规则每月只改一两次，可以直接手动导出 YAML。每次修改后更新日期与修订号，再通过系统文件分享功能导入另一端。若节点来自服务订阅，则只手动维护覆写和自定义规则。

电脑、手机和平板长期共用

建议以订阅链接为主。代理组名称保持一致，例如统一使用“节点选择”“自动选择”“故障转移”，各设备的界面更容易核对。WebDAV 只保存客户端备份，不参与日常规则编辑。

经常重装或测试多个客户端

保留一份尽量标准的 mihomo YAML 作为基线，不把特定图形客户端的数据库当作唯一来源。客户端专属功能通过本地覆写加入。每次升级前做手动导出，WebDAV 则保存最近 3 次可恢复快照。

跨平台保持规则一致的实操方法

统一代理组名称，避免规则指向失效

规则末尾的策略名称必须与代理组完全一致。主配置中写了 DOMAIN-SUFFIX,example.com,节点选择，但移动端把代理组改名为“手动选择”，载入时可能报错，也可能无法得到预期分流。名称确定后尽量不要在单台设备上单独修改。

把平台差异集中在覆写层

通用配置保留节点、规则和 DNS 基础逻辑，平台相关参数放在本地覆写中。Windows 可以保留 7890 混合端口和系统代理；macOS 根据客户端授权 TUN；Android 与 iOS 则由应用建立 VPN 接口。这样更新订阅时不会反复覆盖平台设置。

固定测试清单

每次同步后用相同流程检查，通常 3 分钟即可发现大部分问题：

  1. 确认配置更新时间与预期一致。
  2. 检查代理组数量和默认选项是否相同。
  3. 对自动选择组执行一次延迟测试，记录可用节点数量。
  4. 打开日志，确认没有 yaml、provider 或 dns 相关错误。
  5. 访问一个应走 DIRECT 的站点和一个应走代理的站点，核对规则命中。
  6. 关闭再打开系统代理或 VPN，确认配置重载后仍然有效。

出现差异时先查更新链路

一台设备规则正常、另一台仍使用旧内容时，先比较订阅更新时间，再检查远程文件是否被缓存。若自动更新间隔为 1440 分钟，刚修改的内容不会立即出现，需要手动点击“更新”。更新后仍不一致，再检查客户端是否启用了旧的本地配置、覆写是否修改了规则，以及目标内核是否跳过不支持的字段。

一套可长期执行的组合方案

对于大多数跨平台用户，可以采用“订阅主配置 + 本地平台设置 + 定期手动备份”的结构。主配置通过 HTTPS 订阅统一节点、代理组、规则与通用 DNS；每台设备单独控制系统代理、TUN、VPN 权限和启动行为；每次大改前导出一份带日期的 YAML。

如果客户端支持 WebDAV，可再增加恢复层：每周或每次升级前上传一次备份，只保留最近 3 至 5 份。WebDAV 不负责合并规则，也不替代订阅。这样即使某次订阅内容有误，仍能从手动文件或历史备份回退。

同步的重点不是让每台设备的界面完全相同，而是让规则意图一致：相同域名命中相同策略，相同代理组拥有相同用途，平台特有参数留在各自设备。把主配置与本地状态分开后，多设备维护就从“复制整间屋子”变成“只搬需要的抽屉”。

Clash 客户端下载 查看各平台安装包