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

クライアント画面・コア・現在の設定を区別する

Clashクライアントのウィンドウは設定を表示し、コアは通信を処理し、設定ファイルはノード、プロキシグループ、DNS、ルールを定義します。mihomoコアを使うクライアントでは画面の役割がおおむね共通していますが、ボタン名や配置は異なる場合があります。ここでは一般的な日本語画面の「プロキシ」「設定」「ログ」「接続」「設定」を基準に説明します。クライアントによっては「設定」が「サブスクリプション」、「プロキシ」が「プロキシグループ」と表示されることもあります。

この記事は画面操作の説明であり、特定のクライアントのバージョンには依存しません。表示名が異なる場合は、スクリーンショットの位置を頼りにクリックするのではなく、設定項目の用途を確認してください。Clash配布ステーションはクライアントの情報や使い方を紹介するサイトであり、クライアントの公式開発チームではありません。

プロキシ画面：まず動作モード、次にプロキシグループを確認

ルール・グローバル・ダイレクトの違い

プロキシ画面の上部には、「ルール」「グローバル」「ダイレクト」の3つのモードが表示されることがよくあります。モードは接続先の選び方を決めるもので、システム上のすべてのアプリがプロキシ経由になるかどうかを決めるものではありません。グローバルモードに切り替えても、システムプロキシを参照せず、TUNにも取り込まれていないアプリはコアを経由しない場合があります。

• ルールモード（Rule）：rulesを上から順に照合し、最初に一致したルールで指定されたポリシーを使います。ポリシーにはDIRECT、REJECT、ノード、プロキシグループを指定できます。
• グローバルモード（Global）：グローバルプロキシグループで現在選択されている項目を使います。通常のプロキシグループだけでなく、GLOBALまたは画面上のグローバル選択欄を開いて出口を確認してください。
• ダイレクトモード（Direct）：コアに届いた接続をダイレクトで処理します。これはクライアントやシステムプロキシをオフにする操作とは異なります。

初めて使う場合は、通常ルールモードのままにします。一時的にグローバルモードへ切り替えると、ルールによる振り分けがアクセスに影響しているか確認できますが、テスト後は元のモードに戻してください。グローバルモードでは接続でき、ルールモードではできない場合は、ルールの判定結果と指定先のプロキシグループを確認しましょう。ノードの故障と決めつけるのは早計です。

プロキシグループは、互いに独立したノードの一覧ではない

プロキシ画面の「ノード選択」「自動選択」「メディア」などのグループ名は、通常、設定ファイルのproxy-groupsに由来し、クライアント固有の機能ではありません。グループはノードだけでなく、別のグループを参照することもあります。そのため「自動選択」を選んだ場合、現在のグループが次の選択を子グループに委ねていることを意味します。

• select：手動選択。項目をクリックすると、その後に行われる関連接続で選択した項目が使われます。
• url-test：設定されたテスト先、間隔、許容値をもとに自動選択します。すべてのサイトで最も低い遅延になるとは限りません。
• fallback：設定順に利用可能な項目を選択します。通常、テスト遅延の低い順に並べ替える動作ではありません。
• load-balance：設定された分散方式で複数の出口を使います。1つのダウンロード接続で全ノードの帯域を合算できるわけではありません。

ノードを切り替えても、確立済みの長時間接続は以前の出口を使い続けることがあります。確認する際はリクエストを新たに実行してください。必要であれば「接続」画面で対象の接続を閉じます。ウェブページの確認だけを目的にすべての接続を切断すると、ダウンロードや会議に影響するおそれがあります。

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

インポート・更新・有効化はそれぞれ別の操作

「設定」画面のカードは、通常、ローカルまたはリモートの設定を表します。インポートに成功しても、設定の保存が完了しただけで、現在の設定として有効になったとは限りません。「有効化」「この設定を使用」を選ぶか、カードをクリックして切り替えた後に、選択中の表示と読み込みエラーの有無を確認してください。

1. 「設定」を開き、現在有効なカードの名前と選択中の表示を確認します。
2. カードのメニューから「情報を編集」または「詳細」を開き、サブスクリプションURLが想定した配布元のものか確認します。URL全体が写ったスクリーンショットを公開しないでください。
3. 「更新」を実行し、更新時刻とエラーメッセージを確認します。その後「プロキシ」画面に戻り、グループ名とノード一覧が想定どおりか確認してください。
4. 更新後に有効化できない場合は、「ログ」で設定の解析エラーを確認し、インデント、項目の形式、コアの対応状況を優先して調べます。

サブスクリプションの更新は通常、リモートの設定を再取得する操作であり、クライアントプログラムの更新ではありません。また、個別のproxy-providerを更新すると、ノード一覧だけが更新され、メイン設定のルールやDNSは置き換わらない場合があります。ノードは変わったのにルールが変わらない場合は、設定全体の更新とプロバイダーの更新のどちらを実行したか確認してください。

ローカル編集・オーバーライド・最終的な実行設定

リモートのサブスクリプションから取得したファイルを直接編集すると、次回の更新で変更が上書きされることがあります。長期的に保持したい振り分けルールには、クライアントが対応する「オーバーライド」「拡張設定」「マージ」機能を使ってください。マージの順序はクライアントによって異なります。ルールが末尾に追加されるのか、前方に挿入されるのかも確認しましょう。

以下はルールの抜粋であり、設定全体ではありません。既存の設定にProxyという名前のプロキシグループがあることを前提としています。単独のサブスクリプションとしてそのままインポートすることはできません。

rules:
  - DOMAIN-SUFFIX,example.com,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

DOMAIN-SUFFIX,example.com,Proxyはこのドメインとサブドメインに一致します。GEOIP,CN,DIRECTは接続先IPの地理データベースの判定結果を使います。MATCH,Proxyはそれ以前のルールに一致しなかった接続を処理します。ドメインルールをMATCHより後に置くと、先にフォールバックルールが一致するため機能しません。

クライアントに「実行中の設定」や「ランタイム設定」の表示機能がある場合は、変更後に最終的な内容を確認してください。エディターにルールが書かれていても、コアに読み込まれているとは限りません。設定の切り替え失敗、オーバーライドの無効化、ルールの挿入位置の誤りなどで、内容が食い違うことがあります。

ログ画面：リクエストからルールと出口を特定

ログレベルはまずinfo、必要に応じて短時間だけdebugにする

一般的なログレベルにはdebug、info、warning、error、silentがあります。普段のトラブルシューティングではinfoを使います。より詳細な処理情報が必要なときだけ、短時間debugに切り替えてください。画面上の「レベルフィルター」と設定内の「ログレベル」が別々にある場合、前者は表示内容を絞り込むだけで、コアが出力するログを決めるのは後者である可能性があります。

1. 「ログ」を開き、自動スクロールを止めるか表示内容を消去し、開始時刻を控えます。
2. ブラウザーに戻り、調べたいページに1回だけアクセスします。
3. ログ画面に戻り、ドメインのキーワードで絞り込みます。テストサイトを複数同時に開かないでください。
4. 通信の種類、接続先、ルールの種類、出口の順に確認し、最後にエラーの説明を読みます。

以下は構成を示す例であり、特定バージョンの出力をそのまま再現したものではありません。同じ情報でも、クライアントによって複数の列に分かれたり、別の書式で表示されたりします。

[info] [TCP] 127.0.0.1:53124 --> www.example.com:443
match DomainSuffix(example.com) using Proxy[ノードA]

• TCP：このログはTCP接続を示します。これだけで、ほかのUDP通信も正常に処理されているとは判断できません。
• 127.0.0.1:53124：例にあるローカルの送信元アドレスと一時ポートです。システム設定に入力するプロキシの待ち受けポートではありません。
• www.example.com:443：接続先ドメインとHTTPSでよく使われるポートです。443と表示されているだけで、クライアントがHTTPSの内容を復号しているとは限りません。
• DomainSuffix(example.com)：ドメインサフィックスルールに一致しています。
• Proxy[ノードA]：Proxyプロキシグループを経由し、ノードAが使われたことを示す例です。グループが複数段階で参照されている場合は、「接続」画面も確認し、プロキシチェーン全体を調べてください。

エラーが発生した段階からログを読む

ブラウザーでページを開けず、対応するログも見つからない場合は、まずフィルター条件とログレベルを確認し、リクエストがコアに届いているか調べます。ブラウザーのキャッシュや既存接続の再利用も確認結果に影響します。ノードを何度も切り替えるより、対象のリクエストを新たに実行するほうがログとの対応を確認しやすくなります。

設定画面と接続画面：通信の入口を確認

「システムプロキシ」と「TUNモード」は異なる方法で通信を取り込みます。システムプロキシは、システムのプロキシ設定を参照するアプリにプロキシのアドレスを提供します。一部のコマンドラインツール、ゲーム、独自にネットワークを管理するアプリは、この設定を使いません。TUNは仮想ネットワークインターフェースとルーティングによって通信を取り込みますが、適用範囲はルートの除外、権限、DNS設定、ほかのVPNの影響も受けます。

ポートは現在の設定で確認し、デフォルト値を覚え込まない

たとえば実行設定に次の2項目がある場合、HTTPまたはSOCKSに対応したアプリは各プロトコルでローカルの7890番ポートに接続できます。7890は設定例の値であり、すべてのクライアントで同じ値がデフォルトになっているとは限りません。

mixed-port: 7890
allow-lan: false

同じ端末上のアプリにプロキシを手動で設定する場合、アドレスには通常127.0.0.1を指定し、ポートは「設定」の「混合ポート」と一致させます。external-controllerは制御用インターフェースであり、ブラウザー用のプロキシポートではありません。allow-lan: falseの場合、ほかのLAN上の端末からこのプロキシを直接使えるとは想定しないでください。

スイッチの色だけでなく、接続記録で確認する

システムプロキシまたはTUNを有効にしたら、「接続」画面で接続先ドメインを検索し、ルールとプロキシチェーンを確認します。接続先に198.18.0.0/16の範囲内のアドレスが表示される場合、Fake-IPを使う設定では正常なマッピングの可能性があります。見慣れないアドレスだからといって、誤ったサーバーにアクセスしていると判断せず、ドメインとDNS設定も合わせて確認してください。

システムプロキシとルール設定については、システムプロキシの設定手順とルール設定の説明を参照してください。TUNはシステムのルーティングに関わるため、有効にする前に現在の設定を保存してください。ネットワークに問題が起きた場合は、まず追加した通信取り込み方式をオフにしてから、項目ごとに確認します。

設定からルール判定までを一通り確認する

画面の使い方を把握したら、次の順番で確認できます。一度に変更する条件は1つにし、変更前後の結果を記録してください。サブスクリプション、ノード、DNS、モードを同時に変えるのは避けましょう。

1. 設定を確認：「設定」画面で現在のカードを確認し、更新後に読み込みが成功したことを確かめます。必要に応じて最終的な実行設定も確認してください。
2. モードを確認：「プロキシ」画面でルールモードを選び、対象ルールの指定先グループと、グループ内で現在選択されている項目を確認します。
3. 通信の入口を確認：「設定」でシステムプロキシまたはTUNの状態を確認します。アプリに手動でプロキシを設定した場合は、アドレス、プロトコル、ポートも確認してください。
4. リクエストを発生させる：対象に新しくアクセスし、「ログ」または「接続」で同じドメインを探します。
5. 通信先を確認：一致したルール、グループ名、最終的な出口を確認します。ルールが想定と異なる場合は順序を、出口が違う場合はグループの参照関係を調べてください。
6. 通常の状態に戻す：一時的なグローバルモードとdebug設定を元に戻し、確認できた設定は維持します。

プロキシ画面では「どの出口を選ぶか」、設定画面では「どの定義を読み込むか」、ログ画面では「今回の接続で実際に何が起きたか」を確認できます。通信の入口も合わせて調べることで、設定が反映されていない、ルールに一致していない、ノードに接続できない、アプリの通信が取り込まれていない、といった問題を切り分けられます。原因を特定できない場合は、トラブル対処で該当する問題の種類を確認してください。