安全な更新・バックアップ・ロールバック-ブログ-Clash Verge Rev

更新成功は、画面が開くことだけでは判断できません。プロファイル、ローカルルール、必要な通信が引き続き動作し、不具合があれば復旧できる必要があります。基準状態の記録、読めるスナップショットの保存、適切なビルドの導入、主要操作の検証という順序で進めましょう。

Windows、macOS、Linux のデスクトップ向けの保守手順です。任意のバージョン間で直接ダウングレードできる保証ではありません。正式な移行手順を優先してください。管理対象 PC や遠隔ホストは保守時間を決め、唯一の遠隔接続に依存したまま試さないでください。

1. 復旧するものを三種類に分ける

プログラムと実行環境：インストーラー、クライアントとコアのバージョン、関連ランタイムです。旧インストーラーだけでは設定は保存できません。
ユーザーデータ：購読情報、ローカル設定、上書き設定やスクリプト、独自ルール、アプリ設定です。購読を再取得してもローカル変更が戻るとは限りません。
システムの状態：システムプロキシ、TUN やサービスモード、DNS、自動起動、権限です。アプリのエクスポートに含まれない場合があります。

YAML ファイル一つが、完全な復旧計画とは限りません。実際に必要な操作を挙げ、その裏にあるデータと設定を確認します。使っていない機能を更新テストのために有効化する必要はありません。

2. 更新前の五つの確認

正常動作中のクライアント、コア、OS のバージョンと CPU アーキテクチャを記録します。
設定読み込み、意図したルール一致、対象アプリのアクセスを一度実行します。
更新先の動作要件、既知の問題、移行手順、セキュリティ修正を読みます。
既存の導入経路を確認します。パッケージ管理なら更新、旧版保持、ダウングレード方法を理解し、別経路を安易に混在させません。
使えるバックアップと信頼できる復旧用インストーラーを準備し、重要な作業に影響しない時間を選びます。

Windows の x64 と ARM64、macOS の Apple Silicon と Intel、Linux のパッケージ形式と CPU を区別します。名前に「64」があるだけでは不十分です。現在の要件は公式導入資料と当サイトのダウンロードページで確認してください。

3. 読み取りを確認したオフラインの保存状態を作る

現在のバージョンの設定や資料で、実際のデータディレクトリを確認します。設定フォルダーを開く機能がある場合は利用してください。別の導入方式の固定パスを流用したり、プログラムの場所をユーザーデータと取り違えたりしないでください。

復旧に必要な場所と設定を記録します。エクスポートを使うなら対象範囲を確認します。
通常の操作で終了し、設定への書き込みが止まってから、日付付きの別の場所へコピーします。無関係なサービスを強制終了しないでください。
コピー内の重要ファイルを開き、構造、ファイル一覧、独自ルールを確認します。暗号化コンテナーやアーカイブも解除して読めるか試します。
復旧手順とバージョン情報を添えますが、購読 URL やパスワードを公開メモへ記載しません。

保存データにはノード認証情報、購読トークン、コントローラーの秘密情報、同期用認証情報が含まれる可能性があります。アクセスを制限し、信頼できる暗号化ストレージを利用してください。公開リポジトリ、掲示板、保護状態不明のクラウドへ送信しません。ファイル名が見えるだけでは復旧可能性を確認したことになりません。

4. 警告を回避せず、配布元を確認する

公式リリースまたは信頼できる管理経路から取得し、発行者、バージョン、アーキテクチャ、形式、サイズを照合します。公式チェックサムや検証可能な署名があれば、その説明に従います。自分で計算したハッシュだけでは、配布元の正当性は証明できません。

Windows のランタイム問題はプロジェクト FAQ、macOS の安全警告は配布元とプラットフォーム資料を確認します。システムの安全確認を無効にすることを導入手順にしないでください。Linux は適切なパッケージ管理で依存関係を処理し、出所不明の一括修復スクリプトは実行しません。

5. 更新後は同じチェックリストで検証する

元のバックアップはそのまま保持し、全購読の更新やルール書き換えを同時に行わないでください。古いショートカットで別のインストールを開いていないか、実行中のバージョンを確認します。

起動とデータ：必要な設定と上書き設定があり、継続的な読み込み・解析エラーがありません。
ルール：直接接続を意図した宛先とプロキシを意図した宛先を一つずつ試し、実際の記録を確認します。
元のアプリ：遅延測定だけでなく、更新前の日常操作を繰り返します。
必要なモード：元から使っていた System Proxy、TUN、サービス機能の権限とログを確認します。
再起動・再接続：アプリを閉じて開き直し、保守時間内にネットワーク再接続やスリープ復帰も試します。
終了時：正常終了後のプロキシ設定を確認し、停止したリスナーを参照したままにしません。

「成功」と一言書くだけではなく、各項目の結果を残します。ブラウザー、必要なアプリ、再接続のテストを通過してから、新版を安定した基準状態とします。

6. 戻すべきか、先に調べるべきか

一つの外部サービスだけが失敗するなら、別の宛先や回線状態を比較します。更新直後というだけでは回帰の証明になりません。同じ設定と環境で起動失敗、解析エラー、主要機能の不具合を再現できるなら、ロールバックを検討する根拠が強くなります。

先に伏字済みのログと現在のデータを保存します。旧版に既知の脆弱性がある場合、便利だからと長期間使い続けず、修正版や不具合を避けられるサポート対象の暫定運用を探してください。

7. 新旧のデータを混ぜずに戻す

追加変更を止め、障害と戻す理由を記録します。
通常終了し、更新後のデータも保存して新しい作業を失わないようにします。
リリース情報と導入経路の降格制限を確認します。旧版が移行済みデータを読めるとは限りません。
信頼できる旧インストーラーまたは対応するパッケージ管理を使い、サポートされる復旧方法で対応する更新前スナップショットを戻します。
同じ動作確認を繰り返し、起動だけでなく復旧を検証します。

新旧ディレクトリを無造作に重ねたり、試す前に全データを削除したりしないでください。更新前の保存がなければ、無損失の復旧は保証できません。全データを残してプロジェクトへ相談し、必要ならサポートされる分離環境で最小設定を検証します。

8. 秘密情報を含まない保守記録

時刻とタイムゾーン：
旧版 / 更新先 / コア：
OS / CPU / 導入経路：
保存場所と読み取り確認：
更新前後のテスト結果：
戻す判断 / 理由 / 復旧結果：

仮想例：購読は更新できるのに独自ルールが消えました。再ダウンロードでルールが戻るとは限りません。元の設定、上書きファイル、エクスポート範囲を先に確認します。探しやすい一つのファイルではなく、動作環境を保存する理由がここにあります。

新版が重要な操作を通過するまで、読めることを確認した旧スナップショットを少なくとも一つ保持します。その後は実際の保持要件とプライバシーに従って整理し、公開された設定保管庫にはしないでください。

参考資料

参考資料の確認日：2026-10-14。以下はプロジェクトとプラットフォームの公式資料です。本稿は当サイト独自の編集ガイドです。

更新,バックアップ,ロールバック,メンテナンス