快喵VPN 多端同步：同一份配置，五端各取所需

§ 01 · 字段三分

三个字段层各管什么

同步的最小单位不是文件而是字段。同步载荷被切成三层：哪些字段可以跨端走、哪些只保留在特定端、哪些只存本机。

快喵VPN 4.7.2 把同步载荷切成七个字段，按作用范围归为三层。单次增量同步 6.8 KB，全量快照 42 KB。这个切法是 4.6.0 起采用的，目的是让五端各取所需而不互相覆盖。

为什么要分层：如果整份配置覆盖，桌面端每次改快捷键都会把手机端的设置冲掉。按字段分开之后，快捷键只写桌面端负责的那一格，其他端读不到也不受影响。

跨端字段：四类

节点偏好、分流域名规则集、主题与语言、更新渠道偏好这四类跨端同步。它们不依赖设备的物理形态，在哪一端改都会影响其他端。

限定端字段：两类

• 按应用分流名单只在桌面端与 Android 存在，因为 iOS 的系统接口不支持，Linux 的匹配方式不同。
• 快捷键绑定只在桌面端与 Linux 存在，移动端没有物理键盘常驻场景。
• 这两类字段各自保留，不参与跨端比较，所以桌面端的设置不会覆盖手机端。
• 限定端字段在一台设备上修改后，只写入该端，其他端的同名位置不变。
• 若某端后来支持了该能力，第一次同步时会收到一份空名单，需要手工配置。
• 限定端字段的条数也会记录，便于核对是否被意外清空。

三层归属怎么记住

记住一句话就够：能跨端的是「偏好」，只能落在一端的是「绑定」，压根不该出门的是「观测」。节点偏好与主题属于偏好，快捷键与按应用名单属于绑定，自检快照属于观测。

字段划分的六点用处

• 冲突处理有依据：不同层用不同策略，不必统一。
• 体积可预测：全量 42 KB 里九成是规则集，其余字段加起来不到 4 KB。
• 迁移有清单：导出时按层检查，不会漏掉只存本机的那一项。
• 三个用处都指向同一件事：让五端的行为可预期。
• 记住三层归属后，遇到「改了没同步过去」时能立刻判断是不是限定端字段。
• 这一条也是本站问答里出现频率最高的困惑来源。
• 若把三层归属记混，排查方向会错：先确认字段属于哪一层，再谈为什么没生效。
• 三层划分自 4.6.0 起采用，此前是整份覆盖，多端同时修改会互相冲掉。

§ 02 · 体积与增量

为什么单次同步只有 6.8 KB

全量 42 KB 里九成是规则集文本。改按行差分下发后，单次只传变化的行与校验值，体积降到 6.8 KB。

弱网下的差别

全量同步在弱网下的失败率是 4.1%，增量降到 0.6%。原因是 6.8 KB 能塞进一个数据包，重传成本低；42 KB 需要多次往返，任一次失败都要整份重来。

差分怎么算出来的

• 规则集按行切分，每行计算一次短哈希，客户端与服务端比较哈希列表找出变化行。
• 单值字段直接比较值，不等即下发。
• 删除的行以标记形式下发，不是简单省略，否则无法区分「没变」与「已删」。
• 每批增量都带一份整体校验值，拼接后校验不通过就整批重来。
• 差分不改变合并规则，冲突处理仍按各字段的策略执行。
• 规则集超过 5000 行时，增量会拆成多批下发，单批仍控制在 8 KB 以内。

§ 03 · 冲突

三端同时改同一字段，谁赢

冲突处理按字段策略执行，不是一个统一规则。四类字段四种策略，混为一谈会出现「改了没生效」的困惑。

为什么规则集取多而不是取新

删除规则与新增规则在差分层面无法区分意图。若按时间戳取新，一个误删就会把整批规则清掉；按条数取多，最多是把删掉的规则恢复回来，损失更小。这是保守取舍。

冲突不会弹窗的原因

• 同步频次高，弹窗会变成噪音，用户会习惯性点掉。
• 四类策略的后果都可预期，不需要用户当场决策。
• 真正的风险场景（跨格式）会直接阻断，不靠弹窗提示。
• 若发现某次修改没生效，可在客户端内查看最近一次同步的时间与字段清单。
• 需要精确控制时，先在一端改完并等同步完成，再动另一端。
• 规则集建议只在一台设备上维护，避免多端同时编辑。

四种策略的组合效果

四个字段各有自己的策略，合起来才是一次完整同步。若在桌面端删了规则、在手机端改了主题，同步结果是规则被恢复、主题按手机端更新。两部分互不影响，因为分属不同字段。

什么时候会真的丢东西

• 两个设备同时改同一个跨端字段，且较晚的那次是误操作时会丢。
• 规则集被误删到比另一端少时会丢，因为取多。
• 限定端字段不会丢，因为它不参与比较。
• 所以真正需要小心的是节点偏好与规则集这两项。
• 习惯做法是只在主力设备上改这两项，其他端只读。
• 误操作后可用导出文件恢复，前提是之前做过导出。

§ 04 · 同步流程

一次同步走五步，每步都能看到

同步不是一个黑盒动作，五步各有可观察的迹象。知道每步在做什么，遇到卡住时能判断卡在哪。

五步的顺序固定：鉴权、取清单、差分、合并、回写。前两步只做判断，不写本地；后三步才动数据。因此在前两步失败时，本地配置不会受影响，可以放心重试。

五步各自的耗时

卡住的三个位置

• 卡在第 1 步：账号未登录或登录态过期，表现为同步按钮无响应。
• 卡在第 3 步：规则集行数过多或网络抖动，表现为进度条停在中间。
• 卡在第 5 步：回写失败，下一次会重新拉取同一批，表现为反复同步同一份内容。
• 三步都能在客户端内的同步记录里看到时间戳，据此判断卡在哪。
• 卡住时不要反复点同步，先看记录里的时间戳是否在推进。
• 连续三次卡在同一步时，退出登录再重新登录可清掉本地状态。

为什么前两步失败不影响本地配置

• 鉴权与取清单都只读服务端状态，不写本地文件。
• 失败时客户端直接结束本轮，本地配置保持上一次合并后的状态。
• 因此在前两步失败时重试是安全的，不会产生半写入。
• 从第三步起才写配置目录，写入前会先备份一份临时副本。
• 若第三步中途失败，临时副本会回滚，界面提示一次同步未完成。
• 这也是同步卡住时不必担心配置被破坏的原因。

§ 05 · 五端差异

同一份快照，五端读到的并不完全一样

快照是同一份，但每端只读自己需要的字段。读的字段不同，实际生效的配置也就不同。

iOS 为什么只读规则集

iOS 不支持按域名改路由，因此规则集对它只是只读参考，展示在界面上但不参与生效。写操作被禁用以避免用户以为改了会生效。

Linux 的按应用名单为什么是只读

• Linux 的按应用分流依赖 cgroup 匹配，可配置范围与桌面端不同。
• 为避免把桌面端的名单照搬过来造成误判，Linux 端只读不写。
• 需要精确控制时，在 Linux 端本地配置，不参与同步。
• 三项差异都不是缺陷，而是各端能力范围在同步层的映射。
• 判断某字段是否对自己生效，看表 5 的对应格是实心还是横线。
• 差异只在字段层，账号与节点列表五端完全一致。

只读字段还要同步的三个理由

• 界面需要展示完整信息，用户在手机上也能看到桌面端维护的规则集内容。
• 保留读取能力便于跨端核对，换机时能看到原设备配了什么。
• 只读不等于不参与校验，字段变化仍会触发一次同步，保持版本号一致。
• 三个理由都与「读」有关，与「写」无关。
• 只读字段的大小仍计入全量快照，因此 42 KB 是五端共用的数字。
• 若希望某端完全不接收该字段，可在设置里关闭同步，代价是版本号长期落后。

账号与节点：唯一五端完全一致的两项

七个字段里，账号体系与节点列表不参与字段合并，由服务端统一下发。这两项在任何一端看到的都一样，包括节点数量、排序与分组名。

§ 06 · 导出与迁移

换机时先导出，再靠同步补齐

同步不是备份。换设备时正确顺序是导出、安装、登录、导入、核对。跳过导出会丢掉只存本机的字段。

导出文件里有什么

导出的是七个字段的完整内容加一份格式版本标记，体积与全量快照一致（42 KB）。文件为纯 JSON，可文本编辑，但没有签名，导入时不做完整性校验。

迁移的五步

• 在旧设备导出，确认文件体积在 42 KB 左右，明显偏小说明导出不完整。
• 在新设备安装并登录，先不要导入，让同步完成一次初始拉取。
• 导入导出的文件，选择覆盖而不是合并，避免两份规则叠加。
• 核对字段条数：规则条数、按应用名单条数、快捷键条数三项。
• 最后再开同步，让新设备成为最新的一份。
• 旧设备在确认无误后再退出登录并删除配置，避免它把旧快照写回账号。

§ 07 · 同步边界

四件同步做不到的事

把边界写清比夸大能力有用。以下四件事同步不做，也不必指望它做。

边界一：不合并连接状态

同步只传配置，不传「当前是否已连接」。在桌面端连接不会让手机也连上，五端的连接状态各自独立。

边界二：不传节点实测延迟

节点延迟与本地网络相关，换一台设备数值完全不同，因此不参与跨端。每端各自测量并缓存，缓存只存本机。

边界三：不替代备份

同步只保留当前状态，没有历史版本。误删一批规则后同步，其他端也会跟着删。需要留痕只能靠导出。

边界四：不跨配置格式

v3 快照需要客户端 4.6.0 及以上才能读。低于此版本的设备读到 v3 会拒绝同步而不是报错，表现为同步一直不完成。

• 四条边界都不随版本变化，属于设计决定而不是实现缺失。
• 连接状态不同步是刻意的：多设备同时连接通常不是想要的。
• 不传延迟是为了避免把一台设备的网络状况当成通用结论。
• 不替代备份这条最容易被忽略，误删后同步会立刻扩散。
• 不跨格式是保护措施：宁可拒绝，也不写入半懂的配置。
• 四条边界都能在客户端内的同步记录里看到对应提示。

四条边界的后果一览

§ 08 · 规则集同步

规则集为什么要单独处理

规则集是同步载荷里最大的字段，占全量体积的 92%。它的合并规则与其余字段不同，值得单独说清。

规则集在客户端里是一份按行排列的域名列表，每行一条规则。同步时按行切分、按行比较哈希，因此可以只传变化的行。合并时按条数取多，这个策略与「按时间戳取新」相反，原因是删除意图无法识别。

想让删除生效怎么办

只能在所有设备都同步完成后再删，且删的那一台必须是规则条数最少的一台。更稳妥的做法是在每台设备上都删一遍，或删除后立即在其他设备确认条数。

规则集的三个数量级

• 500 行以内：增量通常一批下发完成，耗时 0.3 秒左右。
• 500 至 5000 行：增量可能拆成两批，耗时 0.6 至 1.4 秒。
• 超过 5000 行：拆成多批，单批控制在 8 KB 以内，耗时 1.8 秒以上。
• 三个数量级的差别主要在差分计算与分批往返，不在写入。
• 行数越多，取多策略带来的恢复风险越大。
• 建议把规则集控制在 2000 行以内，兼顾效果与同步速度。

§ 09 · 同步调优

让同步更快更稳的四个设置

同步的五步里只有两步可调：差分计算与回写。四个设置能改变这两步的耗时，其余三步是固定的。

为什么四个设置都不建议改

默认值是按弱网失败率与耗时两项指标折中出来的。调大阈值能让快网更快，但弱网下重传一次就要重来 8 KB 以上；调小间隔能让改动更快传播，但请求频次上升会拖慢其他端的鉴权。

真正值得做的三件事

• 把规则集控制在 2000 行以内，这是耗时与效果的最佳区间。
• 只在一台主力设备上维护跨端字段，避免冲突。
• 换机时用导出而不是纯同步，避免丢只存本机的内容。
• 三件事都不需要改设置，只改使用习惯。
• 习惯改变带来的收益远大于调参，实测耗时能降到默认值的七成。
• 若一定要调，优先调规则集行数，其余三项保持默认。

同步频次的实测影响

间隔从 5 分钟调到 1 分钟，改动传播时间从 5 分钟降到 1 分钟，但鉴权请求量上升 4 倍，各端首连耗时上升 0.2 至 0.4 秒。收益与代价不成比例，因此默认保持 5 分钟。

两端的版本号为什么会对不上

每端记录自己上次成功回写的校验值。若某端长期离线，它的校验值会落后，重新上线后触发一次较大增量。落差超过 30 天时，客户端会改为拉取全量快照（42 KB）而不是增量，避免拼接过多批次。

离线三周后会发生什么

• 重新上线时先取字段清单，发现校验值差异较大。
• 落差在 30 天以内按增量拼接，最多 12 批。
• 落差超过 30 天改为拉取全量，耗时约 1.4 秒。
• 两种方式的结果一致，只是传输量不同。
• 离线期间该设备上的本地修改会作为一次提交进入队列，上线后参与合并。
• 冲突仍按字段策略处理，与在线时相同。

五个常见现象与对应位置

§ 10 · 同步问答

八个同步相关的问题

以下八问集中在「改了没生效」「会不会覆盖」两类。每条答案独立成立。

数据 · 同步相关数字

七个可复现的同步侧数字

以下七条只涉及同步载荷与体积，条件写在句子里，可与表 1 至表 6 对照。

§ 11 · 下一步

接着看哪一页

同步看清之后，剩下的是装哪个包、设备够不够、版本怎么滚。

若同步卡住且确认不是格式问题，先看版本节奏页的跨版本迁移一节，再判断是否需要导出重装。