Clash 多设备配置同步：先划分共享内容

电脑与手机共用配置，首先要区分“节点来源一致”“分流规则一致”和“客户端状态一致”。同一个订阅地址可以让两台设备获取相同的节点，但不会自动同步当前选中的节点、系统代理开关或 TUN 权限。WebDAV 与 Git 则主要负责传输文件，也不会替客户端完成导入和启用。

Clash 图形客户端负责配置管理与系统接入，内核负责读取配置、匹配规则和建立连接。Clash Meta 后续以 mihomo 名称维护；使用 mihomo 的客户端之间也可能存在内核版本、配置覆写方式和界面功能差异。因此，同步目标应是共同支持的配置内容，而不是复制整个应用数据目录。

适合共享与应当本地保留的项目

  • 适合共享：节点订阅来源、策略组名称、规则顺序、规则集地址，以及两端都支持的 DNS 策略。
  • 本地保留：系统代理开关、TUN 开关与权限、开机启动、网卡名称、日志位置和客户端窗口设置。
  • 单独检查：mixed-port、external-controller、secret 和局域网监听设置，避免把桌面管理接口原样带到手机。

三种同步方案的适用范围

优先根据需要同步的对象选方案。只需要更新节点，订阅链接最直接；希望保存一份可恢复的配置，WebDAV 更合适；长期维护规则并需要追踪修改，私有 Git 仓库更清晰。三种方式可以组合使用，但应明确哪个位置是权威来源。

方案同步对象设备侧要求更新方式
订阅链接托管节点或完整配置支持远程订阅及对应格式手动更新或客户端定时拉取
WebDAV 备份导出的 YAML 文件内置 WebDAV，或文件工具下载后导入上传、下载、重新导入或重载
私有 Git 仓库规则源文件与修改记录Git 工具或受控部署流程提交、拉取、验证后应用

“支持远程订阅”不等于“支持 WebDAV 登录”，也不等于“可以直接读取私有仓库”。如果客户端无法附带认证信息，受保护的文件地址便不能作为普通订阅地址使用。部署前应检查当前版本的订阅管理、文件导入和认证能力，而不是仅看客户端名称。

订阅链接托管：电脑与手机分别导入同一来源

导入与更新步骤

  1. 从服务提供方取得适用于目标内核的订阅地址，确认返回的是完整 Clash 配置、节点列表，还是其他格式。只含节点的内容需要由客户端或配置模板组织成可运行配置。
  2. 在电脑和手机的订阅管理页面分别新增远程配置，粘贴同一地址。界面可能称为“订阅”“配置”或“Profiles”，实际名称以当前版本为准。
  3. 完成下载后，在两端各自选中并启用该配置。检查策略组、规则数量和节点是否齐全，再开启各自需要的系统接入方式。
  4. 有定时更新功能时，可先使用 24 小时一次的更新周期；节点临时失效或提供方通知调整时，手动更新并确认更新时间发生变化。

这里的 24 小时是便于管理的起始建议，并不是所有客户端的默认值。移动系统可能限制后台任务，所以即使设置了自动更新，也应在重要使用前打开应用查看最近更新时间。两台设备没有同时刷新时，短时间内看到不同节点列表是正常现象。

完整订阅与 proxy-providers 的区别

图形客户端更新远程配置，通常是重新获取配置文件；mihomo 的 proxy-providers 则是在配置内部定义节点提供者。对于 HTTP 类型提供者，interval: 3600 表示更新间隔为 3600 秒，但它不等于整个客户端订阅每小时重载，也不负责同步应用设置。选择哪个层级更新，应由配置组织方式决定。

如果远程订阅包含规则，直接编辑下载得到的 YAML，下一次更新可能覆盖修改。需要自定义分流时，应使用客户端明确支持的本地覆写、合并或脚本机制，并检查它作用于哪些字段。电脑与手机没有相同覆写机制时，可在受控服务器生成两端都能读取的最终配置。

WebDAV 备份：传输配置文件与恢复副本

WebDAV 提供远程文件读写能力，适合把已整理的配置保存到个人存储服务，再在另一台设备恢复。它传输的是文件；除非客户端明确提供自动恢复机制，否则上传完成后仍需下载、导入和启用。

单向发布比双向覆盖更容易排错

  1. 在存储服务中建立专用目录，例如 clash-config/。使用 HTTPS 与专用应用密码，让发布设备有写入权限，读取设备尽量只具备读取权限。
  2. 从电脑导出需要共享的 YAML，检查是否包含节点密码、订阅令牌、控制接口密钥等敏感字段。根据备份用途决定保留哪些内容。
  3. 先上传带日期的文件，例如 shared-2026-08-14.yaml，保留上一份可用副本。确认文件完整后，再按存储服务支持的方式更新稳定文件名。
  4. 手机若支持 WebDAV 恢复，使用对应入口；若没有，可通过支持 WebDAV 的文件工具下载，再从代理客户端的本地文件入口导入。
  5. 启用后检查规则与连接日志。恢复失败时重新导入上一份配置，不要立即删除备份。

如果两端都向 shared.yaml 写入，较晚的上传可能覆盖较早的修改。WebDAV 的条件写入、锁定和冲突处理取决于服务端与客户端实现，不能假定它会自动合并 YAML。建议由电脑发布，手机读取；手机上的临时节点选择继续保留在本地。

备份配置与备份应用数据要分开

客户端完整备份可能包含数据库、内部配置标识和系统路径，这类备份通常更适合同一个客户端自身恢复。跨 Windows、macOS 与 Android 迁移时，优先导出可阅读的配置文件。对于 iOS，应确认所用代理客户端实际支持的格式和导入路径，不能假定它能够直接读取任意 mihomo 配置。

若确实需要在远程存储保留含凭据的副本，可先加密归档，再上传 WebDAV。加密后的文件只能用于恢复：先在受信任设备解密，再导入客户端，不能当作普通 YAML 订阅直接拉取。

私有 Git 仓库：管理规则版本与设备差异

Git 适合记录规则为什么调整、哪个版本可以回退，以及桌面和手机采用了哪些差异。建议仓库保存不含凭据的规则源文件，将订阅地址和节点密码保存在本地或受控部署环境。仓库设为私有只是访问控制措施，不会自动清除提交历史中的秘密。

从一份不含节点凭据的规则文件开始

下面是用于说明共享结构的最小配置，example.com 是文档示例域名。它没有代理节点，所有连接最终直连，不能替代服务提供方订阅。接入真实节点后，应让客户端的合并机制或配置生成流程保留相应策略组与节点定义。

mode: rule
mixed-port: 7890
allow-lan: false
log-level: info

proxies: []

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

7890 是示例本地混合代理端口，可接受 HTTP 与 SOCKS 代理连接；若端口已被占用，电脑端应改用可用端口，并让系统代理保持一致。手机客户端可能自行管理监听端口和 VPN 接入方式，因此该字段是否覆盖本地值，要看客户端实现。

建立本地版本记录

安装 Git 并配置提交身份后，可在存放 policy.yaml 的目录执行以下命令。这里只建立本地历史；同步到私有远程仓库时，再按仓库服务提供的说明配置 SSH 或访问令牌。

git init
git add policy.yaml
git commit -m "记录共享分流配置"

git diff -- policy.yaml
git log --oneline -- policy.yaml
  • 使用独立的本地私密文件保存订阅凭据，并通过 .gitignore 排除。忽略规则不会移除已经被跟踪的文件。
  • 发布前审阅 git diff，确认只改变预期规则。桌面与手机不同的 TUN 设置不要混在共享规则文件中。
  • 同步读取设备优先使用只读部署凭据，不把仓库写入权限交给每一台手机。
  • 需要回退已共享的改动时，可使用 git revert 生成逆向提交，再重新生成并导入配置，保留变更记录。

代理客户端通常不会执行 git pull，私有仓库的网页地址也不是 YAML 原始内容地址。手机端可以手动下载导入，或由受控部署流程把规则与订阅组合成带认证的 HTTPS 配置入口。后者仍需确认客户端支持对应认证方式，并把构建日志中的令牌隐藏。

更新验证：配置一致不代表设备接入一致

建议先在一台设备验证，再发布给另一台。每次只调整一个层级：先确认文件获取，再确认配置加载，最后确认系统接入与网络表现。这样能区分同步失败、内核兼容问题和本地权限问题。

  1. 检查源文件：确认下载结果是 YAML 而不是登录页面。HTTP 401 常见于认证失败，403 表示访问被拒绝，404 表示资源不存在；应从存储或托管服务侧检查权限与地址。
  2. 检查解析：查看客户端错误日志，确认没有缩进错误、重复字段或不支持的协议参数。策略组引用的名称必须存在，规则顺序仍是先匹配先处理。
  3. 检查启用状态：配置下载成功后还需确认当前选中的文件已经重载。节点选择是否恢复，取决于客户端缓存和策略组名称是否保持一致。
  4. 检查系统接入：电脑启用系统代理后，支持系统代理的应用才会按该设置接入；Android 等移动平台通常通过 VPN 接口接入，所需授权要在设备本地完成。
  5. 检查实际连接：用同一测试目标查看两端连接日志中的命中规则与策略。页面能打开只能说明连接成功，不能单独证明它经过了预期代理。

即使节点与规则完全相同，电脑和手机仍可能因为 Wi-Fi、蜂窝网络、DNS 环境或 IPv6 路径不同而出现不同结果。遇到“电脑正常、手机失败”，先在同一 Wi-Fi 下复测，再检查移动端权限、节点协议支持及日志中的错误，避免反复覆盖共享配置。

多设备同步的推荐组合与维护节奏

两台设备：同订阅、本地接入

电脑与手机各自导入同一订阅，定期检查更新状态；系统代理、TUN 与启动方式留在本地。修改分流较少时，在更新或重要调整前保存一份带日期的 YAML 备份即可，不必引入仓库和发布流程。

长期维护规则：Git 记录、订阅更新、WebDAV 留档

把不含凭据的规则放入私有 Git 仓库，节点继续由订阅提供。验证后的配置通过受控方式发布，WebDAV 保存可恢复副本。规则变更后立即验证并发布，订阅更新按客户端周期执行，备份在确认新配置可用后生成，三类更新不必绑定为一次操作。

  • 每次更新：记录配置来源、更新时间和当前启用状态，检查一条直连规则及一条预期代理规则。
  • 更换客户端或内核：先导入测试副本，检查协议、规则集、DNS 与 TUN 字段是否受支持，再替换日常配置。
  • 设备丢失或停止使用：撤销该设备的 WebDAV 与仓库访问凭据；订阅链接可能泄露时，按提供方流程重置。

需要查看基础操作时，可先阅读订阅导入教程；规则顺序与内核差异可对照规则技术参考和内核说明。多设备同步的关键，是让节点与规则有明确来源，同时把端口、权限和系统接入留给各设备单独管理。