クライアント選定 読了目安 13分

Clash for Windows終了後の移行方法：代替クライアントと設定移行の手順

継続利用できるクライアントを整理し、サブスクリプション、上書きルール、システムプロキシ設定の移行方法と、切り替え前後の確認項目を解説します。

サポート終了の影響と移行範囲

Clash for Windowsのメンテナンス終了後も、既存のインストールがすぐに使えなくなるわけではありません。ローカル設定、ダウンロード済みのサブスクリプション、プロキシルールは引き続き動作する可能性があります。ただし、クライアントはOSの変更に継続対応せず、新しいmihomoカーネルのフィールド、TUN実装、セキュリティ修正にも追随しません。旧バージョンを使い続けた場合に起きやすいのは「ノードが突然すべて無効になる」ことではなく、サブスクリプション形式の更新を完全に読み込めない、システムプロキシの状態を正しく復元できない、TUNサービスが新しいOSと競合する、新しいルールフィールドが旧カーネルで無視される、といった問題です。

移行時は、3種類のデータを分けて考える必要があります。1つ目はサブスクリプションの入口で、サブスクリプションURL、リモート設定の更新日時、設定名が含まれます。2つ目はユーザーによる変更で、カスタムルール、上書きフィールド、スクリプト処理、プロキシグループの選択などです。3つ目はデバイスの制御状態で、システムプロキシ、起動時の自動起動、LANアクセス、TUNサービス、DNS設定が該当します。YAMLファイルを1つコピーするだけでは、通常この3種類をすべて移行できません。

日常の設定がすべてサブスクリプション由来であれば、移行の中心はサブスクリプションを再インポートし、新しいクライアントでプロキシグループの選択を復元することです。Clash for WindowsでMixin、Parsers、Scriptを使っていたり、設定を手動編集していたりする場合は、それらの変更を個別に記録してください。グラフィカルクライアントによって上書き機能の名称や形式は異なり、旧クライアントのJavaScriptパーサーを汎用設定としてそのまま扱うこともできません。

移行前にサブスクリプションとローカル変更をバックアップする

サブスクリプションの入口を記録する

Clash for WindowsのProfilesページを開き、使用中のものがリモートサブスクリプションかローカル設定かを確認します。リモートサブスクリプションの場合は、クライアントのキャッシュから生成されたYAMLだけでなく、元のサブスクリプションURLを保存してください。元のURLがあれば、新しいクライアントで最新のノード、プロキシグループ、ルールを再取得できます。キャッシュファイルは特定の更新時点の内容しか反映せず、その後にリモートルールセットのパスが変わると読み込みに失敗することもあります。

サブスクリプションURLにはアカウント識別用のパラメータが含まれることが多いため、パスワードと同じように扱ってください。URLを公開スクリーンショット、問い合わせ、公開コードリポジトリに記載しないでください。サービス提供元がサブスクリプションリンクの再発行に対応している場合、URLが漏えいしたときは先に再発行し、新しいURLを新クライアントにインポートします。

ローカル設定を書き出す

手動管理しているYAMLの場合は、クライアントから設定ファイルの保存先フォルダーを開き、使用中のメイン設定と参照ファイルを別のフォルダーにコピーします。プロキシプロバイダー、ルールプロバイダー、ローカルルールセット、証明書関連ファイルもあわせて確認してください。メイン設定の相対パスは元のフォルダー構成に依存します。ファイルを移動した後も階層を維持するか、新しいクライアントでパスを指定し直してください。

設定内で特に個別に記録しておきたいフィールドは次のとおりです。

  • mode：現在使用しているルールモード、グローバルモード、ダイレクトモードのいずれか。
  • proxies と proxy-providers：手動ノードとリモートノードプロバイダー。
  • proxy-groups：プロキシグループの名前、種類、参照関係、ヘルスチェック用URL。
  • rules と rule-providers：カスタムルールの順序と外部ルールセット。
  • dns：DNSの有効・無効、動作モード、上流サーバー、除外範囲。
  • tun：仮想NIC、自動ルーティング、DNSハイジャック、インターフェースの選択。

サブスクリプションから設定をインポートしているだけなら、生成されたYAMLを長期的に直接編集することはおすすめしません。次回の更新で変更内容が上書きされる可能性があります。新しいクライアントへの移行後は、クライアントが提供する上書き、拡張スクリプト、設定マージ機能を優先してユーザー変更を保存し、サブスクリプション更新のたびにその処理が再実行されることを確認してください。

移行記録を作成する

旧クライアントを終了する前に、現在選択しているプロキシグループのノード、システムプロキシのポート、LAN接続の許可状態、TUNの有効・無効、プロキシを利用するアプリを記録します。プロキシグループの選択は通常、クライアント独自のデータベースやキャッシュに保存され、サブスクリプションYAMLへ書き戻されるとは限りません。グループ名とノード名が完全に同じでも、新しいクライアントの初回読み込み時にグループ内の先頭項目へ戻ることがあるため、手動で再選択する必要があります。

代替クライアントの選び方

代替クライアントを選ぶときは、画面だけを比較すべきではありません。カーネル、対応プラットフォーム、設定の互換性、トラフィックの制御方式がより重要です。現在も継続的に更新されているクライアントの多くはmihomoをコアとして採用しています。mihomoはClashの設定体系を引き継ぎ、ルールセット、DNS、トラフィックのスニッフィング、TUNなどの機能を追加しています。クライアントは設定管理とシステム統合を担当し、カーネルは設定の解析、接続の確立、ルールの実行を担当します。

クライアントの方向性 適した環境 移行時の重点項目
Clash Verge Rev Windows、macOS、Linuxのデスクトップ端末 サブスクリプション管理、システムプロキシ、mihomo TUNに適しています。旧Mixinは、新しいクライアントがサポートする上書き方式へ書き換える必要があります。
Mihomo Party デスクトップGUIと設定管理が必要な端末 まずインストーラーのアーキテクチャを確認し、そのクライアントの設定拡張機構に合わせてローカル変更を移行します。
Clash Nyanpasu クロスプラットフォームのデスクトップクライアントを必要とするユーザー 使用中のバージョンのカーネル、サブスクリプション更新方式、TUN権限に関する表示を確認します。
FlClash デスクトップおよび一部のモバイル端末環境 従来と近い操作手順を維持したいユーザーに適しています。インポート後もルールモードとDNSを確認してください。
コマンドライン版mihomo サーバー、ルーター、または自分で管理するサービス環境 設定パス、起動パラメータ、ログ、更新、システムサービスを手動で管理する必要があります。

Windowsユーザーは通常、インストーラーがx64、ARM64など端末のアーキテクチャに合っているか確認する必要があります。macOSではAppleシリコンとIntelプロセッサーを区別してください。Linuxユーザーはアーキテクチャに加えて、デスクトップ環境、パッケージ形式、システムサービスの権限も確認します。クライアントが起動できることは第一歩にすぎません。システムプロキシの切り替え、TUNドライバーやサービスの正しいインストールができて初めて、トラフィックを安定して制御できます。

元の設定にmihomo専用フィールドが含まれている場合は、mihomoカーネルの使用を明記し、継続的に更新されているクライアントを選んでください。設定が基本的なポート、通常のノード、プロキシグループ、ルールだけで構成されているなら、Clash設定に対応する多くのクライアントで読み込めます。一方、GUIクライアント独自の上書きデータベース、画面設定、ショートカット設定はYAML標準には含まれないため、通常はクライアント間で直接コピーできません。

Clash for Windowsから新しいクライアントへ移行する

ステップ1：旧クライアントのトラフィック制御を解除する

  1. Clash for WindowsでSystem Proxyを無効にします。
  2. TUN Modeを有効にしている場合は、先にTUNを無効にし、ネットワークインターフェースが復旧するまで待ちます。
  3. クライアントを終了し、バックグラウンドプロセスが終了していることを確認します。
  4. OSのプロキシ設定を確認し、旧ポートを指す手動プロキシが残っていないことを確認します。

この手順は、ポート競合と二重ルーティングを防ぐためのものです。2つのクライアントでシステムプロキシを同時に有効にすると、通常はシステム設定を最後に書き込んだ側が入口になりますが、もう一方がポートを占有し続ける可能性があります。2つのTUNを同時に動かすと、デフォルトルートの競合、DNSクエリの迂回、LANアクセスの異常が発生することがあります。

ステップ2：新しいクライアントをインストールして初回起動する

クライアントプロジェクトが提供するリリースページから、OSとプロセッサーアーキテクチャに合ったインストーラーを入手します。初回起動後は、すぐにシステムプロキシやTUNを有効にせず、まずカーネルの状態と設定フォルダーが正常か確認してください。一部のクライアントではmihomoカーネルを個別に更新します。画面にカーネル未準備と表示された場合は、クライアントの案内に従ってコアのインストールまたは切り替えを完了します。

ステップ3：サブスクリプションを再インポートする

新しいクライアントのサブスクリプションまたは設定の入力欄に元のサブスクリプションURLを貼り付け、ダウンロードして現在の設定に指定します。読み込みに成功したら、ノード数、プロキシグループ名、ルール数が旧クライアントとおおむね一致するか確認します。移行中にサブスクリプションサービスの内容が更新されることがあるため、各項目が完全に一致する必要はありません。ただし、設定が空、ノードがごく少数、またはプロキシグループがすべて欠落している状態は避けるべきです。

サブスクリプションが「形式エラー」になる場合は、コピーしたURLに余分な空白や改行がないか確認し、ブラウザーまたはサービス提供元の管理画面からリンクを再取得します。サブスクリプション変換テンプレートを誤って有効にしていないか、設定ファイル内のノードプロバイダーURLにアクセスできるかも確認してください。旧版Clash形式で生成された内容でも、新しいクライアントがmihomoを使用していれば基本フィールドは通常読み込めます。実際に問題になりやすいのは、インデントの誤り、参照ファイルへのアクセス不能、存在しないノードをプロキシグループが参照していること、またはサブスクリプションの応答が実際にはログインページになっていることです。

ステップ4：カスタムルールと上書きを移行する

旧設定の個人用ルールを元の順序どおり、新しいクライアントが対応する上書き箇所へ追加します。Clashのルールは上から順に照合され、最初に一致したルールでトラフィックの行き先が決まるため、ルール数より順序が重要です。LANへのダイレクト接続、指定ドメインのプロキシ、アプリのプロセスルール、最終的なフォールバックルールの順序を自由に入れ替えてはいけません。

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

上の例は順序の構造を示したものです。実際には、Proxyが設定内のプロキシグループ名と完全に一致している必要があります。グループ名に空白や日本語が含まれる場合も、一字ずつ正確に合わせてください。サブスクリプション更新のたびにプロキシグループが再構築される場合は、カスタムルールの参照先を安定して存在するグループ名にし、更新後に「プロキシグループが見つからない」という読み込みエラーが出ないようにします。

Clash for WindowsのParsersでは、JavaScriptを使ってサブスクリプションの結果を変更していることがあります。このようなロジックをすべての新クライアントへそのまま貼り付けることはできません。まずスクリプトがどのフィールドを変更しているかを把握し、移行先クライアントが対応する上書き、設定マージ、拡張スクリプトへ書き換えてください。実行段階を理解しないまま複数の上書きを同時に有効にすると、ポートが二重に変更される、DNSフィールドが後から実行された設定で上書きされるなどの問題が起きます。

ステップ5：プロキシグループの選択と更新間隔を復元する

プロキシグループを1つずつ開き、よく使うノードまたは自動選択方式を復元します。url-testやfallbackなどの自動グループではヘルスチェックが実行できることを確認し、selectの手動グループでは現在の選択項目が無効なノードでないことを確認してください。その後、サブスクリプションの更新間隔を設定して手動更新を1回実行し、上書き内容が維持されているか確認します。

システムプロキシとTUN設定を復元する方法

サブスクリプションの読み込みが完了しても、端末のトラフィックがClashへ入ったとは限りません。新しいクライアントでトラフィックの入口を構築する必要があります。システムプロキシとTUNは異なる制御方式なので、まずシステムプロキシから検証し、アプリの互換性に応じてTUNを有効にしてください。

まずシステムプロキシをテストする

新しいクライアントのシステムプロキシを有効にすると、OSはシステムプロキシ設定に対応するHTTPまたはSOCKSの通信をローカルのリスニングポートへ送信します。ブラウザーや多くのデスクトップアプリは通常この方式をそのまま利用できます。クライアントの接続ログを開いてテストサイトへアクセスし、ログにドメイン、適用されたルール、最終的なプロキシグループが表示されることを確認します。

有効にした後にまったくインターネットへ接続できない場合は、新しいクライアントのリスニングポートが他のプログラムに占有されていないか、システムプロキシに正しいローカルアドレスが設定されているか、設定がRuleモードになっているか確認します。クライアントを終了しても接続できない場合は、OSのネットワーク設定を開き、残っている手動プロキシを削除してください。

次にTUNを設定する

ゲーム、コマンドラインツール、一部のストアアプリ、システムプロキシを参照しないソフトウェアでは、TUNによる制御が必要になることがあります。TUNは仮想ネットワークインターフェースを作成し、ルーティング条件に合うIPトラフィックをmihomoへ渡します。初回の有効化には通常管理者権限が必要で、システムサービスや仮想NICコンポーネントのインストールを求められる場合があります。

TUNを移行するときは、旧クライアントのスイッチ状態をそのまま写さないでください。まず新しいクライアントが推奨する初期設定を使い、仮想インターフェースが正常に作成されたことを確認します。その後、auto-route、strict-route、DNSハイジャック、インターフェースの自動認識を確認してください。これらのフィールドの実装はOSによって異なり、新しいクライアントが対応する設定を画面から生成する場合もあります。

TUNを有効にした後、LANプリンター、NAS、ルーターの管理画面にアクセスできなくなった場合は、まずプライベートネットワークがダイレクト接続のままか確認し、厳格なルーティングによってローカルアクセスの経路が変わっていないか確認します。ドメイン名だけ異常で直接IPなら正常な場合は、ノードを何度も切り替えるのではなく、DNSモード、Fake-IPの除外リスト、上流DNSへの到達性を重点的に確認してください。

移行後のチェックリスト

サブスクリプションのインポートとトラフィック制御が完了したら、次の順序で確認します。各項目を終えてから次へ進むことで、問題が設定、ルール、システムの入口のどこにあるかをすばやく判断できます。

  1. カーネルの状態：クライアント上でmihomoが正常に動作し、再起動や設定解析エラーが継続していない。
  2. サブスクリプション更新：手動更新が完了し、更新日時が変わり、ノードとプロキシグループが正常に表示される。
  3. 設定モード：現在のモードが必要なRule、Global、Directのいずれかであることを確認し、移行後に画面の初期値をそのまま使わない。
  4. プロキシグループ：手動グループの選択が復元され、自動グループで遅延テストを実行でき、ルールが参照するグループ名がすべて存在する。
  5. システムプロキシ：ブラウザーへのアクセスが接続ログを生成し、システムプロキシを無効にした後にネットワーク設定が正しく復元される。
  6. DNS：ドメイン名前解決が安定し、ログに連続したタイムアウトがなく、LANドメインと特殊なドメインが想定どおり処理される。
  7. TUN：必要な場合だけ有効にし、システムプロキシを参照しないアプリが接続ログに記録されることを確認する。
  8. LAN：ルーター、NAS、プリンター、共有サービスへ引き続きアクセスでき、プライベートアドレスが誤ってプロキシへ送られていない。
  9. 起動時の自動起動：自動起動項目が新しいクライアントだけになっており、システムプロキシやTUNが想定どおり復元されるか確認する。
  10. 旧クライアントの処理：しばらく安定して使用できることを確認してから旧クライアントをアンインストールし、アンインストール前にバックアップフォルダーがアプリデータの削除対象に含まれていないことを確認する。

移行時によくある障害の切り分け

サブスクリプションのインポートは成功したがノードがない

まずサブスクリプションの応答が有効な設定か確認します。サービス提供元の管理画面でリンクを再生成する必要がある場合があり、期限切れのURLはYAMLではなく案内文を返すことがあります。クライアントで誤ったサブスクリプション変換テンプレートを有効にしていないか、設定ファイル内のノードプロバイダーURLへアクセスできるかも確認してください。

設定は読み込めるがルールがすべてフォールバックになる

カスタムルールがMATCHの後ろに置かれていないか確認します。MATCHは最終ルールであり、その後の項目は実行されません。リモートルールプロバイダーを使用している場合は、rule-providersのダウンロードが成功していること、ルール内のRULE-SET名とプロバイダー名が一致していることも確認してください。

システムプロキシを有効にしても一部のアプリで機能しない

これは通常、サブスクリプションのインポート失敗ではなく、アプリがOSのプロキシ設定を読み取っていないことを示します。まずクライアントのログでブラウザーの通信が正常なことを確認し、対象アプリ自身にプロキシを設定するか、権限とルーティング設定を確認したうえでTUNを使用してください。1つのアプリに記録がないからといって、すぐにDNS設定全体を変更しないでください。

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

まずTUNを無効にし、システムプロキシモードが引き続き動作することを確認します。次に、仮想NICサービスの権限、デフォルトインターフェースの認識、ルート競合、DNS上流を確認してください。端末で動作している他のネットワークフィルター、仮想マシンのネットワーク、企業VPNもルートを書き換える可能性があります。切り分け時は一度に1種類の制御ツールだけを有効にし、複数の変数を同時に変えないでください。

サブスクリプション更新後にカスタムルールが消える

これは、ルールがサブスクリプションのキャッシュファイルへ直接書き込まれ、更新時にリモートの内容で上書きされたことを示します。ルールを新しいクライアントが提供する永続的な上書き箇所へ移し、サブスクリプションの解析後に上書きが実行されることを確認してください。移行完了後は少なくとも2回手動更新し、ルール、DNS、プロキシグループの変更が継続して保持されることを検証します。

Clashをダウンロード