OSに合ったクライアントをインストールしてサブスクURLをインポートし、mihomoカーネルとルール設定の関係を確認します。
まずOSとCPUアーキテクチャを確認してから、クライアントを選びます。GUIはサブスクや接続の管理を担いますが、対応プロトコルやルール、ネットワークモードは使用するカーネルによって異なります。
デスクトップブラウザーや開発ツール、日常的なアプリでの利用に適しています。インストール前にシステム設定でデバイスの種類を確認し、アーキテクチャに合ったパッケージを選びましょう。クライアントを起動したら、設定を有効にしてからシステムプロキシをオンにします。
Clash Plus、Clash Verge Rev、FlClashではメニューの場所が異なりますが、サブスク、プロキシグループ、ログは共通の確認ポイントです。旧バージョンから移行する際は、設定の取得元もバックアップしましょう。アプリのフォルダーだけをコピーしても移行できません。
ダウンロードページへ →まず「このMacについて」で、Appleシリコン搭載かIntelプロセッサ搭載かを確認します。クライアントをインストールして起動したら、システムの案内に従って必要な権限を許可し、メニューバーで動作状況と現在の設定を確認しましょう。
システムプロキシとTUNは、トラフィックを取り込む仕組みが異なります。初回はブラウザーで動作を確認し、ルールが適用されることを確かめてから、ほかのアプリを設定しましょう。複数のスイッチを同時に変更すると、問題の切り分けが難しくなります。
ダウンロードページへ →モバイル端末では通常、システムのVPNインターフェースを通じて通信を取り込みます。サブスクをインポートして設定を選んだら、接続開始時の案内に従って許可してください。ほかのVPNアプリを使用中の場合は、同じインターフェースを取り合っていないか確認しましょう。
バックグラウンド接続が切れても、サブスクが原因とは限りません。バッテリー管理、バックグラウンド動作の権限、ネットワーク切り替え後のログを個別に確認してください。設定画面の場所はメーカーによって異なるため、実際の端末のメニューを確認しましょう。
ダウンロードページへ →ダウンロードページではClash PlusのApp Storeへのリンクと、公式サイトclashplus.ioを案内しています。インストール後は、サブスク形式がクライアントに対応しているか確認し、設定を保存してからシステムの案内に従ってVPN構成を追加してください。
デスクトップで使えるYAML設定一式を、そのままモバイル端末に移行できるとは限りません。インポートに失敗した場合は、形式と対応フィールドを確認してください。アカウントページのURLをサブスクURLとして使わないようにし、リンクのパラメーターが見える状態でスクリーンショットを公開しないでください。
ダウンロードページへ →デスクトップではClash Verge RevやFlClashから始められます。ディストリビューションに合ったパッケージ形式を選びましょう。サーバーやルーターでは、GUIクライアントと単体のmihomoカーネルを区別する必要があります。ソフトウェアのインストールは最初の一歩にすぎず、設定ファイルのパス、実行権限、サービスの起動方法も個別に設定します。
コマンドラインツールがデスクトップ環境のシステムプロキシを使うとは限りません。ブラウザーでは接続できるのにターミナルでは失敗する場合、まずアプリが使うプロキシプロトコルとローカルポートを確認し、次に環境変数を確認してください。特定のプログラムの接続問題を解決するために、待ち受けアドレスをLAN全体に公開するのは避けましょう。
ダウンロードページへ →サブスクは設定の取得元、プロキシグループは接続先の選択肢、ルールは通信の経路を決めます。各要素の役割を把握してから個別の項目を変更すると、スイッチを手当たり次第に試すより問題を特定しやすくなります。
以下はmihomoの設定フィールドや項目の例であり、そのまま接続に使えるサブスク一式ではありません。ラベルをクリックするかフォーカスすると、自動切り替えが一時停止します。
サブスクURLは設定を取得するためのアドレスであり、クライアントに接続サービスが付属しているわけではありません。「設定」または「サブスク」画面に既存のURLを貼り付け、ダウンロードが完了したら、その設定を選択して有効にします。リモート設定一式には通常、プロキシグループとルールが含まれます。一方、プロキシプロバイダーが読み込むのはプロキシ項目だけで、メイン設定のプロキシグループから参照する必要があります。更新時にはリモートの内容が再取得されるため、リモートファイルを直接編集すると変更が上書きされることがあります。長期間保持する設定には、クライアントのオーバーライド機能を使いましょう。URLに含まれるアクセス用パラメーターは、アカウント情報として慎重に扱ってください。
サブスクのインポート手順を見る →
# ローカルのサブスクファイルをプロキシプロバイダーとして使う
proxy-providers:
my-sub:
type: file
path: ./providers/my-sub.yaml
proxy-groups:
- name: PROXY
type: select
use: [my-sub]ルールモードでは、リストの順に通信を照合し、通常は最初に一致したルールで行き先が決まります。末尾のMATCHは、ほかのルールに一致しない通信を受け持ちます。クライアントを「ルール」モードに切り替えたら、接続画面で適用されたルールを確認できます。Webページが開くかどうかだけで判断する必要はありません。ドメインルールはサービスごとの振り分けに、IPアドレスルールは明確なネットワーク範囲の指定に適しています。グローバルモードと異なり、ルールモードでは直結とプロキシを併用できますが、ルール名が有効なプロキシグループを参照している必要があります。変更前に設定を保存し、一度に一項目だけ変更して動作を確認しましょう。
ルールとカーネルのリファレンスを見る →mode: rule
rules:
- DOMAIN-SUFFIX,example.com,PROXY
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- MATCH,PROXY
# PROXY はメイン設定で定義する必要がありますプロキシグループは複数のプロキシ項目をまとめ、ルールから参照できる出口として機能します。「プロキシ」画面で該当グループを開き、手動選択する場合は通常selectタイプを使います。自動選択やフォールバックには別のグループタイプを使用します。グループ内の選択を切り替える際、ルールを一つずつ書き換える必要はありません。また、すべてのアプリがすぐに同じ出口へ切り替わるわけではなく、既存の接続が継続する場合もあります。問題を調べるときは、まずルールが参照するグループを確認し、次にグループ内で実際に選択されている項目を確認しましょう。リストに表示されるグループ名をプロトコル名と混同しないでください。対応する機能は、個々のプロキシ項目とカーネルによって決まります。
モードとプロキシの選び方を見る →proxy-groups:
- name: PROXY
type: select
proxies:
- DIRECT
use:
- my-sub
# my-sub はプロキシプロバイダーで定義する必要がありますTUNは仮想ネットワークインターフェースを通じて通信を取り込み、システムプロキシを参照しないアプリにも対応できます。クライアントの設定で有効にする前に、カーネルの対応状況、サービスの権限、システムの許可を確認してください。モバイル端末では設定項目の名称が異なる場合があります。ブラウザーがプロキシアドレスを参照する方式とは異なり、ルーティングやDNSにも関わるため、単に「より強力なグローバルモード」と考えることはできません。有効にした後にローカルネットワークに問題が起きた場合は、まずTUNをオフにして元の状態に戻し、自動ルーティング、ネットワーク範囲の競合、ほかのVPNソフトを確認しましょう。具体的な設定項目は、使用中のクライアントとカーネルのドキュメントを参照してください。
ネットワークモードのトラブル対処を見る →# 接続方式の例。DNSは別途設定が必要です
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
# 有効にする前に実行権限とルートの競合を確認するオーバーライドを使うと、リモート設定にローカルの設定を適用でき、サブスク更新のたびに同じ変更を繰り返す手間を減らせます。機能名は「オーバーライド」「マージ」「拡張設定」など、クライアントによって異なります。マージの順序や配列の扱いも一律ではありません。まずオーバーライドの適用範囲を確認し、ポートやログレベルなど、一項目から試しましょう。サブスクの内容を直接編集するのとは異なり、変更を独立して保存できますが、どの項目も安全に追加できるわけではありません。ルールの挿入位置、プロキシグループ名の重複、DNS設定は、最終的に生成された設定を確認することが特に重要です。
Profileと複数設定の説明を見る →# よく使われるマージ項目。設定場所と優先順位はクライアントによって異なります
mixed-port: 7890
allow-lan: false
log-level: info
# 保存後に最終設定を確認してから再読み込みする「設定の取得元 → ルールの出口 → アプリの接続」の順に進めます。まず同じ条件で繰り返し確認できる状態を作り、その後でTUNやカスタムDNS、複雑なオーバーライドを検討しましょう。
インストール後、クライアントの設定管理画面を開き、URLからインポートする項目を選んで、サービス提供者から取得したサブスクURLを貼り付けます。ダウンロードに成功しても設定が有効になったとは限りません。リストから対象の設定を選び、カーネルで読み込みが完了したことを確認してください。解析エラーが表示された場合は、URLがWebページやエラーメッセージではなく、クライアントが対応する内容を返しているか確認しましょう。
ローカルのYAMLファイルは、ファイルからインポートできます。リモートサブスクは取得元から更新されますが、ローカルファイルは自分で管理するため、その後の変更方法が異なります。デバイスを移行するときは、設定名、取得元、ローカルオーバーライドも記録しましょう。ログを共有する前に、サブスクのパラメーターを隠してください。手順の詳細を確認し、インポートの成功と接続の成功を混同しないようにしましょう。
初めて使う場合は、まず設定に用意されたルールモードを使い、プロキシ画面でルールから参照されているグループを見つけ、利用可能な項目を選びましょう。ルールモードはリクエストの振り分け方を決め、プロキシグループはそのグループに振り分けられたリクエストの出口を決めます。両者は同じスイッチではありません。どのルールからも参照されていないグループを切り替えても、実際の通信は変わらない可能性があります。
グローバルモードは一時的な比較には便利ですが、あらゆる問題に対する万能の解決策ではありません。テスト前に元のモードとグループ内の選択を控え、テスト後に戻しましょう。既存の接続では変更前の経路が保たれることがあるため、変化を確認するには新しいリクエストを送る必要があります。設定を作成した人のグループ分けの意図を把握してから、自動選択や手動選択を変更してください。ほかのグループから参照されている名前は削除しないようにしましょう。
デスクトップでは、まずシステムプロキシを有効にして、普段使うサイトにブラウザーからアクセスします。次にクライアントの接続画面で、ドメイン、適用ルール、出口を確認しましょう。モバイル端末では、画面の案内に従ってVPN接続を開始します。リクエストのログが表示されるなら、少なくとも通信はクライアントに届いています。ログがまったくない場合は、サブスクを何度も更新したりプロキシ項目を切り替えたりする前に、アプリの接続方式を確認してください。
ブラウザーでは接続できるのにターミナルでは失敗する場合は、ターミナルの環境変数を確認します。すべてのアプリで失敗する場合は、設定が有効か、プロキシグループの選択、エラーログの順に確認しましょう。テスト中は一度に一つの条件だけを変更し、結果を記録してください。こうすれば、サブスクの取得、ドメインの名前解決、実際の接続という各段階を切り分けられ、クライアントの再インストールによる余計な要因も避けられます。
Clash サブスク設定ガイドでは、インストール先と設定方法を紹介していますが、サブスクサービスは提供していません。クライアントが使用中のデバイスに適しているかは、開発状況、プロトコル対応、実際のシステム環境を踏まえて判断してください。
Clashは、プロキシツールのエコシステムで広く使われてきた名称です。初期のカーネル、その後のフォーク、GUIクライアントはそれぞれ別のプロジェクトです。オリジナルのClashや一部の初期クライアントはすでに開発が終了しています。コミュニティのプロジェクトが似た名称を使っていても、開発元、設定機能、更新方法が同じとは限りません。ソフトウェアを選ぶ際は、アイコンや「Clash」の表記だけで判断せず、プロジェクトの正式名称を確認しましょう。
古いクライアントが起動できても、長期間使い続けるのに適しているとは限りません。OSのアップデート、プロトコルの変更、設定への新しいフィールドの追加によって、互換性に問題が生じることがあります。移行前にサブスクの取得元とローカル設定をバックアップし、新しいクライアントに再インポートして動作を確認してから、古いソフトの自動起動、システムプロキシ、バックグラウンドサービスを整理しましょう。詳しい違いはプロトコルとカーネルのリファレンスで確認できます。複数のプロキシプログラムを同時に動かして比較する必要はありません。
GUIクライアントは、トレイメニュー、サブスク管理、設定編集、システム連携を提供します。カーネルは設定の解析、ルールの照合、接続の確立を担います。異なるGUIが同じカーネルを使うこともあれば、異なる実装を採用することもあります。そのため「GUIにスイッチがある」ことと「現在のカーネルがその機能に完全対応している」ことは分けて確認してください。オープンソースリポジトリのドキュメント、リリースノート、Issueの議論は、機能の範囲や既知の制限を把握するのに役立ちます。
このサイトでは、リポジトリの人気度を互換性の判断材料にせず、実際の利用場面に沿って解説しています。クライアントを評価する際は、対象プラットフォームへの対応、設定の読み込み、ログの確認しやすさ、更新方法の明確さを優先して確認しましょう。問題を報告するときは、OS、クライアント名、エラーが起きた段階、個人情報を隠したログを記録すると、「インターネットに接続できない」とだけ伝えるより有効なフィードバックになります。
Clash MetaはClashエコシステムから派生したプロジェクトで、後にmihomoという名称で開発が続けられています。過去の記事やクライアントのメニュー、設定の説明では、引き続きMetaという名称が使われている場合があります。名称が新しくなっても、すべての世代のビルドで同じ機能が使えるわけではありません。プロトコル、DNSの動作、ルールのフィールド、TUNの実装は、実際に動作しているカーネルのドキュメントで確認してください。
既存の設定をmihomoへ移行する場合は、まず解析ログを確認し、プロキシプロバイダー、プロキシグループ、ルールの参照関係を検証しましょう。YAMLを読み込めたとしても、現在の段階で構文や構造を処理できたことを示すだけで、すべてのリクエストが意図どおりに処理されるとは限りません。プロトコルを選ぶ際は、サーバー側の対応状況、ネットワーク品質、デバイスの消費電力も考慮してください。プロトコル名だけから接続速度を判断することはできません。
クライアントの更新は画面やシステム連携を変更し、カーネルの更新は接続機能や設定への対応状況を変えます。サブスクの更新では、リモートの内容を再取得します。これらの操作は別々の画面にある場合も、クライアントで一括管理されている場合もあります。サブスクの更新に失敗したとき、アプリを何度再インストールしても、無効になったリンクは復旧しません。カーネルが新しいフィールドに対応していない場合も、サブスクの更新だけでは機能を追加できません。
更新前に利用可能な設定を保存し、変更内容を確認したうえで、ローカルオーバーライドのマージ方法を把握しましょう。更新後は、使い慣れた接続先で動作を確認してから、振り分けとローカルネットワークをチェックします。更新後にだけ問題が起きた場合は、具体的な変更内容を比較して原因の範囲を絞りましょう。更新元からエラー内容が返される場合は、取得元の状態と有効期限を確認してください。事例はヘルプセンターで、基礎知識、インストールと設定、使い方、トラブル対処のカテゴリに分けて紹介しています。
基本的な手順を確認したら、具体的な問題に応じて解説を読み進めましょう。まず問題がどの層で発生しているかを特定すると、システムプロキシ、サブスクの取得元、プロトコル対応を混同せずに対処できます。
ブラウザーとターミナルに分けてシステムプロキシの不具合を確認します。プロキシ拡張機能の競合、PAC、例外リストを確認し、各OSでターミナルに環境変数を設定する方法も紹介します。
解説を読む →初心者がつまずきやすい10の疑問に回答。サブスクのインポート、モード選択、プロキシの切り替え、ポート、自動起動を取り上げ、各項目に関連ガイドを掲載します。
解説を読む →3世代のカーネルの関係を時系列で整理し、プロトコル対応、ルールの種類、TUN機能を比較。古い設定をmihomoへ移行する際に変更が必要なフィールドも解説します。
解説を読む →