Clash Verge Revの再起動後にProfilesが消えた場合の復元とバックアップ

本記事で扱うのは、次の明確な症状だけです。Clash Verge Rev v2.5.2 に既存のサブスクリプション、ローカル Profile、またはグローバル Merge/Script があり、通常終了、シャットダウン、または再起動後に再び開くと、設定一覧に少数の項目しか残らず、既存のオーバーライドも空のテンプレートに戻っていることがあります。

公式 issue #7577 では、macOS の起動時に 32 個の Profile ファイルのうち 30 個が削除されたと報告されています。issue #7804 では、Fedora を通常どおりシャットダウンした後の次回起動時に 20 個中 18 個のファイルが削除され、その後のコメントには Windows と macOS での報告もあります。いずれも、サブスクリプションサービスがすべてのノードを同時に消したのではなく、起動時の孤立ファイルのクリーンアップを示しています。

まずアプリのログを開き、Removed file、Profile 文件清理完成、および一度の起動で異常に多い削除ファイル数が記録されていないか確認します。ディスク上に Profile が残っていてプロキシ画面だけが空なら、先にコアとの通信を確認します。ファイルは存在するものの Invalid YAML が出る場合は、形式またはフィールドを修正します。一つのサブスクリプションだけ更新に失敗し、他の Profile が残っている場合も、アプリ全体のバックアップをそのまま復元しないでください。

バックアップを復元すると、アーカイブ内の config.yaml、verge.yaml、profiles.yaml と profiles ディレクトリがアプリのデータディレクトリへ書き戻されます。まず、現在のディレクトリ全体と clash-verge-rev-backup サブディレクトリを別の場所へコピーしてください。

現在のディレクトリがすでに不完全に見えても、先にコピーを残してください。誤ったバックアップを選んだり、古い設定で新しい変更を上書きしたりした場合に、元の状態へ戻せます。

通常インストールでは、データは一般にシステムのデータディレクトリ内にある io.github.clash-verge-rev.clash-verge-rev フォルダーへ保存されます。ポータブル版では、プログラムの隣にある .config ディレクトリへ保存されます。不明な場合は、クライアント設定のアプリディレクトリを開く項目を基準にし、似た名前のフォルダーを推測で削除しないでください。

Clash Verge Rev v2.5.2 のローカルバックアップは、アプリのデータディレクトリ内にある clash-verge-rev-backup に保存されます。自動バックアップのファイル名には -auto-scheduled、-auto-merge、-auto-script が付くことがあります。

issue #7804 の報告者は、三日前の auto-script ZIP からグローバルスクリプトを復元できました。

公式の v2.5.2 バックアップ実装では、profiles ディレクトリ、config.yaml、verge.yaml、任意の DNS 設定、profiles.yaml が同じ ZIP に格納されます。

ZIP を開けるというだけで復元しないでください。先にコピーを作り、アーカイブ内に profiles.yaml と profiles/ の両方があることを確認してから、障害発生前のうち最も新しい時点を選びます。

システムプロキシと TUN をオフにしたまま、設定の「バックアップ設定」を開き、「ローカルバックアップ」で「履歴を表示」を選びます。障害発生前のバックアップを見つけ、まずエクスポートボタンで別名保存してから、復元をクリックして確認します。公式画面では、復元完了後にアプリが再起動します。

ZIP を別の場所へ移している場合は、先に「バックアップをインポート」でコピーをローカルバックアップ一覧へ追加し、履歴から復元します。ZIP を実行中のアプリディレクトリへ直接展開しないでください。内蔵の復元機能は書き込み後に config、profiles、画面設定を再読み込みしますが、手動で上書きするとディスク上のファイルとメモリ上の状態が一致しなくなりやすいためです。

利用できる ZIP がない場合、profiles.yaml の参照を推測で作ったり、ランダムなファイル名を勝手に変更したりしないでください。保存してあるサブスクリプション URL からリモート Profile を再インポートします。ローカルで作成した設定は、障害発生前にコピーした profiles ファイルを一つずつ確認し、新しいローカル Profile を作成して内容を貼り付け、クライアントにインデックス関係を再生成させます。

グローバル Merge.yaml と Script.js の古いコピーが残っている場合は、まずオフラインのコピー同士を比較してから、クライアントのグローバル拡張編集画面から復元します。バックアップに古い内容がない場合に限り書き直してください。公開スクリーンショットから、鍵や内部ドメインが含まれる可能性のある完全なルールを推測して復元しないでください。

サブスクリプション URL も失われた場合は、ブラウザー履歴、公開ログ、他人の設定から token をつなぎ合わせるのではなく、元のサービス提供元から再取得またはリセットしてください。一つの情報源を復元するたびに状態を保存し、すべてを一度にインポートしてどの手順で問題が起きたか分からなくなるのを防ぎます。

アプリの再起動後も、すぐには TUN を有効にしないでください。Profile の数、名前、種類、現在選択中の項目を確認し、Merge と Script をそれぞれ開いて、重要なルールが空のテンプレートになっていないことを確認します。リモートサブスクリプションは手動更新でき、ローカル Profile は設定チェックを通る必要があります。

次に、動作確認済みのノードを一つに固定し、システムプロキシだけを有効にして実際の HTTPS リクエストを一度行い、接続履歴でドメイン、ルール、アウトバウンドを確認します。最後にアプリを完全終了してもう一度開き、Profile 数とログを再確認します。二回目の起動でも異常な削除がなければ、復元は安定したと判断できます。

復元後にアプリが起動しない、Profile 数がさらに減った、または新しい設定の検証に失敗する場合は、まずアプリを終了し、複数の ZIP を続けて試さないでください。今回の復元後のアプリデータディレクトリを別名保存してから、最初に保存した元の状態のコピーを使って変更前に戻します。

端末ではまず TUN とシステムプロキシをオフのままにします。ロールバック後もクライアントを使えない場合は、いったん起動せず、ログ、バックアップ ZIP、ディレクトリのコピーを保存し、公式 issue に、機密情報を除いたバージョン、システム、削除件数、最初のエラーを報告します。設定を直すために仮想ネットワークアダプターをアンインストールしたり、システムネットワーク全体をリセットしたり、アプリデータをすべて削除したりしないでください。

2026年9月2日、メンテナーは issue #7804 で、コミット 44f6f6e によって信頼できないクリーンアップ処理を削除したことを確認し、問題をクローズしました。このコミットのタイトルは「preserve files until explicit deletion」で、起動時の cleanup_orphaned_files 呼び出しと自動削除の実装一式をコードから直接削除しています。

2026年9月3日時点で、公式 Releases の最新安定版は引き続き 2026年7月19日公開の v2.5.2 であり、リリースノートにはこの後の修正が含まれていません。そのため、「issue がクローズされた」を「v2.5.2 で修正済み」と書き換えることはできず、回避だけを目的に日常使用の端末を開発ビルドへ切り替えるべきでもありません。

安全な進め方は、まずバックアップと復元を済ませ、不必要な再起動を減らし、44f6f6e を明記した安定版が公式に公開されるまで待つことです。新しい安定版の公開後も現在のバックアップを残し、Release を確認してから、完全終了、再起動、実際の接続による回帰確認を一度行います。

復元後は、バックアップ設定で定期ローカルバックアップを有効にし、「重要な変更時に自動バックアップ」も有効のままにします。v2.5.2 の実装では、予定時刻とグローバル Merge/Script の変更後にアーカイブが作成され、自動アーカイブは最大 20 個保持されます。この上限があるため、ローカルディレクトリは永続的な履歴保管庫ではありません。

さらに、検証済みの ZIP を少なくとも一つアプリデータディレクトリ外へエクスポートするか、自分で管理する WebDAV を設定します。サブスクリプションのオーバーライドを大きく変更するとき、クライアントを移行するとき、アップグレード前には、手動でバックアップを一つ作成してエクスポートします。復元テストは、ロールバック用コピーがある場合に限って実施してください。