クライアント選び 読了時間：約12分

Clash for Windows の更新終了後に使う代替クライアント｜選び方と設定の移行方法

更新が止まったクライアントの現状と、現在も開発が続く代替候補を比較。サブスクリプション、ルール、オーバーライド設定を移行する手順も解説します。

まず結論：移行するのは設定。クライアントのフォルダー全体はコピーしない

Clash for Windows（以下、CFW）は2023年に開発が終了しており、最後に公開されたバージョンは0.20.39とされています。既存のインストールが起動しても、コアや依存関係、OSへの対応が更新されているとは限りません。新しいプロトコルを認識しない、OSのアップデート後にサービスが正常に動作しないといった問題がある場合は、同じ古いインストーラーを何度も入れ直すのではなく、移行を検討しましょう。

Windowsユーザーは、Clash Verge RevとClash Nyanpasuをまず比較してみてください。デスクトップとAndroidで似た操作感を求める場合は、FlClashも候補になります。選ぶ際は、GUIクライアントと付属コアのそれぞれについて、現在もリリースが続いているか確認しましょう。プロジェクト名にClashが含まれているだけで互換性を判断することはできません。インストーラーの入手先、対応OS、CPUアーキテクチャはクライアントのダウンロードページで確認できます。

代替クライアントの選び方：コア、設定方法、OS連携を確認

GUIクライアントは、サブスクリプション、トレイメニュー、システムプロキシ、サービスのインストールなどを管理します。コアはプロキシプロトコル、ルール判定、DNS、通信の転送を担います。Clash Metaは後継プロジェクトがmihomoの名称で開発を続けていますが、Clashを名乗るクライアントがすべて同じコアを使うわけではありません。また、旧UI用のスクリプトが新しいコアでそのまま動くとも限りません。

候補クライアント 優先して検討したい用途 移行時に確認するポイント
Clash Verge Rev Windows、macOS、LinuxのデスクトップでサブスクリプションとOS連携を使いたい mihomoの設定互換性、サービスモード、設定のマージ方法、スクリプトの実行方法
Clash Nyanpasu デスクトップの操作画面や設定管理方法を変えたい 実際に使われるコア、設定の適用順序、システムプロキシ、TUNの設定
FlClash デスクトップとAndroidの両方で使いたい 各OS向けインストーラー、バックグラウンド実行の権限、設定のオーバーライド機能
既存のCFW 短期間の移行作業中に、旧設定をオフラインで参照したい 開発終了済みのため、長期的な更新先としては使わない

ダウンロード前に確認する3つのポイント

「設定項目が多いこと」だけを選定基準にするのはおすすめしません。既存のサブスクリプションが問題なく使えているなら、最終的な設定を確認できること、独自ルールを維持できること、システムのネットワーク設定を安定して元に戻せることのほうが、実験的な設定項目が1つ多いことより重要です。

移行前のバックアップ：サブスクリプション、ルール、画面設定を分けて保存

まずCFWの「Profiles」で現在有効な設定を、「Proxies」でモードと各プロキシグループの選択内容を記録します。次に「Settings」から実際の設定フォルダーを開いてください。通常のインストールで使われるフォルダーは %USERPROFILE%\.config\clash ですが、ポータブル版や独自のパスを使っている場合もあります。必ずクライアントから開いたフォルダーを確認してください。

  1. サブスクリプションの配布元を記録：サブスクリプションURL、更新間隔、サービス提供元の案内を控えます。URLには認証情報が含まれることが多いため、保護されたローカルの記録に保存し、公開フォーラムへの投稿やスクリーンショットへの掲載は避けてください。
  2. 設定ファイルをバックアップ：CFWを終了してから設定フォルダーをコピーし、現在の設定のYAMLテキストも別途保存して項目ごとの比較に備えます。エクスポートしたノード一覧はサブスクリプションURLの代わりにはなりません。自動更新には元の配布元が必要です。
  3. 独自設定を個別に保存：Parsers、Mixin、独自ルール、ルールセットのURL、ローカルファイル、DNSのオーバーライドを保存します。サブスクリプション由来の項目と、後から手動で追加した項目を区別しておきましょう。
  4. OS連携の設定を記録：HTTP、SOCKS、mixedの各ポート、システムプロキシ、自動起動、サービスモード、TUNの有効状態を控えます。キャッシュや旧サービスプログラム、旧コアを新しいインストール先にまとめて上書きしないでください。

バックアップにはノードのパスワード、サブスクリプションのトークン、外部コントローラーのキーが含まれている場合があります。移行後も安全に保管してください。誤って公開してしまった場合は、スクリーンショットを削除するだけでなく、該当サービス側で認証情報を変更しましょう。

サブスクリプションの移行：まず元の設定をそのまま動かす

最初はサブスクリプションだけをインポートし、旧スクリプトは有効にしない

CFWを終了し、システムプロキシ、TUN、自動起動を無効にします。新しいクライアントを開き、サブスクリプション管理画面から元のURLを使ってインポートしてください。たとえばClash Verge Revでは、通常「サブスクリプション」ページから追加できますが、ボタン名や場所はインストールしたバージョンによって異なります。インポート後に手動で更新し、一覧に表示されているだけでなく、その設定が選択され有効になっていることを確認してください。

次にプロキシグループがすべて揃っているか確認します。特に自動選択、フォールバック、自分で名前を付けた振り分け用グループに注意してください。旧クライアントで選んでいたノードは引き継がれない場合があります。同じグループ名があっても、同じノードが選択されているとは限りません。まず利用できると分かっているノードを手動で選び、ルールモードで基本的な接続をテストしましょう。

インポートに失敗した場合はエラーの種類ごとに対処

ローカルのYAMLを移行するときは、rule-providersとproxy-providersに指定された相対パスを特に確認してください。旧フォルダーから新しいフォルダーにファイルをコピーしても、参照先がそのまま有効とは限りません。外部ルールセットの形式も、指定されたtypeとbehaviorに一致させる必要があります。

ルールとオーバーライド：最終的に生成されるYAMLを確認しながら移行

CFWのParsersはクライアント側で設定を処理する仕組みであり、mihomoのコア設定としてそのまま使うことはできません。旧スクリプトの関数の呼び出し口、注入対象、実行タイミングは、新しいクライアントでは異なる場合があります。旧設定を「ルールを追加する」「DNSを変更する」「プロキシグループを調整する」といった具体的な要件に分け、移行先が対応する設定マージ機能やスクリプト機能で書き直してください。

まず再現しやすいルールを移行し、複雑な処理は後から戻す

以下はLAN内の通信を直接接続するルールを2つ記載した例です。サブスクリプション全体ではなく、既存のrulesリストと置き換えてはいけません。必要な場合は、クライアントのルール挿入機能または設定編集画面から既存のルール列に追加し、末尾のフォールバックルールを残してください。

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

192.168.50.0/24はサンプルのネットワーク範囲です。実際のLANのアドレスに合わせて変更してください。ルールは通常、上から順に照合されます。ローカル向けの例外は、それより広いルールに先に一致しない位置に置き、末尾のMATCHで該当しなかった通信を処理します。独自のプロキシグループをルールの対象にする場合は、そのグループが実際に存在する必要があります。旧名称をコピーしただけで設定が有効になるわけではありません。

DNSとFake-IPは個別に移行

旧DNS設定をまとめてコピーしないでください。まず新しいクライアントの標準設定で基本動作を確認し、必要に応じて独自のDNSサーバー、ドメインごとのポリシー、Fake-IPの除外設定を移行します。Fake-IPは予約アドレスを使ってドメイン名を対応付ける仕組みで、実際のプロキシノードのアドレスではありません。有効化後に問題が起きた場合は、仮想アドレスを見ただけで設定ミスと決めつけず、クライアントのDNSログやアプリの動作を確認してください。

LAN内のデバイス検出、プライベートドメイン、固定DNSに依存するアプリは、名前解決の結果と接続経路を個別に確認してください。DNSモードを変更した後は、対象アプリを終了してから再テストします。Windowsではipconfig /flushdnsを実行してシステムのDNSキャッシュを消去できますが、ブラウザーやアプリ独自のキャッシュまでは削除されません。

ポート、システムプロキシ、TUN：3段階で確認

ステップ1：ローカルプロキシの待ち受けを確認

CFWでは、HTTPポートに7890、SOCKSポートに7891、外部コントローラーに9090がよく使われますが、実際の値は旧設定で確認してください。新しいクライアントでは、たとえば7897など別のポートが使われる場合があります。コントローラーのポートはブラウザー用のプロキシポートではないため、アプリのHTTPプロキシ設定に入力しないでください。

新しいクライアントにmixedポートとして7897が表示されている場合、PowerShellで以下のコマンドを実行できます。1つ目で待ち受け中のプロセスを確認し、2つ目で明示的にプロキシを指定してテスト用URLにアクセスします。テスト時にシステムプロキシを有効にする必要はありません。

Get-NetTCPConnection -State Listen -LocalPort 7897
curl.exe -I --proxy http://127.0.0.1:7897 https://example.com/

HTTP応答が返ってきたことは、そのリクエストで応答を受信できたことを示しますが、すべての振り分けルールが正しいとは限りません。接続拒否のエラーが出る場合は、コアが起動しているか、ポートが一致しているかをまず確認します。ポートが使用中と表示された場合は、旧クライアントや別のプロキシプログラムがバックグラウンドで動いていないか調べてください。正体の分からないシステムプロセスをむやみに終了しないでください。

ステップ2：システムプロキシを有効化

ローカルプロキシのテストに成功したら、新しいクライアントでシステムプロキシを有効にします。次にWindowsの「設定」→「ネットワークとインターネット」→「プロキシ」でアドレスとポートを確認してください。ブラウザーではアクセスできても特定のアプリで接続できない場合、そのアプリがシステムプロキシに従わない、独自のプロキシ設定を使っている、または別のネットワーク制限がある可能性があります。まずアプリ側の設定を確認しましょう。

ステップ3：必要に応じてTUNを有効化

TUNは仮想ネットワークインターフェースを使って通信を取り込むため、サービス権限、ルーティング、DNSに影響します。まずシステムプロキシが正常に動作することを確認してから、クライアントの案内に従ってサービスモードをインストールまたは有効化し、最後にTUNを有効にします。原因を特定しにくくならないよう、各段階で動作をテストしてください。

TUNを有効にした後、企業VPN、LANへのアクセス、仮想マシンのネットワークに問題が起きた場合は、まずTUNを無効にして復旧するか確認し、ルートの競合や除外設定を調べます。2つのクライアントで同時にTUNを動かさないでください。また、TUNを有効にするために、デスクトップアプリを常に管理者として実行するのは避けましょう。

移行後の確認とロールバックのチェックリスト

Webページを1回開けただけでは、特定の経路が使えたことしか分かりません。旧クライアントを削除する前に、以下を確認しましょう。サブスクリプション、ルール、システム側の通信制御のどこに問題があるか切り分けやすくなります。

旧環境に戻す場合は、新しいクライアントのシステムプロキシとTUNを無効にしてから、そのコアを終了します。続いてバックアップした旧設定を復元し、ネットワークを制御するクライアントが1つだけであることを確認してください。ロールバックは問題の比較・確認に使うもので、開発が止まったクライアントが再び保守されるわけではありません。新環境が安定したら旧プログラムをアンインストールし、旧クライアントの手順に従って不要なサービスを削除します。必要なオフラインバックアップは保管してください。

移行では、各段階を確認できる状態にすることが大切です。まずサブスクリプションをそのまま動かし、次に独自ルールを移行します。先にローカルポートを確認してから、システム全体の通信制御を有効にしましょう。ルール、DNS、TUNの関係について詳しくは使い方ガイドをご覧ください。インストールや接続でよくある問題はよくある質問から症状別に確認できます。

Clash をダウンロード