まず、通信がどのようにカーネルへ届くかを把握し、ルールで接続先を決めましょう。クライアントは操作の入口、カーネルは設定を実行する部分です。画面が似ていても、すべての設定項目を共通で使えるとは限りません。
ルールモードは日常利用に適しています。カーネルは設定順にドメイン、アドレス、ルールセットを照合し、該当した通信を指定の出口へ渡します。個別のドメインを先に、最後にフォールバックルールを置き、条件の広いルールが先に通信を捕捉しないようにします。問題を調べるときは接続ログを開き、実際に適用されたルールを確認してください。ブラウザーでページが開くかどうかだけでは判断できません。以下の例はDIRECTルールのみで、プロキシサーバーは含みません。プロキシ経由にする場合は、完全な設定内で対応するノードまたはプロキシグループを定義してから、ルールで参照してください。
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,DIRECTプロキシグループを使うと、複数の出口をまとめてルールから参照できます。手動選択にはselect、テスト結果に基づく選択にはurl-test、障害時の切り替えにはfallbackを検討してください。自動テストで測るのは指定先への応答状況であり、ダウンロード速度ではありません。テスト先、タイムアウト、ネットワーク環境によって結果は変わります。以下ではDIRECTを例としてメンバーに加え、ルールから参照する「自動選択」グループを定義しています。実際に使うときは、完全な設定内に存在するノード名に置き換えてください。グループ名だけをコピーしてもプロキシ接続はできません。
proxy-groups:
- name: 自動選択
type: url-test
proxies:
- DIRECT
url: https://www.gstatic.com/generate_204
interval: 300
rules:
- MATCH,自動選択システムプロキシを参照しないアプリは、システムプロキシを有効にしただけでは通信を捕捉できません。TUNは仮想NICとルーティングで通信を取り込み、対象範囲を補います。通常、管理者権限またはクライアントのサービス機能が必要です。TUNが変えるのは通信をカーネルへ届ける方法であり、ルールモードを自動的にグローバルプロキシへ切り替えるものではありません。まず通常の接続が使えることを確認してからTUNを有効にし、ルーティング、DNS、ほかの仮想NICとの競合を順に確認してください。以下はmihomoの設定例です。プロトコルスタックや権限は、クライアントとOSに合わせて調整してください。
tun:
enable: true
stack: system
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53完全な設定を含むサブスクリプションには、通常ノード、プロキシグループ、ルールが含まれます。読み込み後、該当する設定を選択して初めて有効になります。一方、proxy-providersはノード一覧を読み込む機能で、完全な設定の代わりにはなりません。更新前にローカルルールやオーバーライドを保存し、直接編集した内容が次回の更新で上書きされないようにしましょう。以下はローカルプロバイダーの構成例です。指定したパスにファイルが実在し、プロバイダー形式のproxiesリストを含んでいる必要があります。また、完全な設定内のプロキシグループでuseを使って参照してください。リモートのサブスクリプションURLにはアクセス情報が含まれる場合があるため、公開しないでください。
proxy-providers:
local-proxies:
type: file
path: ./providers/local.yaml
proxy-groups:
- name: 手動選択
type: select
use:
- local-proxiesコントロールAPIでは、接続の確認、プロキシグループの切り替え、稼働状況の管理ができます。サーバーやカーネル単体での運用に適しています。デスクトップクライアントには管理画面が統合されていることが多く、通常の利用でAPIを別途公開する必要はありません。待ち受け先は可能な限りローカルループバックに限定してください。リモート接続が必要な場合は、認証とアクセスを制限したネットワーク経路を併用します。以下はローカル待ち受けの例です。ポートは混合ポートと重複させないでください。コントロールAPIを設定してもWebパネルが自動で用意されるわけではありません。パネルのファイル、アクセス方法、認証は別途設定が必要です。
external-controller: 127.0.0.1:9090
log-level: infoシステムプロキシは、アプリからクライアントへ通信を送るかどうかを決めます。ルール、グローバル、DIRECTは、カーネルが受け取った通信をどう処理するかを決めます。混合ポートは、HTTPとSOCKS接続を受け付けるローカルの待ち受け口です。それぞれ役割が異なります。ブラウザーがシステムプロキシを使っていなければ、プロキシグループを切り替えても変化しないことがあります。ルールでDIRECTに指定された通信は、ノードを切り替えても出口が変わりません。原因を調べるときは入口から出口まで順に確認し、複数の設定を同時に変更しないようにしましょう。
画面の設定ウィンドウは静的なイメージです。7897は混合ポートの一般的な例で、すべてのクライアントで固定されているわけではありません。実際のポートは現在のクライアント設定を確認してください。ブラウザーなどのアプリにプロキシを手動設定する場合、アドレスは通常ローカルループバックで、ポートはクライアントと一致させます。ポートを変更したら、システムプロキシやアプリ内に個別保存されたプロキシ設定も確認してください。LAN共有には待ち受けアドレスとファイアウォールの設定も関係します。通常のローカル利用で、最初から共有を有効にする必要はありません。
プロキシグループ、DNS、TUNの応用設定を見る →まずOSとCPUアーキテクチャを確認し、次に必要な機能で選びましょう。Clash Plusは、当サイトがマルチプラットフォーム向けに最初におすすめする選択肢です。デスクトップではClash Verge RevやFlClashなども比較できます。ダウンロードページにインストーラーの入手先と要件をまとめています。
ブラウザーや一般的なデスクトップアプリでは、まずシステムプロキシを使います。プロキシ設定に従わないアプリも通信を取り込む必要がある場合は、クライアントのサービス機能とTUNの権限を確認してください。Clash Plusを起点に、Clash Verge Rev、FlClash、Clash Nyanpasuの設定管理方法を比較できます。
インストール前にシステム設定でアーキテクチャを確認し、デスクトップ用インストーラーとカーネル単体のアーカイブを取り違えないようにしてください。旧Clash for Windowsはサポート終了済みのアーカイブ版です。移行前にサブスクリプション、ルール、スクリプトをバックアップし、新しいクライアントが従来の設定項目に対応しているか確認しましょう。
ダウンロードへ「このMacについて」でApple SiliconかIntelかを確認し、対応するインストーラーを選びましょう。Clash Plus、Clash Verge Rev、FlClashを比較候補にできます。まずシステムプロキシでブラウザーの接続を確認し、TUNを使う場合は権限とルーティングも確認してください。
起動前に、OSが表示するアプリの入手元に関する警告を確認し、プロジェクトのリリース情報に従ってください。アプリを開くためだけにシステムの保護機能を恒常的に無効にしないでください。ClashX Metaを使っていた場合、ダウンロードページでアーカイブ版かどうか確認できます。移行時は古い画面のスイッチをすべて真似るのではなく、サブスクリプション形式、プロキシグループの選択、ローカルオーバーライドを確認しましょう。
ダウンロードへモバイル端末では通常、システムのVPNインターフェースを使って通信を取り込み、初回接続時に許可が必要です。まずClash Plusを確認し、Clash Meta for AndroidやFlClashと比較できます。インストーラーは端末のアーキテクチャに合わせて選んでください。バックグラウンド動作はOSのバッテリー管理の影響も受けます。
スマートフォンにほかのVPNアプリが入っている場合は、現在どのアプリが接続を確立しているか確認してください。通信の取り合いをノードの障害と誤認することがあります。Surfboardもダウンロードページで紹介する選択肢ですが、設定形式はClash YAMLとは異なります。サブスクリプションをそのまま読み込めるかは提供元の形式を確認してください。URLの末尾だけで互換性を判断することはできません。
ダウンロードへまずClash Plusをおすすめします。ダウンロードページにApp Storeへのリンクと公式サイト clashplus.io を掲載しています。インストール後、既存のサブスクリプションを読み込み、アプリの案内に従ってVPN構成を許可してください。OSのVPNステータスは通信の取り込みが始まったことを示すだけで、サブスクリプション内のすべての出口に接続できることを保証するものではありません。
モバイル端末の権限モデルはデスクトップと異なるため、デスクトップの混合ポートやシステムプロキシの手順をそのまま使う必要はありません。検証時は、まず接続先が明確なページを開き、アプリの接続ログとプロキシグループの選択を確認してください。サブスクリプションの更新失敗と接続失敗は分けて対処します。前者はURLとサービスの状態を、後者はルールと出口を確認しましょう。
ダウンロードへデスクトップではClash Verge RevやFlClashから選び、ディストリビューションとパッケージ形式に合った方法でインストールします。デスクトップ環境によってシステムプロキシの対応状況は異なり、ターミナルのアプリがデスクトップのプロキシ設定を参照するとも限りません。環境変数、アプリごとのプロキシ設定、TUNがカバーする範囲をそれぞれ確認してください。
サーバーやルーターでは、mihomoカーネル単体での運用も検討できます。設定ファイルのパス、サービスの起動、権限、ログを自分で管理する必要があり、デスクトップ画面が代わりに処理してくれるわけではありません。まずフォアグラウンドで設定を読み込めることを確認し、その後サービス管理ツールに組み込みます。問題が起きたときは、何度も再インストールするより起動ログを保存しておくほうが役立ちます。
ダウンロードへインストールしただけでは、接続の準備は完了していません。まず設定を読み込み、次に通信を取り込む方法を確認し、最後に接続ログで結果を検証しましょう。初回設定ではできるだけ初期値を保ち、一度に変更するのは一項目だけにしてください。
クライアントのサブスクリプションまたは設定画面を開き、既存のサブスクリプションURLを貼り付けて保存し、ダウンロードが完了するまで待ちます。設定が一覧に表示されたら現在の設定として選択し、プロキシグループが正しく読み込まれているか確認してください。URLは信頼できる提供元から入手しましょう。クライアント自体が利用可能なプロキシサービスを生成することはありません。
ローカルのYAMLファイルを受け取った場合は、ファイルのインポート機能を使います。ダウンロードに失敗したら、URLが完全か、有効期限が切れていないか、返された内容が設定ファイルかを確認してください。ログインページやエラーページを設定ファイルとして読み込まないようにしましょう。インポート前に元ファイルを保存しておくと、元に戻せます。
まずルールモードを選び、手動選択が必要なプロキシグループで利用可能な出口を指定します。デスクトップではシステムプロキシを有効にし、モバイルでは案内に従ってVPN接続を許可してください。特別な理由がなければ、LAN共有は無効のままにし、不要な待ち受けやアクセス範囲を増やさないようにしましょう。
アプリが接続一覧に表示されない場合は、システムプロキシを使わないアプリかどうかを確認してください。必要な場合に限りTUNを有効にし、管理者権限、クライアントのサービス、DNS設定を確認します。問題の切り分けにグローバルモードを一時的に使うことはできますが、すべての問題を解決する既定の方法として使わないでください。
接続先のページを開きながらクライアントの接続ログを確認し、通信がカーネルに届いているか、想定したルールに一致したか、正しい出口が使われたかを確認します。遅延テストで分かるのは特定のテスト先への応答状況です。実際のページ閲覧、ダウンロード、会議アプリの使い心地の確認には代用できません。
接続に失敗した場合は、時刻、接続先、ログを記録し、サブスクリプションの読み込み、プロキシの入口、DNS、ルール、出口の順に確認します。クライアントを終了する前にシステムプロキシを無効にしてください。有効なままだと、停止したローカルポートへアプリが接続し続け、クライアント終了後もネットワークに接続できないことがあります。
クライアントを長く使えるか判断するには、公開コード、メンテナンス履歴、設定の動作を確認しましょう。プロジェクトの歴史、カーネルの実装、GUIクライアント、サブスクリプションサービスを区別し、ひとつの製品として混同しないことが大切です。
Clashのエコシステムはルールベースのプロキシを中心に発展し、複数のカーネル派生版やGUIクライアントが生まれました。元のClashプロジェクトや一部の初期クライアントがメンテナンスを終了した後も、継続中の派生版ではプロトコル対応、DNS、ルーティング機能が発展しています。mihomoはClash.Metaの技術路線を引き継いでいるため、資料にはClash、Clash Meta、mihomoなど複数の名称が登場します。手順を読むときは、まず対象のカーネルを確認し、設定項目が現在のクライアントでも使えるか判断してください。
古い手順のスクリーンショットは操作場所の参考にはなりますが、現在の機能対応を示すものではありません。クライアントのメニュー、サービスのインストール方法、既定のポートは変わっている場合があります。特にサポート終了ソフトから移行するときは、サブスクリプションの原本、ローカルルール、スクリプト、設定を個別にバックアップしてください。新しいクライアントで最低限の接続を確認してから、高度な機能を少しずつ戻すと、古い設定を一度に移して差分を追えなくなる事態を防げます。
mihomoカーネルは設定の解析、ルールの照合、DNS処理、接続の確立を担います。GUIクライアントはインストール、サブスクリプション管理、システムプロキシ、操作画面を提供します。クライアントに特定のスイッチがあるかどうかと、カーネルが設定項目に対応しているかどうかは別の話です。デスクトップソフトでは高い権限が必要な機能をサービスプロセスで処理する場合があり、モバイル端末ではシステムのネットワーク拡張やVPNインターフェースに制限されます。
そのため、同じYAMLでもクライアントによって調整が必要な場合があります。カーネルの違いに加えて、クライアントによるDNS、ポート、TUN設定の上書きや、プロバイダーパスの解決方法も確認してください。原因を調べるときは、サブスクリプションの元ファイルだけでなく、最終的に適用された設定を確認します。問題を報告する際は、クライアント名、OS、通信の取り込み方法、関連する設定項目を伝えると、「Clashが使えない」とだけ伝えるより再現しやすくなります。
mihomoはGPL-3.0ライセンスで公開されており、コード、Issue、リリース履歴はプロジェクトのリポジトリで確認できます。オープンソースライセンスはコードの利用や再配布に関する条件を定めるもので、すべてのサードパーティ製クライアントが同じライセンスを採用していることや、現在もメンテナンスされていることを保証するものではありません。設定項目を確認するときは、現行のカーネルドキュメントを参照してください。不具合が疑われる場合は、公開Issueに同様のケースがないか調べましょう。
当サイトでは、確認できないダウンロード数、評価、接続性能を掲載しません。おすすめはプラットフォーム、設定方法、利用目的をもとにしており、根拠のない統計で裏付けるものではありません。リポジトリの不具合報告をソフトウェアの品質ランキングとして扱うこともできません。端末、設定、ネットワーク環境はそれぞれ異なります。再現手順、ログの時系列、最小限の設定があれば、問題がカーネル、画面、サービス提供元のどこにあるか判断しやすくなります。
mihomoのプロジェクトリポジトリを見る →ソフトウェアの更新ではクライアントやカーネルが変わり、サブスクリプションの更新ではノードや設定内容が変わります。ルールセットの更新では照合条件が変わります。これらは別の更新で、周期も同じとは限りません。アップグレード前に有効な設定とローカルオーバーライドを保存し、変更内容を確認してから、DNS、TUN、プロバイダーが引き続き想定どおり動くか確かめてください。サブスクリプション更新後にプロキシグループの選択肢が変わっても、クライアントのアップグレードが原因とは限りません。
サブスクリプションURLにはアカウントの認証情報が含まれることがあります。スクリーンショットやログを共有する前に、URL全体や機密項目を削除してください。問題を相談するときは、必要な設定部分だけを共有します。完全なサブスクリプションを公開Issueに投稿したり、他人の設定を確認せず既存の設定に上書きしたりしないでください。ルールが参照するプロキシグループ、プロバイダーファイル、スクリプトは一式そろっている必要があります。構文の一部をコピーするだけでは、動作する設定にはなりません。
以下のコマンドはカーネルの調査や開発向けで、GUIクライアントのインストール手順ではありません。通常の利用ではダウンロードページへ進んでください。ビルドする場合は、リポジトリのドキュメントに従ってツールチェーンと対象アーキテクチャを準備します。
git clone https://github.com/MetaCubeX/mihomo.gitルールモードでは一部のサイトだけがプロキシ経由になりますか？実際の動作はモード名ではなく、現在のルールによって決まります。TUNを使うとすべての通信がプロキシ経由になりますか？TUNは通信を取り込みますが、出口はルールとプロキシグループによって決まります。ノードテストに応答があれば、実際のアプリも使えますか？テスト先と接続先は異なるため、実際の接続も確認が必要です。サブスクリプションと設定ファイルは同じものですか？サブスクリプションは設定内容を取得する方法で、返される内容は完全な設定の場合もノード一覧の場合もあります。用語をさらに確認するには用語早見表を参照してから、設定画面に戻って操作してください。
クライアントの移行、ポート、通信の取り込みという具体的なケースを解説します。まず問題がどの層にあるかを特定してから対処し、ソフトの変更、ルールの編集、OSのネットワーク設定リセットを一度に行わないようにしましょう。
旧クライアントのサポート終了に伴うリスクを整理し、プラットフォームごとにメンテナンス中の代替クライアントを紹介。サブスクリプション、オーバーライドスクリプト、カスタムルールを引き継ぐ方法も解説します。
移行手順を見る →システムコマンドで7890や7897などのポートを使用中のプロセスを調べ、残存プロセスかどうかを確認します。そのうえでクライアントと設定ファイルのポートを変更し、システムプロキシにも反映する方法を解説します。
ポートのトラブル対処を見る →仮想NICがシステムプロキシを使わないアプリの通信をどう取り込むかを解説。systemとgvisorのプロトコルスタックを比較し、プラットフォーム別にTUNの利用に必要な権限と設定を紹介します。
TUNの仕組みを見る →