Clashクライアントの画面の見方：プロキシ・設定・ログの3画面を詳しく解説

画面・コア・設定ファイルをまず区別する

Clashクライアントは通常、3つの層で構成されます。グラフィカルインターフェースはボタンや状態を表示し、Clash Meta（現在は mihomo と呼ばれることが一般的）などのコアは接続を制御して DNS 処理やルール照合を実行し、YAML設定ファイルはポート、ノード、プロキシグループ、ルールを定義します。画面で「ノードA」をクリックする操作は、実際にはコアの制御インターフェースへプロキシグループの選択を送信しています。「サブスクリプションを更新」をクリックした場合は、リモート設定を取得してコアに再読み込みさせます。

クライアントによって、項目名は「プロキシ」「ポリシー」「Proxies」などと表示されたり、「設定」が「サブスクリプション」「Profiles」と表記されたりします。ボタンの位置もデスクトップ版とモバイル版で異なりますが、データの関係は基本的に同じです。画面を見るときはアイコンの位置だけを覚えず、現在の領域がコアの制御、設定の管理、実行ログの確認のどれに当たるかを判断しましょう。

上部のステータス領域に表示される項目

実行状態：コアが起動しているかどうか。画面を開けても、コアが動作しているとは限りません。
システムプロキシ：Windows、macOS、またはデスクトップ環境の HTTP プロキシをローカルの待受ポートへ向けているかどうか。
TUNモード：仮想ネットワークインターフェースを使い、システムプロキシを参照しないアプリの通信までより広く取り込むかどうか。
通信量統計：現在のアップロード・ダウンロード速度と累計通信量。これらはクライアント側の統計であり、回線速度テストの結果とは異なります。
アクティブ接続：コアが現在維持している TCP・UDP 接続数。Webページを閉じた後も、再利用される接続がしばらく残る場合があります。

一般的なデスクトップ設定では、混合プロキシポートに 7890、外部制御ポートに 9090 を設定することがあります。古い設定では HTTP と SOCKS をそれぞれ 7890 と 7891 に割り当てる場合もあります。これらはよくある値であり、固定された標準ではありません。実際のポートは「設定」→「ネットワーク」→「ポート設定」を確認するか、現在の YAML にある mixed-port、port、socks-port を直接確認してください。

プロキシ画面：プロキシグループ、ノード、遅延値

プロキシ画面は単なるサーバー一覧ではありません。まず設定内のプロキシグループを表示し、各グループ内に選択可能なノードや下位プロキシグループを一覧表示します。ルールは最終的にプロキシグループ名を指定し、そのグループが接続先のノードを決めます。この関係を理解すれば、特定のノードを切り替えても一部の通信にしか影響しない理由が分かります。

プロキシグループのカードの見方

プロキシグループには通常、グループ名、種類、現在の選択、候補一覧が表示されます。たとえばルールが動画配信サービスのドメインを「動画配信」グループへ送り、そのグループが現在「香港ノード」を選択しているとします。この場合、「ノード選択」グループを変更しても動画配信には影響しないことがあります。2つのルールが別々のプロキシグループを指定している可能性があるためです。

select：手動選択。候補をクリックすると、通常は以後の新しい接続でその候補が使われます。
url-test：設定した間隔で候補をテストし、テスト結果の遅延がより低いノードを自動選択します。
fallback：候補を上から順に確認し、利用可能と判定された候補のうち先頭のノードを優先して使います。
load-balance：設定した方式に従って複数の候補ノードへ異なる接続を振り分けます。1本のダウンロード接続の帯域を単純に合算する機能ではありません。

DIRECT はローカルネットワークから直接接続すること、REJECT は接続を拒否することを示します。どちらも内蔵ポリシーであり、リモートサーバーではありません。広告ドメインが REJECT に一致すると、ログには拒否記録が残る場合がありますが、プロキシ画面にはノードの遅延が表示されません。

遅延テストの結果は帯域幅ではない

ノードの横に表示される 68 ms や 214 ms などの数値は、通常、テストURLへ HTTP リクエストを送信して応答するまでの時間です。その時点の接続応答性は分かりますが、ダウンロード速度を直接示すものではありません。テストURL、DNS解決、TLSハンドシェイク、ノードの負荷、ローカルWi-Fiなどによって結果は変わります。80 ms のノードが、50 ms のノードより高いスループットを持つこともあります。

まずプロキシグループ単位のテストボタンをクリックし、すべての候補から結果が返るまで待ちます。
タイムアウトと表示されたノードは、瞬間的なパケットロスを除外するため、もう一度テストします。
候補を選択したら、対象サイトを開き直して新しい接続に新しいポリシーを適用します。
古いページがまだ以前のノードを使っている場合は、接続画面で該当する接続を終了するか、自然に閉じるまで待ちます。

設定画面：サブスクリプション、アクティブ設定、オーバーライド

設定画面で管理するのは設定の取得元です。一般的な項目には、リモートサブスクリプション、ローカル YAML、クライアントが生成した一時設定、オーバーライド処理後の実行設定などがあります。1つのクライアントに複数の設定を保存できますが、コアが同時に読み込むアクティブ設定は通常1つだけです。

サブスクリプションカードの各操作

有効化またはアクティブに設定：コアにこの設定を読み込ませます。読み込みに失敗した場合、クライアントが直前の利用可能な設定を保持することがあります。
更新：サブスクリプションURLへ再度リクエストを送り、リモートの最新内容を取得します。更新しただけで、その設定へ自動的に切り替わるとは限りません。
情報を編集：名前、更新間隔、サブスクリプションURLを変更します。通常、リモートから返されたノード内容を直接編集する機能ではありません。
ファイルを表示：ダウンロード済みの YAML を開き、フィールドや構文を確認します。保存できるかどうかはクライアントの実装によって異なります。
削除：ローカルの設定記録を削除します。現在のアクティブ設定である場合は、先に正常に読み込める別のファイルへ切り替えてください。

サブスクリプションを更新したら、まず「最終更新」時刻が変わったか確認し、次にノード数とプロキシグループが想定どおりか確認します。時刻は更新されたのに内容が変わらない場合、リモート側から同じ設定が返された可能性があります。HTTP 401、403、429 が表示された場合は、サブスクリプションの権限、URLの有効期限、リクエスト頻度を確認してください。ダウンロードに成功しても読み込みに失敗する場合は、YAMLの構文とフィールドの互換性を確認します。

オーバーライドと直接編集の違い

リモートサブスクリプションは次回の更新時に再ダウンロードされます。キャッシュファイルを直接変更すると、新しい内容で上書きされることが少なくありません。オーバーライド機能は、サブスクリプションのダウンロード後かつコアの読み込み前にフィールドを追加・調整するため、ローカルのポート、DNS、TUNパラメータを維持したい場合に適しています。クライアントによっては「設定」→「オーバーライド」に入口があり、設定カードのその他メニューに配置されている場合もあります。

mixed-port: 7890
mode: rule
log-level: info
allow-lan: false

external-controller: 127.0.0.1:9090

この一般的なフィールド例では、混合プロキシがローカルの 7890 で待ち受け、動作モードはルールモード、ログレベルは info、LAN内の端末からプロキシポートへ直接アクセスできず、制御インターフェースはループバックアドレスのみで待ち受けます。グラフィカルインターフェースの表示ポートとファイル内のポートが異なる場合は、クライアントがオーバーライドによって別の実行設定を生成していないか確認してください。

ログ画面：1件の記録から接続経路を確認する

ログ画面ではコアのイベントを確認できます。設定の読み込み、待受ポート、DNSの初期化などの実行メッセージだけでなく、接続先、ルールの一致、プロキシ経路も記録されます。「クライアントは接続済みなのにWebサイトを開けない」問題を調べるとき、ログはプロキシ画面の遅延値より直接的な手掛かりになります。

ログレベルの選び方

error：ポートのバインド失敗、設定の解析失敗、ネットワークリクエストの失敗など、明確なエラーだけを確認します。
warning：動作に影響する可能性はあるものの、直ちに停止するとは限らない異常を確認します。
info：日常的なトラブル対応に適したレベルで、通常は接続先、ヒットしたルール、送信先ポリシーを確認できます。
debug：内部処理をより詳細に記録します。複雑な問題を短時間で特定する場合に適していますが、常時有効にすると大量の情報が出力されます。
silent：ログ出力をできるだけ減らします。トラブル対応の段階には適していません。

一般的な操作手順は「設定」→「パラメータ設定」→「ログレベル」→「Info」です。DNSやTUNの詳細を追跡する必要がある場合だけ、一時的に Debug へ切り替え、問題を1回再現してから Info に戻します。クライアントによってメニュー名は多少異なりますが、最終的に変更されるのは通常、設定フィールド log-level です。

1件の接続ログから読み取れる手掛かり

TCP 127.0.0.1:53142 --> example.com:443
match DomainSuffix(example.com)
using ProxyGroup[Hong Kong 01]

1行目は、ローカルプロセスが TCP で example.com:443 へアクセスしたことを示します。2行目はドメインサフィックスのルールに一致したことを示し、3行目にはルールが指定したプロキシグループと最終的な選択が表示されます。実際の mihomo のログ形式はバージョンやクライアントの実装によって変わりますが、確認すべき情報は常に4つです。プロトコル、接続先アドレス、一致したルール、送信経路です。

現在のログを消去し、古い記録が調査の邪魔をしないようにします。
対象アプリの古い接続を終了し、対象ページを開き直します。
ドメイン名、対象IP、ポートで絞り込みます。たとえば :443 を検索します。
記録が DIRECT、特定のプロキシグループ、REJECT のどれになっているか確認します。
記録がまったくない場合は、対象アプリがシステムプロキシを参照しているか、TUNの有効化が必要かを確認します。

接続画面と3つの主要画面の連携

多くのクライアントには「接続」画面もあります。現在アクティブな接続の送信元アドレス、対象ホスト、ダウンロード量、アップロード量、ルール、プロキシ経路を表示します。ログがイベントの流れを示すのに対し、接続画面は現在の状態を示します。両方を組み合わせると、ノードを切り替えた後も古いダウンロードが以前の経路を使い続ける理由を確認できます。

ブラウザーがすでに「ノードA」を経由して HTTP/2 の長時間接続を確立している状態で、プロキシ画面から「ノードB」へ切り替えたとします。既存の接続は通常、新しいノードへ移行しません。接続画面には以前の経路が表示され、新しく開いた接続からノードBが使われます。接続を終了すると現在のリクエストが中断され、保存中のファイルや通話も切断される場合があります。そのため、「すべて閉じる」を日常的な更新ボタンとして使わないでください。

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

システムプロキシは、ブラウザーやOSのプロキシ設定に従うアプリに適しています。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」で状態を確認できます。macOSでは「システム設定」→「ネットワーク」→「現在のネットワーク」→「詳細」→「プロキシ」で確認します。クライアントでシステムプロキシを有効にすると、接続先は通常 127.0.0.1 と現在の HTTP または混合ポートになります。

TUNモードは仮想ネットワークアダプターを通じてより多くの通信を取り込みます。システムプロキシを参照しないアプリ、一部のコマンドラインプログラム、UDPが必要な場面に適しています。デスクトップOSで初めて有効にするときは、管理者権限を求められる場合があります。TUNを有効にした後に完全に通信できなくなった場合は、仮想インターフェースの作成、デフォルトルートの追加、コアによるDNS処理、他のVPNやネットワークフィルタリングソフトによるルート変更を確認してください。

初回設定後に確認する画面の順番

初めてクライアントを開いたとき、すぐに複雑なルールを変更する必要はありません。設定の読み込み、コアの起動、ポリシーの選択、通信の取り込み、ログの確認という、検証しやすい最短経路から始めます。以下の手順は Windows 11 24H2、macOS、一般的な Android クライアントで利用できます。具体的な権限確認の表示はシステムによって異なります。

設定画面を開く：サブスクリプションまたはローカル YAML を読み込み、設定を解析できること、プロキシグループとノード数が正常であることを確認します。
アクティブ設定にする：上部のステータスを確認し、ファイルのダウンロードだけでなく、コアが実行状態になっていることを確認します。
プロキシ画面を開く：候補ノードの遅延を一度テストし、手動選択グループで応答可能なノードを1つ選びます。
システムプロキシを有効にする：デスクトップ版ではまずシステムプロキシでブラウザー通信を確認します。待受アドレスがローカルアドレスで、ポートが設定画面と一致していることを確認してください。
ログ画面を開く：Infoレベルを維持したまま新しいドメインへアクセスし、対象、ルール、ポリシーの記録が表示されることを確認します。
必要に応じてTUNを有効にする：アプリがシステムプロキシを参照しない場合、UDPを取り込む必要がある場合、または通信を一元管理したい場合に限って有効にします。

よくある画面上の症状と確認ポイント

ノードの遅延は正常なのにWebページを開けない：ログで実際に一致したポリシーを確認し、DNS解決と対象ポートが失敗していないか確認します。
サブスクリプションの更新は成功したのにプロキシ画面が空：アクティブ設定への切り替えが成功しているか、YAMLに proxy-groups が含まれているかを確認します。
システムプロキシを有効にしたら全体が通信不能になった：コアが実行中であること、プロキシポートが他のプロセスに使用されていないこと、システムプロキシのアドレスと待受ポートが一致していることを確認します。
ノードを切り替えても変化がない：古い接続を終了して再試行し、対象の通信が直前に変更したプロキシグループを使っていることを確認します。
ログに対象の記録がまったくない：アプリがシステムプロキシを迂回していないか確認します。ゲームや独立したアップデーターの場合は、設定を確認したうえでTUNをテストしてください。
起動時に address already in use と表示される：7890、7891、またはカスタムポートが別のクライアントや残存しているコアに使用されていないか確認します。

画面操作から設定ファイルの読み方へ

3つの画面に慣れたら、各クリック操作を YAML に対応付けて確認できます。プロキシ画面は proxy-groups と proxies に由来し、設定画面はファイル全体と更新元を管理し、ログ画面は rules の一致結果を表示します。システムプロキシとTUNは、通信が最初にコアへ入るかどうかを決めます。この見方を身につければ、特定バージョンのクライアントの固定レイアウトに依存せず画面を読めます。

設定を変更するときは、検証の一連の流れを保ちます。保存後に設定が再読み込みされたことを確認し、プロキシ画面でプロキシグループが残っていることを確認し、ログで対象ドメインが想定したルールに一致したことを検証します。異常が出たら、まず直前の利用可能な設定へ戻し、起動できないファイルに変更を重ねないでください。