DESKTOP / 01
Windows
日常的なデスクトップ環境に適しています。ダウンロード前に「設定 → システム → システム情報」でx64アーキテクチャを確認し、Clash Plus、Clash Verge Rev、FlClashなどのGUIクライアントから選びます。インストール後は設定画面でサブスクリプションを追加し、システムプロキシまたはTUNモードを個別に有効にしてください。クライアントが起動しているだけでは、通信が制御されているとは限りません。
ダウンロードページへSUBSCRIPTION CONFIG MANUAL
デバイスに合うクライアントを選び、サブスクリプションURLの追加、プロキシグループの確認、トラフィック制御を順に行います。各手順には、クライアント内の実際の操作項目と確認できる状態があります。
サブスクリプションURLは設定を受け渡すためのものです。追加後は、現在の設定、プロキシグループ、プロキシモード、システム側の制御状態を確認する必要があります。接続に問題がある場合は、この流れに沿って各段階を調べると、クライアントを何度も再インストールするより原因を特定しやすくなります。
PLATFORM OUTPUT
まずOSを確認し、現在もメンテナンスされ、デバイスのアーキテクチャに適したクライアントを選びます。トップページのリンクは対応プラットフォームへ案内するためのものです。インストーラー、動作要件、クライアントごとの違いはダウンロードページでまとめて確認できます。
DESKTOP / 01
日常的なデスクトップ環境に適しています。ダウンロード前に「設定 → システム → システム情報」でx64アーキテクチャを確認し、Clash Plus、Clash Verge Rev、FlClashなどのGUIクライアントから選びます。インストール後は設定画面でサブスクリプションを追加し、システムプロキシまたはTUNモードを個別に有効にしてください。クライアントが起動しているだけでは、通信が制御されているとは限りません。
ダウンロードページへDESKTOP / 02
まず「このMacについて」でAppleシリコンとIntelプロセッサを確認します。2種類のインストーラーは共用できません。初回起動時には、アプリの起動、ネットワーク拡張、管理者権限の許可を求められることがあります。サブスクリプションの追加後は、システムプロキシでブラウザの通信を確認し、ターミナルや開発ツールなども制御する必要がある場合にTUNを有効にします。
ダウンロードページへMOBILE / 03
近年の多くのデバイスではARM64版を利用できます。アーキテクチャが不明な場合は、ダウンロードページでユニバーサル版や他のアーキテクチャ向けの説明を確認してください。Androidクライアントは通常、システムVPNインターフェースで通信を制御します。初回接続時にはVPN許可の確認が表示されます。サブスクリプション追加後は、現在の設定、プロキシグループ、バックグラウンド実行権限を確認し、省電力機能による接続終了を防ぎます。
ダウンロードページへMOBILE / 04
iPhoneとiPadではApp StoreからClash Plusをインストールします。サブスクリプションを追加するには、完全なURLをコピーしてアプリ内に貼り付けるか、提供元の案内リンクを利用します。初回接続ではVPN構成の追加を許可する必要があります。設定が更新されてもプロキシグループが変わらない場合は、システムステータスバーのVPN表示だけでなく、アプリで現在使用中の設定ファイルとプロキシグループを確認してください。
ダウンロードページへDESKTOP / 05
デスクトップ環境ではClash Verge RevまたはFlClashを選べます。サーバー、ソフトウェアルーター、自動化環境ではMihomoコアを直接実行する方法が適しています。GUIクライアントを使う場合も、パッケージ形式がディストリビューションに合っているか確認してください。コアを使う場合は、設定ファイルのパス、起動パラメータ、サービス権限、ログを自分で管理する必要があります。2つの利用方法では操作項目が異なるため、手順を混在させないでください。
ダウンロードページへSELECTION CHECK
GUIクライアントは、トレイメニュー、プロキシグループの選択、システムプロキシの切り替え、設定更新画面を使いたいデスクトップユーザーに適しています。コアプログラムは、コマンドライン、サービス管理、YAML設定に慣れたサーバーやルーター環境に向いています。古いクライアントが起動できても、開発停止後は新しいコアの項目やOSの変更に対応しない可能性があります。移行時は、サブスクリプションURL、オーバーライド、自作ルールを優先して保存し、新しいクライアントで制御方式を確認してください。
デバイスのアーキテクチャも別に確認すべき条件です。Windowsではx64、macOSではApple SiliconとIntel、AndroidではARM64、ARM、ユニバーサル版などがあります。インストーラー名のアーキテクチャ表記はデバイスに合わせてください。ダウンロード後にインストールできない場合は、別の同名インストーラーを続けて試す前に、アーキテクチャとOSバージョンを確認します。
すべてのクライアントと動作要件を見る →RECEIVE CHAIN
Clashの設定は単一のスイッチではありません。サブスクリプションの解析、ルールによる振り分け、DNS処理、自動更新が同じ通信フローに順番に作用します。左側のナビゲーションで確認項目を切り替え、朱色のマークで現在の説明位置を示します。
CONFIG INPUT / CHANNEL 01
クライアントがサブスクリプションURLにアクセスすると、プロキシノード、プロキシグループ、ルール、DNS項目などを読み込み、ローカル設定として保存します。追加に成功したことは、内容がクライアントに書き込まれたことを示すだけです。現在の設定として選択されたことや、通信がプロキシ経路に入ったことを意味しません。設定名、更新日時、選択状態を確認し、プロキシグループにノードが正常に表示されるか確認してください。
追加後に内容が空の場合は、まずURLが完全にコピーされているか、サブスクリプションが有効か、クライアントからURLにアクセスできるかを確認します。ブラウザでテキストが表示されても、クライアントが正常に解析できるとは限りません。レスポンス形式、リダイレクト、項目の互換性が結果に影響します。再追加の前に手動更新を実行し、設定読み込みに関するクライアントログを確認してください。
RULE PROCESS / CHANNEL 02
ルールは、ドメイン、IP、プロセス、ネットワーク種別をどのプロキシグループに送るか判断し、プロキシグループが指定ノード、自動選択、フォールバック、直接接続、拒否を決定します。ノードのテスト結果は選択の参考であり、ルールマッチングの代わりにはなりません。特定サイトの接続を調べるときは、まず現在のモードを確認し、どのルールに一致したか、どのプロキシグループに入ったか、そのグループでどの出口が選ばれているかを確認します。
グローバルモードでは大部分の通信を1つの出口に渡し、ルールモードではルール一覧を上から順に照合し、ダイレクトモードではプロキシノードを使いません。日常利用では通常、ルールモードから始めます。カスタムルールは正しい位置に置いてください。前にある広範なルールが先に一致すると、後ろの具体的なルールが機能しなくなるためです。ノードを切り替えた後は既存の接続が終了するのを待ち、新しいリクエストで確認します。
NAME RESOLUTION / CHANNEL 03
ClashはDNSクエリを制御し、解決結果をルールシステムで処理できます。Fake-IPモードは仮想アドレスでドメインとの対応を作り、接続時にドメイン情報を保持しやすくします。Redir-Hostモードは実際の名前解決結果に近い方式です。どちらが常に正しいというわけではなく、システム環境、LANサービス、ゲーム、特殊なアプリとの互換性に応じて選びます。
Webサイトのドメインには接続できないがIPアドレスなら接続できる、LAN機器名が使えない、アプリが何度も再接続するといった場合は、DNSも確認対象にします。まずDNS機能の有効状態、待受ポートの競合、上流DNSサーバーへの到達性を確認し、その後Fake-IPの除外リストを確認します。システム、ブラウザ、クライアントがそれぞれ解決結果をキャッシュすることがあるため、設定変更後はキャッシュを削除するか関連アプリを再起動して確認してください。
CONFIG REFRESH / CHANNEL 04
サブスクリプション更新に対応したクライアントでは、設定を指定間隔で再取得できます。更新によってノードの増減、プロキシグループ、ルールが変わる可能性があるため、完了後は現在の設定が有効か、よく使うプロキシグループの選択がリセットされていないか確認します。設定オーバーライドに対応している場合は、オーバーライドがサブスクリプション内容の前後どちらで適用されるかを確認し、次回更新でローカル変更が置き換わらないようにします。
自動更新に失敗したら、まず手動更新を実行してエラー内容を確認します。一般的には、サブスクリプションURL、ネットワーク到達性、システム時刻、設定形式、保存権限の順に調べます。更新間隔を極端に短くしても接続品質は改善せず、重複リクエストを増やすだけです。クライアントが対応する標準的な間隔を使い、サービス提供元から設定変更の案内があったときに手動更新を実行してください。
OPEN SOURCE RECORD
Clashエコシステムは、コア、GUIクライアント、設定形式、コミュニティのメンテナンスプロジェクトで構成されています。クライアントを使い続けるべきか判断する際は、画面の名称だけでなく、コード、リリース履歴、コアとの互換性、OSサポートを確認します。
HISTORY / 01
Clashでは当初、ルールマッチング、プロキシグループ、YAML設定などの操作方法が広まり、その後プラットフォームごとのGUIクライアントが登場しました。一部の旧プロジェクトが開発停止した後も、コミュニティは互換コアや新しいクライアントを中心に開発を続けています。現在「Clash クライアント」で検索すると、似た名称のプログラムが複数見つかりますが、使用するコア、画面、配布経路が異なる場合があります。
選ぶ際は、次の3点を個別に確認します。クライアントが最近も更新されているか、搭載コアが現在のサブスクリプション項目に対応しているか、インストーラーがデバイスのOSとアーキテクチャに合っているかです。古いガイドとはメニュー名が異なる場合がありますが、設定フローは「設定を追加—プロキシを選択—通信制御を有効化—ログを確認」の順に理解できます。
ECOSYSTEM / 02
Mihomoなどの互換コアは、設定の解析、接続の確立、ルールの実行、DNS処理、制御インターフェースを担当します。Clash Plus、Clash Verge Rev、FlClashなどのクライアントは、コアの外側でインストール、設定管理、トレイ操作、システムプロキシの切り替え、可視化ログを提供します。GUIクライアントの使いやすさと、コアが特定の設定項目に対応しているかは別の問題です。
障害を調べるときも、層を分けて考える必要があります。インストール失敗は通常、OSまたはクライアント層の問題です。YAMLエラーは設定解析層、サイトが誤って振り分けられる問題はルールまたはプロキシグループ層、特定アプリだけがプロキシを経由しない問題はシステムプロキシ、TUNルーティング、アプリ独自の通信処理に関係することが多いです。問題の層を明確にすると、無関係な設定を変更せずに済みます。
CORE RELATION / 03
クライアントにある「ルールモード」「LANを許可」「TUNモード」「DNS強化モード」などのスイッチは、最終的に設定項目へ書き込まれるか、コアの起動パラメータに変換されます。画面では項目の詳細が隠れていても、基盤での作用は変わりません。クライアントを移行するとき、サブスクリプションURLは再追加できますが、カスタムオーバーライド、スクリプト、ルールプロバイダー、ローカルDNSの例外は個別に整理する必要があります。
コアを直接使うユーザーは、設定パス、制御ポート、サービス起動、ログローテーションを自分で管理する必要があります。GUIクライアントはその一部を代行します。どちらも同じ、または近い設定概念を使いますが、操作手順をそのまま流用することはできません。当サイトの入門ガイドはGUIクライアントを中心に説明し、設定項目ページではYAMLの階層に沿ってコアが実際に読み込む内容を解説します。
UPDATE POLICY / 04
クライアント更新は画面、インストール、OS対応の問題を修正します。コア更新はプロトコル、ルール、DNS、ルーティング機能を拡張します。サブスクリプション更新はサービス提供元から受け取った設定を更新するだけです。これら3種類の更新は互いの代わりにはなりません。接続に問題がなければ、バージョンを追うためにすべての構成要素を頻繁に変更する必要はありません。互換性の問題が起きたら、まずどの層で変化したかを確認します。
クライアントをアップグレードする前に、現在のサブスクリプションURL、プロキシグループの選択、ローカルオーバーライドを記録しておくと安心です。アップグレード後は、設定を読み込めるか確認し、システムプロキシまたはTUNの権限が維持されているかを確認します。サブスクリプションの自動更新後にプロキシグループが変わった場合は、更新日時と設定内容を照合し、すぐにクライアントを戻さないでください。ログに出る項目エラー、権限エラー、ネットワークエラーは分けて対処します。
SOURCE CHECKOUT
コアの動作を確認する必要がある場合は、公開リポジトリで設定の実装、課題、リリースノートを確認できます。クローンコマンドはソースコードを取得するだけで、GUIクライアントをインストールしたり、利用可能なサブスクリプションを自動生成したりするものではありません。一般ユーザーはクライアントのダウンロードページからインストーラーを選び、開発者やルーター管理者はビルドドキュメントを参照してください。
git clone https://github.com/MetaCubeX/mihomo.git
QUICK DIAGNOSIS
以下の質問では、確認すべき方向をすばやく判断できます。詳しい手順、プラットフォームごとの差異、障害対応についてはヘルプセンターを参照してください。
まず追加した設定が現在の設定として選択されているか確認し、次にクライアントでシステムプロキシが有効か確認します。クライアントを起動したりノードを選択したりするだけでは、すべてのアプリの通信経路は自動的に変わりません。ブラウザが独自のプロキシ設定、拡張機能、セキュアDNSを使っている場合は、それらがシステムプロキシを上書きしていないかも確認します。
デスクトップ環境では、まずシステムプロキシでブラウザやシステム設定に従うアプリを確認することをおすすめします。ゲーム、ターミナル、ストアなどがシステムプロキシを利用しない場合に、TUNモードを検討してください。TUNは対象範囲が広い一方、追加の権限が必要で、仮想マシン、他のVPN、セキュリティソフトのネットワークドライバーと競合する可能性があります。
サブスクリプションの更新でプロキシグループが再構築されたり、ノード名が変更されたりすることがあります。以前の選択項目が存在しなくなると、クライアントはプロキシグループのデフォルト値に戻ります。更新後は、よく使うプロキシグループを開いて出口を再確認してください。オーバーライドに対応している場合は、結合順序を理解したうえでローカル設定の一部を固定できますが、次回更新で上書きされるサブスクリプションファイルを直接編集しないでください。
まずアプリがシステムプロキシを利用するか確認し、次にリクエストがクライアントログに記録されているか確認します。ログに記録がなければ問題は通常、通信の入口にあります。記録はあるもののルールに一致しない場合は、ルールとプロキシグループを確認します。ドメイン解決に問題がある場合は、DNSモード、キャッシュ、除外項目を調べます。入口、ルール、出口、DNSの順に切り分けてください。
CONFIG NOTES
記事では、設定構造、ルーティング方式、クライアント移行をそれぞれ解説しています。特定の問題を解決したい場合は、入門手順を最初から読む必要はなく、該当するテーマへ直接進めます。
実際の読み込み順に沿って、ポート、DNS、プロキシノード、プロキシグループ、ルール項目を分解し、インデント、参照、項目の上書き関係を解説します。
サブスクリプションの追加を終え、設定ファイルを読み取ったり変更したりしたいユーザー向けです。各セクションの参照関係と、項目が存在していても実際の動作設定に反映されない理由を重点的に説明します。
動作レイヤー、アプリの互換性、DNS処理、必要な権限から2つの通信制御方式を比較し、一般的なデバイス環境での選択基準を示します。
「ブラウザは正常なのに他のアプリが接続できない」「TUNを有効にしたらネットワークに問題が出た」といった場合に適しています。通信の入口から違いを説明し、切り替え前に確認すべき権限、ルート、競合項目を整理します。
継続利用できるクライアントを整理し、サブスクリプション、オーバーライドルール、システムプロキシ設定の移行方法と、切り替え前後の確認項目を解説します。
移行で重要なのは、古いプログラムのフォルダをコピーすることではなく、再利用できる設定とクライアント固有の状態を分けることです。サブスクリプション、オーバーライド、自作ルール、通信制御設定をそれぞれ記録し、再構築する方法を説明します。