Clash for Windows サポート終了後の移行先は？Clash Verge Rev などを比較

サポート終了後の移行で確認すること：設定の保存先、コア、通信の受け渡し方

Clash for Windows（以下、CFW）のサポート終了後も、インストール済みのアプリがすぐに使えなくなるわけではありません。ただし、クライアントの画面や依存コンポーネント、コアは現在のネットワーク環境に合わせて更新されなくなります。一般的なCFW 0.20.39のインストール環境では、従来のサブスクリプションを引き続き処理できる場合がありますが、接続できることと、長期的な利用に適していることは別です。移行では再利用できる設定を引き継ぎ、新しいクライアントが実際に読み込んでいる内容を確認しましょう。

まず、次の3つを区別しましょう。クライアントはサブスクリプション管理、トレイメニュー、システム連携を担当します。コアは設定の解析、ルールの照合、接続の確立を担います。サブスクリプションにはノードやグループ、場合によってはルールが含まれます。クライアントを変えてもサブスクリプションを変える必要はありませんが、コアを変えた場合は、旧形式の項目やスクリプト、DNSの挙動をあらためて確認してください。

設定の保存先：サブスクリプションURL、現在のローカルYAML、サブスクリプション由来の設定とローカル上書きの設定を記録します。
コアの違い：Clash Verge Revはmihomoを使用します。mihomoは、旧Clash.Metaプロジェクトで後継名称として採用されたものです。CFWの画面を別の外装に置き換えただけではありません。
通信の入口：システムプロキシ、TUN、アプリに手動設定するHTTP/SOCKSプロキシは、それぞれ異なる入口です。スイッチの状態だけで移行の成否を判断しないでください。

移行先を比較：Clash Verge Revとその他の選択肢

Windowsデスクトップでのサブスクリプション読み込み、ポリシー選択、ログ確認、TUNが主な用途なら、Clash Verge Revは移行先として有力です。同じ種類の設定を複数のデスクトップOSで使う場合は、macOS版やLinux版も選択肢になります。スマートフォンではモバイルOSに対応した別のクライアントが必要です。デスクトップ版のインストーラーをAndroidやiOSで使うことはできません。

選択肢	コアと対応OS	設定移行時のポイント	適した用途
Clash Verge Rev	mihomo；Windows、macOS、Linux	サブスクリプションを再読み込みし、ローカル上書きとシステム連携の設定をやり直す	デスクトップ画面での管理、サブスクリプション管理、TUNが必要
ClashX Meta	Meta/mihomo系、macOS	配布パッケージのコアのバージョンを確認し、メニューバーとシステムプロキシの設定をやり直す	主にmacOSのメニューバーから操作する
mihomoのコマンドライン版	mihomo。デスクトップやサーバー向けの複数プラットフォーム版を提供	YAML、サービスの起動、ログ、コントロールインターフェースを自分で管理する	スクリプトでの導入や常時稼働するサービスが必要
CFWを一時的に使い続ける	元のインストールに含まれるコアによる	短期的な切り戻し用途に限定。クライアント名だけでプロトコル対応を判断しない	移行期間中に旧設定の動作を再確認する

引き継げるのは設定の意味であり、設定フォルダー全体ではない

proxies、proxy-groups、rulesは移行の土台にできますが、クライアントが保存する画面の状態、サブスクリプションのデータベース、サービスのインストール情報には互換性がありません。CFWのデータフォルダー全体をClash Verge Revのフォルダーに上書きしたり、旧コアの実行ファイルを新しいクライアントのフォルダーにコピーしたりしないでください。

CFWのParsers、クライアント側のスクリプト、Clash Premiumのスクリプトルールは、それぞれ区別が必要です。Parsersはクライアントの処理フローに属し、スクリプトルールはコアの機能に関わります。どちらもmihomoでそのまま動くとは限りません。単純なドメインの振り分けは標準ルールに置き換えられますが、複雑なスクリプトは同等の実装があるか個別に確認してください。拡張子を変えるだけでは移行できません。

移行前のバックアップ：サブスクリプション以外に保存するもの

まずCFWのGeneralページでHome Directoryを開き、実際のデータフォルダーを確認します。以前のインストールではユーザーフォルダー内の.config/clashが使われていることが多いものの、ポータブルモードやカスタムパスでは場所が異なる場合があります。現在のインストール画面に表示された場所を基準にしてください。設定の書き込み中にバックアップしないよう、作業前にアプリを終了します。

サブスクリプションの登録情報：Profilesにある各サブスクリプションの名前と元のURLを記録します。URLにはアクセス認証情報が含まれることが多いため、バックアップ内だけに保管し、公開サポートチケットやスクリーンショット、オンライン変換サイトには貼り付けないでください。
ローカル設定：使用中のYAMLと、自分で管理しているルールファイル、ルールプロバイダー、スクリプトをコピーします。サブスクリプションのキャッシュファイルを直接編集していた場合は、そのファイルを別に記録してください。更新時に変更内容が上書きされる可能性があります。
実行時の設定：プロキシモード、HTTP/SOCKSまたは混合ポート、LANからの接続許可、DNS、TUN、コントロールインターフェースのアドレスを記録します。コントロールインターフェースのキーをノードのパスワードとして移行しないでください。
選択状態：主要なポリシーグループで現在選択されているノードや下位グループを記録します。グループ名が同じでも、新しいクライアントに選択状態が引き継がれるとは限りません。
外部との連携：ブラウザー拡張、ターミナルの環境変数、Git、開発ツールなどに127.0.0.1:7890のようなアドレスが固定されていないか確認します。

サブスクリプションから復元できるのは、サービス提供元が配信する内容だけです。たとえば、旧クライアントで特定の業務用ドメインを直接接続にしていても、そのルールがサブスクリプションに含まれていなければ、再読み込み後にその動作は失われます。こうした差分を別のリストにまとめておくと、見た目上の設定一式だけを保存するより簡単に確認できます。

Clash Verge Revへの移行：サブスクリプションを確認してからシステムプロキシを有効にする

手順1：インストール後、コアが起動することを確認

OSとプロセッサーのアーキテクチャに合ったインストーラーを選びます。クライアントのダウンロードページから入手できます。CFWを終了し、旧システムプロキシと旧TUNを無効にしてからClash Verge Revを起動してください。まずコアの状態とログを確認します。コアが起動していない場合は、ノードを何度も切り替えるのではなく、設定の解析エラー、ポートの競合、サービスの起動エラーを先に解消してください。

手順2：元のサブスクリプションまたはローカルYAMLを読み込む

「サブスクリプション」ページの読み込みメニューから、元のサブスクリプションURLを追加します。以前ローカルYAMLを使っていた場合は、ローカルファイルの読み込みを選択してください。ボタンの表記はバージョンによって多少異なります。読み込み後、コアが参照できるClash/mihomo設定になっていることを確認しましょう。Base64のノード一覧や他のクライアント専用データを返すURLは、完全なYAMLとしてそのまま使えるとは限りません。

読み込み後に設定を選択し、ノード一覧、ポリシーグループ、ルールが表示されるか確認します。解析エラーが出た場合は、ログに示された項目名や行番号を手がかりに問題を特定してください。HTTP 401や403の場合は、サブスクリプションの認証情報とサービス提供元の状態を確認します。サブスクリプションURLへの接続にプロキシが必要な場合は、使用可能な旧環境で設定をダウンロードしてバックアップできます。ただし、新しいクライアントに切り替えるときは旧コアを終了してください。

手順3：ポートを確認してからシステムプロキシを有効にする

「設定」にあるポート設定を開き、実際の混合ポートを確認します。バージョンによっては「Clash設定」の中にあります。以下では7897を例にしますが、すべての環境で使う固定値ではありません。旧ポートの7890を使い続ける場合は、旧プロセスがポートを使用していないことを先に確認してください。新しいポートにする場合は、アプリに固定設定されているプロキシアドレスも変更します。

モードを「ルール」に設定し、利用可能なポリシーまたはノードを選択します。
「システムプロキシ」を有効にし、TUNはオフのまま、まずブラウザーで普段使うサイトにアクセスします。
「接続」画面またはログで、適用されたルール、ポリシーの経路、接続結果を確認し、新しいコアにリクエストが届いていることを確かめます。
基本的なプロキシ接続が確認できたら、スタートアップ、サービスモード、TUNを一つずつ戻します。複数の項目を一度に変更しないでください。

カスタムルールを引き継ぐ：上書き先とポリシーグループ名をそろえる

サブスクリプションを更新すると、通常はリモートの設定が再取得されます。長期的に維持したいローカルルールは、クライアントが対応する拡張設定、マージ設定、スクリプトの仕組みに追加してください。ダウンロードしたサブスクリプションのキャッシュを直接編集しないでください。設定画面の場所はバージョンによって変わりますが、最終的な設定でローカルルールがrulesに含まれ、フォールバックルールより前に配置されていることが重要です。

以下はルールの順序を示す例であり、サブスクリプション全体ではありません。テスト用にexample.comを使用しています。PROXYは例示用のポリシーグループ名です。実際に使う場合は、自分の設定にある名前と一字一句同じにしてください。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

順序：ルールは上から順に照合されます。MATCHより後ろに置いた通常のルールは、意図したとおりに機能しません。
振り分け先：DIRECTは組み込みのポリシーです。PROXYは実在するノードまたはポリシーグループである必要があります。サブスクリプション側で名前が変更された場合は、参照先も更新してください。
マージ：使う拡張機能がルールを先頭に追加するのか、末尾に追加するのか、配列全体を置き換えるのか確認します。誤ってrulesを置き換えると、サブスクリプション由来のルールがすべて失われることがあります。
ルールセット：rule-providersのURL、形式、動作タイプ、ローカルパスを確認します。以前のPCにある絶対パスは、別のPCではそのまま使えません。

旧YAMLのトップレベル項目をすべて必須設定と考えないでください。新しいクライアントがリスニングポート、コントロールインターフェース、TUNのパラメーターを管理している場合があります。ローカル上書きと画面上の設定で同じ項目を変更するときは、最終的にどちらが優先されるか確認してください。項目の意味は設定リファレンスも参照してください。

DNSとTUN：接続できるだけでなく、アプリの動作も確認する

まずDNSを確認し、特殊なドメインはその後に調整

旧コアから移行すると、DNSのfake-ip、実IPの解決方法、DNSリクエストの送信経路、ルールの照合方法がアクセス結果に影響することがあります。まず新しいクライアントの基本設定で一般的なWebサイトにアクセスできることを確認してから、以前のDNSカスタム設定を少しずつ戻してください。特定のサイトを表示させるために、出所のわからないDNS設定をいくつも重ねないでください。

ブラウザーは正常でも社内ネットワークのドメインにアクセスできない場合は、VPNから配布される内部DNSに依存していないか、専用の名前解決ルールが必要なドメインかを確認します。fake-ipモードで合成アドレスが表示されても、それだけで名前解決エラーとは限りません。アプリが実IPを必要とする場合に限り、実際の設定に合わせてフィルターやドメイン解決の方法を検討してください。

TUNは個別に動作確認する

システムプロキシは、システムプロキシ設定に従うアプリを主に対象とします。TUNは仮想ネットワークアダプターとルーティングを使って、より多くの通信を取り込みますが、あらゆるアプリ、プロトコル、ネットワーク環境で自動的に動作するとは限りません。Windowsでは、クライアントの案内に従って必要なサービスをインストールまたは有効化し、必要な権限があることを確認してからTUNを有効にします。

自動ルートが同時に変更されないよう、旧クライアントのTUNを無効にします。
ブラウザー、システムプロキシに従わないアプリ1つ、LAN内のアドレスをそれぞれテストします。
会社のVPN、仮想マシンのネットワーク、セキュリティソフトが新しいルートと競合していないか確認します。
TUNを有効にした後に社内ネットワークで問題が出た場合は、まずTUNを無効にして比較します。そのうえでルートとDNSを調べ、複数の設定を同時に削除しないでください。

移行後の確認と切り戻し：ポート、リクエスト、ルールの記録で問題を特定

以下のPowerShellコマンドは、新しい混合ポートが7897だと確認済みであることを前提としています。1つ目のコマンドはポートへの接続確認のみを行い、2つ目はHTTPプロキシを明示してリクエストを送信します。サンプルサイトの応答で確認できるのは基本的な接続性です。実際に使うWebサイトのテストに代わるものではありません。

Test-NetConnection 127.0.0.1 -Port 7897
curl.exe --proxy http://127.0.0.1:7897 --connect-timeout 10 --max-time 20 -I https://example.com

TcpTestSucceeded : Trueが示すのはローカルポートに接続できることだけで、ノードや接続先のWebサイトが正常とは限りません。明示的なプロキシ経由のリクエストは成功するのにブラウザーで失敗する場合は、システムプロキシとブラウザー独自のプロキシ設定を確認します。リクエストも失敗する場合は、クライアントのログからポリシーの選択、ノードへの接続、DNSを調べてください。

症状	まず確認する項目	次の対処
コアが起動しない	YAMLの解析エラー、リスニングポートの競合	旧プロセスを終了し、ログをもとに該当項目を特定する
ブラウザーは使えるが、ターミナルでは使えない	ターミナルのプロキシ環境変数が旧ポートを参照している	接続先を変更し、ターミナルを開き直して再テストする
旧クライアントとルールの動作が異なる	モード、ルールの順序、ポリシーグループ名	接続履歴で実際に適用されたルールを確認する
再起動後に通信を取り込めない	サービスの起動状態、システムプロキシ、TUNの権限	コアの起動と通信の取り込み設定を個別に確認する
サブスクリプション更新後にカスタムルールが消える	編集したのがキャッシュか、永続する拡張設定かを確認する	ローカル上書きを作り直し、更新後の動作を再テストする

移行を完了する前に、サブスクリプションの更新、クライアントの終了と再起動、OSの再起動をそれぞれ一度行い、直接接続するサイト、プロキシ経由のサイト、社内ネットワークのリソースを確認してください。切り戻す場合は、まず新しいクライアントのシステムプロキシとTUNを無効にし、新しいコアを終了してから旧クライアントに戻します。通信の不足を補うために、新旧2つのクライアントを同時に起動しないでください。

新しい環境が安定したことを確認してから旧アプリを削除し、必要なサブスクリプションとルールのバックアップを残します。以後は、クライアントのバージョン、コアのバージョン、サブスクリプションの内容、ローカル上書きを分けて管理してください。問題が起きたときは、一度に変更する項目を1つに絞ります。初回設定は入門ガイドを、よくある接続の問題はトラブル対処をご覧ください。