移行ガイド 読了目安 12分

Clashクライアント終了後の移行方法：設定を引き継ぐ手順と代替ソフトの選び方

旧Clashクライアントから移行する前の準備、設定の引き継ぎ方、各プラットフォームの代替クライアントを解説します。

クライアント、コア、設定を切り分ける

Clashクライアントのメンテナンスが終了しても、既存のサブスクリプションやYAML設定まで同時に使えなくなるわけではありません。移行前に最も重要なのは、グラフィカルクライアント、プロキシコア、設定ファイル、サブスクリプションサービスを分けて理解することです。グラフィカルクライアントは設定の取得、プロキシグループの切り替え、システムプロキシの制御、接続ログの表示を担当します。コアはルールの解析、プロキシ接続の確立、DNSやTUNなどのネットワーク機能を処理します。設定ファイルには、ポート、ノード、プロキシグループ、ルール間の関係が保存されています。

旧デスクトップクライアントの中には初期のClashコアを使うものがあり、すでにClash Meta、つまり現在広く使われているMihomoコアへ移行したクライアントもあります。MihomoはClashの設定体系を引き継ぎながら、より多くのプロトコル、ルールセット、DNS、トラフィックの取り込み機能に対応しています。Mihomoクライアントへ移行する場合、通常は proxies、proxy-groups、rules、proxy-providers を引き続き利用できます。ただし、旧クライアント固有の画面設定、スクリプト、データベース、サービスのインストール状態は、共通設定としてそのままコピーできません。

したがって、移行の目的は旧プログラムのフォルダー全体を新しいプログラムへ移すことではありません。クライアント間で再利用できるデータだけを残し、新しいクライアントに実行環境を再構築させることが重要です。これにより、旧バージョンのキャッシュ、壊れたデータベース、ポートの競合、ドライバーの残骸による問題を避けられます。

移行前に保存しておくデータ

旧クライアントをアンインストールしてから設定を探すのは避けてください。設定がユーザーデータフォルダーに保存されている場合、アンインストール時にアプリデータまで削除されることがあります。まず旧クライアントを動作可能な状態に保ち、次のバックアップを完了してから新旧クライアントを切り替えます。

サブスクリプションURLと設定ファイル

設定をサブスクリプションから取得している場合は、まず元のサブスクリプションURLを記録し、現在も更新できることを確認します。クライアント一覧に表示される設定名はローカル上のラベルにすぎず、サブスクリプションURLの代わりにはなりません。サービス提供元が専用の変換リンクを用意している場合は、元のサブスクリプションと変換ルールの関係も記録しておきましょう。移行後に異なる形式の設定を取得する事態を防げます。

手作業で管理している設定は、ノード部分だけでなく完全なYAMLとしてエクスポートしてください。プロキシグループはノード名やProvider名を参照し、ルールはプロキシグループを参照します。proxies セクションだけを残すと、この参照関係が切れてしまいます。設定がローカルのルールセット、スクリプト、オーバーライドファイルを参照している場合は、対応するファイルも一緒にコピーしてください。

ローカルオーバーライドとカスタムルール

多くのクライアントには、サブスクリプション設定とは別にオーバーライド機能があります。DNSの強制変更、ルールの追加、リッスンポートの変更、LANアクセスの有効化などがその例です。これらの内容はクライアントのデータベースに保存され、サブスクリプションYAMLへ書き戻されないことがあります。移行前に「オーバーライド」「グローバル拡張」「設定のマージ」などの画面を一つずつ確認し、実際に適用されている設定を記録してください。

ルールの順序は必ず維持してください。Clashのルールは通常、上から順に照合され、最初に一致したルールで処理が止まります。カスタムの直接接続ルールを MATCH の後ろに追加すると、永遠に適用されません。移行時にルールの内容が完全に同じでも、マージ位置が変わればルーティング結果が変わる可能性があります。

ポート、LAN、外部コントローラー

旧クライアントで使用していた mixed-port、HTTPポート、SOCKSポート、LAN接続の許可設定、外部コントローラーのアドレスを記録します。ブラウザー拡張機能、ターミナルの環境変数、ダウンロードツール、その他のアプリが旧ポートを参照していることがあります。新クライアントがランダムなポートを割り当て、外部プログラムが旧ポートへ接続し続けると、「クライアントは正常なのに一部のソフトだけインターネットに接続できない」という状態になります。

external-controller とコントロールキーは、主にグラフィカルインターフェースや外部パネルから呼び出すためのものです。同じポートを使用している並行インスタンスへ、そのままコピーしないでください。新旧クライアントを同時に動かす場合も、同じプロキシポートをリッスンさせてはいけません。

機密情報の保存方法

サブスクリプションURLには、アカウント識別用のアクセスパラメーターが含まれていることがあります。完全なYAMLにも、サーバーアドレス、認証情報、コントロールキーが含まれる可能性があります。バックアップファイルは管理されたディレクトリに保存し、完全な内容を公開の質問掲示板、スクリーンショット、公開コードリポジトリへ貼り付けないでください。エラーを共有する場合は、フィールド構造を残したまま認証値を削除できます。

Clash設定を移行する手順

  1. 旧設定を更新してエクスポートする。旧クライアントでサブスクリプションを一度更新し、プロキシグループとノード一覧が正常に読み込まれることを確認してから、サブスクリプションURL、YAML、カスタムルールを保存します。
  2. 現在のネットワーク設定を記録する。プロキシポート、システムプロキシの状態、TUNの状態、DNSモード、LANスイッチを保存します。ターミナルにプロキシ環境変数を個別設定している場合は、その変数が使用するポートも記録してください。
  3. 旧クライアントのトラフィック取り込みを停止する。まずシステムプロキシとTUNを無効にしてから、旧クライアントを完全に終了します。ウィンドウを閉じただけではバックグラウンドのコアが停止しないことがあります。タスクマネージャーやシステムのアクティビティモニターでプロセスの終了を確認してください。
  4. 新クライアントをインストールして起動する。初回起動時はまずデフォルト設定を使い、旧クライアントのデータフォルダー全体をすぐにコピーしないでください。新クライアントのコアが正常に動作することを確認してから、設定をインポートします。
  5. まずサブスクリプションを追加し直す。サブスクリプションが有効なら、新クライアントでURLを再登録するほうが、キャッシュファイルをコピーするより確実です。手動設定はローカルファイルからインポートし、関連ファイルの相対パスを維持します。
  6. オーバーライドを再適用する。新クライアントが対応する形式で、DNS、ポート、カスタムルール、Providerを設定します。クライアントによってオーバーライド構文が互換とは限らないため、ファイル拡張子だけで判断しないでください。
  7. 通常のプロキシを確認してからTUNを有効にする。まずシステムプロキシでウェブサイトと接続ログを確認し、ノード、プロキシグループ、ルールが正常に動作することを確かめます。その後、TUNだけを有効にしてください。段階的に検証すると、問題が設定にあるのかトラフィックの取り込みにあるのかを特定しやすくなります。
  8. 安定してから旧クライアントを削除する。旧設定のバックアップはしばらく保管します。ただし、2つのクライアントに同時にシステムプロキシを変更させたり、デフォルトルートを取り込ませたりしないでください。

移行可能な基本設定には、通常、明確な参照関係があります。次の例では具体的なノードを省略し、Providerからノードを取得して、プロキシグループとルールから参照しています。

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

proxy-providers:
  provider-main:
    type: http
    url: "https://example.com/profile.yaml"
    path: ./providers/main.yaml
    interval: 86400
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 600

proxy-groups:
  - name: PROXY
    type: select
    use:
      - provider-main

rules:
  - DOMAIN-SUFFIX,example.net,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

インポート後に「Providerが存在しない」またはプロキシグループが空になる場合は、Provider名、ダウンロード状態、プロキシグループ内の use 参照を順番に確認します。ファイルパスが設定ファイルの場所を基準にしている場合、YAMLだけを移動してルールセットやProviderキャッシュを移動しないと、読み込みに失敗します。リモートProviderなら、新クライアントで再ダウンロードできるため、旧データベースから無理にコピーする必要はありません。

プラットフォーム別の代替クライアントの選び方

代替ソフトは、画面が似ているかどうかだけで選ぶべきではありません。実用的な判断基準は、継続的にメンテナンスされているか、どのコアを採用しているか、既存設定をインポートできるか、システムプロキシとTUNに対応しているか、ログがトラブル解決に役立つか、インストーラーがOSとプロセッサーアーキテクチャに合っているかです。Mihomoコアを採用したクライアントへ移行すれば、主要なClashルール構造を継続して使えることが多い一方、グラフィカルインターフェースの操作手順は異なります。

Windows

Windowsユーザーは、継続的にメンテナンスされ、Mihomoコアを明記し、サービスモードまたはTUN管理に対応したデスクトップクライアントを優先してください。通常のウェブサイトや大半のデスクトップソフトはシステムプロキシだけで利用できます。ゲーム、コマンドラインプログラム、システムプロキシを読み取らないアプリでのみ、TUNが必要になる場合があります。TUNの有効化には管理者権限、ネットワークアダプター、システムサービスが関係するため、先に通常のプロキシをテストしてください。

インストーラーのアーキテクチャも確認します。現代のパソコンの多くはx64ですが、Windows on ARMデバイスではarm64ビルドが必要になることがあります。移行中にシステムプロキシのスイッチを戻せない場合は、すべてのプロキシクライアントを終了し、Windowsのプロキシ設定で手動プロキシが旧ポートを参照していないか確認してください。

macOS

macOSの代替クライアントは、AppleシリコンまたはIntelプロセッサーに合わせて選びます。Appleシリコンでは通常arm64またはuniversalビルド、Intelデバイスではx64ビルドを選択します。初回起動時にネットワーク拡張、補助サービス、VPN構成の許可を求められることがあります。これらの許可はTUNによる取り込み処理に関するもので、YAML設定の一部ではありません。

旧クライアントから移行した後、メニューバーではプロキシが有効なのにアプリが直接接続する場合は、現在のネットワークサービスにシステムプロキシが正しく書き込まれているか確認します。macOSにはWi-Fi、有線ネットワーク、その他のネットワークサービスが同時に存在することがあります。クライアントが変更したサービスと、実際に使用しているサービスが異なると、プロキシが有効に見えてもトラフィックがコアを通らないことがあります。

Android

AndroidのClash系クライアントは、デスクトップのシステムプロキシではなく、通常システムVPNインターフェースを通じてトラフィックを取り込みます。移行時はサブスクリプションの再インポート、VPN接続の作成許可、アプリごとのプロキシ設定、バイパス設定、バックグラウンド動作に対するバッテリー制限を確認します。旧クライアントがエクスポートしたアプリ別振り分けリストを新クライアントが認識できない場合があるため、どのアプリをプロキシ経由にするか再選択してください。

端末に別のVPN、広告ブロッカー、仕事用プロファイルのネットワークが存在する場合、通常は複数の一般VPNインターフェースを同時に有効にできません。新クライアントをテストするときは、先に他のVPNサービスを停止してください。Androidのインストールパッケージはarm64-v8aなどのプロセッサーアーキテクチャにも合わせる必要があります。不明な場合は、クライアントが正式に提供する汎用ビルドを選べますが、ファイルサイズは通常大きくなります。

Linux

Linuxユーザーはグラフィカルクライアントを選ぶことも、Mihomoコアを直接実行してsystemdで管理することもできます。デスクトップ環境のシステムプロキシは、その設定に従うプログラムにしか影響しません。ターミナルツールでは http_proxy、https_proxy、all_proxy 環境変数が必要になる場合があります。TUNを使用する場合は、コアの権限、ルーティングテーブル、DNSの管理方法も確認してください。

グラフィカルクライアントからコマンドラインのコアへ移行する場合は、設定が参照する相対ディレクトリと作業ディレクトリを特に維持してください。同じYAMLでも起動ディレクトリが異なると、外部ルールファイルやProviderのパスが別の場所として解決されることがあります。設定、Provider、ルールセットを固定ディレクトリに置き、サービスの引数で設定パスを明示することをおすすめします。

iPhoneとiPad

iOSとiPadOSには、デスクトップ版やAndroid版のClashクライアントを直接インストールできません。プラットフォームで許可され、必要なプロトコルとルール形式に対応したネットワークツールを選び、そのインポート機能に合わせて設定を変換してください。Clash YAMLをすべてのiOSクライアントがそのまま読み込めるとは限りません。プロキシグループ、スクリプト、ルールセット、DNSフィールドは、対象アプリのドキュメントに合わせて調整が必要になる場合があります。移行前に、サブスクリプションサービスが対応形式を提供しているか確認するほうが、ノードを手作業でコピーするより確実です。

サブスクリプション、ルール、DNSの互換性を確認する

設定をインポートできても、それはYAML構文が通ったことを示すだけで、すべての接続が期待どおりにルーティングされるとは限りません。移行後は、サブスクリプション更新、ノード接続、プロキシグループの参照、ルールのヒット、DNS解決の5つを確認してください。

サブスクリプションの更新に失敗する

まず、エラーがダウンロード段階で発生したのか、解析段階で発生したのかを確認します。ダウンロードのタイムアウトは、ネットワーク、サブスクリプションURL、プロキシのループバックに関係することが多く、解析エラーは、返却内容がYAMLではない、サブスクリプション変換形式に誤りがある、現在のコアが認識できないフィールドを設定に含んでいる、といった原因が考えられます。クライアントが「プロキシ経由でサブスクリプションを更新」に対応していても、初回起動時の利用には注意が必要です。まだ動作するノードがないため、更新が依存関係のループになることがあります。

ルールセットを読み込めない

旧設定が rule-providers でリモートルールセットを参照している場合があります。移行後は、動作タイプ、形式、URL、保存先、ルール内の参照名を確認してください。ルールProviderの名前とプロキシグループの名前は別の概念であり、入れ替えて使うことはできません。GEOIPやGEOSITEなどのルールを使用する場合は、対応する地理データベースをクライアントがダウンロードして読み込めることも確認します。

DNSの動作が変わる

旧クライアントと新クライアントでは、デフォルトのDNS設定が異なる場合があります。fake-ip を有効にすると、コアはアプリに予約アドレスを返し、内部マッピングに基づいて実際の接続を処理します。redir-host では名前解決の経路が異なります。移行時は、旧設定を理解しないままDNSセクション全体をコピーしないでください。特に、リッスンアドレス、上流サーバー、フォールバックルール、Fake IPの除外リストを確認します。

ウェブページが時々開けない、LAN機器のドメイン名が解決できない、特定のアプリでログインに失敗するといった場合は、カスタムDNSのオーバーライドを一時的に無効にし、新クライアントのデフォルト値で再テストします。デフォルト設定で正常なら、旧設定を一項目ずつ戻してください。DNSフィールドを一度に複数変更すると、トラブル解決の比較対象がなくなります。

TUNモードの移行とよくあるトラブル

TUNモードは仮想ネットワークインターフェースを作成し、ルートやシステムのネットワーク拡張を通じて、より多くのトラフィックをコアに処理させます。システムプロキシに従わないアプリも対象にできますが、通常のシステムプロキシよりOSの権限に強く依存します。旧クライアントのTUNドライバー、サービス登録情報、ルーティング状態を新クライアントへコピーしてはいけません。

正しい手順は、まず旧クライアントでTUNを無効にし、完全に終了して仮想インターフェースが動作していないことを確認することです。その後、新クライアント自身の手順でサービスをインストールするか、権限を要求させます。新旧クライアントで同時にTUNを有効にすると、デフォルトルートの競合、DNSの繰り返し変更、ネットワークループ、通信断が発生する可能性があります。

TUNを有効にすると完全にインターネットへ接続できない

  • 現在のプロキシグループで利用可能なノードが選択されているか、最終ルールが存在するプロキシグループを参照しているか確認します。
  • システム上で他のVPN、プロキシツール、ネットワークフィルタープログラムがルートを占有していないか確認します。
  • クライアントのサービスに必要な権限があり、仮想インターフェースの作成時にエラーが出ていないことを確認します。
  • カスタムDNSと複雑なルーティング設定を一時的に無効にし、クライアントのデフォルトTUN設定でテストします。
  • TUNを無効にした状態で通常のシステムプロキシが動作することを確認し、ノードの問題とトラフィック取り込みの問題を切り分けます。

ブラウザーは正常だがターミナルが失敗する

これは通常、ブラウザーがシステムプロキシを使用している一方、ターミナルプログラムがシステムプロキシを読み取っていないことを示します。ターミナルツールから新クライアントのHTTPまたはSOCKSポートへ明示的に接続するか、正しく設定したTUNを有効にしてください。移行後は環境変数に残った旧ポートも更新します。グラフィカルクライアントでリッスンポートを変更しても、shellの設定ファイルは自動的に変更されません。

クライアントを終了してもプロキシ表示が残る

クライアントが異常終了すると、システムプロキシが元に戻らないことがあります。まずOSのネットワーク設定で手動プロキシを無効にしてから、新クライアントを再起動してください。複数の旧クライアントを何度も起動してシステムプロキシの状態を奪い合わせるのは避けましょう。現在の設定がさらに分かりにくくなります。TUNサービスがバックグラウンドで動作している場合は、新クライアントのサービス管理機能で停止し、必要に応じて一時的なルートを消去するためにシステムを再起動します。

移行完了後の確認リスト

移行完了の判断を「ウェブページが開く」だけにしないでください。完全な検証には、少なくとも次の項目を含めます。

  • サブスクリプションを手動更新でき、更新後もカスタムルールが失われない。
  • プロキシグループに想定したノードが表示され、自動速度テストやヘルスチェックを実行できる。
  • 種類の異なるサイトへアクセスした際、接続ログで想定したルールとプロキシが適用されている。
  • システムプロキシを無効にするとトラフィックが直接接続に戻り、有効にするとポートがクライアント設定と一致する。
  • TUNを有効・無効にしても異常なルートが残らず、LANアクセスが設定どおりに動作する。
  • ターミナル、ブラウザー、プロキシを必要とする独立アプリがすべて正しいポートを使用する。
  • OSを再起動した後もクライアントが想定どおり起動し、設定と権限が有効なままである。
  • 旧クライアントが終了し、自動起動やシステムプロキシの変更を行わない。

動作が安定したことを確認してから旧クライアントをアンインストールし、整理した設定バックアップを1つ保管します。バックアップには作成日、対象コア、依存ファイルを記載し、数か月後に出所が分からなくならないようにしてください。サブスクリプション設定はクライアントから定期的に更新し、ローカルのカスタムルールは別途保存すると、サブスクリプションによる上書きで失われるリスクを減らせます。

クライアント移行の要点は、より多くのファイルをコピーすることではなく、どのデータが汎用的なClash設定で、どの状態が旧プログラム固有なのかを明確にすることです。サブスクリプションとルールを先にバックアップし、システムプロキシ、DNS、TUNを段階的に検証すれば、終了したクライアントからの切り替えリスクを特定可能な範囲に抑えられます。

Clashをダウンロード