Clash Verge 如何备份配置文件？内置功能与手动方式说明

为什么「备份」在 Clash Verge 里首先是合规与数据留存问题

很多人第一次意识到需要做 Clash Verge 配置文件备份，往往是在一次误删订阅、一次内核升级失败，或者换了电脑之后。但把备份仅仅理解为「防止丢失」，会漏掉另一半价值：它同时也是数据留存与变更审计的一部分。你的代理规则、分流策略与节点列表，实质上描述的是你所在网络环境的访问边界；一旦需要回溯「上周出现异常分流时用的是什么配置」，手里有没有那份副本，结论会完全不同。

因此本文不把备份当作一次性动作，而是当作一条可以被审计的链条：谁在什么时候改了哪个文件、改动前后的差异是什么、能否在隔离环境里复现。整篇文章会沿着问题定义、最短可达路径、例外与副作用、验证与回退这条线索推进。需要说明的是，凡是涉及界面文案与目录位置的部分，都以你当前安装版本的实际情况为准——Clash Verge 及其社区维护分支的界面迭代较快，不同分发渠道的版本可能并不完全一致。

还有一点前提需要先明确：Clash Verge 是一款主要面向桌面系统的图形客户端，通常运行在 Windows、macOS 与 Linux 上。它本身并不提供官方移动端应用，所以在 Android 或 iOS 上，你用的是其他客户端，配置文件的组织形式与存放位置也不相同。后文在涉及移动端时会显式标注，避免把桌面端的操作习惯错误迁移到手机上。

备份对象盘点：到底有哪些数据值得留存

在动手复制文件之前，先把数据的层次弄清楚。Clash Verge 的工作数据大致可以分成三层：订阅级配置、叠加层文件、应用级设置。三层的重要性并不相同，对应的备份策略也应该有所区别——有的必须留，有的留了只是顺手。

订阅级配置：每个订阅对应一份 YAML

你在界面上添加的每一条订阅，最终都会落成一份 YAML 配置文件，保存在应用的数据目录中，其中包含节点信息、代理组结构与基础规则。这一层是最核心的留存对象，因为它承载了你实际使用的节点与策略。经验性观察：如果订阅是通过远端链接自动更新的，那么本地这份 YAML 随时可能被覆盖，此时备份的意义就变成了「保留某个时间点的快照」，而不是「保存唯一的真本」。

叠加层文件：合并配置与脚本

Clash Verge 支持在原始订阅之上叠加一层自定义修改，通常体现为「合并（Merge）」与「脚本（Script）」两类。合并层以 YAML 形式做字段级的覆盖，脚本层则可以用 JavaScript 对配置做更复杂的改写。这两类文件体积很小，但价值密度极高——它们往往包含你手动调优过的分流规则、DNS 设置、端口与嗅探开关。一旦丢失，即使订阅本身还在，你得到的也只是一个「能用但不顺手」的配置。

应用级设置：端口、内核参数与界面偏好

这一类包括混合端口、允许局域网连接、系统代理开关状态、主题与语言等。它们的可重建性最强，重新点几下就能恢复；但如果你在多台设备之间保持一致的端口规划（例如某台机器固定使用某个混合端口），把它一并留存会让迁移过程省事不少。判断标准其实很简单：重建成本高于留存成本的项目，就值得纳入备份范围。

内置功能能做到什么，做不到什么

标题里提到的「内置功能」，需要先厘清边界。Clash Verge 的定位是客户端，而不是备份工具，所以它的内置能力更偏向「让你方便地触达文件」，而不是「替你管理版本」。换句话说，它解决的是入口问题，而不是流程问题。

设置页中的目录入口

在应用的设置页面中，通常可以找到一个用于打开应用数据目录或配置目录的入口，不同版本的中文文案可能是「应用目录」「配置目录」或类似的名称，具体请以你当前界面为准。点击之后，系统文件管理器会直接定位到相应文件夹。这是最短的内置路径：你不需要记住任何路径，也不需要判断不同系统下用户目录的差异。

举例说明它的实际价值：假设你在三台机器上维护同一套策略，其中一台的合并配置出现了意料之外的覆盖。你可以先在出问题的机器上通过设置页打开目录，把当前的合并文件取出来，再与另一台正常机器的同名字段做逐行比对，几分钟内就能定位是哪一行覆盖顺序写错了。这个流程完全依赖内置入口，不需要任何第三方工具。

配置项自带的查看与编辑能力

针对单个订阅，界面一般会提供查看或编辑其配置文件的能力，也支持对合并层、脚本层进行编辑。这意味着你可以在不离开客户端的情况下，把某个订阅的 YAML 内容全选复制出来，粘贴到自己的归档文件中。对于只需要保留一两条关键订阅的用户来说，这已经是成本最低的留存方式。

内置能力的边界在哪里

边界同样清楚：内置入口通常不负责打包、不负责加密、不负责版本对比，更不会自动把配置推送到你的云端。也就是说，内置功能解决的是「找得到、看得见、改得动」，而「留得住、查得到、回得去」这三件事，需要你在目录之外再补一层流程。如果你的版本恰好提供了某种导出或导入的便捷入口，那属于额外便利，不要把它当作唯一的留存手段。

最短可达路径：桌面三平台的操作差异

下面按平台说明最短路径。所有路径都以「通过设置页打开目录」为优先方案，只有在你无法进入图形界面时，才需要退回到手动定位文件夹的方式。这样做的好处是，路径由应用自己给出，你不必在脑内维护一份跨平台对照表。

Windows

优先方案：打开 Clash Verge 的设置页，找到目录入口并点击，文件资源管理器会跳转到数据文件夹。次选方案：手动进入当前用户目录下的漫游应用数据区域，逐层查找以应用标识命名的文件夹。由于不同分发渠道使用的应用标识可能不同，文件夹名称也会随之变化，请以设置页实际显示的路径为准，不要直接套用他人截图中的路径。

macOS

在访达中，用户级应用数据一般位于个人资源库的 Application Support 之下。个人资源库默认在访达中隐藏，可以用「前往文件夹」功能输入路径，或按住 Option 键从「前往」菜单进入。同样建议优先使用设置页的目录入口，避免在多个相似命名的文件夹之间反复试探。

Linux

Linux 下应用数据通常位于用户主目录的 .config 或 .local/share 目录中。多数桌面环境支持在文件管理器里输入路径直达；如果你在无图形界面的环境下使用命令行，可以用 ls 逐层确认目录结构，再决定复制哪一层。这里同样遵循一个原则：先看设置页显示的路径，再动手复制。

Android 与 iOS 的差异说明

移动端不存在 Clash Verge 的官方客户端，因此也没有可对齐的目录结构。在 Android 上，常见的做法是通过其他客户端的配置导入导出功能，把配置以文件或链接的形式转出，再自行归档；在 iOS 上，配置通常以本地文件或二维码链接的形式存在，受系统沙盒限制，导出方式取决于你实际使用的那个应用。跨设备迁移时，更可靠的做法是依赖订阅链接与自建规则文件，而不是试图搬运本地文件。

手动方式一：整目录快照，最稳也最需要脱敏

整目录快照的思路是：在关闭或不使用客户端的时间窗口内，把整个数据目录复制到一个独立位置，并按时间戳命名。它的优点是恢复路径最短——出问题时把目录整体替换回去即可；缺点也很明显，目录里往往包含订阅链接、令牌以及本地证书等敏感内容，复制得越完整，外泄面也就越大。

在 Windows 上可以用资源管理器直接复制，也可以用命令行完成归档。下面是一个通用的归档示例，具体目录请替换为你机器上的真实路径：

# 以类 Unix 系统为例，Windows 请使用等价命令或直接用资源管理器压缩
# 请自行替换 /path/to/app-data 为设置页显示的真实目录
cp -r "/path/to/app-data" "/path/to/backup/clash-verge-$(date +%Y%m%d)"

归档完成之后，立刻做一次内容检查，确认关键子目录都在里面。判断标准可以定为：订阅配置、合并与脚本文件、应用设置文件三类是否齐全。缺少任何一类，这次快照的完整性都应打上问号。

手动方式二：按订阅粒度导出，适合协作与审计

如果你需要把配置交给同事排查，或者需要在工单系统里留档，整目录快照就不合适了——它携带的信息远超排查所需。此时更合适的是按订阅粒度导出：只保留与问题相关的那一份 YAML，并把其中的节点地址、密码、令牌等字段替换为占位符。

具体做法是：在客户端中打开对应订阅的配置内容，复制到你自己的编辑器，先用搜索替换清除敏感字段，再另存为一个语义清晰的文件名，例如「日期-订阅名-用途.yaml」。这样做的额外好处是，当你在审计「哪次改动引入了错误分流规则」时，可以直接用文本差异工具对比两份导出文件，而不必在整目录里翻找。

需要提醒的是，脱敏后的文件如果仍然包含完整的规则集，也可能间接暴露你的策略偏好。是否属于敏感信息，取决于你所在组织的合规口径。稳妥的判断方式是：把这份文件交给一个完全不了解你环境的人看，如果他能据此推断出你的内部网段或常访问的域名范围，那就需要进一步处理。

手动方式三：纳入版本控制，形成可审计的时间线

当配置修改频率较高时，目录快照会产生大量重复副本，既占空间又难以比较。更工程化的做法，是把脱敏后的配置文件放进一个本地版本库，用提交记录形成时间线。这个仓库可以在本地，也可以是团队内部受控的私有仓库，但不应公开。

# 在脱敏后的配置目录中初始化版本库
cd /path/to/sanitized-configs
git init
git add .
git commit -m "init: 基础订阅与合并配置"

# 每次修改后提交，便于日后比对
git add -A
git commit -m "update: 调整 DNS 与分流规则"

这种方式的取舍在于：你需要维护一个额外的脱敏步骤，一旦忘记脱敏，敏感信息就会进入提交历史，清理起来比删除一个文件麻烦得多。折中的经验做法是，在版本库根目录放一份说明文件，明确写出「本目录内的文件均为脱敏副本，原始文件不在此处」，让协作者一打开就知道规则。

恢复与回退：三种回滚层次

备份的价值只有到恢复那一刻才被检验。建议把恢复拆成三个层次，按故障范围从小到大依次尝试，避免一上来就整目录覆盖——覆盖动作本身也可能破坏现场，让后续定位变得更困难。

第一层：单文件回滚

适用于只有某个合并文件或脚本被改坏的情况。把备份中的对应文件复制回原位置，然后在客户端内重新载入该配置。这一层影响面最小，也最容易验证。

第二层：订阅级回滚

适用于某条订阅被误更新或误删除。把备份中的订阅 YAML 放回订阅目录，再在界面中确认该条目是否重新出现、节点数量是否符合预期。如果你使用的是远端订阅，注意本地回滚之后一旦再次触发更新，远端内容会重新覆盖本地，因此这类回滚更适合作为临时处置手段。

第三层：整目录回滚

适用于更换设备、系统重装或配置目录被大面积破坏的场景。做法是先退出客户端，再把备份目录整体复制回原位置，最后启动应用检查。整目录回滚之前，建议把当前目录先改名保留一份，作为「回滚失败时的退路」——这一步常被忽略，但关键时刻能救命。

例外与取舍：哪些内容不建议进备份包

并非目录里的所有内容都值得留存。以下几类建议单独处理，甚至不纳入常规备份。

第一类是运行期日志与缓存。它们的体积会随时间增长，且只对当前故障排查有意义，放进长期备份只会让归档包臃肿。第二类是本机证书与私钥。这类文件一旦随备份扩散，安全影响远超「配置丢失」本身；如果确实需要留存，应放在加密容器中单独管理。第三类是带令牌的订阅链接。如上一节所述，建议在进入任何共享环节之前先做替换。

反过来说，也有容易被忽略但应当纳入的部分：合并层与脚本层文件、你对默认规则做过的本地微调，以及端口与局域网访问相关的设置。这些内容体量小、重建成本高，属于整份清单里「性价比最高」的留存对象。

验证与观测：怎么确认备份真的可用

只备份不验证，等于把风险推迟到最需要它的时候。下面给出一组可复现的验证步骤，建议在每次重要改动之后执行一次。

第一步，完整性核对。打开备份目录，确认订阅配置、合并与脚本文件、设置文件三类均存在。预期可观测指标是：文件数量与你记忆中的订阅数量一致，且没有出现零字节文件。

第二步，文本比对。用任意文本差异工具，把备份中的关键 YAML 与当前使用中的同名文件做对比，确认差异只来自你有意修改的部分。如果出现意料之外的差异，说明在备份之后配置又被更新过，需要重新归档。

第三步，隔离恢复演练。在一台不承载日常工作的设备上，或者在一个临时配置目录中，尝试用备份恢复并启动。预期可观测指标是：应用能够正常启动，订阅条目在界面中可见，规则能够生效。这里的「生效」可以用一个具体的小案例来判断：假设你在规则中为某个特定域名指定了直连，恢复后访问该域名，观察流量走向是否符合预期。

第四步，记录结论。把验证日期、验证人和结论写进一份简短记录。这一步看似繁琐，但当多人协作时，它能回答「上一次确认可用是什么时候」这个问题。

故障排查：按现象逐层定位

下面按「现象—可能原因—验证方式—处置」的结构列出几类常见情况。需要先说明的是，所有可能原因都属于经验性判断，不构成确定性结论，请以你的实际排查结果为准。

现象一：恢复后界面中看不到订阅条目。可能原因是订阅文件放错了层级，或文件名不符合命名约定。验证方式是回到设置页打开目录，逐层确认文件所在的子目录与备份中的结构是否一致。处置方式是按备份结构重新放置，必要时对比正常机器上的目录层级。

现象二：订阅条目可见，但启动后规则不生效。可能原因是合并或脚本层覆盖了原订阅的关键字段。验证方式是暂时移除叠加层文件，观察问题是否消失。处置方式是逐段恢复叠加内容，定位到具体冲突的字段，而不是一次性回退全部改动。

现象三：恢复后端口冲突，浏览器无法上网。可能原因是应用设置中的端口与你机器上其他程序的监听端口重叠。验证方式是查看当前端口占用情况，并与备份中的设置做比对。处置方式是改用一个未占用的端口，并把这个新端口同步写入你的留存记录。

现象四：备份包体积异常大。可能原因是把日志或缓存目录一并纳入了归档。验证方式是查看备份包内各子目录的体积占比。处置方式是建立排除清单，把运行期产物从归档范围中剔除。

适用与不适用场景清单

为了便于快速判断，下面用准入条件的方式给出边界。适用于以下情形：你需要跨设备迁移并保持一致的分流策略；你的配置包含大量手工调优的规则，重建成本高；你所在的组织要求对网络配置变更留有可追溯记录；你经常在多条订阅之间切换，需要随时回到某个已知可用的状态。

相对不适用的情形是：你的配置完全依赖远端订阅自动更新，本地不做任何叠加修改，此时备份的边际收益较低，只需保留订阅链接本身即可；或者你的设备属于临时环境，用完即弃，投入备份流程反而不划算。

还有一类需要谨慎的情形：当配置涉及企业内部网络边界时，把它复制到个人设备或公有云盘可能违反组织规定。这种情况下，备份的位置、加密方式与访问权限都应当先经过合规确认，再谈技术方案。

最佳实践检查表

把前面各节的内容压缩成一份可执行的规则，建议按顺序核对：其一，明确备份范围，把订阅配置、叠加层、关键设置列为必选，把日志缓存列为排除项；其二，确定存放位置，优先选择本机独立分区或受控的私有存储，公共空间一律不考虑；其三，固定脱敏动作，任何要共享的文件先做字段替换；其四，设定触发时机，把备份绑定在「新增或删除订阅」「修改合并与脚本」「升级客户端前后」这三个节点上；其五，定期演练恢复，至少在一次设备变更之前完成一次完整恢复验证；其六，留下记录，用简短的文字说明每次归档的用途与验证结论。

这六条里，最容易被跳过的是第五条和第六条。它们不产生任何可见的即时收益，却决定了你在真正需要备份的那一天，手里拿到的是一份可用配置，还是一份不知道能否还原的压缩包。

常见问题（FAQ）

结语与下一步建议

回到最初的问题：Clash Verge 的配置备份，本质上是在「可恢复」与「可审计」之间搭建一条链路。内置的目录入口解决了触达问题，让你不必猜测文件在哪；真正决定备份质量的，是你如何划定留存范围、如何做脱敏，以及在什么时候停下来验证一次。把这三件事固定成习惯，配置管理就从「出了事再想办法」变成了「随时能回到已知状态」。

如果你今天只打算做一件事，建议是：打开设置页找到数据目录，把当前的订阅配置与叠加层复制到一个独立位置，按照「日期-用途」的规则命名，然后在文本编辑器里检查一遍是否包含不该外流的字段。完成这一步之后，再考虑是否引入版本控制与定期恢复演练。整套流程不需要任何额外工具，随时可以开始。

最后需要说明的是，客户端界面的文案与目录结构会随版本迭代调整，未来某些入口的名称或位置可能出现变化。但本文所描述的那套判断顺序——先界定留存范围，再选择存放位置，最后用一次隔离恢复来验证——并不依赖具体的界面形态。以此为锚点，版本更新带来的影响通常只是操作入口的重新定位，而不会动摇整个流程。