移行ガイド 読了目安 13分

Clashクライアント終了後の移行方法：設定のエクスポート、代替クライアントとサブスクリプションの切り替え

クライアントのサポート終了に備え、設定とサブスクリプションを保存し、対応プラットフォーム別に代替クライアントを選択。移行後はルールとDNSを確認し、切り替え中の直接接続を防ぎます。

移行対象はインストーラーだけではない

Clashクライアントのサポート終了後に移行すべきなのは、サブスクリプションの入口、ローカル設定、ポリシー選択、システムプロキシの状態です。古いプログラム自体をそのままコピーしても、通常はメリットがありません。Clash for Windowsを例にすると、プロジェクトの更新停止後も既存バージョンは一時的に動作する可能性がありますが、カーネル、プロトコル実装、システム互換性、セキュリティ修正は更新されません。OSのアップデート、サブスクリプション形式の変更、証明書ポリシーの調整によって、正常だった設定が突然使えなくなることもあります。

移行前に「クライアント」と「カーネル」を区別しましょう。クライアントは設定管理、トレイメニュー、システムプロキシ、ログ、画面を担当し、カーネルはポートの待ち受け、ルールの解析、プロキシ接続の確立を担当します。新しいクライアントの多くはmihomoカーネルを採用しており、Clash Metaの機能を引き継ぎながら、より多くのプロキシプロトコル、ルールセット、トラフィック解析、充実したTUN設定に対応しています。古いクライアントのクラシックClash設定は、多くの場合mihomoへインポートできますが、逆方向の互換性は保証されません。

移行の基本方針

まずサブスクリプションURLと現在のYAMLを保存し、新しいクライアントをインストールしてオフラインで確認します。新しいクライアントがシステムプロキシまたはTUNを引き継げることを確認してから、最後に古いクライアントを終了します。同じポートを2つのカーネルで同時に待ち受けさせないでください。

保存しておくべき4種類の情報

ノード名だけをコピーするのでは不十分です。ノードはサブスクリプションから再生成できますが、手書きルール、オーバーライドスクリプト、プロキシグループの選択、DNSの除外項目は通常クライアント内に保存されています。移行後に「ノードの速度テストは成功するのにWebページが開かない」場合、こうしたローカル設定が同期されていないことがよくあります。

サブスクリプションと設定のエクスポート：古いクライアントを開ける場合の手順

手順1：サブスクリプションの取得元と更新日時を記録する

古いクライアントの設定またはProfilesページを開き、設定名、サブスクリプションURL、最終更新日時、自動更新間隔を1件ずつ記録します。画面に「サブスクリプションリンクをコピー」「設定を編集」「フォルダーを表示」などの入口があれば、そちらを優先してください。ログからリンクを抜き出すのは避けましょう。ログではトークンが省略されていたり、リダイレクト後の一時URLが表示されたりする場合があります。

移行記録はローカルのテキストファイルにまとめるのがおすすめです。最低限、次の項目を含めてください。トークン部分をクラウドストレージの公開フォルダー、コードリポジトリ、スクリーンショット共有サイトにアップロードしないでください。

設定名：日常用ルール
サブスクリプションの取得元：https://example.invalid/api/v1/client/subscribe?token=非表示
旧クライアントの更新間隔：1440 分
モード：rule
混合ポート：7890
外部コントロールポート：9090
よく使うポリシー：ノード選択 → 自動選択
ローカルオーバーライド：dns.yaml、rules.yaml

手順2：現在有効なYAMLをエクスポートする

古いクライアントで「設定を編集」「設定ファイルを表示」「設定フォルダーを開く」のいずれかを探し、現在有効なYAMLをコピーします。Windowsの一部の古いClashクライアントはユーザーフォルダー内の .config/clash にデータを保存します。macOSとLinuxの古いツールでも ~/.config/clash がよく使われます。ただし、派生版によってはアプリデータフォルダーを使うため、画面の「フォルダーを開く」で表示された場所を基準にしてください。固定パスだけを頼りに検索するのは避けましょう。

バックアップではメイン設定だけでなく、メインファイルが参照する他のリソースも確認します。次の項目がある場合、外部ファイルまたはリモートコンテンツに依存しています。

手順3：実行キャッシュではなくオーバーライド内容を保存する

GeoIPデータベース、ルールセットのキャッシュ、サブスクリプションキャッシュ、実行ログは新しいクライアントで再ダウンロードできます。本当に保存すべきなのは、ユーザーが編集したオーバーライドファイルです。古いクライアントに「グローバル拡張設定」「Mixin」「前処理」「オーバーライド」「スクリプト」機能がある場合は、内容を項目ごとにそのままコピーし、メイン設定の前後どちらで実行されるかも記録します。実行順が違えば、最終的な dns、rules、proxy-groups の結果も変わります。

サポートが継続しているクライアントをプラットフォーム別に選ぶ

代替クライアントを選ぶときは、画面だけを比較しないでください。OSのバージョン、カーネルの種類、設定のインポート方法、TUN権限の手順、更新経路を先に確認します。既存のClash設定を持つユーザーは、mihomoカーネルを採用し、URLとローカルYAMLをインポートでき、実際の実行設定を確認できるクライアントを選ぶと、移行コストを抑えやすくなります。

プラットフォーム 移行時の重点項目 選定時の確認事項
Windows システムプロキシ、サービスモード、TUNドライバー 古いプロキシを解除できるか、mihomoに対応しているか、実行ログを確認できるか
macOS ネットワーク拡張、管理者権限、キーチェーンの確認 OSのバージョン要件、TUNの許可手順、終了時にプロキシを元へ戻すか
Android VPN権限、バッテリー最適化、バックグラウンド維持 ローカル設定、アプリ別の振り分け、VPN常時接続に対応しているか
Linux デスクトッププロキシ、権限、透過プロキシ ディストリビューションのアーキテクチャ、カーネル権限、トレイと自動起動の方式

FlClashはWindows、macOS、Linux、Androidでの移行先として利用できます。サブスクリプション設定、ローカル設定、システムプロキシ、TUN関連の入口を備えており、古いClash設定をmihomo実行環境へ移行するのに適しています。インストール前に、ダウンロードページに記載されたOSとアーキテクチャを確認してください。たとえばWindowsのx64、Linuxのx64またはarm64などです。アーキテクチャの不一致を設定エラーと誤認しないようにしましょう。

2つのクライアントに同時にネットワークを制御させない

古いクライアントと新しいクライアントを同時に起動した場合、最もよくある衝突はポートの占有です。多くのClash設定では、HTTP、SOCKS、混合ポートに 7890 を使い、外部コントローラーには 9090 を使います。古いカーネルがまだ待ち受けていると、新しいカーネルのログに address already in use やバインド失敗が表示されます。

  1. 古いクライアントでシステムプロキシとTUNを無効にします。
  2. 古いクライアントを完全に終了し、トレイアイコンが消えたことを確認します。
  3. Windowsではターミナルで netstat -ano | findstr :7890 を実行してポートを確認できます。
  4. macOSとLinuxでは lsof -i :7890 を実行して使用中のプロセスを確認できます。
  5. ポートが解放されたことを確認してから、新しいクライアントを起動します。

短時間だけ設定を並行比較する必要がある場合は、新しいクライアントの混合ポートを一時的に 7891 へ変更できます。ただし、システムプロキシやTUNを2つ同時に有効にしないでください。テスト後はポートを統一し、ブラウザー、ターミナル、開発ツールが別々のカーネルを参照しないようにします。

FlClashへインポート：サブスクリプションを優先し、ローカルYAMLを予備にする

サブスクリプションURLからインポートする

FlClashを起動して「設定」ページを開き、URLから設定を追加して、保存したサブスクリプションURLを貼り付けて更新します。インポート後すぐにシステムプロキシを有効にせず、ノード、プロキシグループ、ルールが生成されているかを確認してください。正常なサブスクリプションには、少なくともプロキシノード、1つ以上のポリシーグループ、ルール一覧が表示されます。ノードしかなくルールがない場合、完全なClash設定ではなくノード用サブスクリプションの可能性があります。

自動更新間隔は、サブスクリプションサービスの変更頻度に合わせて設定します。日常利用では 1440 分、つまり1日1回がおすすめです。ノードの変更が多い場合は 360 分に設定できます。間隔が短すぎるとリクエスト回数が増え、サービス側の頻度制限にかかる可能性があります。移行当日はまず手動更新を行い、返された内容が有効であることを確認してから自動更新を有効にしてください。

ローカルYAMLをインポートする

元のサブスクリプションURLがすでに無効でも、古いクライアントに現在の設定が表示される場合は、バックアップしたYAMLを先にインポートできます。ただし、ローカルYAMLに保存されているのはエクスポート時点のノードとルールのスナップショットであり、サービス側の後続変更は自動取得できません。ネットワークが復旧したら、できるだけ早く有効なサブスクリプションへ置き換えるか、ノードとルールを管理下の設定へ移してください。

インポート前に、mihomoの設定チェックコマンドで構文を検証できます。システムに単独のmihomo実行ファイルがある場合は、ターミナルで次を実行します。

mihomo -t -f ./config.yaml

チェックに通ったことは、YAMLを解析できることを示すだけで、すべてのリモートルールセット、ノードアドレス、DNSサーバーにアクセスできるとは限りません。インデントエラーが出た場合は、YAMLでTabではなくスペースを使っているか確認します。重複キーのエラーが出た場合は、設定のマージ時に同じ階層の dns または rules が2つ存在しないか確認してください。

パラメーターの参照先を確認する

インポート後、「設定」→「パラメーター設定」を開き、動作モード、混合ポート、LANアクセス、外部コントロールを確認します。設定ページはサブスクリプションの内容を管理し、パラメーター設定はクライアントの動作方式を管理します。両者を混同しないでください。設定ファイルに mixed-port: 7890 と明記されていて、画面側に別のポートが設定されている場合は、クライアントが最終的に生成した実行設定とログを基準にします。

初回起動時のおすすめ設定

まずはルールモードを使い、TUNを無効にしたままシステムプロキシだけを有効にして、基本的な接続をテストします。HTTPとHTTPSの通信が正常であることを確認してから、TUN、アプリ別プロキシ、LANアクセスを設定します。これにより、サブスクリプションの問題と仮想ネットワークアダプターの問題を切り分けられます。

移行後に必ず確認するルール、DNS、TUN

ルールの順序が維持されているか

Clashのルールは上から順に照合され、マッチすると検索を停止します。移行時にすべてのルールが残っていても、順序が変われば結果は異なります。最終的なルールで、LANとダイレクト接続のドメインが先に処理され、その後にサービス用ルールとプロキシルールが続き、最後にフォールバック項目があることを確認してください。典型的な構成は次のとおりです。

rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN-KEYWORD,streaming,メディアポリシー
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

MATCH は最後に置く必要があります。前に配置すると、後続のルールは決して適用されません。移行後は、プロキシグループ名がルールの3番目の項目と完全に一致しているかも確認します。スペース、大文字・小文字、日本語文字も含めて一致が必要です。ルールが「ノード選択」を指しているのに、プロキシグループが「プロキシ選択」に変更されていると、カーネルはポリシーが見つからないと報告します。

DNSが従来の動作モードを維持しているか

mihomoでよく使われるDNS拡張モードには fake-ip と redir-host があります。古いクライアントが fake-ip を使用していた場合、評価なしに新しいクライアントでモードを切り替えないでください。代表的なFake IPアドレスプールは 198.18.0.1/16 です。このネットワークはベンチマーク用であり、実際のパブリックアドレスとして扱うものではありません。ドメインが 198.18.x.x に解決されても、DNS障害とは限りません。

次の項目を重点的に確認します。

移行後、プロキシノードのドメインだけ名前解決に失敗する場合は、まず proxy-server-nameserver を確認します。この項目はプロキシサーバー自身のドメインを解決するためのもので、まだ確立していないプロキシ接続に依存すると、名前解決のループが発生する可能性があります。テスト時はログで DNS、lookup、timeout、ノードのドメインを検索してください。

TUNモードは段階的に有効にする

TUNは、OSのプロキシ設定を読み取らないアプリを含め、システムプロキシより多くの通信を引き継ぎます。Windowsで初めて有効にする際は、管理者権限と仮想ネットワークアダプターのコンポーネントが必要になる場合があります。macOSではネットワーク拡張の許可、AndroidではVPN接続の許可が表示されます。移行時は、まず通常のシステムプロキシが使えることを確認してからTUNを有効にしてください。

有効化後は auto-route、strict-route、DNSハイジャック、インターフェース選択を確認します。LAN機器にアクセスできない場合は、プライベートネットワークが誤ってプロキシへ送られていないか確認します。代表的なプライベートアドレスは 10.0.0.0/8、172.16.0.0/12、192.168.0.0/16 です。企業VPNとTUNを同時に動かすとデフォルトルートを奪い合うこともあるため、組織のネットワーク要件に応じて対象ネットワークをダイレクト接続として残してください。

シームレスな切り替えの検証チェックリスト

「インポート成功」は、クライアントが設定を受け付けたことを示すだけです。移行を完了するには、システムプロキシ、ルールのマッチ、DNS、サブスクリプション更新、終了後の復元を検証する必要があります。次の順番で、各手順を通過してから次へ進むことをおすすめします。

  1. カーネルの起動：ログにポート占有、YAML解析失敗、ルールグループ欠落がない。
  2. ノードテスト：遅延が安定したノードを1つ選び、TCPまたはURLテストを行う。遅延値はテスト先に到達できることを示すだけで、すべてのWebサイトにアクセスできることを意味しない。
  3. システムプロキシ：システムプロキシを有効にし、ブラウザーの通信が接続記録に表示されることを確認する。
  4. ルールのマッチ：ダイレクト接続対象とプロキシ対象へそれぞれアクセスし、ログのポリシーグループ名が想定どおりか確認する。
  5. DNSチェック：名前解決のタイムアウトが継続しておらず、LANドメインとよく使うサイトの両方を解決できることを確認する。
  6. サブスクリプション更新：1回手動更新し、所要時間と応答状態を記録して、空の内容で設定が上書きされないことを確認する。
  7. TUNテスト：システムプロキシが正常になってからTUNを有効にし、システムプロキシを読み取らないアプリをテストする。
  8. 終了後の復元：新しいクライアントを終了し、OSのプロキシ設定が復元され、ブラウザーが停止済みの 127.0.0.1:7890 を参照しなくなったことを確認する。

切り替え中に通信のバイパスを防ぐ

作業環境で外部通信をすべてプロキシ経由にする必要がある場合、移行時に「クイック切り替え」に任せないでください。保護が必要な業務アプリを先に切断するか、一時的にネットワークを無効にし、新しいクライアントで設定を読み込んでシステムプロキシまたはTUNを有効にしてから接続を戻します。ブラウザーの既存の長時間接続、ダウンロード、インスタントメッセージ接続は、プロキシを切り替えても必ず再確立されるとは限りません。関連アプリを手動で再起動してください。

AndroidではシステムVPN設定で「VPNを常時オンにする」と「VPNなしの接続をブロック」を確認できます。項目名は端末メーカーによって異なります。WindowsとmacOSでは、古いクライアントの終了後に手動プロキシが残っていないか確認してください。システムプロキシが 127.0.0.1 を指したまま対応ポートを待ち受けるプロセスがない場合、通常はすべてのブラウザーページが開けなくなります。

よくある移行トラブルと対処法

サブスクリプション更新は成功したが、ノード一覧が空になる

まず、サブスクリプションの応答が完全なClash YAMLか確認します。サービスによってはUser-Agentに応じて形式を変えたり、ログインページ、エラーJSON、ノードリンクだけのテキストを返したりします。新しいクライアントのサブスクリプション設定で互換性のあるリクエスト方式を試してください。サービスが専用User-Agentを要求している場合は、案内に従って設定します。WebページのアカウントセンターURLをサブスクリプションURLとして使わないでください。

ノードは利用できるが、すべての通信がダイレクト接続になる

動作モードが direct になっていないことを確認し、「設定」→「パラメーター設定」でルールモードになっているか確認します。続いてルールの末尾に MATCH が存在するか、そのルールが指すプロキシグループで DIRECT が選択されていないかを確認します。設定によってはポリシーグループの状態を記憶しますが、新しいクライアントの初回インポートではグループ内の先頭項目が使われるため、両者が異なる場合があります。

Webページは開くが、コマンドラインツールがプロキシを通らない

システムプロキシの影響を受けるのは、主にOS設定に従うプログラムです。コマンドラインツールでは HTTP_PROXY、HTTPS_PROXY、ALL_PROXY を明示的に設定するか、TUNで通信を引き継ぐ必要があります。混合ポートが 7890 の場合、一時的なテストにはプロキシアドレス http://127.0.0.1:7890 を設定できます。テスト後はターミナルの環境変数を削除し、クライアント終了後も無効なポートを参照し続けないようにしてください。

TUNを有効にするとLAN機器に接続できない

まずTUNを無効にして、問題がルーティングの引き継ぎによるものか確認します。次に接続記録で、プリンター、NAS、ルーターのアドレスに適用されたポリシーを確認してください。プライベートネットワークは通常ダイレクト接続にしますが、企業ネットワークでは別のアドレス範囲を使う場合があります。TUN設定をすべて削除するのではなく、実際のネットワークに合わせてダイレクト接続ルールを追加し、厳格ルーティングと他のVPNが衝突していないか確認してください。

移行後、古いクライアントを削除してもよいか

サブスクリプション更新、システム再起動、TUNテストをそれぞれ少なくとも1回完了してから、古いクライアントをアンインストールするのが安全です。アンインストール前にYAMLとサブスクリプションの記録を保存します。ただし、古いクライアントの自動起動は無効にしてください。Windowsでは「設定」→「アプリ」→「スタートアップ」でスタートアップ項目を確認できます。macOSでは「システム設定」→「一般」→「ログイン項目と機能拡張」で、古いプログラムのバックグラウンド実行が許可されていないか確認します。

実行しやすい移行手順

設定がシンプルなら、移行全体は約20〜40分で完了します。カスタムルールセット、企業VPN、TUNを含む環境では、別途テスト時間を確保してください。次の順番で操作すると、ロールバックの負担を減らせます。

  1. 古いクライアントでサブスクリプションURLをコピーし、現在のYAMLとすべてのオーバーライドファイルをエクスポートする。
  2. モード、ポート、ポリシーグループの選択、DNSモード、TUNのオン・オフを記録する。
  3. システムとアーキテクチャに合った新しいクライアントをダウンロードし、自動起動は一時的に無効にする。
  4. 古いクライアントのシステムプロキシとTUNを無効にし、古いプロセスを完全に終了する。
  5. FlClashにサブスクリプションURLをインポートし、URLが無効な場合にだけローカルYAMLをインポートする。
  6. プロキシグループ、ルール数、DNS項目、リモートルールセットの状態を確認する。
  7. まずシステムプロキシを有効にしてブラウザーとルールのマッチを確認し、その後TUNを有効にする。
  8. サブスクリプションを手動更新し、システムを再起動してもう一度テストする。
  9. 古いクライアントの自動起動を無効にし、新しいクライアントが安定してから古いプログラムをアンインストールする。

移行の核心は、古いフォルダーを新しいフォルダーへ移すことではありません。検証可能な設定経路を再構築することです。サブスクリプションを更新でき、YAMLをmihomoが解析でき、ルールが存在するポリシーグループを指し、DNSがノードと対象ドメインを解決し、システムプロキシとTUNを1つのクライアントだけが管理する状態にします。項目ごとに確認すれば、クライアントのサポート終了によってすべてのルールを作り直したり、既存のサブスクリプション利用を中断したりする必要はありません。

FlClash ダウンロード 各プラットフォームのクライアントを見る