一、先划分共享配置与设备配置

电脑与手机共用 Clash 配置，适合共享的是节点来源、代理组名称和规则分流逻辑，不是整个客户端数据目录。Clash Meta 所使用的 mihomo 内核负责读取配置和处理连接；客户端另行管理订阅更新、系统代理、VPN 授权与配置覆写。这两层的设置不能混为一谈。

例如，Windows 可以把系统代理指向 127.0.0.1:7890，Android 通常通过客户端建立 VPN 接口接管流量。即使两端读取相同的 rules，流量进入内核的方式也不同。同步成功应当指“规则与节点来源一致，设备接管方式各自正确”，而不是每个开关都一致。

  • 共享层：proxy-providers、proxy-groups、rule-providers、rules，以及经过两端验证的 DNS 策略。
  • 设备层：mixed-port、allow-lan、tun、监听地址、控制接口密钥和本机文件路径。
  • 客户端状态：当前选中节点、测速结果、日志、缓存和 VPN 权限。默认不纳入配置同步。

二、三种同步方式的更新机制对比

方式 更新如何到达设备 主要边界 适用场景
订阅链接托管 客户端定时或手动通过 HTTP 拉取 服务端内容与客户端覆写分开维护 节点经常变化，手机以读取为主
私有 Git 仓库 先拉取提交，再导入或重新加载文件 需要 Git 工具与独立的导入步骤 规则改动多，需要审阅和回退
WebDAV 同步工具下载文件，再交给客户端导入 文件冲突与配置生效是两件事 已有私有存储，主要由一个设备编辑

mihomo 不会因为远端 Git 仓库有新提交就自动拉取，也不会自动监控 WebDAV。客户端是否支持这些入口，需要逐项确认。即使客户端提供 WebDAV 备份，也可能只备份设置和配置索引，而不是把某个远端 YAML 当作实时订阅。

三、订阅托管：统一来源，保留本地覆写

先确认订阅返回的是哪一种内容

完整 Clash 配置可以包含 proxies、proxy-groups 和 rules；节点集合则可能只适合由 proxy-providers 引用。还有一些订阅返回编码后的节点链接，并不是可直接由 mihomo 加载的 YAML。两台设备应选择相同的配置格式，不能只凭链接后缀判断。

  1. 在电脑客户端的配置管理中新增远程配置，填写服务提供的真实订阅 URL，先手动更新一次。
  2. 在手机上导入同一链接，检查代理组名称和规则数量。若结果不同，核对订阅格式选项，以及服务端是否按客户端标识返回不同内容。
  3. 把设备差异放在该配置关联的本地覆写中，不直接编辑下一次更新会被替换的远程文件。
  4. 两端分别设置更新间隔。例如客户端支持时可设为 24 小时；手机后台受系统限制，不能把定时更新等同于准点执行。

顶层远程配置的拉取周期通常由客户端管理。proxy-providers 内的 interval: 3600 表示该提供者的更新间隔为 3600 秒，不会替代客户端的整份订阅更新设置。规则提供者也有自己的更新周期，需要分别检查。

托管与转换服务的隐私边界

将订阅 URL 交给远端转换服务，意味着该服务有机会读取订阅中的节点资料。自托管转换服务也需要保护访问入口、请求日志和缓存。只有两端确实需要格式转换时才增加这一层；如果原始订阅已经输出兼容的 mihomo 配置，直接导入通常更容易排查。

若要托管自己的完整配置，应使用 HTTPS 与访问控制，并限制日志中的敏感 URL。支持请求头鉴权的客户端可以使用独立凭据；仅支持 URL 的客户端则需要妥善保管链接。链接泄露后要撤销或轮换令牌，单纯更改本地配置名称不能撤回访问权。

四、私有 Git 仓库：规则版本与回退记录

Git 适合维护自定义域名规则、代理组结构和分端覆写。建议仓库只保存可审阅的配置源文件；订阅令牌、节点密码和控制接口密钥在设备端单独维护。私有仓库限制了访问范围，但提交历史、协作者权限和 CI 日志仍然需要管理。

可以约定以下目录。base.yaml 保存公共逻辑，两个覆写文件保存设备差异。目录组织不会自动产生合并行为，最终仍须由客户端的覆写功能或自行编写的构建流程生成有效配置。

clash-config/
├── base.yaml
├── overrides/
│   ├── desktop.yaml
│   └── android.yaml
└── README.md

电脑端的最小更新流程

在已克隆的仓库目录执行以下命令。先看工作区是否有未提交改动，再使用仅快进拉取，避免更新时意外生成合并提交。拉取完成后，按项目约定生成运行配置，并在实际加载前测试。

git status --short
git pull --ff-only
git log -3 --oneline

mihomo -t -f ./runtime.yaml

runtime.yaml 是本流程生成的完整配置，不是 Git 自带文件。测试命令要求本机已安装 mihomo；引用本地提供者文件时，还应使用与实际运行一致的工作目录，必要时用 -d 指定。测试通过只说明配置可被检查，不代表每个节点都能连通。

手机端可以先由可信 Git 工具拉取，再通过客户端的本地文件导入入口更新。不要把普通仓库网页 URL 当成订阅地址。私有仓库的原始文件下载通常还需要鉴权，客户端未必支持对应认证方式。

配置损坏时如何回退

先保留当前运行配置，再比较最近一次规则变更。对于已共享的提交，可以用 git revert 创建撤销提交，而不是强制改写所有设备依赖的历史。如果敏感订阅已经进入历史，删除最新版本中的那一行仍不足以消除泄露，应先轮换凭据，再处理仓库历史和副本。

五、WebDAV：把文件传输与配置加载分开

WebDAV 适合已有 NAS 或私有存储的场景。推荐采用“电脑写入、手机读取”的单写入端流程。两台设备同时编辑 config.yaml，容易出现后上传覆盖先上传，或者同步工具生成冲突副本；Clash 客户端不负责合并这些文件。

  1. 在存储服务中创建独立配置目录，为手机分配只读凭据；具体权限能力取决于服务端。
  2. 电脑将准备发布的配置上传为独立版本文件，例如 config-2026-09-08.yaml，完成后再更新约定的分发文件。
  3. 手机先下载到本地，再从客户端文件导入入口加载。若客户端提供原生 WebDAV 配置入口，先验证它是否确实会更新配置正文。
  4. 保留上一份可用文件。导入失败时恢复旧文件，不反复覆盖当前唯一副本。

WebDAV 账号密码不应直接拼进 URL。普通“远程订阅”输入框不一定支持 WebDAV 所需的认证；遇到 HTTP 401，应检查凭据和客户端能力，不能通过关闭 TLS 验证绕过。证书错误则应修复证书链、域名匹配或设备时间。

六、分端覆写：端口、TUN 与规则列表

桌面端覆写片段

下面是给支持合并覆写的客户端使用的设备片段，不是可独立导入的完整订阅。桌面端先保留系统代理接入，关闭 TUN，避免首次同步时同时改变两种接管路径。客户端若有“允许局域网”或端口界面，应确认保存后没有再次覆盖这些值。

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

系统代理对应的 HTTP 代理地址应为 127.0.0.1、端口 7890。若本机已有程序占用该端口，可改为 7891，同时更新系统代理和应用内的手动代理设置。不要只改 YAML 而保留旧的系统代理端口。

Android 端覆写片段

手机端可只覆写共同支持的基础项，把 VPN 接管交给客户端。不同 Android 客户端建立和传递 TUN 文件描述符的方式不同，不宜把桌面端的 tun.auto-route、接口名称或路由排除项直接搬过去。

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

启动时应完成 Android 的 VPN 连接授权，并检查客户端的分应用代理列表。即使远程规则相同，被排除在 VPN 外的应用也不会进入 mihomo 的规则匹配流程。本机端口同为 7890 不会与电脑冲突，因为它们属于不同设备。

规则覆写不能假定自动追加

YAML 映射项和列表项的合并行为由客户端实现决定。下面是一个完整替换 rules 的最小示例，前提是最终配置已经存在名为“节点选择”的代理组。若只想前插一条规则，应使用客户端明确提供的规则前置功能，而不是默认认为列表会拼接。

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,节点选择

规则按顺序匹配，MATCH 应放在末尾。上述片段只演示局域网直连与兜底，不包含原订阅的其他分流规则；直接替换会失去那些规则。域名匹配也不负责解析 home.arpa，内网域名仍须由可达的本地 DNS 解析。两端所在网络不同，DNS 上游和内网解析地址应留在设备层。

七、同步后的验收与常见故障

先在一台设备验证，再更新另一台。不要同时更新订阅、替换 DNS、启用 TUN 和更改规则顺序，否则连接失败时难以判断来源。以下检查不依赖虚构的测速结果，可以直接在客户端界面和日志中完成。

  • 来源一致：检查两端使用的是同一订阅或同一 Git 提交；WebDAV 流程检查下载文件名和修改时间。
  • 合并正确：查看最终运行配置，而不只是订阅原文，确认端口为 7890、模式为 rule，覆写没有意外删除代理组。
  • 规则命中：访问一个已明确配置规则的域名，在连接记录中核对命中规则与最终策略，不能仅比较出口地址。
  • 本地网络：访问实际存在的路由器管理地址或内网服务，确认局域网规则和 DNS 都可用。
  • 更新可重复：再手动更新一次订阅，确认设备覆写仍然保留，规则顺序没有变化。

电脑可用、手机不可用时先查什么

先看 Android VPN 是否运行、目标应用是否被排除，再看配置加载错误。出现“策略不存在”通常应核对规则引用的代理组名称；出现本地文件读取失败，要检查共享配置是否写入了电脑专用路径。若两端内核支持范围不同，应记录各自客户端版本和内核版本，围绕报错字段排查，而不是仅凭客户端名称判断兼容性。

如何选择最终方案

只需要节点随服务更新，优先使用同一订阅加本地覆写。需要频繁修改规则并审阅差异，使用私有 Git 管理公共配置源文件。已有私有存储、且主要由电脑编辑时，WebDAV 可以承担文件分发。三种方式也能组合：Git 管理规则、订阅提供节点、设备端保存权限与端口设置，但每一层都应只有明确的更新责任，避免多个入口互相覆盖。