手机与电脑共用一份 Clash 订阅配置的同步方案

先确定同步范围：共用订阅，不等于复制全部设置

先在手机和电脑分别打开客户端的「配置」或「Profiles」页面，查看当前启用的配置来源。如果两端都从同一个订阅地址下载配置，节点来源已经统一；但当前选中的节点、规则模式、系统代理开关和后台运行权限，通常仍由各设备独立保存。

订阅链接是客户端获取远程内容的地址。它可能返回完整的 YAML 配置，也可能只返回节点列表，甚至返回经过编码的其他格式内容。YAML 是用缩进表达结构的文本格式。只有客户端能解析的内容才可以直接导入，不能因为地址名称里有“订阅”就默认兼容。

mihomo 是 Clash Meta 后续使用的内核名称，负责处理代理协议和分流规则。客户端则提供配置导入、系统接管、更新等操作界面。两台设备都支持 mihomo 配置，并不代表两套客户端的覆写入口和合并行为完全相同。

配置内容	是否建议共用	处理位置
节点来源、通用策略组	建议	远程订阅或公共配置
公共域名分流规则	建议	公共规则源或公共覆写
监听端口、控制接口	按设备保留	客户端本地设置
Android 分应用代理	仅手机设置	Android 客户端界面
TUN、系统代理、VPN 授权	分别设置	客户端及操作系统

方案一：两端分别导入同一个订阅地址

只有手机和电脑两台设备、主要使用服务方提供的规则时，先选这个方案。它不需要额外托管服务器，出问题时也容易区分是下载失败还是本地配置冲突。

在服务方的账户页面复制适合 Clash 或 mihomo 的订阅地址。不要复制浏览器当前的账户页面地址。
在 Android 客户端打开「配置」，寻找「添加」「新建」或「从 URL 导入」，粘贴地址并保存。入口名称随客户端而变。
在电脑端打开「配置」或「Profiles」，通过 URL 导入同一个地址。下载完成后，明确选中这份配置。
两端各手动更新一次，查看更新时间、节点列表和策略组是否符合预期，再开启自动更新。
分别选择需要的节点或策略组。除非客户端明确提供状态同步功能，否则不要预期电脑切换节点后手机会一起切换。

更新间隔先设为 24 小时

如果界面以小时为单位，可先填 24；如果明确以秒为单位，24 小时对应 86400 秒。部分客户端只提供固定选项，应选最接近的值。遵守服务方公布的更新频率，不要把刷新间隔缩短到几秒来尝试修复连接问题。

Android 进入省电或后台受限状态后，定时任务可能延迟，因此“每天更新”不等于每天某个时刻一定执行。遇到节点变更，先打开应用手动刷新，再检查后台限制。电脑长期休眠也会错过计划更新时间。

这个方案不负责同步本地修改

直接编辑下载后的订阅正文，下一次更新时可能被覆盖。需要长期保留的规则，应放进客户端独立的本地覆写区域，而不是插入远程配置副本。客户端没有覆写能力时，保留一份本地配置可以避免覆盖，但也意味着后续需要自行维护节点和规则更新。

方案二：自建配置托管，统一公共规则

需要管理多台设备，或希望统一维护工作域名、策略组和规则顺序时，可以把公共配置放在自己管理的 HTTPS 服务中。客户端订阅这个托管地址，由维护者更新远端文件。这里的托管是保存与分发配置，不是让手机与电脑直接互传文件。

区分完整配置与节点提供器

完整配置通常包含 proxies 或 proxy-providers、proxy-groups、rules 等字段。proxy-providers 是节点提供器，用于按设定获取节点集合；它的资源不能随意替换为任意格式的订阅正文。

服务方提供可直接用于节点提供器的 YAML 时，可以在公共配置中引用，再让策略组通过 use 使用该提供器。
服务方只提供完整配置时，先确认是否有节点专用输出。不能把完整配置直接当作节点提供器文件使用。
如果必须转换格式，应在自己控制的环境完成。转换后的协议字段仍需与两端内核兼容。

这样可以把“节点更新”和“公共规则更新”拆开，但也多了一层故障点：主配置下载成功，不代表提供器下载也成功。排查时要分别查看两者的更新时间与日志。

托管前检查三个位置

访问响应：用未登录的浏览器测试客户端所用地址是否返回配置文本，而不是登录页、分享预览页或错误页面。若需要鉴权，先确认客户端支持对应方式。
权限范围：含节点凭据的文件不得放进公开仓库，也不要把访问令牌写进公开的规则文件或截图。
缓存策略：发布后分别手动刷新两端，确认实际内容已更新。若仍返回旧文件，检查托管服务和中间缓存，而不是反复修改客户端。

方案三：公共订阅加本地覆写，保留设备差异

先打开客户端的配置管理页，查找「覆写」「扩展配置」「Merge」或「Script」等功能。覆写是在远程配置下载后，再应用一层本地修改；脚本覆写则通过客户端提供的执行接口改动配置对象。它们属于客户端能力，不是所有 Clash 内核客户端都自带同一套脚本接口。

比较稳妥的组织方式是：订阅负责节点和基础策略，公共覆写负责共享规则，设备覆写负责本机差异。实际执行顺序由客户端决定；若产品只允许一层覆写，就把需要的改动合并到该层，并记录来源。

先用一条规则验证合并行为

下面是完整规则列表的演示片段，不是可以脱离节点与策略组直接运行的完整配置。DIRECT 表示直连；名为「代理」的策略组必须已经存在。example.com 是演示域名，部署时换成实际需要分流的域名。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,代理

Clash 规则通常从上往下匹配，命中后使用对应策略。MATCH 是兜底规则，因此要放在最后。如果把新增规则追加到已经存在的 MATCH 后面，它通常不会被执行。

尤其要确认列表如何合并：有的入口会替换整个 rules，有的支持前置或追加。上面的两行若被当成整表替换，会移除订阅原有的其他规则。正式使用前，打开客户端提供的运行配置预览，核对最终结果；没有预览时，先用配置检查与规则页面验证。

手机与电脑分别保留这些设置

Android：分应用代理、VPN 授权、后台电池限制由手机端管理。按包名选择应用的列表，不应直接复制成电脑端规则。
桌面端：系统代理开关、开机启动和 TUN 权限单独设置。TUN 是用于接管网络流量的虚拟网卡方式，不能仅靠复制一个开关就完成系统授权。
监听端口：例如桌面端将 mixed-port 设为 7890 时，使用手动代理的程序也应填写对应端口；手机通过 VPN 接管流量时，不需要照抄桌面程序的代理地址。
控制接口：不要为了同步配置而把 external-controller 暴露到公网。它用于管理内核，不是同步订阅所必需的入口。

更新后规则丢失：按生成顺序查冲突

发现手机规则正常、电脑规则失效时，先不要同时改两端。保留一台能工作的设备作为对照，在另一台逐项检查。每次只改一个位置，才容易找出覆盖发生在哪一步。

确认活动配置：检查当前选中的配置名称和来源。更新了未启用的配置，不会改变正在运行的规则。
保存本地设置：导出本地覆写和必要的客户端设置，备份中包含令牌时妥善保存。不要只备份远程订阅正文。
检查远程下载：先确认配置能成功拉取和解析。下载失败时，客户端可能继续使用旧副本，不能仅凭“还能联网”判断更新成功。
检查提供器：若使用节点或规则提供器，再核对其更新时间。主订阅和提供器各有更新机制，不一定同时刷新。
检查覆写结果：对照最终配置中的 rules 和 proxy-groups，确认规则没有被整表替换，引用的策略组名称也没有变化。
重新加载并测试新连接：使用客户端的重新加载或重启内核功能，再打开新的连接测试。旧的长连接不一定立刻按新规则重新路由。

常见的“策略不存在”错误，往往是服务方把策略组改名，本地规则仍引用旧名称。常见的“更新后自定义规则消失”，则是规则曾写在远程文件里，或后一层覆写替换了前一层。先找出字段的最终来源，再调整合并顺序，不要靠重复粘贴规则解决。

同步完成后的核对清单

最后在两台设备各做一次手动更新，分别测试直连域名、应走代理的域名和常用应用。记录配置更新时间、内核版本与本地覆写内容；版本可从「关于」或内核信息页查看，不要只记录客户端外壳版本。

看到的现象	优先检查	下一步操作
同一地址，两端节点不同	更新时间、缓存、服务方按请求返回的内容	两端手动刷新并比较下载结果
节点相同，访问路径不同	模式、规则顺序、选中的策略	检查连接记录中的命中规则
电脑导入成功，手机解析失败	内核支持的协议与字段	查看解析日志，选用兼容输出
手机锁屏后不再自动更新	后台限制和更新任务调度	先手动刷新，再检查电池设置
更新完成但仍走旧线路	长连接、策略选择、配置是否重载	重载后重新建立连接测试

只需要共用节点时，用同一订阅分别导入即可；需要统一管理规则时，再增加自建托管；设备差异较多时，把差异放进各端覆写。核心是让每项设置只有一个明确的维护位置，而不是让两台设备的全部配置文本始终一字不差。