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

まずClash Verge Rev v2.5.2の再起動後に何が消えたか確認します。複数のサブスクリプション、ローカルのProfile、グローバルのMerge/Scriptが同時に消え、上書き設定が空のテンプレートに戻っているでしょうか。Profileはアプリが保存する設定です。この範囲に当てはまる場合は起動ログのファイル削除を確認し、単独の更新失敗や空のノード一覧は別に調べてください。

公式 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 が付くことがあります。

公式の v2.5.2 は profiles ディレクトリ、config.yaml、verge.yaml、任意の DNS 設定、profiles.yaml を同じ ZIP に入れます。issue #7804 の報告者は三日前の auto-script ZIP からグローバルスクリプトを取り戻しました。この種類のバックアップは、スクリプトだけでなく設定全体を含む場合があります。

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

v2.5.8 の固定ソースでは、起動時の Profile 削除処理の呼び出しがなくなり、設定のインデックスを読み込めない場合もファイルを保持します。更新する際は、公式の v2.5.8 Release から使用する環境に合うパッケージを入手してください。完全なバックアップは残しておきます。更新しても、バックアップのない削除済みの内容は取り戻せません。

インストール後は、まずアプリのバージョンを確認します。失われた内容は、後の手順に沿ってバックアップまたは元の入手先から復元してください。復元後に Profile の数と実際の通信を確認し、アプリを完全に終了して再起動後も確かめます。手元のバックアップは残しておいてください。

システムプロキシと TUN をオフにしたまま、「設定 → Verge 詳細設定 → バックアップ設定 → ローカルバックアップ → 履歴を表示」を開きます。不具合が起きる前のバックアップを選び、アプリのデータフォルダー以外に書き出してから、復元を選んで確認します。自動再起動を待ち、強制終了しないでください。再起動後に Profile を確認してからプロキシを有効にします。

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

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

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

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

アプリの再起動直後に TUN を有効にしないでください。Profile の数、名前、種類、選択項目を確認し、Merge と Script を開いて重要なルールが空のテンプレートでないことを調べます。遠隔サブスクリプションを手動更新でき、ローカルの Profile は検証を通って Mihomo を起動できる必要があります。

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

復元後に起動できない、Profile が減る、設定検証に失敗する場合は、トレイから完全終了して関連プロセスが止まったことを確認します。複数の ZIP を続けて試さず、今回の復元後のディレクトリとログを別保存し、最初に残したディレクトリ全体のコピーで戻してください。不明なバックアップを混ぜないでください。

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

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

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