Windows
Windows 10およびWindows 11のデスクトップ環境に対応しています。ダウンロードページでシステムのビット数を確認し、Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuなどから選択してください。導入後はシステムプロキシを使うほか、権限と連携範囲に応じてTUNモードを設定できます。
ダウンロードページへ5つのプラットフォーム向けクライアント、サブスクリプションとルール設定、システム連携のトラブル対処をまとめて確認できます。まずOSとプロセッサーのアーキテクチャを確認し、各プラットフォームのインストーラーと設定手順へ進んでください。
トップページではプラットフォームを探します。インストーラーの種類、クライアントのメンテナンス状況、プロセッサーアーキテクチャ、各ダウンロードボタンはダウンロードページでまとめて確認できます。
Windows 10およびWindows 11のデスクトップ環境に対応しています。ダウンロードページでシステムのビット数を確認し、Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasuなどから選択してください。導入後はシステムプロキシを使うほか、権限と連携範囲に応じてTUNモードを設定できます。
ダウンロードページへmacOSのインストーラーはIntelとApple Siliconを分けて選びます。M1、M2、M3、M4などのチップは通常ARM、旧型のIntel Macはx64を選択してください。初回起動時は、システムの案内に従ってネットワーク拡張、プロキシ設定、補助権限を確認します。ファイル名だけで導入成否を判断しないでください。
ダウンロードページへAndroidページではスマートフォンとタブレット向けクライアントを案内しています。近年の端末の多くはARM64、旧型端末ではARMまたは汎用パッケージが必要な場合があります。サブスクリプション導入後、システムにVPN接続の確認画面が表示されます。ユーザーが許可して初めて、クライアントはアプリの通信をルールエンジンに渡せます。
ダウンロードページへiPhoneとiPadではApp StoreからClash Plusをインストールします。ダウンロードページでストアへのリンクと公式サイトclashplus.ioを確認できます。初回の設定有効化時、iOSはVPN構成の追加を求めます。システムの確認が完了したら、クライアントに戻ってサブスクリプション、プロキシグループ、接続モードを選択してください。
ダウンロードページへLinuxデスクトップではClash Verge RevまたはFlClashを選べます。サーバー、ソフトウェアルーター、コンテナ環境では通常、mihomoカーネルを直接導入します。デスクトップへの導入前にdeb、rpm、ディストリビューションの種類を確認してください。コマンドラインで導入する場合は、設定ディレクトリ、サービス権限、自動起動、プロキシ環境変数も設定します。
ダウンロードページへOS名が同じでも、インストーラーを共用できるとは限りません。macOSではIntelとApple Silicon、AndroidではARM64、ARM、汎用パッケージ、LinuxではAMD64、ARM64、ARMv7とパッケージ形式を確認します。アーキテクチャが合わないと、インストーラーが起動しない、ファイルがサポートされていないと表示される、カーネル起動直後に終了するといった症状が起こります。
日常的なデスクトップやモバイル端末では、GUI付きクライアントが便利です。サブスクリプション更新、プロキシグループの切り替え、システムプロキシ、ログ確認を画面上で完結できます。サーバーやルーターではmihomoを直接実行し、設定ファイル、systemd、コンテナでプロセスを管理する構成が適しています。ルールの考え方は似ていますが、導入先とトラブル対処の入口は異なります。
クライアントの導入完了は、通信がすでに連携されていることを意味しません。利用可能なサブスクリプションまたはローカルYAML設定を読み込み、設定を更新し、プロキシグループを選択したうえで、環境に応じてシステムプロキシまたはTUNモードを有効にします。接続に問題がある場合は、まずクライアントのログを確認してください。DNS、ポート、ルール、プロキシモードを同時に変更すると、原因を特定しにくくなります。
リクエストがクライアントに入ってから、ルール判定、サブスクリプション更新、システム連携、カーネル互換の役割分担を順に確認できます。
ルールモードは、すべての接続を同じノードへ送る仕組みではありません。クライアントは設定された順序に従い、ドメイン、IP、プロセス、ポート、ルールセットなどを確認し、条件に一致すると指定されたプロキシグループへ接続を渡します。プロキシグループではノードを固定選択することも、自動テスト、フェイルオーバー、負荷分散で出口を決めることもできます。最後の MATCH は、それまでのルールに一致しなかったリクエストを受けるため、ルールの順序とフォールバック設定が実際の結果を大きく左右します。
誤ったルール分岐を調べるときは、まずログでリクエストがどのルールに一致したかを確認し、そのルールが指定するプロキシグループと現在の選択を確認します。すべての接続をグローバルに扱うツールと比べ、Clashのルール体系では直結、プロキシ、拒否、複数の経路を一つの設定にまとめられます。一方で、設定の優先順位を明確に管理する必要があります。変更時は一度に一つのルール群だけを調整し、上位ルールが下位ルールを遮らないようにしてください。
サブスクリプションリンクは通常、リモート設定またはノード一覧を返します。クライアントがダウンロードを完了した後も、YAMLを解析し、ローカルコピーを保存し、プロキシ、プロキシグループ、ルール、DNS設定をカーネルへ読み込む必要があります。画面に更新成功と表示されても、リモート内容を取得できたことを示すだけです。選択可能なノードがあるか、現在のカーネルが設定構文を認識できるか、プロキシグループの参照が完全かは、設定一覧と実行ログで確認してください。
安定した管理方法は、更新日時、更新結果、現在有効な設定の3項目を記録することです。サブスクリプションに失敗したら、リンクが完全か、ネットワークから購読先へアクセスできるか、応答が有効な設定か、クライアントが解析エラーを報告していないかを順に確認します。アプリのデータ全体を何度も削除せず、まずローカルの変更をエクスポートし、リモート設定の問題とクライアント側の通信問題を切り分けてください。
システムプロキシは、OSが提供するHTTP、HTTPS、SOCKSなどのプロキシ設定を主に変更します。システムプロキシに従うアプリは、クライアントの待ち受けポートへリクエストを渡しますが、一部のコマンドラインプログラム、ゲーム、仮想マシン、独自のネットワークスタックを使うソフトウェアは設定を無視する場合があります。TUNモードは仮想ネットワークインターフェースを通じて、より広い範囲のIP通信を連携します。多くのアプリを対象にしたい環境に適していますが、通常は追加権限が必要で、DNSやルーティングの確認経路も変わります。
モードはすべての項目を同時に有効にするのではなく、連携したい対象から選びます。ブラウザーや一般的なデスクトップアプリでは、まずシステムプロキシを試してください。プロキシ設定に従わないプログラムがあると確認できたら、TUNを検討します。有効化後に通信できない場合は、カーネルログ、仮想NICの権限、デフォルトルート、DNSの待ち受けポート、ほかのVPNソフトとの競合を確認します。ノードのタイムアウトとシステム連携の失敗を同じ問題として扱わないでください。
Clashエコシステムのデスクトップ・モバイルクライアントは、主に画面表示、設定管理、システム連携、プロセス制御を担当します。実際にルールを解析して接続を転送するのは下層のカーネルです。クライアントによって組み込まれるカーネルのバージョンは異なり、カーネルを交換できる場合もあります。現在広くメンテナンスされている系統はmihomoで、Clash Metaの設定機能を引き継ぎつつ拡張しています。原版Clashや一部の旧クライアントはすでにメンテナンスが停止しています。古い設定を使える場合でも、新しいフィールドがすべて互換だとは限りません。
クライアントを移行するときは、現在のポート、DNSモード、ルールプロバイダー、プロキシグループ、TUN設定を記録し、移行先のカーネルが対応するフィールドを確認します。画面上の名称が似ていても、設定ディレクトリや起動パラメーターが同じとは限りません。サーバー導入では、カーネルログとサービス状態を直接確認してください。画面、設定、カーネルの問題を層ごとに分けると、調査範囲を大きく絞れます。
システムプロキシのリクエストは通常、クライアントのHTTP、SOCKS、mixed-portへ到達します。TUN通信はまず仮想ネットワークインターフェースに入ります。アプリがログにまったく現れない場合は、ノードを変更する前に連携経路、待ち受けアドレス、システム設定を確認してください。
ドメインはシステムで解決される場合も、クライアントのDNSモジュールに渡る場合もあります。fake-ip、redir-host、リモートDNS、フォールバック設定によって問い合わせ経路は変わります。ドメインに失敗してIPにはアクセスできる場合は、解決経路に沿って確認し、プロキシノードの状態だけを見て判断しないでください。
ログに記録されたルール名、プロキシグループ、最終ノードは、一連の判定結果を構成します。誤った出口へ接続される場合は、より上位のルールに先に一致していないかを確認し、ルールセットの更新日時とプロキシグループの現在の選択を確認してください。
ルールが正しく一致しているのに接続がタイムアウトする場合、調査の重点をノードの到達性、プロトコルパラメーター、ローカルファイアウォール、対象サイトへ移します。段階ごとに切り分ければ、ルール、DNS、連携、ノードの設定を無秩序に変更せずに済みます。
クライアント名、グラフィカルインターフェース、プロキシカーネルは同じプロジェクトではありません。ダウンロードやトラブル対処の前に、問題がどの層に属するかを確認してください。
Clashは、YAML設定、ルール照合、プロキシグループ、複数プロトコルのプロキシという基本的な利用方法を確立しました。原版プロジェクトのメンテナンス停止後も、エコシステムは単一のソフトウェアに統合されず、複数のカーネル系統とグラフィカルクライアントが発展を続けています。古い記事を読む際は、原版Clash、Clash Meta、mihomo、または特定のクライアントのどれを指しているかを確認してください。同じ設定名でも、バージョンによってフィールドや初期値が異なる場合があります。
Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、ClashX Metaなどは、異なるプラットフォーム実装やグラフィカルクライアントを指す名称です。クライアントはサブスクリプション管理、プロキシ選択、システムプロキシの切り替え、ログ確認、更新の入口を提供します。mihomoなどのカーネルは、ポートの待ち受け、DNS処理、ルール照合、外向き接続の確立を担当します。画面は開くのにプロキシが機能しない場合は、カーネルが正常に起動しているかも確認してください。
mihomoはClash Metaのメンテナンス方針を引き継ぎ、ルール、DNS、トンネル、プロトコルの機能を拡張しています。互換性があるからといって、古い設定をすべてそのままコピーできるわけでも、新しい設定を旧カーネルで実行できるわけでもありません。移行時はログレベル、ポート、プロキシグループ、ルールプロバイダー、DNS、TUN設定を順に読み込みます。各層を読み込むたびにテストすれば、解析エラーが出た際に原因のフィールドを特定しやすくなります。
本サイトのダウンロードページでは、バージョン一覧からクライアントのバージョンとダウンロード先を表示します。バージョン情報が空の場合は表示されません。プロジェクトが継続しているかは、リリース記録、コミット活動、告知を総合して判断し、ソフトウェア名の知名度だけで判断しないでください。メンテナンスが停止したクライアントには、ダウンロード一覧でアーカイブ用途の印を付けています。新規導入では、継続的なリリース記録があり、現在のOSとカーネル設定に対応するクライアントを優先してください。
以下の質問から、トラブル対処の方向をすばやく判断できます。用語の定義や関連概念は、用語解説ページで詳しく確認できます。
設定が正常に読み込まれ、プロキシグループに利用可能な選択肢があり、システムプロキシが有効になっているかを確認してください。ブラウザーのリクエストがクライアントログに現れない場合、原因は通常システムプロキシまたは連携経路にあります。ログにリクエストがある場合は、ルールの一致とノード接続を確認します。システムプロキシ、混合ポート、TUNの違いは用語解説で確認できます。
更新成功は、リクエストが応答を受け取ったことだけを示す場合があります。応答が有効な設定であるか、クライアントがフィールドを解析できるか、プロキシ一覧が空でないか、更新直後の設定が有効になっているかを確認してください。更新ログでYAML解析、フィールド互換、プロキシグループ参照のエラーを探し、サブスクリプションとローカル設定の関係を用語解説で確認します。
ブラウザーやシステムプロキシに従うデスクトップアプリでは、経路が分かりやすいシステムプロキシをまず試してください。ゲーム、コマンドラインプログラム、システムプロキシを無視するアプリまで対象にする場合は、TUNモードを検討します。TUNでは仮想NIC、ルート、権限、DNS経路が関係するため、有効化後はこれらを同時に確認してください。関連用語は用語解説で確認できます。
ルールに一致したことは、分岐の段階が完了したことを示すだけで、外向き接続の成功を保証しません。プロキシグループの現在の選択、ノードパラメーター、宛先への到達性、ローカルファイアウォール、ネットワーク制限を確認してください。同じノードですべての宛先に失敗するならノードとプロトコルを重点的に確認し、特定のドメインだけが失敗するならDNS、対象サイト、より細かいルール条件を確認します。用語の関係は用語解説を参照してください。
再現可能なネットワーク経路を軸に、確認方法、ログの追跡、設定の境界、復旧手順を整理しています。
検出結果、システムの名前解決経路、クライアントログを起点に、fake-ip、リモートDNS、フォールバック設定を項目ごとに確認します。ブラウザーの表示結果、OSの問い合わせ、クライアントDNSモジュールを区別し、1回のウェブテストだけで判断しないための解説です。
3つのカーネル系統の関係、設定の互換範囲、メンテナンス状況を整理し、グラフィカルクライアントとカーネルの組み合わせ方を解説します。設定移行前に、再確認が必要なフィールドや、現在の環境に合わない古い記事を判断できます。
アプリのリクエストからプロキシカーネルまで、2つのモードの経路を比較し、権限、仮想NIC、DNS、ルーティングの確認方法を解説します。一部のアプリだけプロキシを通らない、TUN有効化後に通信できない、システムプロキシが反映されない場合に役立ちます。