多台设备共用一套 Clash 配置:订阅、同步与备份的可行方案

先确定同步对象：节点、规则还是完整运行配置

“多台设备共用一套配置”通常包含三种不同需求：让 Windows、macOS 和手机取得同一批节点；让各设备使用相同的规则与代理组；或者直接复制完整的 config.yaml。三者的同步范围不同。节点订阅最容易统一，规则与代理组适合集中维护，完整运行配置则经常受到系统、客户端和内核版本影响。

Clash 与 mihomo 配置不仅包含代理服务器。监听端口、控制器地址、TUN 网卡、DNS 劫持、局域网访问、GeoData 模式以及本地文件路径都可能写在同一个 YAML 文件里。把 Windows 正在运行的完整配置直接覆盖到 macOS，可能造成网卡名称不匹配、端口被占用或规则集路径失效。

按稳定性拆成三层

共享数据层：代理节点、远程规则集、代理组结构。这部分适合在所有设备之间统一。
平台参数层：TUN、DNS、监听地址、端口、进程匹配和网卡选择。这部分应按系统分别维护。
客户端状态层：窗口大小、主题、托盘行为、日志级别、最近选择的配置。通常留在本机，不进入同步。

方案一：各设备使用同一个订阅链接

订阅链接统一更新是最省维护成本的方案。每台设备独立保存订阅记录，在需要时向同一个地址拉取配置。Windows 上的 Clash Verge Rev、macOS 上的 Clash Verge Rev，以及 Android 上使用 mihomo 内核的兼容客户端，都可以分别导入同一地址。设备之间不直接传输本地文件，因此不会互相覆盖运行状态。

典型操作路径

在桌面客户端进入「订阅」或「配置」页面。
选择「新建」或「导入」，粘贴 HTTPS 订阅地址。
下载完成后选中该配置，再执行「设为当前配置」。
在自动更新设置中指定周期，例如 1440 分钟，即每天更新一次。
在另一台设备重复导入，不复制第一台设备生成的缓存文件。

不同客户端的菜单文字可能略有差别。以 Clash Verge Rev 2.x 为例，订阅通常在「订阅」页面管理，内核、系统代理与 TUN 则位于「设置」页面。排查时应明确区分“订阅已经更新”和“当前配置已经切换”：前者只下载新内容，后者才决定内核实际加载哪份配置。

自动更新周期怎样设置

节点信息每天变化不频繁时，12 至 24 小时更新一次通常足够。把周期设成 5 分钟会增加服务端请求，也可能在网络切换时反复写入配置。临时排查节点缺失时，可以手动更新一次，并检查客户端显示的更新时间是否改变。

项目	是否统一	处理方式
节点列表	统一	所有设备导入同一订阅地址
代理组	通常统一	由订阅内容或转换模板生成
当前节点选择	各设备独立	根据本地网络延迟选择
系统代理与 TUN	各设备独立	在客户端设置页分别开启
自动更新时间	可不同	桌面端可设 1440 分钟，移动端按使用频率设置

方案二：使用云盘同步 YAML 配置

云盘同步适合维护过自定义规则、代理组和 DNS 配置的用户。常见做法是把一份人工维护的 YAML 放进 OneDrive、iCloud Drive 或其他同步目录，再由各客户端导入该文件。关键点是把云盘里的文件当作“源文件”，而不是直接同步客户端正在读写的整个配置目录。

为什么不建议同步整个客户端目录

客户端目录可能包含 SQLite 数据库、窗口状态、日志、缓存和锁文件，这些内容会频繁变化。
两台设备同时运行时，云盘可能生成“冲突副本”，内核仍在读取旧文件。
不同系统使用不同路径分隔符，Windows 的盘符路径无法直接用于 macOS 或 Linux。
客户端升级后可能迁移目录结构，直接同步旧目录会把过期状态重新写回。

更稳妥的流程是：云盘保留 shared-base.yaml，各设备下载或复制到本地，再通过客户端执行「配置」→「导入本地文件」。修改规则时只编辑源文件，确认 YAML 能加载后再让其他设备取得新版本。若客户端支持覆写、合并或脚本功能，也可以让共享文件只负责规则和代理组，本地覆写负责 TUN 与端口。

配置目录以客户端入口为准

配置目录不是 Clash 生态中的统一标准。mihomo 以命令行启动时，常见主配置是 Linux 下的 ~/.config/mihomo/config.yaml；旧版 Clash 常见目录则是 ~/.config/clash/。图形客户端通常还有自己的应用数据目录和订阅数据库，文件位置会随应用标识与版本变化。

因此，查找目录时应优先使用客户端提供的按钮，例如 Clash Verge Rev 2.x 的「设置」→「配置目录」→「打开目录」。如果界面中没有该入口，再查看日志开头显示的工作目录或启动参数。不要因为目录中出现 config.yaml 就直接覆盖，先确认日志中的实际加载路径。

云盘同步的安全操作顺序

退出准备修改配置的客户端，避免它同时写入同一个文件。
等待云盘状态显示同步完成，再打开 YAML。
保存后检查是否产生冲突副本，例如 shared-base-conflicted-copy.yaml。
在一台设备上导入并重新载入配置，确认代理组、规则和 DNS 均可解析。
其他设备再取得该版本，并保留上一份可用副本。

方案三：自建配置托管与远程规则集

设备较多、规则需要持续维护时，可以把配置拆成主配置、代理提供者和规则提供者，通过 HTTPS 统一托管。每台设备只保存一个较短的入口配置，节点与规则由 mihomo 定时拉取。这种方式比手动复制 YAML 更适合台式机、笔记本、家庭服务器和移动设备共同使用。

使用 proxy-providers 集中节点

proxy-providers:
  shared:
    type: http
    url: "https://config.example.net/proxies.yaml"
    path: ./providers/shared.yaml
    interval: 86400
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - shared
    proxies:
      - DIRECT

rules:
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

interval: 86400 表示每 86400 秒更新一次，也就是 24 小时。健康检查每 600 秒执行一次，只用于判断节点能否完成指定测试请求，不代表真实下载速度。远程文件下载后会写入 ./providers/shared.yaml；这个相对路径基于内核工作目录，所以应确保客户端有写入权限。

使用 rule-providers 统一规则

rule-providers:
  private:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/private.yaml
    url: "https://config.example.net/rules/private.yaml"
    interval: 86400

rules:
  - RULE-SET,private,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

behavior: domain 适用于域名类规则。若文件包含 CIDR 网段，应使用与内容相符的行为类型；混合多种 Clash 规则语法时，可按 mihomo 支持情况使用 classical。行为类型与文件内容不一致会导致规则载入失败，日志一般会显示 provider 名称与解析错误位置。

远程托管需要处理的细节

服务器应提供 HTTPS，并返回正确的 YAML 文本内容。
私有地址需要访问令牌时，应控制令牌权限与有效期。
更新主配置前保留上一版本，避免一处语法错误影响全部设备。
规则集应使用稳定 URL，避免每次提交后文件地址变化。
远程文件更新后，客户端可能还要执行「重新载入」才能应用新的代理组结构。

跨平台字段差异：哪些内容必须留在本机

共享配置能否跨平台运行，取决于是否包含系统相关字段。规则语法、代理组和远程提供者通常容易复用；网卡、进程、端口和本地路径则需要逐台检查。采用 mihomo 内核也不代表所有图形客户端支持同一套界面选项，客户端可能通过覆写文件生成最终配置。

TUN 模式与网卡设置

TUN 会创建虚拟网络接口并接管路由。Windows、macOS、Linux 和 Android 的权限模型不同，图形客户端通常要求在本机完成授权。共享文件可以保留基础结构，但 interface-name、device、route-address-set 等依赖本机环境的字段不宜硬编码。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-detect-interface: true 能减少固定网卡名称带来的跨平台问题，但双网卡、虚拟机、公司 VPN 同时运行时仍需检查默认路由。若某台设备开启 TUN 后断网，先在「设置」→「TUN 模式」关闭该功能，再查看日志中的路由与权限错误，不要立即修改共享规则。

监听端口与局域网访问

mixed-port: 7890
allow-lan: false
bind-address: "*"
external-controller: 127.0.0.1:9090

mixed-port: 7890 同时接收 HTTP 和 SOCKS 代理连接。端口在某台设备上被其他程序占用时，可以只在本地改为 7891。external-controller 若只供本机客户端连接，建议监听 127.0.0.1:9090。需要局域网共享时，再按实际需求开启 allow-lan，同时检查系统防火墙和 WiFi 网络类型。

本地路径与规则资源

Windows 路径可能写成 C:\Users\Public\Clash\rules，macOS 与 Linux 则使用以 / 开头的路径。为了跨平台，规则提供者尽量采用相对路径，例如 ./rules/private.yaml。如果客户端把工作目录放在受保护位置，还要确认当前用户能够创建 rules 与 providers 子目录。

进程规则的系统差异

PROCESS-NAME 依赖操作系统报告的进程名称。Windows 可能匹配 example.exe，macOS 应用对应的可执行文件名称可能是 Example，Android 则可能按包名匹配。需要精确进程分流时，可以为各平台保留单独规则集，再在本地配置中引用。

推荐结构：共享基础配置加本地覆写

对于同时使用 Windows、macOS 和 Linux 的环境，可以维护一份共享基础配置，再为每个平台准备一份短覆写。基础配置放代理提供者、规则提供者、代理组和通用 DNS 逻辑；覆写文件只处理端口、TUN、进程规则和控制器地址。

文件组织示例

clash-config/
├── shared-base.yaml
├── overlays/
│   ├── windows.yaml
│   ├── macos.yaml
│   └── linux.yaml
├── rules/
│   ├── direct.yaml
│   └── reject.yaml
└── backups/
    └── shared-base-2026-08-04.yaml

是否能直接合并覆写，取决于客户端功能。部分客户端提供 Merge、Mixin、覆写或脚本入口；另一些客户端只能导入最终 YAML。不能自动合并时，可以在电脑上生成最终文件，例如 windows-final.yaml，再由对应设备导入。合并后必须检查同名键的覆盖结果，尤其是 rules、dns 和 proxy-groups 这类列表或嵌套对象。

同步时不要统一当前节点

家中宽带、办公网络和移动网络的路由条件不同。同一节点在 Windows 台式机上延迟 42 ms，在手机蜂窝网络上可能达到 180 ms。各设备应独立保留代理组选择，或者使用 url-test、fallback 等自动策略。共享的是候选节点和测试规则，不必强制共享最后一次选择。

备份、回滚与冲突处理

配置同步不能替代备份。同步会把删除、错误缩进和错误规则一起传播到其他设备；备份的作用是保留过去可恢复的版本。至少应保留当前可用配置、最近一次修改前配置，以及一个经过长期验证的稳定版本。

每次修改前执行四项检查

复制当前文件，并用日期命名，例如 config-2026-08-04.yaml。
确认 YAML 使用空格缩进，不混入 Tab 字符。
检查代理组引用的 provider、节点名称和其他代理组是否存在。
重新载入后查看日志，确认 rules、proxy-providers 与 rule-providers 均成功载入。

如果更新后所有设备同时出现问题，先暂停云盘同步或远程发布，避免错误版本继续扩散。随后恢复上一份稳定文件，关闭自动更新一次，重新载入内核。确认基础连接恢复后，再逐段加入本次修改，定位是 DNS、规则、代理组还是远程资源导致失败。

常见冲突的处理顺序

出现两个同名副本：比较修改时间与内容，不直接按文件名判断新旧。
客户端提示 YAML 错误：从日志给出的行号向上检查缩进和引号。
规则更新但行为没变：确认当前配置已重新载入，并检查规则匹配顺序。
某一台设备断网：先关闭该设备的 TUN 和系统代理，再验证共享配置本身。
远程 provider 下载失败：检查 HTTPS 地址、访问权限、DNS 与本地缓存路径。

三种方案怎样选择

使用场景	建议方案	主要维护点
两三台个人设备，只需相同节点	同一订阅链接	各设备独立更新与选择节点
有自定义规则，修改频率较低	云盘同步源 YAML	避免同步客户端数据库和缓存
设备较多，规则长期维护	自建 HTTPS 托管	版本管理、权限与回滚
跨 Windows、macOS、Linux	共享基础配置加平台覆写	TUN、端口、路径与进程规则

多数个人使用场景从订阅链接开始即可。只有在规则、DNS 或代理组需要自行维护时，再引入云盘源文件。设备数量增加后，可以把节点与规则拆成 provider，通过 HTTPS 定时更新。无论采用哪一种方案，都应让系统相关设置留在本机，并保留可直接回滚的稳定配置。

完成同步后，可以在每台设备分别检查四个结果：订阅更新时间正确、当前配置已切换、规则命中符合预期、TUN 或系统代理能够正常关闭与恢复。把这四项分开验证，比直接判断“能否打开网页”更容易发现配置差异。