Clash Verge Rev v2.5.4-rc はアップグレードすべき？

Clash Verge Rev v2.5.4-rc は 2026 年 9 月 17 日 19:36（Asia/Shanghai）に公開され、GitHub Release では明確に Pre-release と表示されています。同じ時点でプロジェクトの Latest 安定版は引き続き v2.5.2 です。v2.5.4 というバージョン番号が表示されても、正式版に置き換わったことを意味しません。

今回の RC と継続的な AutoBuild には、システムプロキシ、サービスモード、サブスクリプション編集、ノード選択、ポート競合の回避、TUN など多数の変更が含まれ、ポータブルモードも廃止されて、システムのアプリデータディレクトリへ統一されました。完全なバックアップを保持し、デスクトップのネットワーク検証ができ、すぐにロールバックできる人には適していますが、バージョン番号が大きいという理由だけで日常利用する唯一の環境を上書きする用途には適しません。

現在の v2.5.2 が正常に動作し、リリースノートにある特定の修正を検証する必要もないなら、安定版を使い続けるのが妥当です。システムプロキシの状態表示の誤り、サービスモードのタイムアウト、Windows の system/mixed TUN が通信を処理しない問題に対応している場合や、ポータブルモードの移行を事前に検証する必要がある場合に限り、ロールバックできる時間を確保してテストしてください。

リリースノートには多くの修正が並んでいますが、アップグレード前に、自分で再現できる対象を一つだけ選んでください。たとえば、システムプロキシの切り替え失敗後に画面の状態が誤っている場合は、スイッチの表示、OS 上の実際のプロキシ設定、実際のリクエスト一件を記録します。サービスモードの操作がタイムアウトする場合は、最初のエラーと、その後の操作でも異常が続くかを記録します。

最近の issue #7915 が扱う範囲は限定的です。Windows のサービスモードで、特定の v2.5.4 AutoBuild が system または mixed TUN スタックを使うと通信できず、gVisor は正常に動作し、v2.5.2 へ戻すと復旧するという内容です。

その後 Service IPC では、%ProgramData% に一時配置されるコア向けにファイアウォールルールが追加され、メインリポジトリはこの修正を含む 2.7.0 へ更新されました。v2.5.4-rc のリリースノートにも、この修正が記載されています。

これは、TUN で通信できないすべての問題がファイアウォールに起因するという意味ではなく、Windows ファイアウォールを手動で無効にすべきでもありません。バージョン、Windows のサービスモード、スタックの違い、通信できない症状がすべて一致する場合に限り、RC へアップグレードする理由の一つとして扱ってください。

ポータブルモードの利用者が最初に確認すべきなのはネットワークではなく、設定がどこから読み込まれるかです。v2.5.4 ではポータブルモードが明確に廃止され、システムのアプリデータディレクトリへ統一されました。以前のインストールで、プログラム付近、Scoop のディレクトリ、またはカスタムの場所にデータを置いていた場合は、先に以前のディレクトリを特定し、別途保存する必要があります。

Scoop は公式ドキュメントに記載された、コミュニティによって管理される配布方法です。設定ディレクトリの変更やポータブル利用に使えると説明されていますが、プロジェクトは下流の配布チャネルの問題をサポートしないことも明記しています。これは v2.5.4 のアプリ側での「ポータブルモード廃止」と同じ保証ではありません。Scoop を使う場合は、Scoop 側の永続化ディレクトリとアップグレード時の動作も確認してください。

まず Clash Verge Rev を完全に終了し、システムトレイのプロセスとサービス操作が終了したことを確認してから、アプリデータディレクトリをコピーします。

公式のプライバシードキュメントでは、Windows のディレクトリは %APPDATA%\io.github.clash-verge-rev.clash-verge-rev、macOS は ~/Library/Application Support/io.github.clash-verge-rev.clash-verge-rev とされています。

Linux では $XDG_DATA_HOME/io.github.clash-verge-rev.clash-verge-rev を使用し、通常は ~/.local/share にあります。

ディレクトリ内の verge.yaml、config.yaml、profiles.yaml、profiles/ は、設定、サブスクリプション、Profile を復元するうえで重要です。logs/、service-logs/、cache.db、Geo データも比較に役立ちますが、設定を保存せずログだけを残すことは避けてください。

バックアップはアプリの作業ディレクトリ外に保存し、OS、アーキテクチャ、元のバージョン、日時を明記してください。verge.yaml には WebDAV のアドレス、ユーザー名、パスワードが平文で保存されている場合があり、Profile にはサブスクリプションの token、ノードのパスワード、UUID が含まれる場合があります。元のバックアップを公開クラウドストレージにアップロードしたり、そのまま Issue に添付したりしないでください。

v2.5.4 のリリースノートで確認できるのは「ポータブルモードを廃止し、システムのアプリデータディレクトリへ統一する」ことだけで、あらゆるサードパーティーのポータブルパッケージやカスタムディレクトリを自動検出する保証はありません。そのため、以前のファイルを先に削除したり、新しいプログラムを以前のプログラムディレクトリへ直接展開して、元の設定が自動的に読み込まれることを期待したりしないでください。

以前のバージョンをまだ開けるうちに、現在の Profile 名、サブスクリプション元、オーバーライドとスクリプト、システムプロキシ、TUN、サービスモード、ポートを記録します。その後、以前のプログラム付近にあるデータディレクトリと、公式のシステムアプリデータディレクトリを両方バックアップします。RC をインストールしたら、まず新しいシステムデータディレクトリを作成して使わせてから完全に終了し、アプリのインポート機能またはバックアップ復元機能で復元します。

手動でしか復元できない場合は、まず新しいバージョンを終了し、直前に作成されたディレクトリのコピーを残してから、バックアップ済みの設定一式をまとめてコピーします。profiles.yaml だけを選ぶ、profiles/ だけをコピーする、新旧の verge.yaml を混在させる、といった復元は避けてください。ファイル間の参照と現在の選択状態が同期しなくなる可能性があります。

Clash Verge Rev の公式ドキュメントによると、現在の配布チャネルは GitHub Release のみです。v2.5.4-rc をテストする場合は、その RC の公式 Release を開き、ページに Pre-release と表示されていること、対象コミットが c7ffb212 であることを確認し、公開日時とアセットのファイル名を記録してから、OS とアーキテクチャに合うアセットを選んでください。

一般的な Windows 端末では通常 x64、ARM Windows では arm64 を選びます。OS に WebView2 がなくインストールもできない場合、または通常版で画面を開けない場合に限り、ファイル名に fix_webview2 を含む容量の大きい版を検討してください。macOS では Apple シリコンと Intel を区別し、Linux ではディストリビューションのパッケージ形式と CPU アーキテクチャの両方を一致させます。

インストール前にアセットのファイル名とダウンロード日時を保存してください。サードパーティーの「ポータブル版」を使わず、検索広告から同名のインストーラーをダウンロードせず、安定版と RC のリソースディレクトリを混在させないでください。正式運用環境が一つしかない場合は、テストインストールを始める前に、v2.5.2 の公式インストーラーと完全なデータバックアップを用意してください。

v2.5.4 Release では、重要な注意事項が最初に示されています。サービスモードでは、設定ディレクトリ内のルールセットとプロキシセットのファイルはキャッシュコピーにすぎず、手動で変更しても実行中のコアには反映されません。自分で管理するファイルは、サービスが生成するキャッシュを編集し続けるのではなく、設定で type: file を使用してください。

今回の AutoBuild では、サービスモードのマルチユーザー分離と以前のサービスからのアップグレード移行も追加され、操作のタイムアウト後もエラーや状態異常が続く問題が修正されています。アップグレード後は、まず画面でサービスのインストール状態と現在のユーザーを確認し、その後アプリのログと service-logs を調べてください。以前のキャッシュが残っているだけで、新しいコアが手動変更を読み込んだと判断しないでください。

元の設定が provider キャッシュの手動変更に依存している場合は、まずバックアップを復元し、実際に管理が必要なルールセットまたはプロキシセットを、明示的なローカル file provider へ変更します。一度に一つのファイルだけを移行し、再読み込み後に接続記録またはルールの一致結果で確認してください。サービス移行、provider 移行、サブスクリプション更新を同時に行わないようにします。

Profile を復元したら、まず TUN を無効にし、システムプロキシだけを有効にして、同じノードで実際の HTTPS リクエストを一度実行します。Connections で対象、ルール、出口を確認してください。その後、システムプロキシを無効にし、OS のプロキシ状態も連動して元へ戻ることを確認します。この手順で、リリースノートにあるシステムプロキシの状態表示と復元に関する修正を検証します。

システムプロキシが安定してから、サービスをインストールまたはアップグレードし、TUN を有効にします。Windows で元の問題が system または mixed スタックにだけ発生していた場合は、同じノードとテスト対象を保って再検証してください。gVisor、DNS、ポート、オーバーライドを同時に切り替えないでください。macOS と Linux では、権限付与の手順、バイパスルール、サービスログに以前の権限エラーが続いていないことを重点的に確認します。

v2.5.4 では TUN に Mips スタックの選択肢が追加され、Release では Mihomo v1.19.31 以上が明確に必要とされています。このコアバージョンがない場合や、明確なテスト目的がない場合は、新しい選択肢が増えたという理由だけでスタックを切り替えないでください。

バージョン番号が表示され、画面を開けるだけではインストール完了の証明にしかならず、移行成功の証明にはなりません。OS と Clash Verge Rev を一度再起動し、アップグレード前に保存した同じ Profile、同じノード、同じ HTTPS 対象を使って、アプリの起動、システムプロキシ、サービスモード、TUN の順に検証してください。

さらに、システムのアプリデータディレクトリに新しい変更が実際に保存され、再起動後も Profile、選択中のノード、オーバーライド、ポートが以前の値へ戻っていないことを確認します。ローカルの type: file を使うルールセットまたはプロキシセットでは、実行時設定がサービスのキャッシュコピーではなく、元のファイルを参照していることも確認してください。

テスト中は、以前のポータブルディレクトリ、v2.5.2 のインストーラー、アップグレード前のバックアップを削除しないでください。少なくとも一度の再起動と、プロキシを無効にした後の直接接続への復旧を完了してから、RC を使い続けるか判断してください。

RC が起動しない、設定の移行が不完全、システムプロキシまたは TUN に新しい不具合が出た場合は、まず TUN とシステムプロキシを無効にし、アプリを完全に終了して、OS が直接接続へ戻ったことを確認します。異常な状態のままサブスクリプションを更新したり、データディレクトリを繰り返し上書きしたりしないでください。

v2.5.4 で不具合が発生した時点の状態をコピーして保存してから、公式の v2.5.2 インストーラーでプログラムを復旧し、アップグレード前の完全なデータバックアップを一式として復元します。実行ファイルだけを戻して、新しいバージョンが書き換えた一部の設定を使い続けたり、新旧のリソースファイルを組み合わせたりしないでください。

ロールバック後は、まずバージョンと Profile を確認し、次にシステムプロキシ、サービスモード、TUN の順で検証します。以前のポータブル版が安定していた場合は、以前のプログラムと以前のデータディレクトリを一時的に復元できますが、システムのデータディレクトリとは分離したままにして、今後の正式版で明確な移行手順が示されるのを待ってください。

2026 年 9 月 17 日時点で、v2.5.4-rc と AutoBuild はどちらもプレリリースで、v2.5.2 が引き続き Latest 安定版です。今後は、プロジェクトの正式 Release ページで新しい安定版が公開されたか、ポータブルモード廃止とデータディレクトリに関する説明が維持されているかを基準に判断し、プレリリースのバージョン番号から正式版の公開日を推測しないでください。

正式版が公開された後も、完全なバックアップ、システムデータディレクトリの確認、Profile の復元、システムプロキシ、サービスモード、TUN の順でのテスト、最後のロールバック検証という同じ移行確認を一度行う必要があります。AutoBuild のテスト成功は正式版の再確認に代わるものではありません。

問題を報告する場合は、OS、アーキテクチャ、インストール経路、旧版と新版、以前のデータディレクトリと新しいシステムディレクトリ、最初の関連ログ、最小限の再現手順を提示してください。公開前に、サブスクリプションの token、ノードの認証情報、WebDAV 情報、アクセス先ドメイン、完全なローカルパスを削除してください。