Clashクライアント画面ガイド：プロキシ・設定・ログ画面の役割

まず理解したい：クライアント画面とプロキシコアの違い

Clashクライアントは通常、GUIとプロキシコアで構成されます。GUIはサブスクリプションの取り込み、プロキシグループの表示、設定の切り替えを担当し、コアはローカルポートの待ち受け、ルール判定、接続の確立を担当します。ウィンドウが開いていても、コアが起動しているとは限りません。ノード一覧が表示されても、アプリの通信がコアに届いているとは限りません。

Clash Meta（現名称：mihomo）を採用したクライアントでは、TUN、プロセスルール、DNSの拡張モードなどを利用できる場合があります。対応機能はコアとクライアントの実装によって異なります。この記事では機能ごとに説明し、特定のクライアントの画面構成を共通仕様として扱いません。デスクトップ版ではサイドバー、モバイル版では下部タブやドロワーメニューが一般的です。同じ名前のボタンが見つからない場合は、下の表で対応する機能を探してください。

概要画面：稼働状況と通信の取り込みを確認

コアの起動とシステムプロキシの有効化は別

概要画面には通常、リアルタイムのアップロード・ダウンロード速度、累計通信量、稼働状況が表示されます。速度がゼロでも、現在の集計対象で通信が発生していないだけかもしれません。それだけでノード障害とは判断できません。初回利用時は、まずコアが起動していることを確認し、次にアプリの通信をどの方法でクライアントに渡すかを確認してください。

• システムプロキシ：OSにローカルプロキシのアドレスを登録します。システムプロキシ設定に従うアプリが対象です。一部のゲーム、コマンドラインツール、独自のプロキシ設定を持つソフトは利用しません。
• TUNモード：仮想ネットワークインターフェースを使い、ルーティング条件に合う通信を取り込みます。管理者権限やサービスが必要な場合があり、ルートの除外設定、DNS、クライアントの設定にも左右されます。
• LAN内からの接続を許可：他のデバイスから、この端末のプロキシ待ち受けポートに接続できるようにする設定です。この端末のブラウザーがインターネットに接続するために必要な設定ではありません。有効にする前に、待ち受けアドレス、ファイアウォール、アクセス認証を確認してください。

画面上では「概要」→「システムプロキシ」から切り替え項目を探せます。クライアントによっては、タスクトレイの右クリックメニューにあります。TUNの設定は「設定」→「TUNモード」にあることが多いです。これは機能を探すための目安です。実際のメニューは利用中のクライアントで確認してください。「システムプロキシ」と「TUN」は名前が似ていても別の設定です。

ポートとプロキシモードの違い

ローカルポートは、アプリの接続先を指定します。設定画面で混合ポートが7890と表示されている場合、HTTPプロキシに対応したアプリには、アドレスを127.0.0.1、ポートを7890と設定できます。これは設定例であり、すべてのクライアントの初期値ではありません。画面に別のポートが表示されている場合は、その値を使ってください。混合ポートは通常HTTPとSOCKSの両方に対応します。HTTP専用・SOCKS専用ポートを使う場合は、アプリ側で選んだプロキシの種類と一致させてください。

ルール、グローバル、ダイレクトは別の概念です。ルールモードではルールに沿って通信を振り分けます。グローバルモードでは通常、グローバル用のプロキシグループで出口を選びますが、すべてのアプリの通信が取り込まれるわけではありません。ダイレクトモードでは、コアに届いた通信を直接外部へ接続します。普段はルールモードを使い、ルールの影響を切り分けたい場合に限って、一時的にグローバルモードへ切り替えるとよいでしょう。

設定画面：サブスクリプションの更新と適用を確認

設定画面では、個々のノードではなく設定一式の管理を行います。設定の取得元はサブスクリプションURLの場合も、ローカルのYAMLファイルの場合もあります。ノードだけでなく、プロキシグループ、ルール、DNS、ルールセットの参照情報が含まれることもあります。インポート成功は、クライアントが設定を受け取ったことを示すだけです。解析に成功したか、選択して適用されているか、更新が完了したかも確認してください。

1. 「設定」または「Profiles」を開き、インポート機能からサブスクリプションまたはローカルファイルを追加します。
2. 設定項目の更新日時、ステータス、エラーメッセージを確認します。サブスクリプションの更新タイムアウトとYAMLの解析エラーは別の問題です。
3. 設定項目をクリックするか「有効化」を選び、現在使用中の表示がその項目に移ったことを確認します。
4. プロキシ画面を開き、プロキシグループとノードが表示されるか確認します。続いてルール画面で、ルールの内容が想定どおりか確認してください。

更新後に自動適用するクライアントもあれば、手動で再読み込みが必要なクライアントもあります。更新してもノード一覧が変わらない場合は、まず現在有効な設定を確認してください。すぐに何度もインポートするのは避けましょう。似た名前の設定が増えると選び間違えやすく、「ファイルを変更したのに反映されない」と誤解する原因にもなります。

サブスクリプションの内容と上書き設定、実行時設定は異なる場合がある

GUIクライアントでは、画面上の設定でサブスクリプション内のポート、DNS、TUN項目などを上書きすることがあります。また、設定のマージやスクリプト処理に対応している場合もあります。そのため、サブスクリプションの内容がそのままコアに渡されるとは限りません。トラブル対処では、「実行時設定」「有効な設定を表示」などの項目を探し、最終的な値を確認してください。項目の有無はクライアントによって異なります。

一時生成された実行用ファイルを直接編集して、長期的な設定を保存するのは避けてください。再読み込み時に再生成されることがあります。サブスクリプションのファイルも更新時に置き換えられる場合があります。変更を維持したい場合は、クライアントが対応する上書き設定を使うか、バックアップを取ったうえで独立したローカル設定を管理してください。

プロキシ画面：選ぶのはプロキシグループで、単一のノードとは限らない

プロキシ画面では通常、まずプロキシグループが表示され、その中に選択肢が並びます。グループにはノード、別のプロキシグループ、DIRECTなどの組み込みポリシーを含められます。ノードを選んでも、対象サイトに適用されるルールがそのグループを参照していなければ、通信経路は変わりません。現在の接続で使われていないグループを変更しても、その接続の出口には影響しません。

遅延の数値はダウンロード速度の順位ではない

同じテストでノードAが65 ms、ノードBが120 msと表示されたとします。これは、そのテスト先への応答にかかった時間が異なることを示すだけです。数値は説明用の例であり、本サイトでの実測値ではありません。テストURL、DNS、ハンドシェイク、測定時のネットワーク状況によって結果は変わります。動画の通信速度やゲームのUDP通信の快適さは、この数値だけでは判断できません。

テストがタイムアウトしても、ノードが完全に使えないとは限りません。テスト先に到達できない可能性もあります。まず設定されているテスト先を確認し、実際の通信で動作を確かめてください。手動で切り替えた後は、新しい接続を開始します。すでに確立した長時間接続は、選択肢を変更しても自動で経路が切り替わらないことがあります。

ルール画面：ルールの数ではなく適用順序を確認

ルール画面には、現在読み込まれている通信振り分けルールが表示されます。通常は上から順に照合され、最初に一致したルールのポリシーが適用されます。ドメインサフィックス、IPアドレス範囲、最後のフォールバックルールには、それぞれ異なる役割があります。ルールが多くても、期待どおりに振り分けられるとは限りません。以下はルールの仕組みを示す例で、現在のサブスクリプションと置き換えて使える完全な設定ではありません。

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,PROXY

1行目は、一致したドメインを直接接続にします。2行目は該当するプライベートIPv4アドレス範囲に一致させ、このルールのためだけにドメイン解決を実行しないようno-resolveを指定しています。最後の行は、それまでに一致しなかった通信をPROXYという名前のポリシーに渡します。実際の設定にそのポリシー名がなければ、この例をそのまま使うことはできません。

ここでのexample.comは、ドキュメント用の例示ドメインです。実際のトラブル対処では、接続画面に記録された接続先ドメインを使ってください。1つのウェブページでも、ログイン、画像、APIなど複数のドメインへ同時にリクエストすることがあります。ブラウザーのアドレスバーに表示されたドメインだけを調べると、失敗したリクエストを見落としやすくなります。

RULE-SETを使う設定では、参照先のルールセットが正常に読み込まれていることも確認してください。ルール画面に参照が表示されていても、リモートのルールセットがダウンロード済みとは限りません。ルール定義の正しさと接続で実際に適用されたルールは、接続画面とログ画面をあわせて確認してください。設定の構成について詳しくは、使い方ガイドのプロキシグループ解説をご覧ください。

接続画面：通信が実際に通った経路を確認

接続画面は、通信の振り分けを確認するのに最も直接的な画面です。一般的な表示項目は、接続先ホスト、接続先ポート、送信元アドレス、ネットワーク種別、適用ルール、プロキシ経路、アップロード量、ダウンロード量です。クライアントによってはプロセス名も表示されますが、OSの権限やコアの機能に左右されます。プロセス欄が空白でも、接続に異常があるとは限りません。

1. 関係のないダウンロードを一時停止して、一覧のノイズを減らします。表示記録は消去できますが、「記録の消去」と「接続の切断」は別の操作なので注意してください。
2. 確認したいサイトを開き、すぐにドメイン名またはプロセス名で絞り込みます。
3. 接続先ポートを確認します。たとえばHTTPSでは443がよく使われます。続けて適用ルールとプロキシ経路を確認してください。
4. ノードやルールを変更した場合は、該当する既存の接続を切断してからページを再読み込みし、新しい接続を開始します。

一覧に対象のリクエストがまったく見当たらない場合は、まず通信の取り込み経路を確認します。アプリがシステムプロキシに従うか、独自のプロキシ設定を使っていないか、TUNのルートが対象通信をカバーしているかを調べてください。リクエストが表示され、プロキシ経路の末尾がDIRECTなら、ノードの速度を何度も測るのではなく、適用されたルールを確認します。

ブラウザーのアクセスでは、TCPとUDPの両方が発生することがあります。HTTP/3を使うリクエストはUDP接続として表示される場合もあります。接続が通信中でも画像が表示されない場合は、失敗したリソースごとに確認してください。ページ本体の接続成功だけで、すべてのリソースが正常とは判断できません。

ログ画面：発生時刻を手がかりにエラーを追う

ログ画面に記録されるのはイベントであり、ブラウザーの閲覧履歴ではありません。ログレベルには通常、error、warning、info、debugがあります。選べるレベルはクライアントとコアによって異なります。普段は情報レベルを使い、詳細な調査が必要なときだけ短時間デバッグを有効にしてください。問題を再現したら元に戻し、ログが増えすぎて重要な記録が埋もれないようにします。

同じtimeoutでも、サブスクリプションのダウンロード、ノードへの接続、DNSクエリのいずれを指す場合もあります。時刻、コンポーネント、接続先をあわせて確認してください。更新やノード切り替えを行った時刻を記録し、問題を一度だけ再現してから、その前後約10秒のログを確認するのがおすすめです。複数の設定を同時に変更すると、原因との関係が分かりにくくなります。

読み込みからルール適用の確認まで：一通りのチェック

初めて設定するときは、次の順番で確認してください。各ステップでは確認事項を1つに絞り、問題が見つかったら該当する画面で対処します。DNS、TUN、ルール、ノードを一度に変更する必要はありません。

1. 設定画面：サブスクリプションの読み込みが成功し、現在の設定が有効で、更新エラーがないことを確認します。
2. 概要画面：コアが正常に稼働し、ローカルポートとアプリの設定が一致していることを確認します。テストでは通信を取り込む方法を1つ選んでください。
3. プロキシ画面：対象のプロキシグループを確認し、最終的に利用可能なノードまたは想定したポリシーにつながることを確かめます。
4. ルール画面：関連するルールが存在し、適用順序が妥当で、ルールセットが読み込まれていることを確認します。
5. 接続画面：新しい接続を開始し、接続先、適用ルール、最終的な出口を確認します。
6. ログ画面：接続に失敗した場合は、同じ時間帯のログから名前解決、接続、設定のエラーを特定します。

6つの画面で確認できる情報を覚えておきましょう。設定画面は「何を読み込んだか」、プロキシ画面は「どの出口を選ぶか」、ルール画面は「どう振り分けるか」、接続画面は「実際に何が起きたか」、ログ画面は「どこでエラーが起きたか」を示します。概要画面では稼働状況と通信の取り込み方法を確認できます。ブラウザーやOSのネットワーク設定も確認する場合は、接続確認の手順を順番にお試しください。