外观
换电脑、重装系统前必看：Clash 配置备份与迁移完整指南
很多人第一次重装系统、换新电脑，或把常用配置迁移到另一台设备时，才发现 Clash 里的设置并不只是“导入一次订阅”这么简单。
节点订阅通常可以重新添加，但手动写过的覆写规则、代理组选择、TUN 设置、系统代理习惯、脚本与本地规则文件，未必会跟着订阅一起回来。更常见的情况是：新设备上明明已经导入订阅，却发现访问行为和旧电脑完全不同；要么部分网站走错策略，要么更新订阅后自定义内容又消失了。
这篇文章不绑定某一个 Clash 客户端界面，而是从配置结构出发，讲清楚迁移前该备份什么、怎样避免泄露订阅地址，以及迁移后如何有条理地验证。无论使用的是 Clash Verge、Clash Party，还是其他兼容 Clash Meta 配置格式的客户端，思路都大体相通。
先分清：订阅、配置文件和客户端设置不是一回事
迁移失败，往往不是操作问题，而是把不同类型的数据当成了一份东西。
订阅链接：用于重新获取节点和基础规则
订阅链接通常是一段以 https:// 开头的地址。客户端通过它下载远程配置，其中可能包含代理节点、代理组、规则、DNS 设置等内容。
它的优点是更新方便：换设备后重新添加链接，再执行更新，就能恢复服务端下发的主体内容。
但也要注意，订阅链接本身接近于一把“配置钥匙”。拿到它的人通常可以获取你的订阅内容，甚至消耗相关流量配额。因此不要把链接发到群聊、截图、工单之外的陌生渠道，也不要把含有完整链接的配置文件上传到公开网盘、Git 仓库或论坛。
本地配置文件：你真正修改过的内容可能在这里
许多客户端允许导入 YAML 配置、创建本地 Profile，或者通过覆写（Override）对订阅进行二次修改。例如：
- 自己添加的规则集与分流规则；
- 修改过的 DNS、nameserver、fallback 等项目；
- 自建代理组、规则提供者；
- 局域网访问控制设置；
- 指定某个域名必须直连或必须经过代理的规则；
- 覆写脚本和外部规则文件。
其中一部分内容可能保存在单独的覆写文件中，而不在远程订阅本体内。只备份订阅链接、不备份这些文件，就会出现“节点回来了，使用习惯却没回来”的情况。
客户端设置：经常被忽略，却直接影响能否联网
还有一类数据属于客户端本身，例如：
- 当前启用的是哪个 Profile；
- 规则模式、全局模式等运行模式；
- 系统代理是否开启；
- TUN 模式是否启用；
- 开机启动、自动连接等偏好；
- 端口监听设置；
- 选中的节点与代理组记忆。
不同客户端保存这些内容的位置不同，版本升级后目录结构也可能变化。所以迁移时不要盲目复制整个安装目录，更不要直接把旧版本的所有数据库文件覆盖到新版客户端中。正确做法是优先导出可读的配置与覆写，再按需手动恢复少量客户端偏好。
迁移前的准备：用一份清单避免遗漏
在旧设备仍然可以正常使用时，先做一次整理。建议创建一个本地加密文件夹或离线存储目录，命名为“Clash 迁移备份”，并按以下顺序处理。
1. 记录正在使用的配置名称与来源
打开客户端的 Profiles、配置文件或订阅管理页面，记下：
- 当前正在启用的配置名称；
- 它是订阅导入、本地 YAML 导入，还是客户端内新建的；
- 最后一次更新时间；
- 是否绑定了覆写配置；
- 是否依赖本地规则文件或脚本。
这一步看似简单，但非常重要。很多人有多个旧订阅，迁移后只记得“以前能用”，却不知道究竟启用的是哪一个。
2. 导出或保存订阅信息，但不要裸露传播
如果客户端支持复制订阅地址，建议将地址保存到可信的密码管理器、安全笔记或加密文档中。不要仅放在普通截图里：截图容易同步到相册云端，也不便于搜索、更新和撤销。
如果服务提供方支持在用户后台重新生成订阅链接，迁移完成后也可以考虑更换旧链接。这样即使旧电脑遗留过文件、截图或缓存，旧链接失效后带来的暴露风险会更低。
3. 导出本地 Profile、覆写与规则文件
重点检查以下项目：
- 手动导入的 YAML 文件；
- 客户端中创建的本地配置；
- Override、Merge、Patch、覆写配置；
ruleset、rule-providers引用的本地文件；- JavaScript 脚本、GeoIP/GeoSite 自定义数据库；
- 仅在本地生效的 hosts 或 DNS 映射。
如果你的规则依赖相对路径，例如 ./rules/custom.yaml，迁移后一定要保持文件层级不变，或者在新设备中改成正确的新路径。否则客户端可能能够加载主配置，却在规则下载或解析阶段报错。
4. 截图保存关键运行设置
对于不方便导出的客户端设置，截图比靠记忆可靠。建议保留这些页面：
- General 或通用设置；
- System Proxy 或系统代理；
- TUN 设置；
- DNS 设置；
- 当前模式与当前代理组选择；
- 覆写配置的关联状态。
截图中如果显示了订阅完整地址、账号信息、设备名称或局域网 IP，建议在备份前打码，或将图片仅存放在本地加密空间。
最稳妥的迁移方法：先装客户端，再恢复配置
不建议一开始就复制旧电脑上整个 Clash 的数据目录。不同系统、不同客户端版本的内部数据库格式可能不兼容，直接覆盖可能造成配置列表空白、无法启动，甚至持续崩溃。
更稳妥的顺序如下。
第一步：从可信来源安装对应客户端
在新设备上安装你准备继续使用的客户端。安装完成后先运行一次，让程序自行创建必要目录。
此时不要急着打开 TUN，也不要马上导入多个订阅。先从一个最常用的配置开始，便于定位问题。
第二步：优先恢复订阅或导入主配置
如果旧设备使用的是远程订阅，在新客户端添加订阅链接并更新；如果使用的是本地 YAML，则先导入主 YAML 文件。
导入后先确认配置确实出现在列表中，并检查更新时间是否正常。如果更新失败，优先排查新设备的基础网络、系统时间和安全软件拦截，而不是立刻怀疑节点全部失效。
第三步：恢复覆写与附属文件
主配置能够成功加载后，再逐项恢复覆写、规则集、脚本和本地文件。一次只恢复一类内容，然后重新加载配置。
这种“逐项恢复”的方式虽然比一次性复制麻烦，但出现故障时可以快速知道是哪份文件造成的。例如导入主订阅正常，加入某个覆写后无法联网，那么排查范围就已经缩小到覆写内容、文件路径或 YAML 缩进，而不必重装所有软件。
第四步：恢复代理组偏好，而不是盲目照搬节点名
代理组通常比单个节点更适合长期使用。因为订阅更新时节点名称、地区标签和排序可能改变，而策略组名称往往相对稳定。
迁移后，建议检查各类常用策略组的选择，例如“自动选择”“手动选择”“国外服务”“流媒体”“AI 服务”等。若旧配置中的节点已被订阅更新替换，直接寻找完全相同的节点名没有意义；选择合适的地区或自动测速组即可。
迁移完成后，按这四层验证网络
不少人一看到网页打不开，就反复切换节点。其实迁移后的问题可能发生在任意一层，按层检查效率更高。
第一层：客户端内核是否正常运行
查看客户端日志或状态页，确认配置没有 YAML 解析错误、端口占用错误、权限错误等提示。
典型现象包括：启动后立即停止、配置显示加载失败、TUN 启动失败、规则提供者下载失败。此时先处理报错文本中最靠前的错误，因为后续错误往往只是连锁反应。
第二层：系统代理或 TUN 是否真正接管流量
如果只开启了客户端，却没有打开系统代理，浏览器和多数软件可能仍然直连网络。反过来，如果旧客户端残留了系统代理地址，而新客户端尚未启动，也会造成“所有网页都打不开”。
迁移时最好确保旧客户端完全退出，并在新设备的系统网络设置中确认代理状态。使用 TUN 时还要留意系统是否弹出网络扩展、管理员权限或防火墙授权提示；拒绝这些权限可能导致 TUN 看似打开，实际无法转发流量。
第三层：DNS 是否按预期工作
如果 IP 地址连接正常，但特定域名打不开、网页提示找不到服务器，问题可能在 DNS。新设备可能继承了不同的网络 DNS、IPv6 设置，或者客户端没有加载原来的 DNS 覆写。
不要在问题未定位前同时改系统 DNS、客户端 DNS、浏览器安全 DNS 和路由器 DNS。一次改动太多，反而无法判断到底是哪项生效。推荐先让 Clash 的 DNS 配置保持明确、单一，再检查浏览器是否另行启用了加密 DNS。
第四层：规则命中是否符合预期
客户端的 Connections、连接详情或日志页面通常会显示某个域名匹配了哪条规则、走了哪个代理组。遇到“只有某个应用无法使用”时，这正是最有价值的信息。
如果连接走到了 DIRECT，说明它被规则判定为直连；如果走到了错误的策略组，就检查规则顺序与覆写是否正确。规则通常从上到下匹配，越具体、优先级越高的规则应放在更前面，最后再保留兜底规则。
三个常见误区：看似省事，实际容易出问题
误区一：把完整客户端数据目录直接覆盖过去
这可能连带复制旧路径、缓存、数据库锁文件和版本不兼容的数据。对于跨系统迁移，例如从 Windows 换到 macOS，更没有直接覆盖的意义。
建议只迁移可读、可审查的配置文件；客户端运行数据让新设备自行生成。
误区二：只备份订阅，不备份覆写
订阅负责“基础配置”，覆写负责“你的个性化修改”。如果你曾经添加过特殊分流、DNS 调整或规则集，覆写往往才是最难重新写出来的部分。
建议给覆写文件加上清晰的注释，例如写明用途、创建日期、依赖文件和需要修改的路径。半年后再次迁移时，这些注释会节省大量时间。
误区三：迁移后立即开启所有高级功能
系统代理、TUN、增强 DNS、IPv6、局域网共享等功能最好分阶段恢复。先验证基础订阅与规则模式正常，再开启 TUN；确认 TUN 正常后，再处理 IPv6 或局域网功能。
每次只变更一个变量，才有可能准确找到问题来源。这是网络排障中最朴素也最有效的原则。
建议建立一套长期可用的备份习惯
Clash 配置并不需要每天备份，但在以下时机做一次备份很有价值：
- 新增了重要覆写或自定义规则后；
- 准备更新客户端大版本前；
- 重装系统、换电脑前；
- 修改 DNS、TUN、局域网共享等核心设置后；
- 订阅来源更换或重新生成订阅链接后。
可以将备份目录按日期保存，例如 2026-09-clash-backup，目录内放置主配置、覆写文件、规则文件和一份简短说明文档。说明文档不需要复杂，只要写清“主配置从哪里导入”“需要关联哪个覆写”“启用顺序是什么”即可。
对于含订阅链接、令牌或账号信息的文件，建议使用设备加密、加密压缩包或可信密码管理器保存。迁移结束后，记得删除临时复制到下载目录、桌面和聊天软件中的明文文件，并清空回收站。备份的目的不是留下更多敏感副本，而是在需要恢复时拥有一份可控、可验证的资料。
总结
Clash 迁移的核心不是“把节点搬过去”，而是把配置分成订阅、本地文件和客户端设置三部分分别处理。先记录现状，再备份可读配置；新设备先安装并运行客户端，再导入主配置；覆写和高级功能按步骤恢复；最后通过内核、接管方式、DNS、规则命中四层验证网络。
做到这些，即使以后更换设备、重装系统或尝试新的 Clash 客户端，也不必从头摸索。更重要的是，配置文件里可能包含敏感订阅信息，整理与保护备份本身，也是日常网络安全的一部分。