Clash Verge Rev再起動後の自動バックアップ修正

公式issue #8331の報告者は、Windows 11とClash Verge Rev v2.5.8を使用していました。1時間おきに設定し、完全に終了してから再起動。設定を変えずに端末をスリープさせず、1時間を超えて待っても自動アーカイブが作られず、対応するBackupログも出なかったと報告しています。

その報告では、設定を変更してから再び間隔いっぱい待つと、定期バックアップが作られました。これは症状を見分けるための対照であり、起動のたびに適当な設定を変えることを恒久対策にはできません。調査のために言語、プロキシ、サブスクリプションを何度も変える必要もありません。

この記事の根拠は、このWindowsでの報告、共通のバックアップコード、正式な修正内容です。全プラットフォームや全旧バージョンで影響を実測したわけではありません。v2.5.9には正式に修正が入りましたが、単に間隔が経過していない場合やアプリを終了している場合は、先に通常のタイマー動作の条件を確認してください。

次の定期バックアップを待たず、現在の設定を保護してください。「設定 → Verge詳細設定 → バックアップ設定」を開き、「Local backup」（ローカルバックアップ）の「バックアップ」を押します。次に「View history」（履歴）を開き、作成されたZIPをアプリのデータディレクトリ外へ書き出してください。

書き出したファイルが存在して開けることを確認し、profiles.yaml、profiles/、自分の重要な設定内容を調べます。ZIPはアーカイブであり、暗号化とは別です。サブスクリプションのトークン、ノードのパスワード、ローカルの上書き設定が含まれる場合があるため、自分で管理できる保護された保存先に置いてください。

手動バックアップでもエラーが出る場合は、最初のエラーを保存し、現在のデータを別途コピーして、実際のファイル書き込みの問題を調べます。再起動後の定期処理の不具合だと即断せず、試しにアプリのディレクトリを空にしたり、古いZIPを復元したり、アンインストールしたりしないでください。

公式PR #8386によると、旧実装は保存済みのバックアップ設定を送信してから、タイマー処理を購読させていました。受信側がないと、watchチャネルのsendは新しい値を保持しません。後から起動する処理は初期値の「無効」を読み、次の設定変更を待ち続けてしまいます。

修正では、起動時と設定更新時の両方をsend_replaceに変え、後から起動する処理にも保存済みの値が届くようにしました。この修正はマージされ、2026年11月2日公開の正式版v2.5.9に含まれています。issueが閉じたことや開発ブランチの変更だけで、公開済みと判断しているわけではありません。

これはClash Verge Revアプリのバックアップスケジューラーの問題です。Mihomoコアだけの更新、サブスクリプションの再取得、コアの再起動では、アプリの更新を代替できません。すでに修正を含む根拠のある後続の正式版を使っているなら、この記事のためにv2.5.9へ戻す必要はありません。

定期バックアップは、アプリ内のタイマー処理がローカルファイルを作成します。OS上で独立して常駐するバックアップサービスでも、毎日の決まった時刻に動くカレンダー式の処理でもありません。アプリを完全終了している間の作成や、開き直した後の取りこぼし分の補完を期待しないでください。

この記事で確認した正式な修正版はClash Verge Rev v2.5.9です。更新には、本文の参考資料にある公式v2.5.9 ReleaseからOSとチップのアーキテクチャに合うものを選んでください。今回の保守では当サイトの配布パッケージを更新していません。旧v2.5.8のミラーを修正版として扱わないでください。

公式パッケージを取得できない場合やインストールでエラーが出る場合は、現在使える環境とエラーを残し、まず取得・インストールの問題を解決します。署名確認やセキュリティ保護を無効にせず、サイトの古いパッケージがダウンロードできることを今回の更新成功と取り違えないでください。

「バックアップ設定 → Automatic backup」（自動バックアップ）で、「Enable scheduled backup」（定期バックアップの有効化）と「Backup frequency」（バックアップの間隔）を確認します。固定v2.5.9コードの初期値は24時間で、1–168時間に設定できます。観察用に一時的に1時間を選ぶ場合は元の値を記録し、反映後に完全終了して一度開き直してください。

今回開き直した時点から計測し、アプリを起動したまま端末をスリープさせずに保ちます。その間は設定変更や再起動をせず、グローバルの上書き設定やスクリプトを編集して別のバックアップを発生させることも避けます。設定した間隔を超えて待ってください。起動直後にファイルができないことだけでは、失敗と判断できません。

アプリの再起動や設定の通知があると、改めて間隔いっぱい待つことになります。頻繁に設定を保存すると、観察できる時刻が後ろへ延び続ける場合があります。スイッチが有効なのに、長時間設定を変えなくても実行されない症状とは分けて判断してください。

時間が経過したら「Local backup → View history」（ローカルバックアップの履歴）で新しいファイルを確認し、ログのAuto backup created (Scheduled)と照合します。定期アーカイブのファイル名には-auto-scheduled.zipが付きます。-auto-merge、-auto-script、手動ファイルだけでは、今回の検証は完了していません。

固定コードが保持するのは、-auto-付きの自動アーカイブを合計で新しい順に20件です。定期処理、グローバルの上書き設定、スクリプトの変更で作られるファイルがこの枠を共有し、それぞれ20件ではありません。ローカルのディレクトリは永久保存の履歴庫ではないので、動作確認済みのバックアップは別途書き出してください。

当サイトでは、実際のClash Verge Revクライアントで一時間待ったり、復元実験を行ったりしていません。ここで示すのは、公式のユーザー報告と固定ソースに基づく確認手順です。当サイトのページ、翻訳、ビルドのチェックが通っても、お使いの端末で定期バックアップを検証したことにはなりません。

定期処理だけが失敗しているなら、手動でバックアップを作って書き出し続け、予定処理を試すために復元で現在の設定を上書きしないでください。アプリのロールバックやデータ復元が必要な場合は、完全終了し、更新前後の独立したコピーを残します。新旧プログラムで唯一のデータディレクトリを取り合わないようにしてください。

旧アプリには同じ不具合が残っている可能性があります。ロールバックは応急処置であり、定期処理の修正とは別です。プログラムとデータを戻したら、元のProfile、上書き設定、プロキシモード、実通信を確認します。手動バックアップは引き続き別に保存し、定期処理は前節どおり改めて待って検証してください。

公式プロジェクトへの報告では、使用しているシステム、完全なアプリのバージョン、元の間隔、起動と設定保存の実際の時刻、手動での結果、定期ファイル名、最初のエラーから機密情報を除いたものを伝えます。ZIP一式、サブスクリプションのリンク、認証情報はアップロードしないでください。他のプラットフォームで未実施の検証を、成功済みと書くことも避けてください。