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

先区分配置同步、订阅更新与客户端备份

Clash 多设备同步并不是一个单独开关。Windows、macOS、Android 与 Linux 客户端可能都使用 mihomo 内核，但各客户端保存的数据并不完全相同。真正需要同步的内容通常分为三层：远端提供的节点与规则、本地编写的 YAML 配置，以及客户端自己的界面设置和运行状态。

三类数据不能混为一谈

• 订阅内容：包括代理节点、代理组、规则和提供方定义。客户端通过 URL 重新下载，适合由一个远端来源集中维护。
• 内核配置：包括 dns、tun、sniffer、监听端口、规则集地址等 YAML 字段。不同内核版本对字段的支持范围可能不同。
• 客户端状态：包括当前选中的代理节点、主题、开机启动、系统代理开关、窗口尺寸和日志级别。这些通常存放在客户端数据库或偏好设置中，不一定包含在 YAML 文件里。

例如，电脑上启用系统代理并监听 127.0.0.1:7890，只是电脑客户端的运行设置。把同一份配置导入 Android 后，手机并不会获得相同的系统代理状态，而是通过 Android VPN 接口接管流量。类似地，桌面端的 TUN 网卡名称、路由排除项和管理员权限设置，也不应原样套到手机。

同步前先记录四项基线

1. 确认每台设备使用的内核名称和版本，例如 mihomo 1.19.x，避免旧内核无法识别新字段。
2. 记录混合端口、控制端口和局域网监听设置。常见混合端口是 7890，外部控制器常见为 127.0.0.1:9090，但实际值以当前配置为准。
3. 检查配置中的本地绝对路径，例如 Windows 的 C:\Users\... 或 Android 私有目录。这类路径无法直接跨平台使用。
4. 保存当前可正常工作的配置副本，并注明日期、设备和客户端版本，例如 home-win-2026-08-16.yaml。

方案一：用订阅链接集中维护节点和规则

订阅链接是多设备场景中操作成本最低的方案。电脑和手机分别保存同一个 URL，需要更新时各自向服务器拉取最新内容。它不是设备之间相互复制文件，而是让所有设备读取同一个数据源，因此不会产生“哪台设备的副本才是最新版”的冲突。

典型导入流程

以常见客户端界面为例，桌面端通常进入「订阅」→「新建」→「URL」，填写订阅地址并设定自动更新时间；Android 客户端通常进入「配置」→「＋」→「从 URL 导入」。菜单文字会随客户端版本变化，但核心动作都是保存 URL、下载配置、选择该配置并启动内核。

1. 在第一台设备上导入订阅，确认下载返回正常，并检查节点数量与代理组名称。
2. 切换到规则模式，测试一个直连站点和一个需要代理的站点。
3. 在第二台设备导入同一 URL，不要先复制第一台设备生成的缓存文件。
4. 分别设置更新时间。日常使用可设为每 1440 分钟更新一次；节点变化频繁时可缩短到 360 分钟，但没有必要每几分钟请求一次。
5. 更新后查看客户端日志，确认返回状态和配置解析均成功。

订阅方案的优势与限制

最常见的问题是直接编辑订阅下载后的 YAML。很多客户端把该文件视为远端缓存，点击“更新”时会覆盖本地修改。需要长期保留的 DNS、规则或代理组调整，应放进客户端支持的覆写、扩展脚本或合并配置中；如果客户端没有这些功能，就维护一份独立配置，而不是把订阅缓存当作主文件。

用 provider 拆分可变内容

熟悉 YAML 的用户可以让主配置保持稳定，只把节点或规则放进远端 provider。以下结构展示了基本关系，URL 和路径需要换成实际可访问的位置：

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

proxy-providers:
  remote-nodes:
    type: http
    url: "https://example.net/profile/nodes.yaml"
    path: "./providers/remote-nodes.yaml"
    interval: 21600
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

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

interval: 21600 表示节点提供方每 6 小时检查一次，规则的 86400 则是每天一次。provider 的本地 path 是缓存位置，不应依赖某台设备的绝对目录。不同版本的 mihomo 对 format、规则行为和 provider 字段支持可能不同，导入后应先查看解析日志。

方案二：通过 WebDAV 做备份与恢复

WebDAV 更接近“把客户端资料打包保存到远端，再在另一台设备恢复”。它适合保存多个配置、覆写脚本、规则文件和部分客户端偏好，但前提是两端客户端都实现了兼容的 WebDAV 备份格式。WebDAV 只规定文件访问方式，并没有规定 Clash 客户端必须采用同一种备份结构。

适合 WebDAV 的场景

• 同一客户端在两台桌面设备之间迁移，例如旧电脑换到新电脑。
• 需要同时保存多个配置文件、脚本和客户端设置，而不只是节点订阅。
• 希望定期保留恢复点，在配置改坏后回退到昨天或上周的版本。
• 远端服务支持 HTTPS、独立账号和文件版本历史。

若客户端提供该功能，入口通常位于「设置」→「备份与恢复」→「WebDAV」或「设置」→「数据」→「WebDAV」。填写服务器地址、用户名、密码和远端目录后，应先执行“测试连接”，再创建第一份备份。地址可能是服务根路径，也可能是完整目录，例如 https://dav.example.net/remote.php/dav/files/user/clash/，具体格式以服务端说明为准。

一套稳妥的首次同步顺序

1. 在主设备停用自动恢复，手动创建一个带时间的远端备份。
2. 登录 WebDAV 服务确认文件已经生成，并记录文件大小。例如正常备份为 2.8 MB，若只有几十字节，应检查是否上传了错误页。
3. 在第二台设备安装相同客户端的大版本，再配置 WebDAV 连接。
4. 先下载备份列表，不要立即开启双向自动同步。
5. 选择明确时间点恢复，重启客户端，然后逐项检查订阅、规则模式、DNS 和 TUN 开关。
6. 确认第二台设备运行正常后，再决定是否启用定时备份。

连接失败时，可根据 HTTP 状态缩小范围：401 通常表示凭据未通过，403 表示账号缺少目录权限，404 常见于路径填写错误，409 可能是上级目录尚未创建，507 则表示远端空间不足。客户端只显示“备份失败”时，需要同时查看 WebDAV 服务端日志。

WebDAV 不等于实时双向合并

如果电脑与手机分别修改同一份配置，然后都上传到相同文件名，后上传的一方可能覆盖前一份。大多数客户端不会像协作文档那样逐字段合并 YAML，也无法判断代理组改动和 DNS 改动是否都应保留。

跨客户端恢复尤其需要谨慎。客户端甲可能把配置保存为 YAML 和 JSON 索引，客户端乙可能使用数据库记录配置 ID。即使二者都使用 mihomo，WebDAV 备份也未必互通。更换客户端时，应优先导出标准 YAML 或重新导入订阅，而不是直接恢复另一款客户端的完整数据包。

方案三：手动导出与导入 YAML

手动导出最容易理解，也最适合低频迁移：从现有客户端导出配置文件，通过局域网文件传输、数据线或个人存储空间送到另一台设备，再从文件导入。它不会自动更新，但每次传递的内容明确，便于归档和对比。

标准操作步骤

1. 在客户端进入「配置」或「订阅」，找到当前启用项，选择「导出」或「打开配置目录」。
2. 复制主 YAML 文件；若配置引用本地 provider、脚本或规则文件，也要一并复制对应目录。
3. 使用文本编辑器搜索绝对路径、局域网地址和设备专用网卡名称。
4. 将文件命名为包含用途和日期的形式，例如 travel-phone-2026-08-16.yaml。
5. 在目标设备进入「配置」→「＋」→「从文件导入」，完成后先查看解析错误，再启动代理。

跨平台时重点检查这些字段

• external-controller：若写成 0.0.0.0:9090，控制接口可能对局域网开放。普通本机使用可改为 127.0.0.1:9090。
• secret：控制接口令牌应随设备重新设置，不建议把同一值长期复制到所有设备。
• allow-lan：电脑为其他设备提供代理时才需要开启；手机导入后通常应重新判断。
• interface-name：网卡名称具有平台差异，Windows、Linux 和 Android 不能直接共用。
• tun：桌面端的路由、DNS 劫持和自动网卡检测参数不一定适合移动端。
• path：检查 provider、规则集和脚本是否使用了目标设备不存在的绝对路径。

external-controller: 127.0.0.1:9090
secret: "replace-with-device-specific-secret"
allow-lan: false

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

这段配置适合作为检查示例，不代表所有平台都应原样启用。Android 客户端通常通过系统 VPN 权限运行，桌面系统则可能需要管理员权限创建 TUN 网卡。若导入后出现“配置有效但无法联网”，可先关闭 TUN，只开启系统代理或应用内 VPN，确认基础节点可用后再逐项恢复。

手动方案最容易漏掉的文件

主配置中的 proxy-providers 和 rule-providers 如果使用 HTTP 类型，目标设备通常可以重新下载缓存；如果使用 type: file，则必须连同本地文件一起迁移。配置里引用的脚本、自定义 GEO 数据和证书文件也不会自动嵌入 YAML。

另一个常见误区是把运行缓存当成原始配置。名称类似 cache.db、profiles.json 或 state 的文件可能只对当前客户端有效。跨平台迁移时，优先寻找客户端明确提供的“导出配置”功能，而不是复制整个程序数据目录。

三种同步路线怎么选

推荐的组合方式

多数用户不必三选一。更稳定的结构是：订阅链接负责节点和公共规则，客户端覆写负责每台设备的 DNS、TUN 与局域网设置，WebDAV 或手动导出负责保留恢复点。这样即使某台设备设置损坏，也能重新导入订阅，再恢复少量设备专用参数。

1. 公共层：节点、代理组和公共规则从订阅或 provider 获取。
2. 设备层：端口、TUN、系统代理、局域网访问和控制接口在本机设置。
3. 备份层：每次大改前创建带日期的 WebDAV 备份或导出 YAML。
4. 验证层：更新后检查配置解析、DNS 查询、规则命中和实际连通性。

例如，Windows 桌面端可以使用混合端口 7890 并开启系统代理，Android 端则通过 VPN 模式运行；两端共享代理节点和规则，但不强求共享运行状态。当前选中的节点也可以不同：电脑选择低延迟节点，手机根据移动网络稳定性选择另一节点。

同步后无法使用的排查顺序

第一步：确认配置是否成功解析

先查看客户端日志，不要立即归因于节点。出现 field not found、yaml unmarshal 或重复键提示时，通常是内核版本不支持字段、YAML 缩进错误或合并配置产生冲突。YAML 应使用空格缩进，避免 Tab；同一级字段不要重复定义两次。

第二步：检查远端资源

• 手动更新订阅，确认 URL 可访问且返回的是配置内容。
• 检查 provider 下载状态，确认缓存文件不为空。
• 核对设备系统时间，时间偏差可能影响 HTTPS 连接。
• 确认订阅更新没有覆盖本地覆写，代理组中仍能看到预期节点。

第三步：把 DNS、规则与 TUN 分开测试

1. 暂时关闭 TUN，仅使用客户端支持的基础代理方式测试节点连通性。
2. 将模式临时切到全局，判断问题来自节点还是规则匹配。
3. 恢复规则模式，查看日志中请求命中了哪条规则和哪个策略组。
4. 检查 DNS 监听与劫持。若本机已有服务占用 53、7890 或 9090，应调整端口或停止冲突进程。
5. 最后重新开启 TUN，确认系统权限、默认路由和网卡自动检测正常。

多设备维护的长期做法

设备越多，越需要减少每台设备上的直接编辑。公共规则最好只有一个维护来源，设备专用设置则明确留在本地。不要让电脑、平板和手机分别保存三份稍有差异却没有版本标记的完整配置，否则几个月后很难判断哪一份包含最新修改。

建立简单的版本记录

• 文件名加入日期和用途，不使用“最终版”“最新版”这类无法排序的名称。
• 每次修改记录具体字段，例如“调整 fallback-filter”或“为 Android 关闭 allow-lan”。
• 大改前保留旧配置，确认运行 24 小时后再清理更早版本。
• 订阅、WebDAV 和控制接口凭据分开管理，设备丢失时可以单独撤销。
• 每月执行一次恢复测试，确保备份文件不只是成功上传，也确实能够导入。

最终选择可以很直接：只想让多台设备使用同一批节点，选订阅链接；需要完整迁移同一客户端，选 WebDAV；只是临时复制或跨客户端搬运，选手动导出。对经常修改规则的进阶用户，则采用“远端公共配置＋本地设备覆写＋定期备份”的分层方式，维护成本最低，也更容易定位同步后的异常。