Windows
OSの種類とプロセッサアーキテクチャを確認してから、インストーラーを選びます。システムプロキシはブラウザーなどに適しています。ストアアプリではUWPのループバック制限も個別に確認してください。
ダウンロード WindowsクライアントまずOSを確認し、次にCPUアーキテクチャに合ったものを選びます。ダウンロードページでは、クライアントごとの対応アーキテクチャとインストール先を確認できます。メニューの位置は異なっても、サブスクリプション、プロキシグループ、通信の入口の基本的な関係は共通です。
OSの種類とプロセッサアーキテクチャを確認してから、インストーラーを選びます。システムプロキシはブラウザーなどに適しています。ストアアプリではUWPのループバック制限も個別に確認してください。
ダウンロード Windowsクライアント「このMacについて」でApple SiliconかIntelかを確認します。インストール後に設定を読み込み、システムプロキシを有効にしてください。TUNモードを使う場合は、クライアントの案内に従ってサービスと権限を設定します。
ダウンロード macOSクライアントデバイスのアーキテクチャに合ったインストーラーを選びます。初回接続時は通常、VPNの使用許可が必要です。他のVPNアプリを使っている場合は競合を確認し、必要に応じてアプリごとのプロキシ設定やバックグラウンド実行の権限を設定してください。
ダウンロード AndroidクライアントダウンロードページからClash PlusのApp Storeページに進みます。インストール後、対応する設定を読み込み、システムVPNの使用を許可してください。クライアントの詳細は公式サイトclashplus.ioで確認できます。
ダウンロード iOSクライアントデスクトップではディストリビューションに合ったパッケージを選び、サーバーでは必要に応じて単体のコアを検討します。デスクトップのプロキシ設定、サービス権限、ルーティング管理はそれぞれ独立しているため、インストール後に個別に確認してください。
ダウンロード Linuxクライアントクライアントのインストーラーにサブスクリプションサービスは含まれません。利用権限のある設定ソースを用意し、使用可能なプロキシノード、プロキシグループ、ルールが含まれているか確認してください。別のデバイスへ移行する際は、元のサブスクリプションか設定のバックアップを使い、スクリーンショットだけを頼りに再設定しないでください。
すべてのクライアントを見る →システムプロキシはアプリからクライアントへリクエストを渡す方法を決め、通信モードは受け取ったリクエストの処理方法を決めます。この2つを分けて考えることで、すべてのスイッチを有効にせず、変更すべき設定を判断できます。
まずはルールモードから使い始めましょう。
ルールモードでは、設定の記述順に従ってルールを照合し、通信の経路を選びます。ローカルサービスと外部リソースを併用する場合に便利です。グローバルモードは、コアに届いたリクエストを通常グローバルプロキシグループへ送るため、一時的な比較やテストに使えます。DIRECTモードではプロキシを介さずにアクセスした結果を確認できます。モードを切り替えてもノードは自動作成されず、クライアントに届いていないアプリの通信も取り込まれません。プロキシグループに利用可能な選択肢があることを確認してから新しいリクエストを送り、接続ページで実際の経路を確認してください。既存の長時間接続は、切り替え前の経路を使い続ける場合があります。
システムプロキシを有効にすると、OSのネットワーク設定がクライアントのローカル待ち受けアドレスを参照します。この設定に従うブラウザーやデスクトップアプリに適しています。有効にする前にコアを起動して有効な設定を選び、混合ポートはクライアントに表示されている値を確認してください。一部のコマンドラインツール、ゲーム、独自のプロキシ設定を持つアプリは自動でこの入口を使わないため、個別設定またはTUNモードの検討が必要です。終了後にネットワークへ接続できなくなった場合は、システムプロキシが停止中のローカルサービスを参照したままになっていないか確認してください。すぐにサブスクリプションを変更したり、再インストールしたりする必要はありません。
TUNモードは仮想ネットワークインターフェースとルーティングを使って通信を取り込み、システムプロキシ設定に従わないアプリにも対応します。ただし、有効な設定と利用可能な通信経路、適切なDNS処理が必要で、すべてのリクエストがプロキシ経由になるわけではありません。有効にする前に、選択したクライアントのサービス導入手順を確認し、管理者権限や他のVPN、仮想ネットワークアダプター、セキュリティソフトへの影響に注意してください。ローカルデバイスに接続できない、または名前解決に失敗する場合は、まずTUNを無効にして比較し、ルート除外とDNS設定を確認します。原因を特定しやすくするため、一度に変更する設定は1つにしてください。
rules:
- DOMAIN-SUFFIX,apple.com,DIRECT
- GEOIP,LAN,DIRECT
- MATCH,Proxy
ルールは通常、上から順に照合され、最初に一致した項目がリクエストの経路を決めます。ドメインサフィックスルールは関連ドメインのまとめ指定に、プロセスルールはアプリ単位の判定に使えます。ルールセットでは、多数のルールを外部リソースで管理できます。編集時はポリシー名がプロキシグループと一致しているか確認し、具体的なルールをフォールバック用のルールより前に置いてください。例にあるProxyは、実際に存在するプロキシグループを指す必要があります。そのままどの設定にもコピーできるわけではありません。変更後は設定を読み込めるか確認し、接続の詳細で一致したルールを調べてください。ページが開けるかどうかだけで正しさを判断しないようにしましょう。
接続ページではリクエスト先、一致したルール、通信経路を確認でき、ログページでは設定の読み込みや解析、接続中のエラーを追跡できます。問題を調べるときは、エラーが出たアプリと発生時刻を記録し、もう一度リクエストを送って確認範囲を絞りましょう。接続ページに該当リクエストがない場合は、まず通信の入口を確認します。リクエストがあるのに接続できない場合は、DNS、ノード、接続先サービスを確認してください。一時的にログレベルを上げると手がかりが増えますが、調査後は通常のレベルに戻します。ログを共有する前に、サブスクリプションURL、ノードの認証情報、個人のアクセス内容を削除してください。
設定ページでは、サブスクリプションURL、ローカルファイル、現在有効な設定を管理します。読み込みに成功した後、その項目を選択し、プロキシページに想定したプロキシグループが表示されるか確認してください。サブスクリプションURLを保存しただけでは、コアの設定は切り替わりません。リモート更新でサブスクリプションファイルに直接加えた変更が上書きされることがあります。長期的に残すルールには、クライアントが対応するオーバーライドまたはマージ機能を使ってください。サブスクリプション変換では元の設定を変換サービスに渡すため、処理内容と信頼性を確認しましょう。ソースを変更する前に復元可能な設定のコピーを保存し、認証情報を含むファイルは公開リポジトリに登録しないでください。
まず必要最小限の設定で、再現できる接続を1回確立してから、ルールや通信の取り込み範囲を広げます。問題が起きても、検証済みの設定に戻って原因を探せるため、最初から推測し直す必要がありません。
デバイスのアーキテクチャに合ったクライアントをインストールし、設定ページでURLまたはローカルファイルから読み込みます。解析が終わったら項目を選択し、プロキシページに想定したプロキシグループが表示されることを確認してください。読み込みエラーが出た場合は、URLにアクセスできるか、取得した内容が設定ファイルか、現在のコアがその項目に対応しているかを確認します。
サブスクリプションURLにはアクセス認証情報が含まれる場合があります。コピー時に余分な空白を入れず、URL全体を公開の掲示板に貼り付けないでください。既存のクライアント設定がある場合は、まずコピーを保存します。サブスクリプションソースの変更と通信の入口の変更は分けて行い、複数の変更を一度に加えて原因が分からなくなるのを防ぎましょう。
プロキシページで使用する通信経路を選び、ルールモードのまま、現在のOSに合った通信の入口を有効にします。デスクトップアプリでは、まずシステムプロキシから試すのがおすすめです。他のアプリも対象にする必要があれば、ガイドに従ってTUNを設定してください。モバイルではOSの案内に従ってVPNの使用を許可し、他の接続が同じ機能を使用中でないか確認します。
ノードの遅延値は、特定のテストリクエストの結果を示すにすぎず、ダウンロード速度やすべてのサイトでの使い心地を直接表すものではありません。まず正常に接続できる経路を選び、実際に使うサービスへのアクセスを確認してから、自動選択の利用を検討してください。遅延が低いという表示だけで、ルールが正しく適用されたと判断しないでください。
対象のページやアプリを開き直し、接続ページで該当するリクエストを探して、接続先、一致したルール、実際の通信経路を確認します。同時にローカルサービスへ引き続きアクセスできることも確認してください。クライアントが起動中というだけでは、アプリがプロキシを使っている証拠にはなりません。入口、ルール、通信経路の3つが対応していることを確認して初めて、設定が意図どおりと判断できます。
接続に失敗した場合は、まず現在のエラー記録を残し、設定、入口、DNS、ノードを順番に確認します。プロキシを無効にした後、システムのネットワーク接続が復旧することも確認してください。リモートワークやLAN内のデバイスへのアクセスが必要な場合は、社内ドメインやアドレスのルールも確認し、業務中にルーティングが競合するのを防ぎましょう。
Clashは設定、ルール、通信経路を基盤とするプロキシツールのエコシステムです。各クライアントが同じプロジェクトというわけではありません。機能の対応状況を確認するには、画面を提供するプロジェクト、使用するコア、現在の設定をあわせて確認し、名前が似ていることだけで判断しないでください。
オリジナルのClashが採用したルール設定方式は、多くのデスクトップ・モバイルクライアントに影響を与えました。元のプロジェクトがメンテナンスを終了した後も、コミュニティでは独立したコアやGUIプロジェクトが開発されています。プロトコル対応、DNSの動作、設定項目、OSとの連携には、それぞれ違いが生まれています。古いガイドは基本概念の理解に役立ちますが、ダウンロード先、権限の設定手順、メニュー画面が現在のクライアントと一致するとは限りません。
クライアントを選ぶ際は、まずメンテナンス状況とOS対応を確認し、必要なプロトコルを使えるか調べましょう。アーカイブ版のクライアントは既存環境との互換性を調べる用途に向いています。ガイドの画面に見覚えがあるからといって、新規インストールで優先して使うべきではありません。古い設定を読み込めない場合は、元ファイルを残してエラー内容を確認し、現在のコアの設定項目に沿って移行してください。認識できない項目をすべて削除するのは避けましょう。
GUIクライアントは設定管理、メニューバーやトレイからの操作、システムプロキシの切り替え、OS権限との連携を担います。コアは設定の解析、ルールの照合、通信経路への接続を担います。mihomoはClash Metaの後継として使われているプロジェクト名で、ソースコードや設定ドキュメントを公開しています。クライアントがこのコアを採用していても、コアの全機能がGUIに表示されるとは限らず、関連機能が初期設定で有効になっているとも限りません。
たとえば、プロセス照合にはOSと権限の対応が必要です。ルールセットには正しいリソースURLとポリシーの参照が必要で、DNSの動作は設定や通信の取り込み方法によって変わります。機能名を見かけたら、それがクライアントの設定かコアの項目かを確認してから、対応するドキュメントを参照してください。GUIにボタンがないからコアが未対応だと誤解したり、別のクライアント専用のオーバーライド形式をそのまま使ったりするのを防げます。
クライアントをインストールしても、ローカルツールの準備ができるだけです。ノードの認証情報、プロキシグループ、ルールは選択した設定に含まれ、実際の接続可否はサービスの状態、ローカルネットワーク、接続先、ルーティングにも左右されます。このサイトではクライアントのダウンロード先と設定方法を案内しますが、サブスクリプション提供元のアカウント管理を代行するものではなく、画面の遅延値だけで通信品質を保証するものでもありません。設定を使う前に、提供元、利用許可の範囲、有効期限を確認してください。
Clashのサブスクリプション変換では、元のURLが変換サービスに渡る場合があります。クライアントが直接読み込める互換設定なら、まず直接読み込みを試してください。変換が必要な場合は、変換サービスの信頼性、対応項目、ルールの処理方法を確認します。問題を共有する際は必要最小限の、機密情報を削除した抜粋だけを使い、ノードのパスワード、サブスクリプションURL、個人のアクセス記録を含むログ全体を公開しないでください。
クライアント、コア、サブスクリプションの更新はそれぞれ別のものです。クライアントの更新では主に画面やOS連携が変わり、コアの更新ではプロトコル対応や設定の解析方法が変わることがあります。サブスクリプションの更新ではノード、プロキシグループ、ルールが置き換わります。問題が起きたら、直近で変更したのがどの層かを記録し、復元できる設定を残して、該当プロジェクトの更新内容を確認しましょう。すべてのコンポーネントを同時に更新するより、原因を特定しやすくなります。
別のデバイスへ移行する場合は、まず移行先OSのアーキテクチャと権限要件を確認し、互換性のある設定を読み込みます。カスタムルールはクライアントが対応するオーバーライド機能で保存し、リモートサブスクリプションに上書きされないようにしてください。更新後は同じ接続先を使って通信経路とローカルネットワークへのアクセスを再確認します。古い設定を保存できても、新しい環境で同じ動作をするとは限りません。
ソースコードのリポジトリでは、コアの実装、設定ドキュメント、公開されている課題を確認できます。以下のコマンドはソースコードを取得するだけで、GUIクライアントをインストールしたり、システムプロキシを自動設定したりするものではありません。一般ユーザーは上のクライアントダウンロードリンクをご利用ください。
MetaCubeX / mihomoリポジトリを見る ↗git clone https://github.com/MetaCubeX/mihomo.git
初回接続が完了したら、通信がクライアントに届く仕組みや速度テストの見方、コアごとの設定の違いを確認しましょう。実際の問題に応じて調べればよく、初回インストール時にすべての詳細設定を変更する必要はありません。
mihomo(旧Clash Meta)で拡張されたプロトコル対応、rule-providers、スニッフィング、DNS設定を整理し、古い設定から移行する際に注意すべき項目の違いを解説します。
通信がクライアントに届く経路を起点に、アプリが設定に従うシステムプロキシと、ネットワーク層で通信を取り込むTUNの違いを比較。互換性、DNS処理、用途も解説します。
url-testの計測範囲を分解し、ハンドシェイク、テスト先、同時接続、回線混雑が画面の数値と実際の使い心地に差を生む理由を解説。ノードを適切に判断する方法も紹介します。