旧Clashクライアントのサポート終了後に：mihomo対応クライアントの選び方と設定の移行手順

1. クライアント・コア・サブスクリプションの違い

Clash for Windows（CFW）の旧プロジェクトはすでに開発・保守を終了しています。古いインストーラーが起動し、登録済みのノードに接続できる場合もありますが、GUIや依存コンポーネント、プロキシコアの修正が今後も提供されるわけではありません。移行の目的は旧ソフトを別の名前のソフトに置き換えることではなく、サブスクリプションの取得元、ローカルルール、システムへの適用方法を、保守が続いているクライアントに移すことです。

Clash MetaはClashから派生したコアプロジェクトで、後にmihomoへ改称されました。GUIクライアントはサブスクリプション管理、トレイメニュー、システムプロキシ、サービスのインストールを担当し、mihomoコアは設定の解析、接続、DNS、ルールの照合を担います。mihomo対応クライアントを選んでも、CFWのユーザーデータ一式をそのまま読み込めるとは限りません。

サブスクリプション：通常は認証情報を含むURLで、ノード一覧またはYAML設定一式を返します。アカウント権限、通信量、有効期限は引き続き提供元によって管理されます。
コア設定：よく使われるキーにはproxies、proxy-groups、rules、dns、tunがあります。
クライアントデータ：サブスクリプションの一覧、画面設定、更新スケジュール、オーバーライドの適用関係などが含まれ、形式はクライアントによって異なります。
システムへの適用：システムプロキシ、TUN仮想インターフェース、バックグラウンドサービスは別レイヤーの設定です。YAMLをコピーするだけでは移行できません。

2. OSに合わせてmihomo対応クライアントを選ぶ

まずOSとCPUアーキテクチャを確認し、次に設定編集やオーバーライド機能を確認します。インストーラー名のx64とARM64は対応するCPUが異なります。macOSもAppleシリコン版とIntel版を区別してください。クライアントのバージョン番号とコアのバージョン番号は別々です。インストール後は「バージョン情報」や「コア」の画面でそれぞれ確認し、画面上の製品名だけで稼働中のコアを判断しないようにしましょう。

OS	検討できるクライアント	移行前に確認するポイント
Windows	Clash Verge Rev、Clash Nyanpasu、FlClash	サブスクリプションのオーバーライド設定、サービスのインストール権限、起動時の自動実行、TUNの適用方法。
macOS	Clash Verge Rev、FlClash、ClashX Meta	CPUアーキテクチャ、システムプロキシの許可、選択したディストリビューションで利用できる拡張的な通信制御機能。
Linux	Clash Verge Rev、FlClash、またはmihomo単体	ディストリビューションのパッケージ形式、デスクトップのトレイ対応、サービス権限、設定ディレクトリ。
Android	FlClashなどmihomoベースのクライアント	VPNの使用許可、バックグラウンド実行の制限、アプリ別プロキシ、サブスクリプションの更新方法。
iOS / iPadOS	クライアントが明示的に対応するサブスクリプション形式を確認する	Clash設定に対応していても、mihomoを使っているとは限りません。ルールやスクリプトの調整が必要な場合があります。

デスクトップ版で確認する3つの機能

「サブスクリプション」または「設定」画面で、URLから読み込めることと、現在のサブスクリプションを個別に更新できることを確認します。
「設定」でポート、システムプロキシ、TUN、コアのログを確認します。現在の設定を記録し、すべての機能をすぐに有効にするのは避けましょう。
設定オーバーライド、設定マージ、スクリプトの項目を探し、個別のサブスクリプションと全体設定のどちらに適用されるか確認します。

メニュー名はクライアントやバージョンによって異なります。Clash Verge Revの場合は、まず「サブスクリプション」からリンクを読み込み、「設定」でシステムプロキシ、仮想インターフェース、サービス関連の項目を確認します。画面上の項目が見つからない場合は、現在のバージョンのドキュメントを確認してください。CFWと同じメニュー操作をそのまま当てはめないようにしましょう。各OSのインストール方法はクライアントのダウンロードページにまとめています。

3. CFWの設定をバックアップして移行リストを作る

Windows版CFWのユーザーディレクトリは通常%USERPROFILE%\.config\clashですが、ポータブル版、起動オプション、カスタムディレクトリによって場所が異なる場合があります。旧クライアントで「General」→「Home Directory」を開き、実際のディレクトリを確認してください。画面にパス欄やフォルダーを開くボタンが表示される場合は、その場所を基準にします。

旧クライアントを終了し、設定ディレクトリ全体を自分だけがアクセスできる場所にコピーしてから、以下の項目を個別に整理します。選択中のYAMLだけを保存すると、サブスクリプションのURLや設定拡張のロジックを取りこぼしがちです。

サブスクリプションの取得元：元のURL、サブスクリプション名、更新間隔、ローカルファイルかどうかを記録します。ノード名だけでは不十分です。
ローカル設定：profiles内で使用しているYAMLと関連ファイルを保存し、手書きの設定とサブスクリプション更新で上書きされるファイルを区別します。
設定拡張：CFWのParsers、ルールのマージ設定、スクリプトと適用条件をエクスポートするかコピーします。
実行時の設定：HTTP、SOCKS、混合ポート、LANからのアクセス許可、DNS、TUN、バイパス対象のアドレスを記録します。
プロキシグループの選択：よく使うプロキシグループで現在選択されているノードを記録します。選択状態が別のクライアントに引き継がれるとは限りません。

4. サブスクリプションを移行し、プロキシグループとルールを確認する

まずは基本的な接続だけを確認する

旧クライアントのシステムプロキシ、TUN、自動起動を無効にして終了します。バックグラウンドサービスをインストールしている場合は、そのサービスも停止していることを確認してください。
新しいクライアントを開き、元のサブスクリプションURLから新規登録します。旧クライアントのデータディレクトリ全体を新しいディレクトリに上書きしないでください。
サブスクリプションを更新して設定を選択し、ログにYAMLの解析エラー、未対応のプロトコル、存在しないプロキシグループの参照などが出ていないか確認します。
ルールモードを選び、ノードを1つ手動で選択します。まずはシステムプロキシでブラウザーの接続を確認し、TUNは無効のままにします。

サブスクリプションにはノードのみが含まれる場合と、proxy-groupsやrulesを含む設定一式の場合があります。ノードのみのサブスクリプションは、クライアントのテンプレートか独自のメイン設定と組み合わせて使います。読み込み後にノードしかなく、利用可能なプロキシグループがない場合は、mihomoとの互換性を疑う前にサブスクリプションの種類を確認してください。

ルール移行では順序と参照先を一致させる

rulesは上から順に照合され、通常はMATCHを最後に置きます。カスタムドメインルールはフォールバックルールより前に追加します。ルールが参照するプロキシグループ名は、スペースや大文字・小文字も含めてproxy-groupsの名前と一致させてください。以下はルールの順序を示す例であり、サブスクリプション設定全体ではありません。

ルール例：LANと指定ドメインを優先的に照合

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,出口グループ

この例では「出口グループ」という名前のプロキシグループがすでに存在する必要があります。例のドメインは構文を示すためのものです。実際に直接接続したいドメインに置き換えてください。クライアントの「前置ルール」機能を使う場合は、通常リスト項目だけを入力し、さらにrules:で囲む必要はありません。入力形式の詳細は該当項目の説明を確認してください。

rule-providersを使っている場合は、各providerのtype、behavior、format、url、path、更新間隔も移行します。相対パスのpathは新しいコアの作業ディレクトリに依存します。旧キャッシュディレクトリも一緒に移していない場合は、再ダウンロードできるようにしてください。「ルールファイルが存在しない」というエラーをノードの障害と取り違えないようにしましょう。

5. Parsersとオーバーライドスクリプトを新しいクライアント向けに書き換える

CFWのParsersはmihomo共通の設定仕様ではありません。どちらもJavaScriptを書ける場合でも、設定の受け取り方、戻り値、実行順序、利用可能なAPIが異なることがあります。旧スクリプトをそのまま新しいクライアントに貼り付けると、実行されない、サブスクリプションの更新に失敗する、正常に実行されても別の設定を上書きするといった問題が起きる可能性があります。

固定の変更は宣言型のオーバーライドに置き換える

ポート、モード、LANアクセスの設定など、値が固定されている項目は、まず新しいクライアントの設定画面や設定マージ機能を使います。以下は移行時に確認するキーの例です。サブスクリプションの設定全体をそのまま上書きするのは避けてください。

ローカル実行設定の例

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

mixed-port: 7890を設定すると、同じポートでHTTPとSOCKSのリクエストを受け付けます。ただし、クライアントが最終設定の生成時にポートを書き換える場合があります。変更後はオーバーライドファイルだけでなく、実際に使用されている設定も開いて確認してください。リストのマージ方法にも注意が必要です。rules配列全体を置き換える項目もあれば、先頭への追加や末尾への追加に対応する項目もあり、結果はまったく異なります。

スクリプトが必要な場合は、変換ロジックを1つずつ作り直す

まず、特定ノードの削除、プロキシグループの追加、DNSの変更など、旧スクリプトの目的を整理します。過去の不要な処理までまとめて引き継がないようにしましょう。
新しいクライアントのドキュメントに記載されたスクリプト機能を使って実装し、関数の引数、設定全体を返す方法、エラーの表示方法を確認します。
変更を一度に1つだけ移行します。実行後にノード数、プロキシグループのメンバー、ルールの順序を確認してから、次の変更に進みます。
サブスクリプションを手動で一度更新し、ローカルの変更が残っているか確認します。更新後も反映されて初めて、オーバーライドが正しく適用されていると判断できます。

旧Clashのコア向けスクリプト設定と、クライアントのJavaScriptによる前処理を混同しないでください。scriptなどの旧形式のキーがある場合は、現在のmihomoでサポートされているか確認し、明示的なルール、ルールセット、またはクライアントの前処理に置き換えることを検討してください。

6. ポート・DNS・TUNを個別に確認する

ブラウザーでアクセスできても、確認できたのはその経路が使えることだけです。コマンドラインツール、ゲーム、LAN内の機器、UDP通信では異なる経路を使う場合があります。移行後の確認は段階的に行い、変更する設定は一度に1つにしてください。

確認項目	操作	確認ポイント
ローカルポート	新しいクライアントの混合ポートが7890になっているか確認する。	ログにポート競合がないか、ターミナルのプロキシ環境変数が旧ポートを参照したままになっていないか。
プロキシを明示して接続	curlで127.0.0.1:7890を指定してリクエストを送信する。	接続履歴が記録され、適用されたルールと接続先が想定どおりか。
システムプロキシ	システムプロキシを有効にして、実際に利用するWebサイトにブラウザーからアクセスする。	アプリがシステムプロキシを使っているか、旧PAC設定の影響を受けていないか。
DNSとTUN	基本接続の確認後にTUNを有効にし、ドメイン、LAN、UDPを使うアプリを個別にテストする。	DNSの制御、ルーティングの競合、仮想インターフェースの権限、ローカルサービスへのアクセス。

Windows PowerShellでは、以下のコマンドでポートと明示的なHTTPプロキシを確認できます。旧バージョンのPowerShellではcurlが別名として定義され、引数の動作が異なる場合があるため、ここではcurl.exeを指定しています。テスト用URLは、確認したい実際のサービスに置き換えてください。

Windows PowerShell

Get-NetTCPConnection -LocalPort 7890 -State Listen
curl.exe --proxy http://127.0.0.1:7890 --head --max-time 15 https://example.com

HTTPプロキシを明示したリクエストが成功しても、UDPがTUN経由で処理されている証明にはなりません。TUNを有効にした後、UDPが必要なアプリを別途テストし、接続履歴も確認してください。DNSについては、旧設定でenhanced-mode: fake-ipを使っている場合、fake-ip-filterとローカルドメインの名前解決要件も確認します。社内ネットワークのドメインは社内DNSを必要とすることが多いため、すべてを一律にパブリックDNSへ任せないでください。

必要に応じてコアで設定を検証する

mihomoの実行ファイルを単体で用意できる場合は、設定ディレクトリから構文を検証できます。以下はWindowsで、現在のディレクトリにコアと設定ファイルがある場合の例です。クライアントが内部で生成した設定は、内蔵のチェック機能を優先して使ってください。

config.yamlを検証

.\mihomo.exe -t -d . -f .\config.yaml

-tは設定のテスト、-dは作業ディレクトリ、-fは設定ファイルの指定に使います。検証に通ってもノードに接続できるとは限りません。サブスクリプションの権限、リモートルールのダウンロード、実際のDNS動作も確認できないため、実行ログと合わせて調査してください。

7. 更新を確認してから旧クライアントを整理する

サブスクリプションの手動更新、PCの再起動、普段使うネットワークへの切り替えをそれぞれ一度は確認してください。再起動後は新しいクライアントだけが自動起動することを確認します。有線LANからWi-Fiに切り替えた後も、TUNのルートとLANへのアクセスをチェックしましょう。こうした確認は、1回の遅延テストより実際の利用状況に近い検証になります。

更新の確認：サブスクリプションを更新した後も、カスタムルール、プロキシグループ、DNSのオーバーライドが有効なままになっている。
アプリの確認：ブラウザー、ターミナル、開発ツール、LAN内のサービスを個別にテストする。Webページを1つ開くだけでは不十分です。
サービスの確認：旧クライアントのバックグラウンドサービス、起動時のタスク、システムプロキシ設定がネットワークを制御していない。
復元の準備：アクセス制限された場所に元のバックアップを保管し、新しいクライアントのバージョン、コアのバージョン、移行日を記録する。

新しい設定が安定してから、旧クライアントのサービス管理機能を使ってバックグラウンドサービスをアンインストールし、プログラムを整理します。移行に失敗して元に戻す場合は、新しいクライアントのTUNとシステムプロキシを無効にしてコアを終了してから、旧環境を復元してください。比較のために2つのクライアントを同時に起動しないでください。