まずOSとプロセッサのアーキテクチャを確認してから、クライアントを選びます。インストーラーは画面と実行環境を提供するもので、実際に接続するには有効なサブスクリプションまたは設定ファイルが必要です。設定をすでに持っている場合は、ソフト名だけで互換性を判断せず、プロトコル、プロキシグループ、ルールが対象クライアントに対応しているかを確認してください。
Clash PlusやClash Verge RevなどのGUIクライアントから始めましょう。インストール前にシステム設定でデバイスのアーキテクチャを確認します。起動後は設定を読み込み、システムプロキシを有効にしてブラウザーで接続を確認してください。ゲームやコマンドラインなど、プロキシ設定を参照しないアプリの通信も取り込みたい場合は、サービスモードとTUNの権限を確認します。
アプリストアのアプリだけで問題が起きる場合は、UWPのループバック制限を確認してください。クライアントを切り替える際は、先に古いアプリを終了し、複数のプロセスが同時にシステムプロキシを書き換えたり、待ち受けポートを取り合ったりしないようにします。
ダウンロードへ「このMacについて」に表示されるチップを確認し、Apple SiliconまたはIntel向けのインストーラーを選びます。GUIクライアントではサブスクリプションやプロキシグループの管理、メニューバーからの切り替えができます。まずはシステムプロキシでWebサイトへの接続を確認しましょう。TUNを使うには追加のネットワーク権限が必要です。具体的な許可手順はクライアントの案内に従ってください。
ターミナルからのリクエストとブラウザーの結果が異なる場合は、まずターミナルのプロキシ環境変数を確認してください。システムプロキシを有効にしても、すべてのコマンドラインツールが同じ経路を自動で使うとは限りません。
ダウンロードへClash Plus、Clash Meta for Android、FlClashなどのクライアントを選べます。比較的新しいスマートフォンの多くはARM64ですが、端末情報でアーキテクチャを確認してください。サブスクリプションを追加して設定を選択した後、初回起動時にシステムのVPN接続要求を許可します。この許可により、端末内の通信を取り込むための経路が確立されます。
バックグラウンドで接続が切れる場合は、バッテリー最適化とバックグラウンド実行の制限を確認してください。アプリごとに通信を振り分ける場合は対象アプリの一覧を確認し、ほかのVPNアプリが接続を使用中でないかも調べます。
ダウンロードへダウンロードページからClash PlusのApp Storeページに進めます。公式サイト clashplus.io も確認できます。インストール後、クライアントに対応したサブスクリプションを追加し、設定が選択されていることを確認します。システムの案内に従ってVPN構成の追加を許可し、接続を開始して対象アプリで動作を確認してください。
サブスクリプションをダウンロードできることと、記載されたプロキシに接続できることは別の問題です。追加に失敗する場合はリンクと形式を確認します。接続後に一部のサイトだけ開けない場合は、ルール、DNS、接続先サービスの状態を調べてください。
ダウンロードへデスクトップ環境ではClash Verge RevやFlClashを選べます。インストール時は、ディストリビューションに合ったDEBやRPMなどのパッケージ形式を選んでください。サーバー、コンテナ、ルーターではmihomoコアを直接導入し、設定ファイルとサービスマネージャーで実行を管理できます。コマンドラインで導入する場合は、設定ディレクトリ、ファイル権限、ログ、起動時の自動実行を自分で管理する必要があります。GUIクライアントのようにスイッチ一つで済むわけではありません。
初回起動時はフォアグラウンドで設定を読み込めるか確認し、待ち受けアドレスを確かめてからsystemdに登録します。リモートマシンでTUNを有効にしたりデフォルトルートを変更したりする前に、独立した管理用接続を確保してください。プロキシ経由のルートによってSSHセッションが切断されるのを防げます。一般的なデスクトップユーザーは、まずGUIクライアントを使うと設定の問題を特定しやすくなります。
ダウンロードへ旧式のクライアントは、明確な互換性要件がある場合に限って検討してください。新たに導入する場合は、現在もメンテナンスされている選択肢を優先し、サブスクリプションとの互換性、必要な権限、対応OSをあわせて比較しましょう。
すべてのクライアントを見る → 用途に合わせて選ぶ →設定ファイルは通信先を定義し、クライアントは設定の管理と適用を担います。以下の例は項目間の関係を示すもので、そのまま接続に使える完全なサブスクリプションではありません。例にあるPROXYはプロキシグループ名のため、実際の設定内の定義と一致させる必要があります。TUNとDNSのパラメーターも実行環境に合わせて調整してください。
mode: rule
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,PROXYrulesは上から順に照合され、最初に一致したルールで接続先が決まります。ドメインサフィックスのルールは対象サイトを指定するのに適しており、GEOIPは接続先IPアドレスの地域による振り分けに使えます。残りの接続を受けるMATCHは最後に配置します。PROXYは定義済みのプロキシまたはプロキシグループに対応させてください。グローバルモードと異なり、ルールモードではリクエストごとに異なる接続先を選べます。変更前にアプリの通信がコアに届いているか確認し、接続ログで適用されたルールを調べましょう。リクエスト自体が表示されない場合は、ルールを追加するのではなく、先にシステムプロキシまたはTUNを確認してください。
設定項目とルールを見る →proxy-groups:
- name: PROXY
type: select
proxies:
- AUTO
- DIRECT
- name: AUTO
type: url-test
use:
- provider-main
url: https://www.gstatic.com/generate_204
interval: 300proxy-groupsを使うと、ルールの接続先と実際のプロキシを分けて管理できます。selectでは手動で選択でき、url-testでは指定したテスト先への接続結果に基づいて利用可能な接続先を選びます。例にあるprovider-mainはproxy-providersで別途定義する必要があり、この部分をコピーするだけでは起動できません。ルールを一つずつ変更する代わりに、プロキシグループを使えばルール名を維持したままグループ内の選択肢を入れ替えられます。テスト結果が示すのはテスト先への接続状況だけです。すべてのサイトでの使い心地を保証するものではなく、通信量の倍率、アカウントの容量、接続先サービスの地域制限も反映されません。
プロキシとプロキシグループの違いを見る →tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53TUNは仮想ネットワークインターフェースを使い、そのインターフェースにルーティングされた通信を取り込みます。システムプロキシ設定を参照しないアプリに適しています。auto-routeやインターフェースの検出方法は経路に影響するため、OSの権限とクライアントの実装に合わせる必要があります。通常、TUNはシステムプロキシより広い範囲の通信を取り込みますが、DNSやルーティング、ほかのVPNの状態にも左右されます。まずシステムプロキシでサブスクリプションの動作を確認してからTUNを有効にし、ログでアダプターとルートの情報を確認してください。リモート接続やLANアクセスに影響が出た場合は、グローバルモードへ切り替えるのではなく、まずルートの除外設定を確認します。
TUNとシステムプロキシの仕組みを比較 →サブスクリプションURL
↓ クライアントの「設定」でリモート設定を新規作成
YAMLを取得して解析
↓ 設定を選択し、読み込みログを確認
プロキシグループを確認
↓ システムプロキシまたはプラットフォームのVPNを有効化
対象のリクエストと適用ルールを確認サブスクリプションURLは設定を取得するためのもので、クライアントをインストールしただけではプロキシを利用できません。通常は設定画面でリモート設定を新規作成し、URLを貼り付けてダウンロードした後、その設定を選択してプロキシグループを確認します。ローカルのYAMLを手動編集する方法に比べ、リモート設定はサービス提供元の変更を同期しやすい一方、ダウンロードした内容を直接編集すると次回更新で上書きされることがあります。長期的に維持したいルールには、クライアントが対応する上書き機能を使ってください。URLにアカウントの認証情報が含まれる場合は安全に保管します。更新に失敗したら、変換を試す前にURLの有効性、ネットワーク接続、形式を確認し、機密性の高いURLを見知らぬ変換サービスに渡さないでください。
手順に沿ってサブスクリプションを追加 →クライアント、コア、設定の入手元を分けて考えると、更新がどの層に影響したのか判断しやすくなります。Clashガイドはダウンロード先と日本語の設定解説をまとめたもので、各クライアントのプロジェクト告知に代わるものではなく、プロキシサブスクリプションも提供していません。プロジェクトの状況、機能の範囲、ライセンスについては、それぞれの公開情報を確認してください。
Clashは当初、ルール駆動型のプロキシコアとして設定エコシステムを形成しました。元プロジェクトの公開メンテナンスが終了した後、コミュニティでは異なるコアやクライアントの開発が続いています。mihomoはClash Metaの開発方針を引き継ぎ、プロキシプロトコルの処理、ルール照合、DNS、トラフィックの取り込みなどの機能を提供します。名称が似ていても同じチームがすべてのプロジェクトを管理しているとは限らず、設定項目が異なる実装間でそのまま使えるとも限りません。
GUIクライアントは通常、コアを画面の裏側に組み込み、設定管理、サブスクリプションの更新、システムプロキシの切り替え、ログ表示を担います。プロトコルの非対応、認識できない項目、実行時の異常が起きた場合は、クライアント名と実際に使っているコアの情報をあわせて記録してください。「Clashが接続できない」だけでは、問題を再現する情報として不十分なことがよくあります。同じ設定でも、コアによって動作が異なる場合があります。
コアとクライアントの用語を確認 →mihomoのソースコード、ライセンス、リリースノート、問題に関する議論は公開リポジトリで確認できます。公開コードは項目の実装や動作の変更を追跡する手掛かりになりますが、手元の設定確認の代わりにはなりません。問題を報告する前に既存の議論を読み、OS、起動方法、エラーが起きるまでの手順、必要なログを記載してください。スイッチ画面のスクリーンショットだけを添付するのは避けましょう。
ログや設定には、サブスクリプションURL、プロキシの認証情報、アクセス履歴が含まれることがあります。共有する前にアカウント情報を削除し、問題の再現に必要な最小限の設定だけを残してください。トラブルは、設定の解析、ポートの待ち受け、通信の取り込み、ルールの選択、接続先への通信という段階に分けて調べられます。まず失敗した段階を特定してから、関連する実装を確認するか報告してください。複数のパラメーターを一度に変更するより、確実な結論を得やすくなります。
mihomoのオープンソースリポジトリを見る ↗コマンドの実行には、ローカルにGitがインストールされている必要があります。cloneで取得できるのはソースコードであり、GUIクライアントのインストーラーではありません。通常のインストールにはダウンロードページを利用してください。
git clone https://github.com/MetaCubeX/mihomo.gitクライアントを更新すると、画面、OSとの連携、コアのコンポーネントなどが変わります。一方、サブスクリプションの更新では設定内容を再取得します。この2つは別々の操作です。サブスクリプションの更新に成功しても、ソフトウェア自体が最新版になったとは限りません。インストーラーを入れ替えても、期限切れのサブスクリプションは自動で直りません。アップグレード前に正常動作している設定と必要な上書きルールを保存し、更新後はまず読み込みログを確認してから、システムプロキシとTUNの動作を検証してください。
リモート設定のルール、プロキシグループ、プロバイダーは、サービス提供元が管理している場合があります。ダウンロードしたファイルを直接編集すると、更新時に変更が失われやすくなります。カスタムルールを追加する前に、クライアントが対応する上書きまたはマージの方式を確認し、最終的に適用された設定をチェックしてください。自動更新の間隔はサービス提供元の案内に従って設定します。頻繁にリクエストすればサブスクリプションの無効化が直るわけではありません。
サブスクリプション更新の確認手順を見る →初めて設定する際は、クライアントを一つだけ起動した状態にします。設定を追加したら、まず正常に解析できることを確認し、次にローカルポートが待ち受け状態になっているか調べます。その後、システムプロキシまたはプラットフォームのVPNによる通信の取り込みを有効にし、対象のアドレスへアクセスして接続ログを確認してください。ブラウザーは使えるのにほかのアプリが使えない場合は、プロキシサーバーの故障と決めつけず、対象アプリがシステムプロキシ設定に従うかを先に確認しましょう。
TUNを有効にしたときだけ問題が起きる場合は、権限、DNS、ルーティングを重点的に確認します。どのモードでも失敗する場合は、サブスクリプションの状態とプロキシへの接続を調べてください。パラメーターは一度に一つだけ変更し、変更前後のログの違いを記録します。設定をリセットする必要がある場合は、先にバックアップをエクスポートし、再現可能な障害状況や既存のルールまで消さないようにしてください。詳しいドキュメントでは、プラットフォームごとにインストール、権限許可、よくある競合の確認手順をまとめています。
全プラットフォームのインストール・設定ガイドを見る →まず、リンクから互換性のある設定が返されるか確認してください。ログインページやエラーメッセージが返っている場合もあります。元のリンクは保管し、有効期限とネットワーク接続を確認します。実際に形式の違いがある場合にのみ、サブスクリプションの変換を検討してください。変換では設定内容や認証情報が受け渡されるため、利用する前に送信先と処理方法を確認しましょう。
追加時のトラブル対処を見る →まず、通信を取り込む範囲が比較的明確なシステムプロキシで基本の接続を確認します。対象アプリがプロキシ設定を参照しない場合や、より広い範囲の通信を取り込む必要がある場合に限り、TUNを有効にしてください。通信の取り込み範囲が広がるほど、ルーティングやDNSの確認項目も増えます。スイッチがあるからといって、すべて有効にする必要はありません。
ネットワークの取り込みに関する用語を見る →有効な設定の入手元、クライアントが対応するプロトコル、OSが要求するネットワーク権限が必要です。クライアントは通信を管理するツールであり、インストールしただけでプロキシサービスが使えるわけではありません。これらを用意したら、ガイドに従って設定を追加し、プロキシグループを選択して接続を確認してください。
初期設定の手順を見る →具体的な設定の問題を取り上げ、現象と仕組みを説明したうえで、確認箇所やパラメーターを紹介します。以下は最新の3記事です。基本操作はチュートリアルから、プラットフォームごとの差やコマンドラインでの導入方法は詳細ドキュメントをご覧ください。
リンク切れ、更新リクエストの遮断、プロキシを経由しないリクエスト、形式の非互換を切り分けます。クライアントの更新画面をもとに、自動更新間隔と更新時のネットワーク経路を確認する方法を解説し、設定のダウンロード失敗とプロキシ接続の失敗を混同しないようにします。
ノートを読む →デスクトップクライアントのインストールと、GUIのない環境でのコア導入をそれぞれ解説します。設定ディレクトリ、実行権限、ターミナルのプロキシ環境変数、systemdサービスを軸に手順を整理し、フォアグラウンドでの動作確認と長期的なバックグラウンド運用に必要な設定の違いを説明します。
ノートを読む →アプリが自らプロキシ設定に従う方式と、仮想インターフェースで通信を取り込む方式の違いを比較します。DNSの処理、stackオプション、権限要件を解説し、ブラウザーは使えるのにほかのアプリが直接接続される場合の切り分け方を紹介します。
ノートを読む →