☁
云端同步
适合日常多设备协作。改动一处，其余端自动拉取刷新，不必每次手动搬运文件。
- 一键推送：改完即可同步，省去手动传递步骤
- 自动刷新：其余设备在下次载入时读取最新版本
- 改动可回溯：保留历史版本，误改可以找回
- 随时随地：跨网络、跨地点，不受局域网限制
1份配置，四端读取同一份
2条路径：云端推送与本地直传
0逐条重录的必要
热重载生效，连接不中断
One Source
一份配置，几台设备同时读懂
设备只是读取端，配置才是唯一的事实来源。任何一端改动后同步，其余设备在下次载入时得到相同的规则与策略—— 行为一致，不依赖「我上次好像在笔记本上改过」这种记忆。
C
同一份配置文件
规则 · 策略组 · 订阅地址 · 应用偏好
Windows
已同步
macOS
已同步
Android
已同步
iOS
已同步
i
同步的内容是配置，不是节点。节点与线路来自你的订阅，同步只保证各端读到的规则和策略结构相同。 订阅更新时各端各自拉取，节点选择依旧跟随你本地的策略组设置。
Two Paths
云上推还是本地递，你选
同步不一定非要走外部服务。日常多设备协作用云端更省心；一次性换机或在意数据路径时，本地直传更稳妥。 两条路径最终落到同一份配置上，效果一致。
⇄
本地迁移
适合一次性换机，或希望配置完全不经过第三方的场景。文件直传，链路自己掌握。
- 文件直传：通过文件管理器、U 盘或网络盘直接拷贝
- 局域网传输：同一网络下设备之间快速递送
- 不依赖外部服务：数据路径全部在自己控制范围内
- 可离线完成：没有网络也能完成迁移
两条路径不是二选一。可以先本地备份一份存档，再通过云端让其余设备日常保持同步；
关键配置有本地副本，日常使用有云端便利，两者互不冲突。
Consistency
同步之后，各端到底一致在哪里
一致性不是模糊的感受，而是可以被逐项对照的清单。下面这些内容在同步后，四端读到的是同一份。
同步项
Windows
macOS
Android
iOS
分流规则与规则顺序
一致
一致
一致
一致
策略组结构
一致
一致
一致
一致
节点订阅地址
一致
一致
一致
一致
应用偏好与开关
一致
一致
一致
一致
规则集引用路径
一致
一致
一致
一致
节点实际选择
按本地策略组
按本地策略组
按本地策略组
按本地策略组
i
规则一致，节点选择各自决定。同步的是判断逻辑，不是「必须走哪个节点」。 各端可以根据自己的网络环境选择不同的策略组，规则本身保持统一。
Migration
换设备，四步回到熟悉的状态
新增设备或更换设备时，最耗时的部分往往不是装软件，而是把过去积累的配置重新搭起来。 同步把这段过程压缩成几步。
Step 01
装好客户端
在新设备上安装对应版本，先不急着配置任何规则——这一步只是把入口准备好。
Step 02
导入同一份配置
通过云端拉取，或把旧设备上的配置文件直接传过来。规则、策略组、订阅地址随配置一并就位。
Step 03
按需微调本机偏好
桌面端可能开启系统代理，移动端可能使用 VPN 模式——这类与本机环境相关的设置，按需调整即可。
Step 04
开始使用
规则与策略和旧设备保持一致，日常访问的分流结果不需要重新熟悉。
# 一份可同步的配置骨架
mixed-port: 7890
mode: rule
log-level: info
proxies: # 来自订阅
# ...
proxy-groups: # 策略组结构
- name: PROXY
type: url-test
- name: DIRECT-FIRST
type: select
rules: # 分流规则
- DOMAIN-SUFFIX,internal.dev,DIRECT
- RULE-SET,ads,REJECT
- GEOIP,CN,DIRECT
- MATCH,PROXY
i
纯文本的好处：体积小、可读、可 diff。它既能通过云端同步，也能随其他文件一起备份， 放进版本管理里还能看到每次改动前后的差异。
Scenarios
多设备的人在哪些时刻会用到它
同步的价值往往不在配置的那一刻，而在你换了一个位置、换了一台设备之后。
⌂
在家与办公之间
台式机和笔记本共用一份规则：在家直连的服务，在办公网络下依旧直连； 需要绕行的目标，两端行为一致。换位置只是换网络环境，不需要重新适应分流结果。
✈
出行时的手机与平板
移动端读取同一份配置后，浏览器里常访问的站点、开发调试用的接口，分流结果与桌面端一致。 出门在外也不必回忆「这条规则我在电脑上是怎么写的」。
⌘
更换主力设备
旧机器退役、新机器上岗，配置导入即可回到熟悉的状态。 过去积累的规则、策略组命名习惯、订阅地址一并延续，不用从头再来一遍。
Conflict
多端同时改动，怎么不打架
同一份配置在多处被编辑，冲突几乎不可避免。与其事后补救，不如一开始就把结构摆对。
①
公共基线放订阅
规则集、广告表、地区表这类多人共用的内容放在订阅里，由来源统一维护。 各端只读取，不分别编辑，冲突自然减少。
②
个性化条目留本地
某台设备特有的规则——比如本机开发端口、特定环境适配——单独放在本地片段里。 公共部分保持整洁，个人调整互不影响。
③
改动前先拉一次
在编辑前先获取最新版本，可以减少在旧版本上修改带来的覆盖。 小步修改、随手同步，比攒一大波改动再合并更轻松。
同步的前提是「一份事实来源」。公共部分由订阅统一维护，个性化部分各自保留；
两者在加载时按顺序合并，既保证一致，也留出空间。
Notes
同步之外，还需要知道的事
把能力讲清楚，也把边界说明白。下面几点，能帮你对同步建立更准确的预期。
◐
同步不替你做节点选择
配置同步的是规则与策略组结构，节点依然来自订阅，实际使用哪条线路由本地策略组按测速或手动指定决定。 各端网络环境不同，节点选择本来就不必强求一致。
◑
云端路径仍取决于你的信任
如果选择走云端同步，意味着配置内容会经过相应的存储服务。 对数据路径有更高要求时，本地直传同样能完成迁移，两条路径最终落到同一份配置。
◒
热重载不等于零感知
配置重新载入时服务不中断，但正在进行的请求可能按新规则重新判定。 建议在改动较大时分批调整，便于观察每一步的效果。
◓
定期备份仍然值得
同步解决的是多端一致，备份解决的是「改坏了还能回去」。 同步之前保留一份本地副本，是成本很低但很有用的习惯。
Q & A
关于多端同步，常被问到的几件事
配置同步指的是同步什么内容？
同步的是配置本身：分流规则、策略组结构、节点订阅地址、应用偏好等文本内容。节点与线路来自你的订阅，同步只负责让各端读到同一份配置。
云端同步和本地迁移有什么区别？
云端同步适合日常多设备协作，改动一处、其余端自动刷新；本地迁移适合一次性换机或对第三方服务有顾虑的场景，通过文件直传或局域网传输，不依赖外部服务器。
换新设备后需要逐条重写规则吗？
不需要。导入同一份配置即可恢复完整环境：规则、策略组、订阅地址一并就位，不需要重新逐条录入。
同步会不会覆盖我在某台设备上的本地改动？
取决于同步策略。可以按需选择覆盖方向：本地修改推送上去，或拉取远端版本覆盖本地。建议把公共基线放在订阅里，个性化条目放在本地，减少冲突。
同步过程会不会影响正在使用的连接？
配置同步后由引擎重新载入，属于热重载范畴，服务进程不中断，已有连接按新规则继续判定。
配置文件是什么形态？
纯文本，通常是一份或一组 YAML 文件。体积小、可读、可 diff，也方便纳入版本管理或随其他文件一起备份。