まずOSとCPUアーキテクチャを確認してから、インストーラーを選びます。デスクトップ用GUIクライアント、モバイルアプリ、単体カーネルでは使い方が異なります。
まずはClash PlusなどのGUIクライアントを選びましょう。インストール前にシステムのアーキテクチャを確認し、TUNを使う場合はクライアントの案内に従ってサービスをインストールし、必要な権限を許可します。
ダウンロードへ ›Apple Silicon用とIntel用のインストーラーを確認してください。初回起動時はシステムの権限要求に注意し、接続後にシステムプロキシとネットワーク拡張機能の状態を確認します。
ダウンロードへ ›端末のアーキテクチャに合ったアプリを選びます。設定を追加したらVPN接続を許可し、バックグラウンド実行の権限とバッテリー管理の設定も確認してください。
ダウンロードへ ›ダウンロードページでClash Plusのストア掲載先を確認できます。インストール後にサブスクリプションを追加し、VPN構成の作成を許可してください。利用できる設定項目はアプリの対応範囲によって異なります。
ダウンロードへ ›ディストリビューションに合ったパッケージ形式を選びます。デスクトップではGUIクライアントを使い、サーバーやルーターに導入する場合はカーネルのプロセスとネットワーク権限を別途管理します。
ダウンロードへ ›クライアントは設定の読み込みやプロキシの選択、OSとの連携を担当し、カーネルはプロキシプロトコルとルールに基づく振り分けを処理します。カーネル単体をダウンロードしてもデスクトップの設定画面は表示されず、システムプロキシも自動設定されません。初めて使う場合は、まずGUIクライアントを選び、ガイドに沿ってサブスクリプションを追加し、接続を確認しましょう。その後、透過プロキシやルーターへの導入を検討してください。
インストールが完了しても、すぐに使える設定があるとは限りません。サブスクリプションURLは通常、利用中のサービスから提供されます。当サイトではノードやサブスクリプションを発行していません。追加前にリンクの入手元を確認し、認証情報を含むURL全体を公開の場に貼らないよう注意してください。クライアントを乗り換えるときは、元の設定とプロキシ選択を保管しておきます。新しいクライアントで接続を確認してから旧クライアントを終了すれば、同じポートを複数のアプリが使用する競合を避けられます。
Clash for Windowsをインストール済みの場合は、まずサポートが終了していることを確認し、移行を検討してください。設定ファイルを引き継げても、旧バージョンのすべての項目をそのまま使えるとは限りません。mihomoを採用したクライアントに移行した後も、プロキシプロトコル、DNS設定、プロキシグループ名を確認しましょう。ダウンロードページにはプラットフォーム別のクライアントを掲載しています。各製品のシステム要件とサポート状況は、それぞれの案内を確認してください。
目的に合った設定項目から確認しましょう。以下の例は設定の構造を説明するものです。利用する前に既存の設定と統合し、参照関係に問題がないか確認してください。
サブスクリプション管理は設定の入手元と継続的な更新を扱うもので、通信を制御する機能そのものではありません。まずクライアントの設定画面またはサブスクリプション画面にURLを追加します。更新が完了したら該当する設定を選び、プロキシグループに選択肢が表示されるか確認してください。URLから取得した内容はクライアントが対応する形式である必要があります。ノードの一覧をそのまま完全なYAML設定として使えるとは限りません。ノードを1つずつ登録するより一元管理しやすい一方、リモート更新でローカルの変更が上書きされる場合があります。個人用ルールはクライアントのオーバーライド機能に追加しましょう。更新に失敗したときは、ダウンロードエラーと解析ログを確認し、使用できている設定をむやみに削除しないでください。
設定リファレンスを見る ›完全な設定ファイルには、リスニングポート、DNS、プロキシグループ、ルールをまとめて定義できます。一方、プロキシプロバイダーはプロキシ項目だけを提供し、通常は proxy-providers から読み込みます。役割が異なるため、読み込み方法も同じとは限りません。独自の振り分けルールを維持する場合は、メイン設定からプロキシプロバイダーを参照し、プロキシグループ側で use を使って関連付けます。設定全体を置き換える場合より、ノードの更新がルール構造に与える影響を抑えられますが、名前やパス、プロキシグループの参照は自分で管理する必要があります。分割する前に元のファイルをバックアップし、プロバイダーを読み込めることを確認してから、項目ごとに移行してください。一度に複数の階層を変更しないようにしましょう。
ルールモードでは、接続をルールの上から順に照合し、最初に一致したルールに指定されたプロキシグループへ渡します。まず mode: rule になっていることを確認し、対象範囲が明確なドメインルールを前に、最後にフォールバックとなる MATCH を配置します。ルールに指定するプロキシグループ名は、定義と完全に一致させてください。一致しない場合、設定を読み込めないことがあります。グローバルモードと異なり、ルールモードでは直結とプロキシを併用できます。動作確認ではスイッチの状態だけでなく、実際の接続に適用されたルールを確認しましょう。ルールを追加するときは対象を1つずつ設定し、ドメインとサブドメインの範囲を確かめてから、他のアプリに影響する広すぎるマッチを避けてください。
ルールは接続をどのプロキシグループに渡すかを決め、プロキシグループは実際に使う出口を決めます。手動選択グループは固定の出口を選ぶ場合に、遅延テストやフォールバックを行うグループは、それぞれの条件に応じた選択に適しています。まずグループが参照するノードやプロバイダーが存在することを確認し、そのうえでテスト先や間隔などの設定を調整してください。ルールにノードを直接指定するより、プロキシグループを参照すればルールを変えずに出口を変更できます。ただし、テストに成功しても、確認用の通信が届いたことを示すにすぎず、すべてのサイトやサービスが正常に使えるとは限りません。アクセス状況に差がある場合は、対象ドメイン、接続ログ、出口の対応状況をあわせて確認してください。
設定リファレンスを見る ›TUNは仮想ネットワークインターフェースで通信を受け取るため、システムプロキシ設定を参照しないアプリにも利用できます。まずクライアントが必要とするサービスやネットワークコンポーネントをインストールし、権限を確認してからTUNを有効にし、ルーティングとDNSの状態を確認しましょう。通常、TUNはシステムプロキシより広い範囲の通信を扱えますが、OSやルーティング設定、ほかのネットワークソフトとの互換性にも左右されます。有効にした後でLANに接続できなくなった場合は、すべてのプロキシノードをすぐに変更するのではなく、ルートの除外設定とDNSの結果を先に確認してください。デスクトップとモバイルでは権限の仕組みが異なるため、あるプラットフォームの手順を別のプラットフォームにそのまま適用しないでください。
設定リファレンスを見る ›TUNを有効にしても、すべての接続がプロキシを通るとは限りません。TUNで受け取った通信も、現在のモードとルールに従って処理されます。問題を調べるときは、まず対象の接続がクライアントの接続一覧に表示されるかを確認し、次に適用されたルールと最終的な出口を調べてください。モード、DNS、ノードを同時に切り替えるより、段階ごとに確認したほうが有効な手掛かりを残せます。別のVPNや仮想ネットワークアダプターを使っている場合は、元のルーティングとネットワーク状態を記録しておき、複数の通信制御機能が競合しないようにしてください。TUNを無効にするとアクセスが戻る場合は、プロトコルの調整より先にインターフェースの選択、ルーティングループ、名前解決を確認します。
設定リファレンスを見る ›DNSはドメイン名からIPアドレスなどの応答を得る仕組みで、後続のルール判定にも影響します。まずクライアントのDNS機能が有効か、システムやTUNからのDNSリクエストがクライアントに届いているかを確認し、次に上流DNSサーバーと名前解決モードを調べましょう。公共DNSサーバーのアドレスを置き換えるだけでなく、リクエストの経路を理解することが重要です。ブラウザーのセキュアDNS、アプリ内蔵の名前解決、システムキャッシュによって、確認できる結果が変わる場合があります。設定を変更する前に元の状態を記録し、同じドメインで名前解決と接続をテストして、どの段階で失敗するかを確認してください。暗号化DNSを使う場合は、上流サーバーへの通信経路が循環依存になっていないことも確認します。
設定リファレンスを見る ›Fake IPはドメインと接続の対応関係を保つための仕組みで、接続先サーバーの実際のIPアドレスを示すものではありません。一部のLANサービスや特殊なアプリで実際のDNS応答が必要な場合は、DNS機能全体を無効にするのではなく、フィルタールールの適用を検討してください。名前解決モードを全体的に切り替えるより、対象を絞った例外のほうが影響を管理しやすくなります。フィルターを追加する前に問題のドメインとアプリの動作を確認し、変更後は関連するキャッシュを消去して再試行してください。例外は必要な対象だけに適用し、LAN内のドメイン1つを直すためにすべてのサイトへ範囲を広げて、元のルール判定に必要なドメイン情報を失わないようにしましょう。
設定リファレンスを見る ›複数端末で使う場合は、サブスクリプションの取得元とルールの目的をそろえ、クライアントの設定をすべてコピーするのは避けましょう。デスクトップのリスニングポート、サービスのインストール先、TUNの権限は、通常スマートフォンにそのまま適用できません。各端末に同じ信頼できる取得元から設定を読み込み、システムでの通信制御方法を個別に設定して、プロキシグループ名を確認してください。アプリのデータを丸ごと同期するより、共有するルールと端末固有の設定を分けたほうが管理しやすくなります。クラウド同期の対応状況や対象項目は、クライアントの実際の機能を確認してください。サブスクリプションを共有しても、端末ごとのプロキシ選択が自動でそろうとは限りません。切り替え後はそれぞれの端末で動作を確認しましょう。
設定リファレンスを見る ›サブスクリプションの更新でリモート設定が再生成される場合があるため、個人用の変更はクライアントが対応するオーバーライドやマージ機能に追加してください。まずリストのマージ方法を確認します。設定箇所によって、全体を置き換えるものもあれば、先頭への追加や末尾への追加に対応するものもあり、動作は一律ではありません。サブスクリプションのキャッシュファイルを直接編集するより、個別のオーバーライドのほうが移行や復元が容易ですが、プロキシグループの参照先が存在するか確認する必要があります。別の端末に設定を移すときは必要な項目だけを選び、端末固有のパスやコントロールAPI設定を含めないようにしてください。更新後は最終的に適用された設定を確認し、追加したルールがフォールバックルールより前にあることを確かめてから、対象の接続に正しく適用されるかテストします。
設定リファレンスを見る ›クライアント、カーネル、設定の取得元を分けて考えましょう。問題が起きたら、まず該当する動作を担うコンポーネントを特定し、適切なドキュメントとトラブル対処方法を確認してください。
Clash関連のソフトウェアは、単一の製品として一斉に更新されているわけではありません。過去のClashカーネル、その派生プロジェクト、各種GUIクライアントには、それぞれ異なるリリースとメンテナンスの範囲があります。mihomoはこのエコシステムで継続的に開発されているカーネルプロジェクトで、一般的なデスクトップクライアントはその上に設定管理、プロキシ切り替え、OS連携の画面を提供します。画面が似ていても、カーネルの機能や初期設定まで同じとは限りません。設定を移行するときは、実際に動作しているカーネルとクライアントのドキュメントを確認してください。
GUIクライアントのスイッチは、カーネル設定やOSの状態に影響することがあります。たとえばシステムプロキシのスイッチはOSのプロキシ設定を変更し、TUNのスイッチは仮想ネットワークインターフェースやルーティングに関わります。クライアントによっては起動時に最終的な設定を生成するため、ディスク上のYAMLファイルを編集しても、画面上の設定にすぐ反映されるとは限りません。設定が有効か判断するには、現在選択されている設定、オーバーライドの適用結果、再読み込みログをあわせて確認してください。ファイルを保存できたことだけで、反映されたと判断しないようにしましょう。
オープンソースコードを参照すれば、実装や設定項目の変遷を確認できますが、一般ユーザーがアプリをインストールするためにソースコードの取得は必要ありません。初めて使う場合は、ダウンロードページからOSに合ったクライアントを選んでください。カーネルの動作を確認する必要がある場合は、mihomoプロジェクトのドキュメント、リリースノート、関連コードを参照します。当サイトは日本語で確認できる情報と設定項目の解説を提供します。異なるクライアントをひとつの製品として扱ったり、プロジェクトのメンテナーに代わって互換性を保証したりするものではありません。
Clash for Windowsはサポート終了後も、既存の環境で動作する場合があります。ただし、今後のOSやプロトコル、設定項目に対応し続けるとは限りません。移行先を選ぶときは、メンテナンス状況、使用カーネル、端末のアーキテクチャ、現在の設定で必要な機能を確認しましょう。名前が似ているという理由だけで置き換えると、システムサービス、設定ディレクトリ、自動起動項目の違いを見落とし、プロキシのプロセスが重複して動作するおそれがあります。
移行前に現在の設定をエクスポートまたはバックアップし、ローカルのリスニングポート、使用中のプロキシグループ、独自ルールを記録してください。新しいクライアントを初めて起動したときは、設定を読み込んでも、通信制御機能をすぐにすべて有効にする必要はありません。構文を確認した後、対象をひとつ決めてテストし、接続がクライアントに表示されること、適用されたルールと実際の出口を確認します。この経路が正常に動作してから、オーバーライド、LAN接続、TUNなどの設定を移行してください。
ポートが使用中の場合は、旧クライアントやバックグラウンドサービスがまだ待ち受けていないか確認してから、プロセスを終了するかポートを変更します。競合を解消するために、古い設定ディレクトリをいきなり削除しないでください。mixed-port を変更した場合は、プロキシアドレスを手動設定しているアプリ側も変更する必要があります。カーネルが正常に起動しても、アプリが旧ポートに接続し続ける可能性があります。よくある違いは FAQ を、具体的な手順は Clash設定ガイド を確認してください。
ソースコードが公開されていても、すべてのサブスクリプション、変換サービス、通信出口が信頼できるとは限りません。クライアント、設定の提供元、通信出口サービスはそれぞれ役割が異なり、クライアントをダウンロードしただけでリモートサービスを利用できるわけではありません。サブスクリプションを追加する前に、入手元と用途を確認し、設定に含まれるプロキシ、ルール、上流DNSを把握してください。不明な提供元から入手した完全な設定は通信経路を変えるおそれがあるため、読み込み後も重要な項目とプロキシグループを確認しましょう。
サブスクリプションURLにはアクセス用の認証情報が含まれる場合があり、設定ファイルにはアカウント、パスワード、専用サーバーの情報が含まれることもあります。問い合わせるときは、クライアント名、OS、エラーメッセージ、機密情報を削除した最小限の設定例を提示してください。設定ファイル全体をそのままアップロードしないでください。スクリーンショットにも、アドレスバー、QRコード、ログ内の機密情報が写っていないか確認しましょう。ルールの問題を説明する場合は、通常、ルールの順序、関連するプロキシグループ名、対象接続に適用された結果があれば十分です。
トラブル対処では、できるだけテスト条件を一定に保ちましょう。対象をひとつ、通信制御方法をひとつ、出口をひとつに固定してから、DNS、ルール、接続結果を確認します。サブスクリプション、ノード、モード、DNS設定を同時に変更すると、アクセスが回復しても原因を特定しにくくなります。動作する基準設定を保管し、項目をひとつずつ変更して結果を記録するほうが、出所不明の設定を大量にコピーするより長期的な管理に役立ちます。職場のネットワークや管理対象の端末では、その環境のネットワーク利用規則も守ってください。
クライアント、カーネル、サブスクリプション、ルール用データは、それぞれ別々に更新されます。アプリを更新してもリモートのサブスクリプションが更新されるとは限らず、サブスクリプションを更新しても新しい設定項目にカーネルが対応しているとは限りません。設定項目を解析できない場合は、まずどのカーネル向けの項目かと適用範囲を確認し、次にクライアントが実際に使用しているカーネルの情報を調べてください。設定の解析エラーをノードへの接続不良と決めつけないようにしましょう。発生する段階が異なるため、必要な調査情報も異なります。
GeoIPやルール用データを使う場合は、設定が参照しているデータ形式、保存場所、更新方法を確認してください。ファイル名を変えただけではカーネルがそのファイルを読み込むとは限らず、ファイルが存在していても現在のルールで使われているとは限りません。変更後に設定を再読み込みし、ログにデータの読み込みエラーがないか確認してから、対象の接続に適用されたルールを調べます。リモートのルールプロバイダーを使う場合は、データのダウンロード失敗、形式の誤り、ルール順の問題をそれぞれ分けて確認してください。
動作確認では、ウェブページを開けることは最初の一歩にすぎません。直結が必要なLAN内のサービス、システムプロキシを使わないアプリ、端末がスリープから復帰した後の動作も確認しましょう。ノードの速度テストで分かるのは、指定されたテスト通信の結果であり、実際のサービスの動作確認の代わりにはなりません。問題が起きたら、発生条件、エラー内容、直近の変更を記録し、ポート、名前解決、ルール、出口の順に原因を絞り込みます。設定項目の解説とYAMLの例は 設定リファレンス をご覧ください。
具体的な問題に応じて操作手順を確認してください。まず通信の流れを段階ごとに把握し、関連する設定を変更しましょう。複数の項目を一度に変更しないようにしてください。
仮想ネットワークアダプターとHTTPプロキシという2つの通信制御方式を取り上げ、対象範囲、DNS処理、互換性を比較し、用途に合った方法を選ぶためのポイントを解説します。
通信制御方式の比較を読む ›ルーターやバイパスルーターでmihomoカーネルを直接動かす際の構成、ゲートウェイとDNSの指定方法、透過プロキシの基本設定を解説します。
バイパスルーターの導入ガイドを読む ›サブスクリプションURLの追加方法や更新間隔の設定に加え、Clash YAMLやBase64形式のノード一覧など、よく使われる形式の違いと互換性を解説します。
サブスクリプションの追加方法を読む ›