同步边界：共享规则，保留设备参数

电脑与手机共用 Clash 配置，通常不是把一份运行中的 YAML 原样复制到所有设备，而是让它们引用同一组节点和分流规则，再分别保存系统相关设置。订阅负责节点来源，配置文件负责组织节点与规则，客户端负责导入、更新和启动内核；这三层各有状态，不能用一次文件复制全部覆盖。

例如，Windows 上的系统代理指向本机 127.0.0.1:7890，手机则通常通过系统 VPN 接口接管流量。两台设备可以使用同名策略组，却不应因此强制使用相同的 TUN 参数、网卡名称或文件路径。Android 的按应用代理与桌面系统的进程规则，也不是能够直接互换的配置。

配置层 适合同步的内容 宜留在本机的内容
节点与订阅 订阅地址、节点集合、更新约定 设备专属凭据、流量或连接数限制
分流策略 域名规则、策略组名称、规则集引用 本地网段例外、进程规则、应用排除列表
运行环境 经过各端验证的通用字段 监听端口、控制接口、TUN、DNS 接管方式

路线一：各设备订阅同一个地址

只需要电脑和手机使用同一批节点时，分别导入同一个订阅地址最直接。先确认服务方是否允许多设备使用，再核对同时在线数量、流量统计与套餐限制。配置可以被复制，并不代表账户允许任意设备同时连接。

先辨认订阅返回什么

  • 完整 Clash YAML：通常包含 proxies、proxy-groups 和 rules，可按客户端支持的方式作为远程配置导入。
  • 节点集合：用于节点提供器时，常见顶层结构为 proxies。它不能自动补齐完整配置所需的策略组和分流规则。
  • Base64 节点链接或其他内核格式：能否导入取决于客户端是否提供解析或转换功能。扩展名是 .yaml 也不足以证明内容兼容。

尤其要区分远程配置更新和 proxy-providers 更新。前者可能替换整份配置，后者主要刷新提供器中的节点；节点提供器更新不会自动把主配置的 rules 换成服务方的新规则。完整配置地址能否兼作节点提供器，应以目标内核实际解析结果为准。

更新频率不是即时同步

在支持的 HTTP 节点提供器中，interval: 3600 表示更新间隔为 3600 秒，即 1 小时。客户端远程配置的自动更新周期则是另一项设置，不能由这个字段替代。手机休眠、后台限制和客户端未运行，都可能使刷新时间晚于预期。

  1. 在第一台设备导入订阅，检查节点数、策略组名称以及配置加载日志。
  2. 在第二台设备导入同一地址，手动更新一次，确认没有导入旧的本地副本。
  3. 给更新周期设定一致的目标，例如 1 小时；确认两个客户端都支持该周期及后台执行方式。
  4. 服务方更换节点后，分别检查更新时间，不用“电脑已经更新”推断手机也已更新。

这条路线维护成本最低，但分流规则是否一致取决于订阅内容和本地覆写。若手机导入时自动附加了一套规则，电脑没有附加，两端行为仍然会不同。

路线二：私有仓库保存配置与规则

需要维护自己的域名例外、规则顺序或多台设备配置时，私有 Git 仓库更适合做配置的版本来源。它提供变更记录和回退能力，但不是客户端之间的实时同步服务，也不自动解决客户端下载时的认证问题。

仓库按共享层与设备层拆分

clash-config/
├── shared/
│   └── rules.yaml
├── desktop/
│   └── override.yaml
├── mobile/
│   └── override.yaml
└── README.md

以上是文件组织示例，不是 Clash 自动识别的目录约定。客户端不会因为目录叫 shared 就自动合并它。规则集需要主配置通过 rule-providers 引用，并以 RULE-SET 规则接入；覆写文件则需要客户端支持相应的合并或导入机制。

若使用 YAML 格式的域名规则集，下面的内容可作为格式示例。其中 example.com 是文档示例域名，不代表建议直连的业务地址。

payload:
  - "+.example.com"

这类内容可供 behavior: domain、format: yaml 的规则提供器使用。主配置还需定义提供器名称、获取方式和匹配后的策略。规则集文件本身不包含出口选择，不能直接替代完整的 rules 列表。

私有仓库的访问凭据单独处理

  • 浏览器能打开不代表客户端能拉取：浏览器已有登录会话，内核请求通常不会继承这些 Cookie。
  • 下载链接可能短期有效：带临时授权参数的原始文件地址，过期后可能返回登录页面或错误页。
  • 认证能力各端不同：需要自定义请求头或专门认证流程的地址，必须逐个客户端验证。
  • 订阅凭据不进提交历史：仓库保持私有只能缩小访问范围，不能消除历史记录、克隆副本和备份中的泄露风险。

Git 更适合存放不含订阅令牌的规则源文件；私密地址通过本地配置注入。若确实需要发布一份合成配置，应限制获取权限，并确认发布流程的日志不会输出完整内容。不要为了让手机方便拉取，就把私有配置改成公开文件。

回退与上线分开操作

桌面维护端可以用下面的命令检查改动，并撤销一次已提交的错误变更。回退提交产生后，仍需让各客户端重新获取并加载配置；Git 操作成功不等于手机配置已生效。

git diff -- shared/rules.yaml
git add shared/rules.yaml
git commit -m "调整共享域名规则"
git log --oneline -5
git revert HEAD

路线三：订阅加本地覆写或脚本

订阅负责节点变化，本地覆写负责保留个性化设置，是多数多设备场景的折中方案。关键在于把覆写保存在客户端提供的独立层，而不是直接编辑每次更新都会被替换的订阅缓存文件。

合并规则比文件内容更重要

不同客户端可能采用浅合并、深合并、列表替换或专门的前置追加机制。同一份 YAML 片段在一个客户端中追加规则，在另一个客户端中可能替换整个列表。下面仅是希望写入最终配置的字段示例，不是跨客户端通用的导入格式：

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

mixed-port 是 HTTP 与 SOCKS 混合监听端口。两台不同设备都使用 7890 通常不会互相占用；同一台设备同时启动两个监听相同地址与端口的进程，才可能出现绑定冲突。手机客户端是否允许用户覆盖该端口，应以其界面和运行配置为准。

规则列表尤其需要审查。例如想把一条本地域名规则放在兜底规则前，目标是调整顺序，而不是简单在文件末尾加一行。若 MATCH 已经匹配所有剩余流量，追加在它后面的规则不会再被执行。共享规则引用的策略组名称也必须在最终配置中存在。

脚本属于客户端能力，不是统一内核字段

部分桌面客户端提供 JavaScript 配置处理入口，能在加载订阅后修改配置对象。这种脚本的入口函数、执行时机和可用接口由客户端决定，不能直接复制给所有 Android 或 iOS 客户端，也不要与历史 Clash 配置中的脚本能力混为一谈。

  1. 先用静态覆写处理固定字段，减少脚本执行环境依赖。
  2. 只有确实需要根据节点或策略组动态生成内容时，再使用客户端脚本。
  3. 为脚本记录目标客户端、适用版本和测试日期；升级客户端后重新检查输出。
  4. 检查最终运行配置，而不只检查脚本是否保存成功。

平台差异：DNS、TUN 与内核能力

Clash 配置生态包含不同内核与图形客户端。使用 mihomo 的两个客户端，也可能因为内核版本、客户端生成逻辑或系统权限不同而表现不同。判断兼容性应看实际内核及版本，不应仅凭应用名称中含有 Clash 就认定字段全部通用。

差异项 多端处理方式 验证位置
TUN 接管 各端分别设置权限、路由与排除项 启动日志、系统 VPN 状态、连接列表
DNS 监听 避免复制桌面专用绑定地址与端口 最终 DNS 配置及端口绑定日志
进程与应用规则 桌面进程名和移动应用选择分开维护 实际应用连接的命中规则
文件路径 使用各客户端允许的工作目录 提供器下载结果与文件读取错误

DNS 的 fake-ip 模式会使用合成地址配合内核处理连接，不应把某台设备运行时产生的 DNS 缓存视为需要同步的配置。手机从 Wi-Fi 切到蜂窝网络后，上游解析可达性也可能改变；配置一致仍需要在两个网络环境分别测试。

iOS 上提供类似代理功能的应用，不一定使用 mihomo，也不一定直接接受完整 Clash YAML。选型时先核对订阅导入格式、规则语义和本地覆写能力，再决定共享哪些源文件。跨内核使用转换结果时，还需复核协议参数与规则行为，不能只看节点名称是否出现。

更新验收：确认两端加载的是同一版

配置同步应有可重复的验收动作。下面是一轮建议检查流程，不是特定客户端的实测性能结果。菜单名称会随客户端变化，操作时寻找远程配置更新、运行配置、连接和日志等对应入口。

  1. 记录来源：记录配置名称、订阅更新时间和共享规则的 Git 提交短编号，记录中不要包含完整订阅令牌。
  2. 主动刷新：两端分别更新远程配置；使用提供器时，再确认节点与规则提供器的更新时间。
  3. 确认加载成功：日志中没有 YAML 解析错误、未知策略组、提供器获取失败或端口绑定失败。
  4. 核对最终配置：确认运行模式为 rule，检查覆写是否保留，以及兜底规则是否仍在末尾。
  5. 检查真实连接：各端访问一个预期直连地址和一个预期代理地址，在连接列表核对命中规则及出口；延迟测试成功只说明测试目标可达。
  6. 补做网络切换：手机分别在 Wi-Fi 与蜂窝网络下验证，桌面再检查局域网服务是否仍能按预期访问。

若电脑正常、手机失败，先确认手机真正加载的配置与提供器更新时间，再检查 VPN 权限、后台刷新、DNS 和协议支持。不要先把所有规则改为全局代理，否则可能暂时绕过分流问题，却丢失用于定位原因的线索。

推荐组合与凭据处置

  • 仅共享节点：各设备订阅同一地址，设备参数各自保存；维护重点是账户限制和更新状态。
  • 共享节点与少量例外规则：订阅加独立覆写；优先采用各端都能表达的静态规则，分别确认列表合并行为。
  • 长期维护多台设备：私有仓库存规则源文件和变更记录，订阅凭据留在设备端，再按平台生成或导入不同配置。
  • 需要动态生成策略组：在具备相应能力的维护端处理，向其他设备交付兼容的结果，不假设手机能运行桌面脚本。

订阅 URL 通常具有凭据性质，二维码、配置导出文件和日志截图也可能包含同样的访问能力。分享问题截图前遮盖查询参数、节点密码与控制接口密钥。若地址已被他人获取，应在服务方后台重置订阅令牌，再更新所有设备；仅删除聊天消息或把仓库重新设为私有，无法使已复制的地址失效。

控制接口同样不属于需要同步到手机的公共入口。不要为了远程管理而直接将 external-controller 开放到公网。多设备同步的目标是分发配置与规则，而不是共享本机管理权限。先限定共享层，再保留设备差异，通常比追求所有 YAML 字节完全一致更易维护。