Windows
GUIクライアントはClash Plus、Clash Verge Rev、FlClashなどから選べます。まずシステム情報でプロセッサのアーキテクチャを確認してください。インストール後はシステムプロキシで接続を確認し、システムプロキシを参照しないアプリも通したい場合は、ガイドに沿ってTUNを設定します。
ダウンロードへ Windowsクライアント→OSに合ったクライアントを選び、mihomoコアでプロキシ接続を処理。ルールによる振り分けで通信を管理し、日本語ドキュメントを参考に設定できます。
MIHOMOコア · GPL-3.0オープンソース · ルールによる振り分け
プロトコル名は接続方式を示すもので、速度を保証するものではありません。サーバー側のパラメーター、ネットワーク経路、クライアントのコアが対応している必要があります。サブスクリプションを登録したら、まずプロトコル設定を現在のコアが認識できるか確認しましょう。
サーバー側で指定されたプロトコルと転送パラメーターを使用します。クライアントが設定を読み込めることは最初の確認にすぎません。TLS、トランスポート層、プロキシグループの参照先がそろっているかも確認してください。
ネットワーク切り替え後の復帰動作やバックグラウンド制限を確認しましょう。QUICベースのプロトコルはUDPが利用できることを前提としています。プロトコル名だけで電池消費や接続の安定性を判断することはできません。
デスクトップではGUI操作やOSとの連携が重視され、サーバーではサービス管理や設定の保守性が重要です。プロトコルとコアの技術資料を見る →
GUIクライアントはサブスクリプション管理、プロキシ切り替え、OS連携を担い、コアはルールを解析して接続を確立します。まずデバイスに合ったインストーラーを選び、必要なプロトコルにコアが対応しているか確認しましょう。
GUIクライアントはClash Plus、Clash Verge Rev、FlClashなどから選べます。まずシステム情報でプロセッサのアーキテクチャを確認してください。インストール後はシステムプロキシで接続を確認し、システムプロキシを参照しないアプリも通したい場合は、ガイドに沿ってTUNを設定します。
ダウンロードへ Windowsクライアント→Apple SiliconかIntelかを確認し、対応するビルドを選んでください。システムプロキシとネットワーク拡張では許可する場所が異なります。初回起動時はOSの案内に従って設定しましょう。クライアントを更新する前に設定をバックアップしてください。サブスクリプションやルールの問題は、再インストールではなく原因を切り分けます。
ダウンロードへ macOSクライアント→Clash Plus、Clash Meta for Android、FlClash、Surfboardなどを選べます。デバイスのアーキテクチャと設定形式を確認し、初回接続時はVPN接続を許可してください。アプリを切り替えた後に接続が途切れる場合は、バックグラウンド実行やバッテリー管理に関するOSの制限を確認しましょう。
ダウンロードへ Androidクライアント→App StoreからClash Plusをインストールします。公式サイトはclashplus.ioです。設定をインポートしたら、VPN構成の追加を許可してプロキシグループを選択してください。アプリの画面はデスクトップ版と完全には同じではありません。接続状況、使用中の設定、ルールの適用状況を確認してトラブルを切り分けましょう。
ダウンロードへ iOSクライアント→デスクトップ環境ではClash Verge RevまたはFlClashを選び、ディストリビューションに合ったパッケージを使用します。GUIのないホストではmihomoを直接実行し、サービスマネージャーでプロセスを管理できます。設定ディレクトリの権限、リッスンアドレス、サービスログも確認してください。
ダウンロードへ Linuxクライアント→通信はローカルの受信設定、ルールの照合、出力先の選択という順に処理されます。この流れに沿って設定すると、複数のスイッチを同時に切り替えるより結果を確認しやすくなります。
mixed-port: 7890
allow-lan: falseDOMAIN-SUFFIX,github.com,PROXY
GEOIP,CN,DIRECT
MATCH,DIRECTルールモードは、すべての接続を同じノードに送る機能ではありません。コアはドメイン、アドレス、ルールセットを上から順に確認し、一致した条件に対応するポリシーへ通信を渡します。ポリシーには直接接続のほか、プロキシグループも指定できます。設定を調整するときは具体的な条件を先に置き、最後にフォールバックのMATCHを配置し、ルールが参照するグループ名が存在することを確認してください。グローバルモードと違い、ルールモードでは通信ごとに経路を分けられますが、結果はルールの内容に左右されます。特定のアプリが意図しない出口を使う場合は、接続一覧で適用されたルールを確認してから該当条件を修正しましょう。すべてのノードを何度も切り替える必要はありません。
rules:
- DOMAIN-SUFFIX,github.com,PROXY
- GEOIP,CN,DIRECT
- MATCH,DIRECT
混合ポートはHTTPとSOCKSのプロキシ接続を同時に受け付けるため、ブラウザー、ターミナル、開発ツールで1つのローカル接続先を共用できます。ポート番号に決まりはなく、実際の値は有効な設定に従います。mixed-portを変更した場合は、プロキシアドレスを手動で設定したアプリも更新してください。allow-lanはLANからのアクセスを許可するかどうかを決めますが、実際に接続できるかはバインドアドレスやOSのファイアウォールにも左右されます。ローカルだけで使う場合は無効のままで構いません。外部コントローラーポートはクライアントとコアの通信に使うもので、プロキシ接続の入口ではありません。ブラウザーのプロキシ設定には入力せず、インターネットに直接公開しないでください。
mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
システムプロキシは、アプリがOSの設定を参照することで機能します。一方TUNは、仮想ネットワークインターフェースとルーティングを使って条件に合う通信を取り込み、明示的なプロキシ設定に対応しないアプリにも適しています。有効にする前に、クライアントのサービスが動作し、必要な権限があることを確認してください。DNS設定もルーティング方式に合わせて確認しましょう。対象範囲は除外ルール、インターフェース設定、プラットフォームごとの実装にも左右されるため、スイッチを有効にしただけですべての通信がプロキシを通るわけではありません。ドメイン名では接続できないのにIPアドレスでは接続できる場合は、まず名前解決の経路を調べます。ルーティングやDNSを変更するツールを複数同時に使うと設定が上書きされることがあるため、避けてください。
サブスクリプションには、設定全体を含むものとノード一覧だけを提供するものがあり、同じ入力として扱うことはできません。インポート後はどの設定が有効かを確認し、プロキシグループに選択可能なノードがあるか確認してください。長期的に残したいルールやポートの変更は、クライアントの上書き機能やマージ機能で管理するのがおすすめです。リモートファイルを直接編集すると、更新時に変更が消えることがあります。自動選択グループは測定結果に基づいて切り替わり、手動選択グループは指定した出口を維持します。更新に失敗した場合は、現在使える設定を残したうえで、サブスクリプションへの接続、取得内容の形式、コアの解析ログを個別に確認しましょう。
リモートサブスクリプション → ローカルの上書き設定 → コアの実行設定
クライアントに表示されるサブスクリプションの原文が、そのままコアに渡される最終設定とは限りません。問題を調べる際は、マージ後の設定も確認してください。
ノードの速度テストは通常、指定した測定先への応答時間を測るもので、継続的なダウンロード速度を測定するものではありません。応答が速いノードでも、帯域幅、サーバーの負荷、接続先サイトの制限によって速度が出ないことがあります。比較するときは同じネットワーク、同じ測定先、近い時間帯にそろえ、変更する条件は1つだけにしてください。ブラウザーは使えるのにターミナルで失敗する場合は、ターミナルがプロキシ環境変数を参照しているか確認しましょう。すぐにノードの障害と決めつけないでください。
サブスクリプションの取得失敗、設定の解析失敗、ドメイン名の解決失敗、接続先への接続失敗を切り分けてから、該当する設定を確認しましょう。調査中にログの詳細度を一時的に上げると役立ちますが、共有する前にサブスクリプションURL、認証情報、個人のアドレスを削除してください。使用中の設定、モード、再現手順を記録すると、何度も再インストールするより原因を見つけやすくなります。
初回設定ではポートをデフォルトのままにし、必要なネットワークモードだけを有効にしてください。手順ごとに状態を確認してから、次へ進みましょう。
クライアントのサブスクリプションまたは設定画面でURLを追加し、ダウンロード後にその設定を選択します。設定を解析できること、プロキシグループに選択可能な項目があることを確認してから次へ進みましょう。サブスクリプションURLにはアクセス認証情報が含まれることがあるため、公開の掲示板には貼らないでください。インポート時にエラーが出た場合は、取得内容が設定ファイルなのかエラーページなのかをまず確認します。
通常はルールモードから始め、主要なプロキシグループで利用可能なノードを1つ選びます。デスクトップではシステムプロキシを有効にし、モバイルではOSの案内に従ってVPN接続を許可してください。複数のプロキシアプリを同時に有効にしたり、基本接続を確認する前にDNS、ポート、ルーティングなど複数の設定を変更したりしないでください。
確認したいアプリを開き、接続一覧で該当するドメインまたはプロセスを見つけ、適用ルールと実際の出口を確認します。スイッチがオンになっているだけでは、通信がコアに届いたとは限りません。アプリの通信記録がない場合はプロキシの入口を確認し、記録はあるのに失敗する場合は名前解決、ノードへの接続、接続先サービスを調べましょう。
ここでいうClashは、共通の設定モデルを持つクライアントとコアのエコシステムを指します。すべてのアプリが同じチームによって開発されているわけではありません。画面が似ていても、プロトコル対応や設定の動作まで同じとは限りません。
ClashではYAMLを使ってプロキシ、プロキシグループ、ルールを定義し、GUIクライアントがそのモデルをもとにインポート、切り替え、OS連携の機能を提供します。オリジナルのプロジェクトがメンテナンスを終了した後も、エコシステム内の各プロジェクトは開発を続けています。Clash Metaという名称と後継のmihomoには、プロジェクトの変遷におけるつながりがあります。そのため、古いガイドでは両方の名称が使われています。機能が使えるかどうかは、アプリ名にMetaが含まれるかではなく、現在実行中のコアで判断してください。
mihomoコアはGPL-3.0ライセンスを採用しており、ソースコード、課題、コミット履歴はプロジェクトのリポジトリで確認できます。GUIクライアント、システムサービスのコンポーネント、設定ツールには、それぞれ別のリポジトリやライセンスが適用される場合があります。コアのライセンスがすべてのソフトウェアに適用されるわけではありません。コードの改変、再配布、組み込みを行う場合は、対象プロジェクトのライセンスファイルと依存関係の表記を確認してください。日常的な接続に使う場合は、まずダウンロードページでメンテナンス状況とシステム要件を確認できます。
古い設定の基本ルールや一部のプロキシ項目は引き続き使える場合がありますが、新しいプロトコル、ルール種別、高度なDNS項目には対応するコアが必要です。設定を別のクライアントにコピーする前に、YAML全体を受け取るのか、ノードのサブスクリプションだけを受け取るのかを確認してください。クライアントがデフォルト設定を自動でマージするかどうかも確認が必要です。解析エラーが出たら、ログで示された項目を1つずつ確認します。設定を読み込ませるために、認識されない項目をまとめて削除することはおすすめしません。
クライアントの更新では主に画面、プラットフォーム連携、パッケージ内のコンポーネントが変わります。コアの更新はプロトコルの実装やルールの解析に影響し、サブスクリプションの更新はリモートで提供されるノードや設定を変更します。それぞれ解決する問題は異なります。更新前に復元できる設定を保存し、更新後は使用中の設定、リッスンポート、システムプロキシの状態を確認しましょう。使用中の接続に変化があった場合は、まず更新内容を照らし合わせてから、設定の復元か調整かを判断してください。
クイックスタートでは初回接続を案内し、技術資料ではプロトコルとコアを解説します。個別の問題については、関連記事で確認手順を紹介しています。状況を整理して、目的に合ったガイドを選んでください。
3世代のコアの変遷を整理し、プロトコル対応、ルール種別、設定項目の違いを比較。既存の設定ファイルをそのまま使えるか判断するための情報をまとめています。
記事を読む →ブラウザー拡張機能によるプロキシの上書き、システムプロキシを参照しないターミナル、環境変数の設定漏れをそれぞれ切り分け、確認可能な対処方法を紹介します。
記事を読む →仮想ネットワークインターフェースとルーティングテーブルの仕組みから、TUNモードがシステムプロキシに対応しないアプリの通信も取り込める理由を解説。各プラットフォームでの有効化方法と必要な権限も紹介します。
記事を読む →