平台指南 预计阅读 12 分钟

电脑与手机共用一份配置:订阅链接、WebDAV 与私有 Git 同步方案对比

对比订阅链接托管、WebDAV 备份和私有 Git 仓库三种多设备同步方式,讲清各自的更新时机、冲突处理方法与适用场景。

1. 先区分共享配置、节点订阅与客户端设置

电脑与手机使用同一个订阅地址，不等于两台设备的所有设置都已同步。Mihomo 是处理代理连接、规则和 DNS 的内核；客户端负责导入配置、定时更新、保存界面选项以及申请系统权限。WebDAV 备份和 Git 拉取通常属于客户端或外部工具的能力，不是 Mihomo 内核自动完成的同步流程。

开始操作前，先确认订阅返回的内容。完整配置一般包含 proxies 或 proxy-providers、proxy-groups、rules 等字段；只包含节点信息的订阅，需要客户端转换或由另一份主配置引用。把节点列表当作完整配置导入，可能出现有节点、却缺少预期策略组和规则的情况。

  • 适合共享：代理组名称、分流规则、规则集引用，以及经过兼容性确认的节点来源。
  • 适合设备本地保存：系统代理开关、TUN 授权、Android 分应用名单、客户端窗口和启动设置。
  • 需要单独评估：DNS 监听地址、入站端口、网卡名称、外部控制接口和本地文件路径。

2. 三种方案的更新方式与适用场景

方案 同步对象 更新触发 冲突处理 适用场景
订阅链接 服务端发布的节点或配置 客户端手动或定时拉取 远端内容重新导入，本地修改可能被覆盖 个人多设备获取同一份发布内容
WebDAV 客户端支持的备份包或文件 备份、恢复；自动化能力取决于客户端 保留副本后选择恢复来源 换机、重装、同系列客户端迁移
私有 Git 文本配置、规则与修改历史 提交、推送、拉取后部署 按行比较并手动合并 自维护规则、多设备协作、需要回滚

三者可以组合，但不要让三个工具同时写入同一个生效文件。例如，用 Git 保存规则源文件，用订阅地址发布生成结果，再用 WebDAV 备份客户端本地偏好。这时每类数据只有一个写入来源，排查覆盖问题也更直接。

3. 订阅链接：同一来源，分别更新

导入后先核对内容，而不是只看更新时间

  1. 在提供方后台取得适用于 Clash 或 Mihomo 的订阅地址，确认套餐是否允许多设备使用及同时在线。
  2. 分别在电脑和手机的配置管理界面导入远程地址。不同客户端的菜单名称不同，应选择“从 URL 导入”或对应的远程配置入口。
  3. 手动更新一次，核对策略组名称、规则数量和当前启用的配置。更新下载成功，不代表已经切换到这份配置。
  4. 在两端分别完成系统代理或 VPN 授权，发起一次网页请求，再查看连接记录中的规则命中与出口。

可以先把客户端的完整配置更新间隔设为 24 小时，这是起始建议，不是内核固定默认值。若提供方另有频率限制，应按其要求设置。Android 后台调度、省电策略与电脑休眠都可能推迟更新，遇到节点变更时仍应手动刷新并检查结果。

完整配置更新与 provider 更新不是同一个计时器

客户端定时下载订阅，通常是在替换或重新导入完整配置；Mihomo 中 HTTP 类型 proxy-providers 的 interval 则控制该节点来源的更新周期，单位为秒，例如 interval: 3600 表示一小时。HTTP 类型规则集的更新周期也需在对应的 rule-providers 下配置。修改这些字段，不会自动改变客户端的完整配置更新计划。

如果需要保留自定义规则，优先使用客户端明确支持的覆写或合并功能。不要只在下载后的 YAML 中插入一行规则，就认为它会长期保存；下次订阅更新可能覆盖文件。合并后的规则顺序也要检查，尤其是 MATCH 兜底规则不能提前截走后续请求。

4. WebDAV：更适合备份与恢复，不默认等于双向同步

WebDAV 提供远程文件访问能力，但“上传备份”“下载恢复”和“持续双向同步”是三种不同操作。客户端即使支持 WebDAV，也可能只备份自己的数据库，无法把备份直接导入另一款客户端。开始迁移前，应确认两端是否支持相同的备份格式，以及备份是否包含订阅地址和敏感凭据。

建立可恢复的备份流程

  1. 在存储服务中创建专用目录，为同步工具分配仅能访问该目录的账号或应用密码。
  2. 使用 HTTPS 地址连接。HTTPS 通常使用 TCP 443；若服务指定了其他端口，应使用服务端实际地址。
  3. 先从电脑上传备份，再在手机上手动下载或恢复。恢复前保存手机当前配置，不直接覆盖唯一可用副本。
  4. 检查恢复后的订阅、策略组和本地权限。VPN 授权与系统代理状态仍需在目标设备上确认。

如果使用外部文件工具同步 YAML，建议把远程文件下载到暂存目录，验证后再导入客户端，而不是让同步工具持续写入客户端正在读取的文件。这样即使发生半途断网或文件冲突，也不会立刻替换正在工作的配置。

两台设备都修改时如何选择

假设电脑在 09:00 修改规则，手机离线后在 09:10 修改订阅，两端随后上传同名备份。仅凭“最后修改时间较新”不能证明较新的备份包含另一端的改动；设备时间也可能不一致。应先分别保存两个副本，再对照订阅和规则，选定一份作为主版本。

对于二进制或加密备份包，不能像文本一样逐行合并。更稳妥的做法是指定一台设备负责发布备份，其他设备主要执行恢复。若备份含有凭据，应使用客户端提供的加密能力；仅通过 HTTPS 传输，不代表服务器保存的文件已加密。

5. 私有 Git：追踪规则变更，凭据独立管理

需要经常调整域名规则、审查改动或回退历史时，Git 更合适。它记录每次文本变更，可以看清某条规则由谁、何时、为何修改。但私有仓库仍有账号、协作者和自动化访问边界，不应把节点密码、订阅令牌或控制接口密钥直接提交进去。

先划分文件，再接入同步

下面是一种源文件组织方式，不是 Mihomo 自动识别的目录约定。Mihomo 最终仍需加载一份完整、有效的配置；分文件内容必须经过明确的组装流程，不能假定内核会自动合并。

proxy-config/
├── base.yaml
├── rules/
│   └── local.yaml
├── devices/
│   ├── desktop.yaml
│   └── android.yaml
├── .gitignore
└── README.md

base.yaml 保存共享结构，rules/ 保存规则源文件，devices/ 保存不含秘密的平台差异。实际订阅地址和生成后的配置留在仓库之外。下面的忽略规则只针对本方案约定的文件名，不能替代提交前检查。

# .gitignore
secrets/
private-provider.yaml
runtime.yaml
*.log

每次修改采用同一组步骤

  1. 先运行 git pull --ff-only 获取远端更新。若提示分支分叉，先处理差异，不直接强制覆盖。
  2. 编辑规则，运行 git diff 查看改动，确认没有混入真实订阅地址或节点密码。
  3. 按项目流程生成 runtime.yaml，使用目标设备对应的 Mihomo 版本检查配置。
  4. 验证通过后提交源文件，再推送到私有仓库；其他设备拉取后，重新生成并导入配置。
mihomo -v
mihomo -t -f runtime.yaml
git diff --check
git add base.yaml rules/local.yaml
git commit -m "调整本地域名分流规则"
git push

mihomo -t -f runtime.yaml 用于配置测试，不代表远端节点一定可连接，也不代表 TUN 权限已就绪。若配置引用相对路径或外部规则文件，还要准备相同的工作目录与依赖文件。Windows 上可使用实际内核可执行文件名，客户端内置内核的路径则取决于安装方式。

手机端未必提供 Git 工具或任意目录访问能力。如果没有可靠的拉取和部署流程，建议让电脑维护仓库，再通过受控的 HTTPS 地址发布结果供手机订阅。不要为同步配置而把仓库访问令牌直接写入订阅 URL。

6. 跨平台时保留端口、TUN 与 DNS 的本地差异

“共用一份配置”更适合理解为共用规则逻辑，而不是所有字段逐字一致。桌面系统可以设置系统代理；Android 客户端通常通过 VpnService 接管流量。两者的权限、路由和分应用控制入口并不相同。

字段或功能 处理建议 检查点
mixed-port 按设备端口占用情况设置 7890 是常见示例值，不是所有客户端的固定端口
allow-lan 不需要局域网接入时保持关闭 开启后还需核对监听地址、防火墙与认证
TUN 与 VPN 按平台完成权限和路由设置 桌面 TUN 开关不能代替 Android VPN 授权
DNS 与 dns-hijack 结合设备网络环境测试 确认 DNS 请求是否实际进入内核
external-controller 无远程管理需求时不要对外开放 本机管理优先绑定回环地址，并设置访问密钥

设备覆写也需要检查合并语义。有的客户端替换整个 dns 段，有的会合并映射，但对 rules 数组采用追加或替换。不能只看覆写编辑器中的几行内容，应查看最终生效配置。Android 分应用代理还依赖实际安装的应用包名，不宜直接复用桌面进程规则。

7. 更新冲突、回滚与生效验证

规则更新后消失

先确认规则写在远程订阅、客户端覆写还是临时生成文件中，再查看本次更新覆盖了哪一层。建议在自己的源文件中加入注释，例如 # profile-revision: 2026-08-23-01。它只是便于识别的发布标记，不会参与分流；需要结合最终配置和日志确认是否已经加载。

电脑正常，手机无法联网

依次比较当前配置名称、更新时间、内核版本、节点来源和策略组选择，再检查手机的 VPN 授权与后台限制。同一订阅不保证同一时刻使用同一个节点；手动选择结果和健康检查状态可能保存在各端本地。先统一出口再测试，才能减少干扰因素。

新配置加载失败

  1. 保留失败文件与错误日志，记录出错字段或行号。
  2. 切回上一份已验证配置，先恢复连接，不连续修改多个设置。
  3. Git 方案比较最近提交；WebDAV 方案恢复独立历史副本；订阅方案检查提供方是否支持历史版本。
  4. 修正后先在一台设备测试，再向其余设备发布。

最终验证至少包含三项：内核能加载配置、需要代理的请求命中预期策略、需要直连的请求没有被错误转发。若共享内容包含 DNS 或 TUN 调整，还应分别在 Wi-Fi 与移动网络下检查解析和连接。不要仅凭“订阅更新成功”判断整套配置已正常工作。

8. 按维护方式选择同步方案

  • 主要使用服务商订阅：两端导入同一地址，分别设置更新周期；自定义规则使用本地覆写，并保留导出副本。
  • 主要解决重装和换机：选客户端支持的 WebDAV 备份，先验证恢复格式，再决定是否开启自动备份。
  • 主要维护自定义分流：用私有 Git 保存文本源文件，通过验证后发布，手机只获取可用结果。

长期维护时，固定“源文件在哪里、由谁修改、怎样验证、如何回退”这四件事，比追求所有设备实时互相覆盖更重要。共享规则集中维护，平台权限在本地处理，更新前保留可用副本，才能在配置变化时定位到具体环节。需要进一步核对字段，可查阅规则与配置说明；客户端安装与权限步骤见使用教程。

下载Clash