多台设备共用一套 Clash 配置：订阅链接、云盘与覆写文件同步方案

先划分共享配置与设备参数

电脑和手机共用 Clash 配置，通常需要共享的是节点来源、策略组名称与分流规则，而不是整个客户端数据目录。Windows 的系统代理、Android 的 VPN 接管与 Linux 的路由权限并不相同。把一台设备正在使用的全部文件复制到另一台，可能连同不适用的网卡名称、监听地址和运行状态一起带过去。

还要区分客户端与内核：客户端负责导入订阅、定时更新、生成配置和设置系统代理；Clash 或 mihomo 内核负责读取最终配置并处理流量。客户端中的“覆写”“合并”“脚本”等功能，不是所有内核都能直接读取的通用配置字段。

方案一：各设备导入同一订阅链接

订阅链接适合统一更新节点，也最适合手机与桌面端混用。它的工作方式是各客户端独立请求同一个地址，并保存各自的副本；不是一台设备修改后，其他设备立即跟随改变。订阅服务是否允许多设备使用、并发连接数如何计算，需要以服务端约定为准。

导入与更新步骤

1. 确认订阅输出格式。完整 Clash YAML 通常包含节点、策略组和规则；仅含节点的订阅需要客户端或本地配置补齐其他部分，不能仅凭链接后缀判断。
2. 在每台设备的订阅管理页使用“从 URL 导入”一类入口。不同客户端的入口名称不同，导入后先预览配置，确认不是网页、登录提示或错误文本。
3. 分别启用更新任务。例如把桌面端更新间隔设为 24 小时；手机端仍需允许后台运行，不能把计划时间当作必定执行的时间。
4. 手动更新一次，检查节点数量、策略组名称与更新时间，再激活该配置。不要只看到订阅条目出现，就认定内核已切换成功。

服务端生成的整份订阅配置可能在更新时被替换。直接编辑下载副本中的 rules，下一次更新就可能丢失。需要长期保留的规则，应放入客户端支持的本地覆写层，或者放到自行维护的配置源中。

订阅同步不包含当前节点选择

同名的 select 策略组，在手机上可以选节点 A，在电脑上选节点 B。部分内核支持通过 profile.store-selected 保存本机选择，但这不等于跨设备同步。自动测速组也会受本地网络影响，同一配置在家庭宽带与移动网络上选出不同节点，属于正常现象。

订阅地址通常带访问凭据。不要把完整链接放进公开仓库、截图或公开的问题反馈，也不要交给来源不明的在线转换服务。发生泄露时应在服务端重置订阅地址，再更新所有设备保存的地址；只删除本地文件不能撤销旧链接的访问权限。

方案二：云盘同步配置源文件

云盘更适合维护自定义 YAML、规则文件和修改说明，尤其适合两台桌面设备之间同步。建议同步一个独立的“配置源目录”，不要直接同步正在运行的客户端数据目录。后者可能同时包含缓存、日志、数据库、锁文件和客户端专属元数据。

使用单一编辑端，避免双向覆盖

可以在云盘中建立以下目录。文件名用于说明职责，并不要求客户端识别这些名称；客户端需要导入哪个文件、是否复制到内部目录，应单独确认。

clash-config-source/
  shared-rules.yaml
  desktop-source.yaml
  mobile-source.yaml
  change-notes.txt

1. 指定一台电脑编辑源文件。其他设备只读取或导入，避免离线修改后出现两个冲突副本。
2. 修改后先在编辑端检查 YAML 和规则目标，再等待云盘完成上传。
3. 接收端确认下载完成，随后重新导入或重新加载配置。文件到达云盘目录，并不等于客户端已经读取新内容。
4. 保留上一份可用文件及修改说明。回退时恢复源文件，并在客户端重新加载。

云盘的网页分享链接通常返回预览页面，可能还要求登录，不能直接当作订阅地址。客户端需要能够直接获取配置内容的地址；如果做不到，就使用本地文件导入。手机通过系统文件选择器导入时，客户端可能只保存一次性副本，后续云盘更新不会自动传入。

敏感配置需要限制访问

完整配置可能包含节点密码、订阅凭据以及外部控制接口的访问密钥。云盘目录应限制共享范围，停用不再需要的公开分享。备份与日常分发也应分开：一份长期保留的备份，不应自动成为所有设备持续读取的生产配置。

方案三：订阅加本地覆写文件

当节点需要跟随订阅更新，而端口、DNS 或规则需要长期保留时，覆写更合适。客户端先获取订阅，再按自己的合并或脚本逻辑生成最终配置，最后交给内核。覆写的入口、格式与执行顺序依客户端而异，不能把某个客户端的合并文件原样导入所有设备。

把设备参数留在本地

下面是桌面设备的局部参数示例，不是独立可运行的完整订阅。它不包含节点和策略组；需要放入支持这类顶层字段合并的客户端覆写入口，或手动合入完整配置。

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

mixed-port: 7890 表示在同一端口接收 HTTP 与 SOCKS 代理连接。若本机已有程序占用 7890，可以改为 7893，并同步修改指向该端口的系统代理或应用代理。allow-lan: false 用于关闭局域网访问，不能把这一设置误解为跨设备共享代理服务。

手机端若通过系统 VPN 接口接管流量，通常不需要照搬电脑的系统代理端口设置。Android 的按应用代理、后台电池策略，以及桌面端的 TUN 开关与管理员权限，都应在各设备分别核对。

规则列表不能假定自动拼接

YAML 是数据格式，不自带统一的覆写算法。一个客户端可能用本地 rules 替换整个列表，另一个则提供“前置规则”功能。新增规则前，先确认合并行为；尤其不要用仅含两条规则的列表覆盖原订阅后，才发现所有其他分流规则都消失了。

# 仅为规则顺序示例，目标 PROXY 必须已在最终配置中定义
rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,DIRECT

上述示例会将 example.com 及其子域交给 PROXY，其余连接交给 DIRECT。它不是通用的日常分流方案。实际添加规则时，应放在能匹配它的兜底规则之前；如果最终配置只有名为“节点选择”的策略组，就不能继续引用不存在的 PROXY。

跨平台兼容：检查内核、DNS 与 TUN

同一份 YAML 能被桌面客户端加载，不代表手机端一定支持所有字段。Clash 与 mihomo 的能力并不完全相同，客户端也可能对配置进行裁剪或重新生成。遇到加载失败，应先记录每台设备的客户端版本与实际内核版本，再查看第一条解析错误，不要只比较应用名称。

• 节点协议：逐一检查订阅中的节点类型是否被目标内核支持。某类节点在一台设备缺失，可能是兼容性问题，不一定是同步遗漏。
• DNS 监听：例如 127.0.0.1:1053 是本机监听地址。仅复制这行配置，不会让操作系统自动把 DNS 查询发到 1053，也不会自动建立手机端的 DNS 接管。
• TUN 与网卡：不要共享写死的网卡名称或设备专用路由。TUN 所需权限、路由建立方式和 DNS 劫持入口，应按目标系统设置。
• 文件引用：proxy-providers 或 rule-providers 的本地路径需要在目标设备可读。复制主配置却漏掉引用文件，仍会导致加载或更新失败。

如果只需要共享节点来源，可以让各平台维护自己的主配置，通过兼容的 proxy-providers 引入节点提供器。但提供器有对应的内容格式要求，不能把任意完整订阅 YAML 填入 url 就认定兼容；应先确认订阅端提供的输出类型和目标内核的解析要求。

同步完成后，验证最终生效配置

验收重点不是“文件是否相同”，而是“需要共享的部分是否一致，设备差异是否保留”。配置源、覆写文件与客户端生成的运行配置可能是三个不同文件，排查时应优先查看客户端提供的最终配置预览或内核实际加载文件。

1. 确认输入：手动更新订阅，记录更新时间与节点数量；云盘方案则确认文件已完整下载，并重新导入。
2. 确认结构：检查策略组名称、规则目标和兜底规则。加载日志中出现策略不存在或 YAML 解析错误时，先修复结构。
3. 确认接管：桌面端检查系统代理或 TUN 是否启用；手机端检查 VPN 连接和需要代理的应用是否在接管范围内。
4. 确认连接：访问一个需要验证的域名，在连接记录中查看命中的规则、策略与实际节点。测速成功不能代替网页访问验证。
5. 确认持久性：再次更新订阅并重启客户端，检查自定义规则是否仍存在、设备端口是否仍正确，以发现被更新覆盖的问题。

三类常见同步故障

按设备组合选择同步方式

手机与电脑共用节点时，优先采用同一订阅、各自更新，并保留本机接管设置。两台桌面设备需要统一自定义规则时，可以使用云盘保存源文件，但应指定单一编辑端，避免直接同步运行目录。订阅更新频繁、又需要保留个性化规则时，采用订阅加本地覆写，并明确列表的合并顺序。

后续增加设备时，按“导入来源、设置本机参数、检查最终配置、验证连接”的顺序操作。节点和规则保持可追踪，端口、TUN 与权限保持设备独立，比强求所有文件完全一致更容易维护。