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

この記事では9月17日のプレリリース版を扱います。公式のGHSA-99qg-xv7m-jf4vはWindowsサービスの<= 2.5.4を影響範囲とし、修正ビルドをv2.5.4+autobuild.0908.bbab52dと明示しています。Windowsユーザーはv2.5.2のサービスを安全な切り戻し先にしないでください。

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の変更を記録してください。ポータブルモードの廃止とシステムのアプリデータディレクトリへの統一も確認します。完全なバックアップがあり、デスクトップの接続を検証してすぐに戻せる場合にだけテストし、唯一の普段使う環境を直接上書きしないでください。

システムプロキシの状態エラー、サービスモードのタイムアウト、Windows system/mixed TUNで通信を捕捉できない問題に対応している場合や、ポータブルモードの移行確認が必要な場合は、まず現行の公式Releaseとセキュリティアドバイザリを照合し、バックアップを用意してからテストしてください。

2026年9月17日時点では、v2.5.4-rcとAutoBuildはいずれもプレリリースで、v2.5.2が当時のLatest安定版でした。これは過去の公開状況であり、現在のインストール推奨ではありません。9月22日にはv2.5.5正式版が公開されましたが、Windowsサービスのリスクは引き続きGHSAの修正済みビルドと照合する必要があります。

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

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

Service IPC では、%ProgramData% に一時保存されるコアのファイアウォール規則が追加され、v2.5.4-rc のリリースノートにもこの修正が記載されています。このタグの Cargo.toml で使われる Service IPC の依存バージョンは v2.7.1 です。バックグラウンドコンポーネントの依存バージョンであり、インストールするクライアントのバージョンではありません。

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

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

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

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

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

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

旧版をまだ開けるうちに、現在の Profile 名、サブスクリプションの配信元、上書き設定とスクリプト、システムプロキシ、TUN、サービスモード、ポートを記録します。旧プログラムの隣にあるデータディレクトリと、公式のシステムアプリデータディレクトリを両方保存してください。

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

一般的な Windows 端末は x64、ARM 版 Windows は arm64 を選びます。WebView2 がなくインストールもできない場合、または通常のパッケージで画面が開かない場合に限り、ファイル名に fixed_webview2 が含まれる大容量版を検討してください。

macOS では Apple シリコンと Intel を区別し、Linux ではディストリビューションのパッケージ形式と CPU アーキテクチャの両方を合わせます。

インストール前にアセットのファイル名とダウンロード時刻を保存します。第三者の「ポータブル版」を使わず、検索広告から同名のインストーラーを入手せず、安定版とRCのデータディレクトリを混在させないでください。本番環境が一つしかない場合は、データ全体のバックアップと、影響対象のWindowsサービスに依存しない通信への切り戻し手段を先に用意します。

以前のバージョンを完全に終了し、二つの画面またはコアが同じデータディレクトリを同時に変更しないようにする。

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

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

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

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

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

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

Windows のサービスモードと TUN は、完全なビルド、インストール元、実際のサービス部品に GHSA 修正の証拠がある場合だけテストします。証拠が不足する場合はサービスを停止し、システムプロキシだけ検証します。元の問題が system または mixed スタックで起きた場合は、安全条件を満たしてから元のスタックで再テストします。

テスト中は同じノードと宛先を使い、gVisor、DNS、ポート、上書きを同時に変更しません。macOS、Linux は元の許可手順に従って迂回ルールとサービスログを確認し、以前の権限エラーが続かないことを確かめます。

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

システムと Clash Verge Rev を再起動し、更新前と同じ Profile、ノード、HTTPS 宛先で起動とシステムプロキシを確認します。Windows のサービスモードと TUN は、完全なビルドと実際のサービスの両方に GHSA 修正の証拠がある場合だけ検証し、それ以外は停止したままにします。macOS、Linux は元の許可手順に従います。

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

テスト中は旧ポータブルディレクトリや更新前のバックアップを削除せず、影響対象のWindows旧サービスも再び有効にしないでください。少なくとも一度再起動し、プロキシをオフにした後の直接接続も一度確認してから、現在のビルドを使い続けるか決めます。

AutoBuild のテストに成功しても、正式版で同じ条件の移行と通信復旧を確認します。

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

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

障害発生時のデータディレクトリのコピーを保存し、信頼できる設定全体のバックアップを残してください。ただし、Windowsで<= 2.5.4の古いサービスを再インストールしたり有効にしたりしないでください。そのサービスに依存しないシステムプロキシか別の信頼できるクライアントで必要な接続を復旧し、GHSAに明記された修正済みビルドを確認してください。

復旧後はまずProfileと実際のHTTPSリクエストを確認します。サービスモードとTUNは、インストール元、完全なビルド番号、実際のサービスコンポーネントのすべてについて修正の根拠を得てから再有効化してください。根拠が足りない間は停止を続け、エラーをメンテナーへ報告します。