Clashクライアントによってメニュー名や配置は完全には同じではありませんが、中心となる作業は共通しています。設定の読み込み、コアの起動、システム通信の取り込み、プロキシグループによる出口の選択、ログや接続履歴を使った問題の切り分けです。特定のクライアントでボタンの位置を覚えるより、各画面の関係を理解することが重要です。

一般的なデスクトップクライアントでは、画面名が「概要」「プロキシ」「設定」「接続」「ログ」「設定」などになっています。Androidクライアントでは、一部の機能がサイドバーや下部ナビゲーションにまとめられている場合もあります。mihomoコアを使用するクライアントでは、ルールプロバイダー、外部コントロール、設定のオーバーライド、ランタイム設定などの項目が追加されることもあります。名称に違いはあっても、データの流れは次のように整理できます。設定がルールとノードを提供し、コアがマッチングと転送を実行し、システムプロキシまたはTUNがアプリの通信をコアへ送り、ログと接続画面が実行結果を表示します。

概要画面：通信が本当にクライアント経由になっているか確認する

概要画面は「ホーム」「ダッシュボード」「ステータス」などと呼ばれることもあります。ここには通常、コアの動作状態、現在のプロキシモード、システムプロキシのオン・オフ、TUNの状態、アップロード・ダウンロード速度、アクティブな接続数、メモリ使用量などが表示されます。最初に確認したいのは、クライアントがウィンドウを開いているだけなのか、それとも実際にネットワーク通信を処理しているのかという点です。

コアの動作状態

グラフィカルなクライアントとプロキシコアは別の層にあります。画面のプロセスは設定管理とシステム連携を担当し、Clashまたはmihomoコアはポートの待ち受け、ルールの照合、接続の確立を担当します。そのため、ウィンドウが正常に開いても、コアが正常に起動したとは限りません。概要画面に「停止」「コアが実行されていません」と表示される場合や、起動直後に終了する場合は、まずポートの競合、設定ファイルの構文、コアファイルの状態を確認します。

コアの起動に成功すると、HTTP、SOCKS、mixed-portなどのローカル待ち受けポートが表示されます。mixed-portは、同じポートでHTTPとSOCKS5のリクエストを受け付けられます。通常はポートを頻繁に変更する必要はありませんが、別のプロキシツール、開発環境、古いクライアントが同じポートを使用していると、起動に失敗することがあります。

システムプロキシとTUNの違い

システムプロキシは、OSのプロキシ設定を変更する方式です。ブラウザーやシステムプロキシに従うアプリはClashへリクエストを渡しますが、一部のゲーム、コマンドラインプログラム、独自のネットワークスタックを使用するソフトウェアは設定を無視することがあります。TUNモードは仮想ネットワークインターフェースを作成し、ルーティング条件に一致する通信をより低い層で取り込むため、通常はより広い範囲をカバーできます。

両者は単純な「強弱」の違いではありません。システムプロキシは仕組みを理解しやすく、切り分けもしやすいため、普段のブラウジングには十分なことが多いです。TUNは、システムプロキシを参照しないアプリ、UDP通信、より完全な透過的な通信取り込みに適しています。TUNを有効にするには管理者権限が必要な場合があり、ファイアウォール、他の仮想NIC、企業向けセキュリティソフト、システムのルーティング設定の影響も受けます。

通信グラフの見方

アップロード・ダウンロード速度は、コアを通過するデータがあることを示すだけで、対象サイトに正常にアクセスできることを直接証明するものではありません。少量の通信が続く場合は、システム更新、通知、バックグラウンド同期などが原因かもしれません。アクティブな接続数が増え続けて減らない場合は、接続画面で具体的なプロセスと対象ドメインを確認します。クライアントの通信量がゼロなのにブラウザーが正常に接続できるなら、そのアプリがClashを経由していないか、DIRECTの経路に入っている可能性があります。

プロキシ画面：ノード一覧だけでなくプロキシグループを理解する

プロキシ画面は、最も誤解されやすい項目です。ここに表示されるのはサーバーノードだけではなく、プロキシグループも含まれます。プロキシグループには複数のノードを登録でき、別のプロキシグループを入れ子にすることもできます。ルールがプロキシグループに一致すると、コアがそのグループの現在の選択方式に従って出口を決定します。

代表的なプロキシグループの種類

  • select：手動選択。画面上でノードや下位のプロキシグループを直接選べます。選択結果は、設定を再読み込みするか、クライアントの保存機能によって置き換えられるまで維持されます。
  • url-test：自動速度テスト。コアが指定されたテストURLへ定期的にアクセスし、遅延結果をもとにパフォーマンスの良いノードを選択します。測定対象への応答を評価するもので、すべてのサイトでの実速度を示すわけではありません。
  • fallback：フェイルオーバー。リストの順番に従って利用可能なノードを使い、現在の出口が利用できなくなると次の候補へ切り替えます。
  • load-balance：負荷分散。設定した方式に従って異なる接続を複数のノードへ振り分けます。セッションの一貫性に関する要件を理解している場合に適しています。

画面に「自動選択」「ノード選択」「海外メディア」「インスタントメッセージ」などの名前が表示されても、それらは通常、設定の提供元が定義した名称であり、クライアント固有の機能ではありません。プロキシグループをクリックすると、そのグループの出口が変わります。現在のサイトに影響するかどうかは、そのサイトがルールによってそのグループへ割り当てられているかにも左右されます。

遅延の数値が示す実際の意味

ノード横に表示される遅延は、通常、従来のICMP pingではなくHTTPテストによるものです。結果はテストURL、DNS、ネットワークの混雑、ノードの負荷、測定間隔などの影響を受けます。低遅延は対話的な操作に向いていますが、ダウンロード速度は帯域幅、経路品質、対象サイトにも左右されます。「タイムアウト」と表示されても、ノードが完全に使えないとは限りません。テストURLに制限がある、測定のタイムアウトが短い、現在のネットワークから一時的に到達できないといった可能性もあります。

ノードを選ぶときは、まず利用可能かを確認し、そのうえで実際のアクセス結果を見ます。グループ全体の速度テストを何度も実行すると、複数の測定接続が同時に作られます。モバイル回線やノード数が多い環境では余分な通信が発生し、短時間の結果が不安定になることもあります。

設定画面：サブスクリプション更新・設定切り替え・オーバーライドの違い

設定画面は「Profiles」や「サブスクリプション」と呼ばれることもあります。ここでは、リモートのサブスクリプション、ローカルのYAMLファイル、クライアントが生成した設定を管理します。設定を選択すると、通常はその内容がコアへ渡されて読み込まれます。プロキシグループ、ルール、DNS、ノード一覧の主な情報源もここです。

サブスクリプションの更新と設定の切り替えは別の操作

「更新」は、元のサブスクリプションURLから内容を再取得する操作です。「切り替え」は、保存済みの別の設定をコアに読み込ませる操作です。サブスクリプションの更新後は、ノードやプロキシグループが変わり、手動で選択したプロキシグループがリセットされることもあります。更新に失敗した場合は、ダウンロード失敗、取得内容の形式エラー、コアによる読み込み失敗の3つを区別してください。

  1. ダウンロード失敗では、タイムアウト、ドメイン名の解決失敗、接続拒否、異常なHTTPステータスなどが発生します。
  2. 形式エラーは、WebページのURL、単一ノード用リンク、ログインページなどをClash設定として読み込もうとした場合に起こることがあります。
  3. 読み込みに失敗すると、YAML解析、フィールドの型、ルール構文、ポート競合などの情報がログに表示されます。

自動更新間隔は、クライアントがリモート設定を確認する頻度を示すもので、サブスクリプション側で必ず新しい内容が生成されることを意味しません。提供元が特定のリクエスト方式を要求している場合は、クライアントが対応するパラメーターをサポートしているかどうかも更新結果に影響します。

YAML設定に含まれる主な項目

典型的な設定には、待ち受けポート、動作モード、DNS、ノード、プロキシグループ、ルールなどが含まれます。プロキシプロバイダーやルールプロバイダーを使う場合は、一部の内容がリモートファイルに分割されます。構造を理解するための簡略化した例を示します。

mixed-port: 7890
mode: rule

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - 自動選択
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,ノード選択
  - GEOIP,CN,DIRECT
  - MATCH,ノード選択

ルールは上から順番に照合され、最初に一致したルールが適用されます。最後のMATCHは通常、フォールバックとして機能します。あるドメインが前のルールですでにDIRECTに一致している場合、フォールバックグループを変更しても経路は変わりません。画面に表示されるプロキシグループ名は、ルール内の参照名と一致している必要があります。一致しないと、設定の読み込み時にエラーが発生することがあります。

オーバーライドとマージ機能

一部のクライアントには、Merge、Script、Override、オーバーライドなどの機能があります。サブスクリプションの更新後にローカル設定を追加し、DNSの調整、ルールの挿入、プロキシグループの変更などを行うための機能です。直接サブスクリプションのキャッシュを編集せずに済むため、次回更新時に変更が上書きされない点が利点です。一方で処理の段階が増えるため、問題を切り分けるときは元の設定とオーバーライド後の結果を確認する必要があります。

入門段階では必要な変更だけを残し、それぞれのオーバーライドの目的を記録しておくことをおすすめします。更新後に突然起動できなくなった場合は、一時的にオーバーライドを無効にして、元の設定が読み込めるか確認します。これにより、問題がサブスクリプションの内容にあるのか、ローカルでの加工処理にあるのかをすばやく判断できます。

接続画面：どのアプリがどのアドレスへアクセスしているか確認する

接続画面には、現在または最近コアを通過したネットワーク接続が表示されます。主な項目は、対象ドメイン、対象IP、送信元アドレス、ネットワーク種別、アップロード・ダウンロード量、適用ルール、使用したプロキシチェーン、接続確立時刻などです。分流結果を確認するには最も直接的な画面です。

適用ルールとプロキシチェーンを確認する

Webサイトが想定したノードを経由しない場合は、まず接続画面でドメインを検索し、適用されたルールとプロキシチェーンを確認します。たとえば「DOMAIN-SUFFIX → DIRECT」と表示されるなら、ルールによって直接接続が明示されています。「MATCH → ノード選択 → あるノード」と表示されるなら、リクエストはフォールバックルールに入り、指定されたプロキシグループとノードを経由しています。

接続によってはドメイン名が表示されず、IPアドレスだけが表示されることがあります。アプリがIPへ直接アクセスしている、DNSの対応情報が関連付けられていない、スニッフィング機能がプロトコル内のホスト名を認識できていない、といった原因が考えられます。この場合は対象IP、プロセス情報、ログを組み合わせて判断し、ドメイン名が空欄だからといってルールが無効だと決めつけないでください。

Webページを閉じても接続が残る理由

現在のブラウザーはHTTP/2、HTTP/3、長時間接続を再利用することがあり、メッセージアプリも継続的なセッションを維持します。そのため、ページを閉じても接続がしばらく残ることがあります。ノードやルールを切り替えても、古い接続が新しい出口へ自動的に移行することは通常ありません。接続画面の終了ボタンで特定の接続を停止すると、アプリは現在のルールに従って接続を再確立します。

「すべて閉じる」を実行すると、進行中のダウンロード、通話、バックグラウンド同期が中断されます。プロキシモードやプロキシグループを変更した後の確認には便利ですが、日常的な高速化手段として使うものではありません。接続がすぐに何度も再作成される場合は、どのプロセスが継続的にリクエストを送っているかを確認します。

ログ画面：レベルと時刻から起動・DNS・接続エラーを特定する

ログ画面には、コアの動作イベントが記録されます。一般的なレベルはdebug、info、warning、errorです。通常の利用ではinfoで十分です。debugはマッチングや接続の詳細をより多く出力するため、短時間の調査に向いていますが、記録量が大幅に増えます。調査が終わったら通常のレベルに戻してください。

まずエラーが発生した段階を判断する

  • 起動段階：設定の解析失敗、待ち受けポートの競合、権限不足、TUNデバイスの作成失敗、データベースファイルの読み込み異常を確認します。
  • DNS段階：名前解決のタイムアウト、上流サーバーへの到達不能、異常なアドレス応答、fake-ipとアプリの互換性問題を確認します。
  • 接続段階：接続タイムアウト、接続拒否、TLSハンドシェイク失敗、ネットワーク到達不能、ノード認証エラーを確認します。
  • ルール段階：ルールプロバイダーのダウンロード失敗、プロキシグループの不存在、現在のコアでサポートされていないルールフィールドを確認します。

1件のログには通常、時刻、レベル、ネットワーク種別、対象アドレス、適用ルール、最終的な出口が含まれます。最後の「timeout」だけを見るのではなく、同じ対象の前後にあるDNSやルーティングの記録を追ってください。タイムアウトは、ローカルからノード、ノードから対象、DNSクエリのどの段階でも起こり得るため、対処方法も異なります。

INFO  TCP connection matched DOMAIN-SUFFIX
source: 127.0.0.1
target: example.com:443
policy: ノード選択
outbound: 自動選択

このような記録は、接続がコアに入り、ドメインルールに従って「ノード選択」プロキシグループへ渡されたことを示します。接続画面にもログにも対象リクエストが見つからない場合は、通信がClashへ入る前に問題が起きている可能性があります。概要画面に戻り、システムプロキシ、TUN、アプリのプロキシ設定、バイパスルールを確認してください。

ルール画面とプロバイダー画面：設定内容が読み込まれているか確認する

一部のクライアントには、ルール画面、プロキシプロバイダー画面、ルールプロバイダー画面が個別に用意されています。ルール画面では通常、現在の読み込み順に沿ってDOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、GEOSITEなどの項目と適用先のプロキシグループが表示されます。特定のルールが存在するかの確認には便利ですが、実際に適用された結果は接続画面を基準にしてください。

プロキシプロバイダーは外部ファイルからノードのグループを読み込み、ルールプロバイダーはルールのグループを読み込みます。画面に表示される更新時刻、ヘルスチェックの状態、エラーメッセージから、リモートリソースが利用可能か判断できます。プロバイダーの更新に成功しても、メインのサブスクリプションが更新されたとは限りません。それぞれ別のURLと更新間隔を持つ場合があります。

mihomoは豊富なルール形式と実行機能に対応していますが、設定を利用できるかどうかはクライアントに同梱されたコアのバージョンにも左右されます。「サポートされていないルール形式」や「不明なフィールド」が表示された場合は、クライアントの外側のバージョン番号だけでなく、実際に動作しているコアを確認してください。

設定画面：ポート・モード・DNS・システム起動項目の選び方

設定画面は項目が最も多いことが多いものの、頻繁に変更する必要がある設定は限られています。特に理解しておきたいのは、プロキシモード、待ち受けポート、LANアクセス、DNS、TUN、外部コントロール、OS起動時の自動起動です。

プロキシモード

  • Rule：設定内のルールに従って、直接接続、拒否、プロキシのいずれかを決めます。日常利用で最も一般的なモードです。
  • Global：通信をグローバルプロキシグループへ渡します。ルールによる分流が原因かどうかを一時的に確認するときに使います。
  • Direct：通信を直接接続します。プロキシ経路を一時的に無効にして比較テストするときに適しています。

グローバルモードにしても、すべてのシステム通信が自動的にクライアントへ入るわけではありません。すでにコアへ入っている通信の出口の選び方だけが変わります。システムプロキシもTUNも有効になっていなければ、Globalへ切り替えても効果が見えないことがあります。

LANアクセスと外部コントロール

「LAN接続を許可」を有効にすると、同じネットワーク上の他のデバイスが本機のプロキシ待ち受けポートへアクセスできる可能性があります。プロキシを共有する明確な目的がある場合だけ有効にし、ファイアウォール、待ち受けアドレス、認証設定でアクセス範囲を制限してください。外部コントロールインターフェースは、グラフィカルな画面や管理ツールが状態を読み取り、プロキシグループを切り替えたり接続を終了したりするために使われます。信頼できないネットワークへ公開しないことが重要です。

DNSとfake-ip

ClashのDNSモジュールは、設定に応じて上流サーバーを選択し、ルールマッチング、ドメインの復元、TUNによる通信取り込みと連携します。fake-ipモードでは、アプリに予約アドレスを返し、コアがその接続を元のドメインへマッピングします。これにより、ドメインベースの分流を行いやすくなります。一部のLANサービス、特殊なゲーム、実際の名前解決結果を必要とするアプリでは、除外リストへの追加が必要になることがあります。

DNSの問題は、複数の項目を同時に変更して解決しようとしないでください。まずシステムのDNSクエリがClashへ渡っているかを確認し、次に上流DNSへ到達できるかを調べ、最後に対象ドメインの応答結果と適用ルールを確認するのが安全です。ブラウザーのセキュアDNS機能がシステムの名前解決経路を迂回することもあるため、あわせて確認します。

OS起動時の自動起動とサイレント起動

OS起動時の自動起動はクライアントを起動するだけで、コアの自動起動、システムプロキシの復元、TUNの有効化まで行うかどうかは、クライアント側の個別設定によって決まります。「再起動後にインターネットへ接続できない」場合は、前回のスイッチ状態が復元されているか、異常終了後にシステムプロキシがローカルポートを指したままになっていないかを確認してください。

再現性のあるClash画面トラブルシューティング手順

各画面の役割を理解したら、よくある問題を固定の手順に沿って確認できます。ノード、DNS、モードを順番なく試す必要がなくなります。

  1. 設定画面を確認：現在選択されている設定、更新時刻、読み込み状態を確認し、構文エラーやプロバイダーエラーがないか調べます。
  2. 概要画面を確認：コアが動作していることを確認し、通信がシステムプロキシ経由なのかTUN経由なのかを把握します。
  3. プロキシモードを確認：普段はRuleを使用します。ルールの影響を判断するときは、短時間だけGlobalまたはDirectに切り替えて比較します。
  4. プロキシ画面を確認：対象のプロキシグループで利用可能なノードが選択されていることを確認します。対象通信と関係のないグループだけを変更しないよう注意してください。
  5. 接続を再確立：対象アプリの古い接続を終了し、既存のセッションが以前の出口を使い続けないようにします。
  6. 接続画面を確認：対象ドメインまたはIPを見つけ、適用ルール、プロキシチェーン、実際の出口を確認します。
  7. ログ画面を確認：障害が発生した時刻を基準に、DNS、接続、TLS、ルール、権限に関するエラーを探します。

DirectではアクセスできるのにRuleではアクセスできない場合は、ルールとプロキシグループを重点的に確認します。Globalでもアクセスできない場合は、ノード、DNS、対象への到達性を引き続き確認してください。3つのモードすべてで該当する接続記録がない場合は、システムプロキシ、TUNのルーティング、アプリ自体のプロキシ設定を調べます。このように段階を分けて判断すれば、問題が設定、通信の取り込み、分流、出口のどこにあるかをすばやく絞り込めます。

Clashクライアントの画面は、本質的にはコアを観察・制御するためのツールです。プロキシ画面は「どの出口を使うか」、設定画面は「ルールとノードがどこから来るか」、接続画面は「この通信が実際にどこへ向かったか」、ログ画面は「実行中に何が起きたか」に答えます。この4つを理解していれば、別のプラットフォームや画面構成に移行しても、対応する機能を見つけ、基本設定とトラブルシューティングを行えます。

Clashクライアントの設定を続ける

使用中のシステムに合ったクライアントを選び、ガイドに沿って設定の読み込み、プロキシモードの選択、接続確認を行ってください。

ダウンロードページへ ガイドを見る