Clashクライアントの更新停止後：mihomo対応クライアントへの移行先

更新停止の対象がクライアントかコアかを確認

旧クライアントの「バージョン情報」画面を開き、アプリ名、アプリのバージョン、コアのバージョンを記録してから、何を置き換えるか決めましょう。クライアントはサブスクリプションの読み込み、ノードの表示、サービスの起動を担う画面です。コアは設定を読み込み、ルールを照合してプロキシ接続を確立するプログラムです。両者は別のプロジェクトであり、更新状況も同じとは限りません。

2023年にClash関連のオリジナルプロジェクトが公開メンテナンスを終了しましたが、既存のインストーラーがその日を境に使えなくなるわけではありません。既存のノードに接続できる場合もありますが、新しいプロトコルへの対応、OS互換性の修正、今後の問題への対応が保証されるわけではありません。Clash for Windows、オリジナル版Clash for Android、mihomoは、名前が似ているだけで同じ更新系列と見なせません。

mihomoは、Clash.Metaプロジェクトを引き継いだプロキシコアです。以前のチュートリアルにある「Metaコア」は通常、この技術系列を指し、別のサブスクリプションサービスではありません。移行では、mihomoを実行でき、現在も更新されているクライアントを選び、サブスクリプションとローカル設定を分けて移します。

Androidとデスクトップ、それぞれの移行先

OSに合わせて候補を絞り、公式リリース情報、対応アーキテクチャ、コアに関する説明を確認しましょう。以下はmihomoエコシステムにおける移行候補であり、過去のインストーラーが今後もメンテナンスされることを保証するものではありません。プロジェクトの状況は変わるため、インストール時に直近のリリースや問題への対応状況を確認してください。ダウンロードファイルの更新日時だけで判断しないようにしましょう。

プラットフォーム	移行候補	インストール前の確認項目
Android	Clash Meta for Android、FlClash	Androidの最低要件、ARMアーキテクチャ、コアのバージョン、VPNの許可
Windows	Clash Verge Rev、Clash Nyanpasu、FlClash	システムアーキテクチャ、使用するコア、TUNサービスのインストール要件
macOS	Clash Verge Rev、FlClash、ClashX Meta	Apple Silicon／Intel向けインストーラー、ネットワーク権限、補助サービス
Linux	Clash Verge Rev、FlClash	ディストリビューションのパッケージ形式、デスクトップ環境、TUNの権限とサービスの実行方法

Android：設定を移してから通信を切り替える

オリジナル版Clash for Androidの設定、プロキシ、ログ画面に慣れている場合は、Clash Meta for Androidを検討できます。スマートフォンとPCで似た画面を使いたい場合は、FlClashも候補です。どちらもメニューやバックアップ形式、内蔵設定が完全に同じではないため、アプリのデータフォルダ全体をそのまま入れ替えないでください。

比較的新しいAndroidスマートフォンの多くはARM64ですが、発売年だけでは判断できません。ダウンロード案内で端末が対応するABI（アプリケーションバイナリインターフェース）を確認し、arm64-v8aに対応していることを確かめてからARM64版を選びましょう。Androidのバージョン要件も、各リリースの案内に従ってください。

デスクトップ：まずシステムプロキシで確認し、次にTUNを検討

WindowsやmacOSでは、まずサブスクリプションを読み込み、ノードを選んでシステムプロキシだけを有効にし、ブラウザーで動作を確認できます。Clash Nyanpasuなど、複数のコアを選べるクライアントでは、コア管理画面でmihomoが実行されていることも確認してください。クライアントのバージョン番号をコアのバージョン番号と混同しないようにしましょう。

TUNは端末のネットワーク通信を受け取る仮想ネットワークインターフェースです。システムプロキシだけを変更する場合より広い通信を扱えますが、ルーティング、DNS、システム権限に関わります。旧クライアントでシステムプロキシを問題なく使えていた場合は、移行後の最初の確認でも同じ方式を使い、変数を増やさないようにしましょう。

旧クライアントで事前にバックアップする4項目

サブスクリプションの取得元：元のサブスクリプションURL、更新間隔、プロバイダーからの案内を保存します。URLにはアカウントトークンが含まれることが多いため、公開メモやスクリーンショット、オンライン変換サイトに載せないでください。
設定ファイルのコピー：現在使えるYAMLファイルを書き出します。YAMLはインデントで階層を表すテキスト形式です。編集時はスペースによるインデントを維持し、タブを混在させないでください。
ローカルでの変更：カスタムルール、オーバーライド、スクリプト、DNS設定を記録します。クライアントによっては起動時にこれらを実行用設定へ統合するため、サブスクリプションのファイルだけをコピーすると取りこぼすことがあります。
システム設定：プロキシポート、LAN共有、アプリごとの通信振り分け、自動起動の設定を記録します。Androidのアプリ除外リストやデスクトップのシステムプロキシ設定は、通常、共通のサブスクリプションには含まれません。

旧画面に「実行中の設定を表示」があれば、比較用に保存しても構いません。ただし、新しいクライアントの作業ディレクトリ全体を上書きしないでください。実行用設定には一時パス、コントロールAPIのシークレット、展開済みのノードパスワードが含まれる場合があります。端末間で再利用しにくく、公開の場で相談する際にも適しません。

設定の移行：項目と名前の参照先を一つずつ確認

新しいクライアントのサブスクリプションまたは設定画面で、まず元のURLから設定を追加し、手動で一度更新します。ローカルファイルしかない場合は、「ファイルからインポート」などの項目を使います。具体的な名称はクライアントによって異なりますが、「サブスクリプションのソースファイル」と「アプリ設定のバックアップ」を区別してください。両者は互換性がありません。

プロキシ、プロキシグループ、ルールのつながりを確認

proxiesには設定ファイルに直接記述するノードを保存します。proxy-providersには外部ノードプロバイダーを設定します。後者を使う場合は、ダウンロード先にアクセスできることと、ローカルのキャッシュ保存先に書き込めることも確認してください。
proxy-groupsでは、手動選択グループなどのプロキシグループを定義します。グループ内で参照するノード名、他のグループ名、プロバイダー名が存在することを確認してください。大文字・小文字や空白も一致させる必要があります。
rulesは順番に接続先を照合します。先に書かれたルールから適用されるため、後続の照合が必要なルールより前に、範囲の広いMATCHルールを置かないでください。
rule-providersでは外部ルールセットを参照します。type、behavior、formatが実際のファイル内容に合っているか確認してください。ドメインリストを、そのまま完全なclassical形式のルールセットとして扱うことはできません。

「プロキシグループがありません」というエラーが出た場合は、まずエラーに表示された名前を確認してください。ノードをすぐに変更する必要はありません。クライアントのオーバーライドで「プロキシ」を「ノード選択」に変更しても、カスタムルールが古い名前を参照したままだと、設定の読み込みに失敗します。

ポートとコントロールAPIの設定を丸ごとコピーしない

mixed-portはHTTPとSOCKSの両方の接続を受け付けるローカルポートです。external-controllerは画面や管理ツールから操作するためのコントロールAPIで、プロキシポートではありません。以下はローカル設定の一例であり、サブスクリプション全体としては実行できません。

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

この例では7890を使っていますが、すべてのクライアントでこのポートが初期設定とは限りません。端末が以前127.0.0.1:7890に接続していて、新しいクライアントが7897で待ち受ける場合は、端末側の設定を変更するか、クライアントの設定画面からポートを変更してください。

旧ファイルのexternal-controller、secret、external-ui、絶対パスをそのままスマートフォンに移さないでください。新しいクライアントがコントロールAPIやリソースの保存先を管理している場合があります。また、待ち受けアドレスを0.0.0.0にすると、APIにアクセスできる範囲が広がるおそれがあります。明確な理由がなければ、アプリが管理するローカル設定を使いましょう。

DNS、TUN、旧スクリプトは分けて対応

DNS：まずは新しいクライアントの標準設定を使う

DNSはドメイン名をIPアドレスに変換する仕組みです。移行後に「ノードの遅延は正常なのに、Webページが開かない」場合、ノードのプロトコルが非対応とは限らず、名前解決の経路が変わった可能性もあります。まずは新しいクライアントの推奨DNS設定を使い、動作を確認してから、以前のカスタムDNSサーバーを一つずつ移行してください。

fake-ipは、合成IPアドレスを割り当てて通信の振り分けを補助するモードです。旧設定で198.18.0.1/16のようなアドレス範囲を使っている場合、それをノードの実IPアドレスと誤認しないでください。DNSモードを切り替えた後は、テスト接続をやり直します。必要に応じてアプリを再起動するか、システムのDNSキャッシュを消去し、古い結果が判断に影響しないようにしましょう。

TUN：スマートフォンとPCのルーティング設定を混用しない

Androidクライアントは通常、AndroidのVpnServiceを使って通信を受け取ります。初回接続時には、システムのVPN接続許可画面が表示されます。デスクトップでは補助サービスのインストールや管理者権限が必要な場合があります。どちらも通信を制御できますが、システムの許可方法、ルーティングの実装、利用できる設定は異なります。

tun.stack、auto-route、dns-hijackは、移行先のクライアントとOSに合わせて確認してください。旧PCの設定に特定の仮想ネットワークアダプター名が書かれていても、その名前をスマートフォンの設定に記述しないでください。Androidでは「設定」→「ネットワークとインターネット」→「VPN」で旧アプリの設定も確認します。メーカーによっては「接続と共有」に項目があります。

スクリプト：どの層で実行されるかを確認

旧設定のscript:、旧画面のJavaScriptオーバーライド、サードパーティのサブスクリプション変換テンプレートは、それぞれ異なる仕組みです。mihomoが旧Clash Premiumのスクリプトを実行するとは限りません。また、デスクトップクライアントのオーバーライドスクリプトをAndroidにそのままインポートできるとも限りません。まずスクリプトを無効にし、標準ルールで動作する状態を作ってから、必要な処理を移行先が明示的にサポートするルールやオーバーライドに置き換えてください。

5つの手順で移行結果を確認

設定の読み込みを確認：ログを開き、YAMLのインデントエラー、未対応のプロキシタイプ、プロキシグループが見つからないという警告がないか確認します。読み込みに失敗した場合は、最初のエラーから解決してください。後続のエラーは連鎖的に発生している可能性があります。
サブスクリプションの更新を確認：手動で一度更新し、ノード数とアカウントの有効期限を確認します。HTTP401または403が返った場合は、まずトークンとアクセス権を確認してください。プロキシポートの競合と混同しないようにしましょう。
ノードを個別に確認：プロキシグループでノードを1つ手動選択し、接続テストを実行します。遅延テストで確認できるのは指定されたテストリクエストの結果だけで、すべてのサイトやプロトコルが使えることを示すものではありません。
実際の振り分けを確認：Ruleモードにして、直接接続する想定の接続先とプロキシ経由の想定の接続先にそれぞれアクセスします。接続一覧で、適用されたルール、プロキシグループ、最終的に使われたノードを確認してください。
システム側の動作を確認：デスクトップではブラウザーとターミナルをそれぞれ確認します。Androidではブラウザーと対象アプリを確認し、画面ロック後に再度起動したときの接続状態も確認してください。

たとえば、デスクトップのローカルHTTPプロキシポートが7890であることを確認できたら、以下のコマンドでプロキシリクエストを個別にテストできます。このコマンドが影響するのはそのリクエストだけです。システムプロキシを有効にするものではなく、TUNのルーティングが正常に動作する証明にもなりません。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com/

接続タイムアウトは10秒、処理全体の上限は20秒です。これは問題を切り分けるための設定で、実測速度ではありません。ログにaddress already in useと表示された場合は、旧サービスがポートを使用していないか確認します。no such hostの場合は、該当ドメインの名前解決を優先して確認してください。context deadline exceededの場合は、接続先と接続段階も踏まえて判断し、サブスクリプションが無効だと決めつけないでください。

ロールバック手段を残し、サブスクリプション更新による上書きを防ぐ

最初の動作確認が終わったら、自動起動、バックグラウンド実行、カスタムルールを戻します。Androidでは「設定」→「アプリ」→対象クライアント→「バッテリー」でバックグラウンド制限を確認してください。項目名はOSによって異なります。「常時接続VPN」や「VPNを使用しない接続をブロック」を有効にしている場合は、新しいクライアントに設定されていることを確認してください。旧アプリを停止した後、端末全体がネットワークに接続できなくなるおそれがあります。

次回のサブスクリプション更新後に、カスタムルールが残っているか再確認してください。サブスクリプションから取得したYAMLを直接編集すると、更新時に上書きされることがよくあります。長期的に維持する変更は、クライアントが対応するオーバーライド、設定のマージ機能、または独立したルールプロバイダーに追加し、最終的な実行設定でルールの順序を確認してください。

旧設定と新設定は別々に保存し、ファイル名に日付を付けて混同を防ぎます。
互換性の問題を特定しやすいよう、クライアントのバージョン、mihomoコアのバージョン、再現手順を記録します。
相談する際は、サブスクリプショントークン、ノードのパスワード、コントロールAPIのシークレットを削除したログだけを共有してください。
旧環境に戻す場合は、まず新しいクライアントのシステムプロキシまたはVPNを無効にしてから、旧サービスを再開し、ルート設定が残らないようにします。

移行できたかどうかは、新しい画面が開くことでは判断できません。サブスクリプションを更新できる、ルールが適用される、対象アプリが接続できる、再起動や画面ロック後も想定どおりに動作することが基準です。まずこの最短の確認手順を完了してからDNS、TUN、複雑なオーバーライドを調整すると、問題を切り分けやすくなります。