Clashクライアントの画面ガイド：プロキシ・設定・接続・ログの各画面を解説

画面の見方：設定・選択・稼働状況を区別する

Clashクライアントは、グラフィカルな画面とプロキシコアを組み合わせて動作します。画面では設定のインポートや変更、状態の確認を行い、ClashまたはClash Meta（mihomo）コアはポートの待ち受け、ルールの照合、接続の確立を担います。そのため、画面が開くこと、サブスクの更新に成功すること、ノードの遅延を測定できることは、それぞれ別の状態です。互いに代わりにはなりません。

サイドバーの項目名や並び順はクライアントによって異なります。デスクトップ版では「プロキシ」「設定」「接続」「ルール」「ログ」「設定」などが一般的ですが、モバイル版では一部の機能が下部ナビゲーションやサブメニューに配置されることがあります。以下では一般的な機能の流れに沿って説明します。メニュー名は機能の場所を示すもので、実際の表示は利用中のクライアントにより異なります。特定バージョンの画面をそのまま再現するものではありません。

画面	主な対象	まず確認すること
プロキシ画面	プロキシグループとノード	現在のモード、グループ内の選択項目
設定画面	サブスク、YAML、オーバーライド	有効な設定、更新結果
接続画面	処理中の接続	宛先、ルール、プロキシチェーン
ルール画面	適用されるルール	ルールの順序、宛先ポリシー
ログ画面	コアの稼働イベント	時刻、レベル、エラー箇所
設定画面	トラフィックの入口とクライアント設定	システムプロキシ、TUN、待ち受けポート

プロキシ画面：ノードを選ぶだけでなく、プロキシグループを選択する

ルール・グローバル・DIRECTモード

一般的なメニューは「プロキシ」→「モード」です。ルールモードは mode: rule に対応し、接続は設定内のルール順に出口を選択します。グローバルモードでは通常の接続がグローバルポリシーに渡され、GLOBAL と表示されることがあります。DIRECTモードでは直接接続します。モードで決まるのはトラフィックの振り分け方であり、アプリの通信をコアに送るシステムプロキシやTUNの代わりにはなりません。

通常はまずルールモードを選び、ルールが参照しているプロキシグループを確認します。たとえば、あるドメインの接続先が「Web用出口」に設定されているのに「ダウンロード用出口」だけを変更しても、そのドメインへの新しい接続は元のノードを使うことがあります。切り替えが反映されたか確認するときは、ノードカードのハイライトだけでなく、実際に使われたグループを確認しましょう。

プロキシグループの種類によってボタンの役割が異なる

select：ノードまたは子プロキシグループを手動で選択します。出口を明示的に指定したい場合に使います。
url-test：設定されたテスト先と間隔を使って候補を評価し、許容値などの設定に応じて出口を選択します。ダウンロード速度のランキングとは異なります。
fallback：通常、候補の順序に従って利用可能な項目を選択します。遅延が最も短い項目を常に選ぶのではなく、障害時の切り替えを重視します。
load-balance：設定された方式に基づいて接続を振り分けます。通常の1つのダウンロード接続で、すべてのノードの帯域が合算されるわけではありません。

グループには DIRECT、REJECT、または別のプロキシグループが含まれることもあります。それぞれ直接接続、拒否、次のグループへの引き渡しを意味し、すべてが実サーバーというわけではありません。速度テストボタンに表示されるミリ秒値は、指定したテスト先への測定結果です。たとえば80 msと160 msは、その測定条件で比較するための値であり、動画の実効速度を示すものではありません。ここに示す数値は読み方の例で、実測結果ではありません。

設定画面：インポート・更新・有効化は別の操作

一般的なメニューは「設定」→「インポート」または「新規作成」です。リモートのサブスクは通常、サブスクURLを入力し、ローカル設定の場合はYAMLファイルを選択します。インポートは設定を登録し、更新は内容を再取得、有効化はコアに設定を読み込ませる操作です。インポート後に自動で有効になるクライアントもあれば、設定カードをクリックする必要があるものもあります。一覧に名前が表示されただけでは、切り替えが完了したとは限りません。

インポート時に確認する4項目

コンテンツの種類：ブラウザーで開けるURLでも、Clash YAMLが返されるとは限りません。ログインページやエラー、別クライアント用の形式が返されると、解析に失敗することがあります。
有効状態：目的の設定が選択またはハイライトされていることを確認し、プロキシ画面に想定したプロキシグループが表示されるかチェックします。
更新時刻：更新成功は新しい内容を取得できたことを示します。すべてのノードで接続できることを意味するわけではありません。
エラー内容：ダウンロード失敗、YAML構文エラー、コアが未対応の項目を区別しましょう。それぞれ対処方法が異なります。

サブスクURLにはアクセス情報が含まれることが多いため、パスワードと同様に扱ってください。画面を共有するときは、URL全体、QRコード、トークンを隠し、公開の問い合わせ窓口に貼り付けないようにしましょう。一部クライアントに表示される通信量や有効期限は、サーバーのレスポンスヘッダーに基づいています。これらの数値が表示されなくても、インポートに失敗したとは限りません。

元の設定を編集する場合とオーバーライドの違い

リモート設定を更新すると、直接編集した内容が上書きされることがあります。ローカルルールやDNS、ポート設定を継続して保持したい場合は、クライアントの「オーバーライド」「マージ」「スクリプト」機能を使い、どの設定に適用されるか確認しましょう。マージの順序はクライアントごとに異なるため、エディターに表示される元のYAMLだけでは、最終的な稼働値を判断できません。

# 学習用の抜粋：項目の意味を示すもので、完全なサブスクではありません
mixed-port: 7890
mode: rule
log-level: info
allow-lan: false

ここでの 7890 は、HTTPとSOCKSの接続を受け付ける混合ポートの例です。すべてのクライアントの初期値ではありません。保存後、画面に「実行時の設定を表示」などの項目があれば、そこで最終的な値を確認してください。各項目の説明はYAML設定ハンドブックを参照してください。この抜粋だけで接続できる完全な設定として使わないでください。

接続画面：リクエストがどの出口を通ったか確認する

接続画面では、コアに届いたトラフィックを確認できます。表示項目には宛先ホスト、宛先IP、ポート、送受信バイト数、接続時間、照合されたルール、プロキシチェーンなどがあります。プロセス名が表示されるかどうかは、システム権限、コアの機能、プロセス識別の設定によって異なります。表示が空欄でも、ただちに通信異常とは限りません。

接続情報から処理経路をたどる

「接続」を開き、宛先ドメインまたはプロセスで絞り込みます。確認対象のサイトだけにアクセスし、バックグラウンド通信の影響を減らしましょう。
宛先ポートを確認します。HTTPSでは 443 が一般的ですが、ポート番号だけではプロキシ経由かどうかは判断できません。
DOMAIN-SUFFIX、IP-CIDR、フォールバックの MATCH など、適用されたルールを確認します。
プロキシチェーンを確認し、最終的に DIRECT で接続したのか、指定したノードを使ったのか、入れ子のプロキシグループを経由したのかを確認します。
グループ内の選択を切り替えて新しい接続を確立し、プロキシチェーンが変わったか比較します。

対象アプリの接続が画面に表示されない場合は、すぐにノードを変更せず、まずアプリの通信がプロキシに入っているか確認しましょう。アプリがシステムプロキシを参照しない、アプリ独自のプロキシ設定がある、システムの除外リストに含まれている、TUNのルートが対象通信をカバーしていない、といった原因が考えられます。接続画面に表示されるのはコアが処理した接続であり、システム全体の通信を監視する画面ではありません。

「接続を閉じる」は選択したセッションを中断し、アプリが自動で再接続する場合があります。「すべて閉じる」は、ダウンロード中のファイルや会議、長時間接続するサービスに影響する可能性があります。まず対象の接続だけに絞り込んで閉じましょう。画面に表示される累積通信量は通常、今回の起動中または現在の集計条件に基づく値であり、サブスク事業者の請求明細とは異なります。

ルール画面：直接接続またはプロキシ経由になる理由を確認する

ルール画面は通常、稼働中のルールを確認する場所であり、直接編集できるとは限りません。ルールは上から順に照合され、最初に一致したルールが処理先を決めます。具体的なルールが広範なルールの後ろにあると、適用されないことがあります。以下の抜粋では予約済みの例示ドメインを使い、順序とポリシーの参照先を示します。

rules:
  - DOMAIN-SUFFIX,example.com,Web用出口
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,Web用出口

Web用出口 は、完全な設定内で対応するプロキシグループとして定義されている必要があります。no-resolve は、このIPルールの照合時にドメイン名の解決を自動で行わないことを示します。クライアント全体のDNSを無効にする設定ではありません。最後の MATCH はフォールバックルールです。一覧の先頭に置くと、それ以降の通常のルールが照合されなくなります。

設定で rule-providers を使っている場合は、メインのルール一覧と外部ルールセットも区別する必要があります。ルールセットのダウンロード失敗、内容が未更新の状態、ルール順序の誤りは、画面上では似た症状に見えることがあります。まず接続の詳細で実際に適用されたルールを確認し、その後設定画面でルールの取得元を調べましょう。全体モードを何度も切り替えるより、原因を特定しやすくなります。

ログ画面：行ごとに推測せず、時刻を手がかりにエラーを探す

一般的なメニューは「ログ」→「レベルで絞り込み」です。コアのログレベルには debug、info、warning、error などがあり、クライアントによっては日本語で表示されます。フィルターは現在の表示内容を変えるだけです。log-level を変更するとコアが記録するレベルが変わるため、別の設定です。

よくあるログの内容	考えられる原因	次に確認すること
`address already in use`	ローカルの待ち受けアドレスまたはポートが使用中	別のクライアントやバックグラウンドのコアを確認する
`connection refused`	接続が明示的に拒否された	エラーの対象を確認してから、サービスの状態とポートを調べる
`i/o timeout`	ネットワーク操作がタイムアウトした	DNS、ノードまでの接続、宛先までの接続のどこで発生したか切り分ける
`no such host`	名前解決で利用可能な結果を取得できなかった	対象ドメインとDNS設定を確認する
`certificate`	TLS証明書の検証が関係している可能性がある	システム時刻、サーバー名、証明書の情報を確認する

効率よく調べるには、まず操作した時刻を記録して問題を再現します。たとえば14:32:10にリクエストを送った場合、その前後のログを確認し、エラーの対象がサブスクサーバー、プロキシノード、宛先サイトのどれかを特定します。timeout の1行だけでは、判断に必要な前後関係がわからないことがほとんどです。

設定画面：システムプロキシ、TUN、ポートの役割

システムプロキシはアプリの通信を取り込む入口

一般的なメニューは「設定」→「システムプロキシ」です。クライアントによってはホーム画面にスイッチがあります。通常はOSのプロキシ設定を、127.0.0.1:7890 などローカルの待ち受けポートに向けます。この方法で通信を送るのは、システムプロキシ設定に従うアプリだけです。スイッチがオンでも、すべてのアプリがコアを経由しているとは限りません。

外部アプリにプロキシアドレスを手動で入力する場合は、クライアントに表示される実際のポートを使ってください。HTTP専用ポート、SOCKS専用ポート、混合ポートは異なる場合があります。パネル用の external-controller APIアドレスをブラウザーのプロキシ欄に入力しないでください。これは制御用インターフェースであり、通信を中継する入口ではありません。

TUNは仮想ネットワークインターフェースであり、別のノードではない

デスクトップ版では「設定」→「TUNモード」から有効にするのが一般的です。起動には管理者権限やサービスのサポートが必要な場合があります。TUNは仮想インターフェースとルートを使ってIP通信を取り込みますが、対象範囲は自動ルート、除外ルート、DNSの引き継ぎ、システム環境にも左右されます。モバイル版ではOSのVPNインターフェースを利用することが多く、デスクトップ版とは設定の配置が異なります。

システムプロキシは使えるが、一部アプリでは使えない：まずアプリがシステムプロキシに対応しているか確認し、必要に応じてTUNを検討します。
TUNを有効にするとLANへのアクセスに問題が出る：LAN向けの除外ルート、DNS、他のVPNとの競合を確認してください。ノードだけを変更しても解決しないことがあります。
LANへの接続を許可：allow-lan は他のデバイスからプロキシの待ち受けサービスにアクセスできるかを制御します。ローカル端末からLAN内の機器に接続できるかを制御する設定ではありません。
OS起動時にクライアントを起動する設定と、起動後にプロキシを有効にする設定：別々の項目である場合があります。一方を設定した後、もう一方も確認してください。

クライアントを切り替える場合は、クライアント比較ガイドでOSや機能を比較できます。複数のクライアントでシステムプロキシとTUNを同時に有効にしてから、個別の動作を判断するのは避けましょう。まず通信の入口を1つに絞ると、同じ手順で問題を再現しやすくなります。

初めて使うときは、6つの手順で画面を確認

設定画面：利用するClash YAMLまたはサブスクをインポートし、更新が成功したことを確認して有効にします。
プロキシ画面：ルールモードを選び、ルールが実際に参照しているプロキシグループを見つけて、利用可能な出口を選びます。
設定画面：コアの稼働状態、実際の待ち受けポート、システムプロキシまたはTUNの入口の状態を確認します。
接続画面：対象サイトにアクセスし、新しい接続の宛先、適用ルール、プロキシチェーンを確認します。
ログ画面：リクエストに失敗した場合は、発生時刻をもとに前後のログを確認し、エラーに関連する設定だけを変更します。
設定画面で再確認：サブスクを更新した後、ローカルのオーバーライドと有効な設定を確認し、変更が引き続き反映されているかチェックします。

この6つの手順では、「設定が読み込まれたか」「通信が取り込まれたか」「ルールが適用されたか」「出口に接続できるか」を分けて確認できます。プロキシ画面では正常に見えるのにWebサイトが開けない場合や、ノードを切り替えても出口が変わらない場合は、該当する画面に戻って確かめましょう。異なる段階の問題を一度の操作でまとめて扱わずに済みます。