🔄 先说说我为什么折腾同步
我手上一共四台常用设备：一台 Windows 台式机、一台 MacBook Pro、一台跑着 Ubuntu 的迷你主机（当家庭网关），还有一台 Android 手机。每台设备上都装了 Clash Verge Rev 或者兼容的客户端，节点信息、规则集、DNS 设置基本是一样的。以前我都是靠手动导出导入配置文件来保持同步，但每次改一点小地方就要重复四次操作，实在受不了。后来我下定决心搞一套自动化的同步方案，顺便把平时折腾过程中用到的各种同步软件都梳理了一遍。
你可能会说，直接放云盘不就好了吗？没那么简单。配置文件里包含了节点密码、订阅链接等敏感信息，直接丢到公共网盘有风险；而且不同设备上的路径、环境变量甚至系统权限都不一样，不是简单的文件覆盖就能搞定。这篇文章记录的，就是我在过去大半年里折腾同步软件的真实经历，包括那些我踩过的坑和最后留下的方案。如果你已经看过我之前写的 多设备同步方案，这篇可以当作那篇的补充和延伸，我会更侧重工具本身的横向对比。
📋 选同步工具前，我先列了个需求清单
任何工具选择都不能凭感觉，我先把自己的需求拆解成几个硬性指标：
- 安全性：配置文件含敏感信息，必须支持加密或私有化部署。
- 跨平台：Windows、macOS、Linux 至少都要支持。
- 自动化：最好能定时同步或者文件变化时自动触发，不需要每次手动。
- 冲突处理：多设备同时改配置时，不能轻易覆盖丢失。
- 轻量：不希望为了同步再装一个笨重的客户端。
另外，我还有一个特别的诉求：保留版本历史。有时候改错配置导致网络彻底断掉，能回滚到上一个可用版本非常重要。这一点直接影响了后面很多选择。
基于这些条件，我试了五类工具：Syncthing（去中心化文件同步）、Git（版本控制）、WebDAV/云盘（存储型同步）、chezmoi（专门的配置管理器），以及一些零散的脚本方案。下面一个个说。
🔁 Syncthing：去中心化文件同步，折腾但可靠
Syncthing 是我第一个认真尝试的方案。它是一个开源的 P2P 文件同步工具，不需要中央服务器，每台设备之间直接建立连接。安装包很小，配置好之后完全在后台静默运行，文件一有变动就自动同步。我把它部署在 Windows、macOS 和 Ubuntu 三台设备上，共享同一个文件夹（Clash 配置目录）。
优点是显而易见的：完全去中心化，数据不经过任何第三方服务器；同步速度极快，局域网内基本可以达到满速；没有存储容量限制；而且开源免费。对于担心隐私泄露的人来说，这可能是最理想的方案。
但问题也很快暴露。首先是冲突处理不够智能。如果两台设备同时修改了同一个文件，Syncthing 会把冲突文件重命名为 config.sync-conflict-20260818-123456.yaml，但不会自动合并。对于 Clash 配置这种一个文件包含全部设置的情况，你只能手动打开两个版本，逐行对比合并。其次是没有历史版本。虽然 Syncthing 有“版本控制”功能，可以设置保留 N 个旧版本或者按时间清理，但默认是不开启的，而且配置起来有一定门槛。最后是文件监听并不总是及时，在 Linux 无图形界面环境下，inotify 的监听数量有限制，偶尔会出现同步延迟。
后来我学聪明了：用 Syncthing 同步的是 ~/.config/clash-verge-rev 目录下的 规则文件和本地配置文件片段，而不是直接同步主配置文件 config.yaml。因为主配置往往包含订阅自动生成的节点信息，每次更新都会变化，同步起来意义不大。而规则文件、自定义 DNS 配置、以及一些预处理脚本变化不频繁，同步价值更高。这样大大减少了冲突概率。如果你对 Clash 配置的模块化还不了解，可以先看 配置教程 和 Rule Provider 的内容。
📦 Git：版本控制带来的安心感
第二个方案是 Git，也是我最终长期使用的主要方案。把 Clash 的配置目录初始化成一个 Git 仓库，推送到私有的 GitHub 或自建的 GitLab 仓库。每次修改配置后 git commit，其他设备 git pull 拉取最新更改。这个方案的优点是版本历史完备，任何时候都能回滚到任意一次提交；而且可以利用 Git 的分支功能做实验性配置。
但 Git 也有学习成本，而且不适合完全无脑操作。你需要掌握基本的 add、commit、push、pull 流程，还要处理合并冲突。如果多设备同时修改了同一部分，Git 会提示冲突，你需要手动解决。但比起 Syncthing 的“直接生成冲突文件”，Git 的冲突提示更明确，至少你知道两个版本分别改了什么。
另外，Git 不支持二进制文件或大文件的良好处理，但我们的配置文件都是纯文本 YAML，没有这个问题。我还用 .gitignore 忽略了日志、缓存以及包含敏感信息的文件（比如 cache.db）。节点密码等敏感信息其实仍然存储在 config.yaml 里，所以我用的是私有仓库，并且配合 git-crypt 对 config.yaml 进行了透明加密。这样即使仓库不小心泄露，别人也看不到节点密码。关于 git-crypt 的配置，我之前的 多设备同步方案 里有详细步骤。
如果你不想用 Git 命令行，也可以配合 GitHub Desktop、VS Code 的 Git 插件 等图形化工具来降低门槛。我习惯在电脑上用 VS Code 管理，手机上用 Working Copy 或者 Termux 里跑命令行。
☁️ WebDAV 与云盘：简单直接的存储型方案
如果你完全不想折腾 Git 和 Syncthing，只想“把文件扔到一个地方，其他设备去取”，那么 WebDAV 或者云盘同步盘可能是最简单的选择。我用过坚果云和 Nextcloud 自建的 WebDAV，它们在 Clash Verge Rev 里可以通过“从 URL 导入”直接读取配置，也可以配合脚本定时上传下载。
WebDAV 方案最大的优点是上手极其简单。你只需要有一个支持 WebDAV 的云盘账号，在每台设备上设置好上传和下载脚本，然后交给 cron 或计划任务定时执行。坚果云还提供历史版本功能（付费），可以在一定范围内恢复旧文件。但它的缺点也很明显：没有实时同步，只能定时拉取；冲突处理基本靠手动；而且云盘服务器在第三方，节点信息上传上去总有点不放心。
我的使用方式是：WebDAV 作为 备份手段，而不是主力同步。每周用脚本把整个配置目录打包加密后上传到坚果云，相当于一个异地备份。这样即使本地所有设备都挂了，我还能从云端恢复。实际上，这更像是给 Git 方案加了一层保险。
🏠 chezmoi：配置管理的专业玩家
chezmoi 是一个专门用来管理 dotfiles（配置文件）的工具，支持模板、加密、跨平台差异化。我用它来管理所有非 Clash 的配置文件（比如 .zshrc、.vimrc），顺便也把 Clash 配置纳入管理。它和 Git 的关系很紧密，通常搭配一个 Git 仓库使用。
chezmoi 的强大之处在于：可以为不同设备生成不同的配置内容。比如在 Windows 上，Clash 的配置路径是 %APPDATA%\clash-verge-rev，而在 Linux 上是 ~/.config/clash-verge-rev，chezmoi 可以通过模板变量自动适配。你还可以写条件判断，比如“如果是 macOS，DNS 监听地址用 127.0.0.1；如果是 Linux 网关，监听 0.0.0.0”。
不过 chezmoi 的上手门槛比前面几个都高，它有自己的命令体系和配置语法。如果你只是同步一两个文件，用 chezmoi 有点大材小用。但对于我这种同时还管理其他 dotfiles 的人来说，它确实能统一管理所有配置文件，而且结合 Git 后也有完整的版本历史。如果你有兴趣深入了解，可以查阅官方文档。
📊 五款工具横向对比，以及我的最终选择
| 工具 | 安全性 | 跨平台 | 自动化 | 版本历史 | 冲突处理 | 学习门槛 |
|---|---|---|---|---|---|---|
| Syncthing | 高（P2P） | 全平台 | 高（实时监听） | 中（需配置） | 弱（生成冲突文件） | 中 |
| Git | 高（私有仓库+加密） | 全平台 | 中（需手动或脚本） | 极高 | 强（明确冲突提示） | 高 |
| WebDAV/云盘 | 中（依赖服务商） | 全平台 | 低（定时脚本） | 低（部分服务商提供） | 弱 | 低 |
| chezmoi | 高（+Git 加密） | 全平台 | 中 | 高（依托 Git） | 中 | 高 |
| 普通网盘客户端 | 低（明文存储） | 全平台 | 高 | 无 | 弱 | 极低 |
经过一段时间的折腾，我的最终方案是：Git 作为核心同步 + Syncthing 作为局域网实时同步补充 + WebDAV 作为异地备份。具体来说，Git 仓库承载所有配置文件和规则集的版本管理，每台设备通过 git pull 和 git push 保持同步；在家庭局域网内，用 Syncthing 实时同步一个“待同步”文件夹，让改动可以在几秒内出现在其他设备上；每周再用脚本加密打包上传到坚果云，作为最终保障。这个组合兼顾了版本历史、实时性和备份安全，可能不是最简单的，但对我来说最踏实。
🔧 结合 Clash Verge Rev 的同步细节与避坑
最后说说在实际同步 Clash 配置时遇到的一些细枝末节。首先，不要同步整个 configs 目录。这个目录里包含所有导入的订阅和临时文件，有些文件是自动生成的，没必要同步。只需要同步你手工编辑的那几个 YAML 文件，比如 my-rules.yaml、dns.yaml、tun.yaml 等，然后在主配置里通过 RULE-SET 或 include 引用。这样同步的体积小，冲突也少。
其次，注意不同平台上的路径差异。如果你的配置里写死了本地路径（比如 path: ./rules/cn.yaml），同步到其他设备后路径可能不存在。最好的做法是使用相对路径，或者用 配置教程 里提到的环境变量。
还有，订阅更新与同步的冲突。Clash Verge Rev 的自动订阅更新会覆盖主配置文件，如果你同时用 Git 管理这个文件，更新后就会产生未提交的更改。你需要养成习惯：每次自动更新后，先检查一下变更内容，再提交。或者干脆把订阅更新和本地配置解耦，让订阅只更新节点信息，规则和 DNS 部分保持独立。这一点在 订阅更新时间 那篇里也反复强调过。
最后，测试同步流程本身。别等到真出问题了才发现同步脚本没生效。我每隔一段时间会故意在一台设备上修改一个测试字段，然后看其他设备是否能在预期时间内收到更新。这个习惯帮我提前发现了好几次脚本错误。
✍️ 写在最后
同步软件没有银弹，适合我的方案不一定适合你。但核心原则是相通的：把动态和静态文件分开、重视版本历史、多做备份、定期测试。如果你连 Clash Verge Rev 的配置都还在用默认设置，建议先把 配置教程 吃透，再考虑同步的事情。同步只是让配置管理更方便的手段，真正的关键还是配置本身是否合理。