Clashクライアントの画面構成を理解する:プロキシ・設定・ログ画面の機能ガイド
Clashクライアントの主要画面を、プロキシのグループ選択、設定のサブスクリプション管理、ログのトラブル対応に分けて解説。初めてでも操作の全体像をつかめます。
まずクライアント画面の操作マップを把握する
ClashのGUIクライアントは、通常、プロキシサービスそのものではなく、カーネル、設定ファイル、システムのネットワーク設定を管理する画面です。クライアントによってサイドバーの名称や並び順は多少異なりますが、基本的な構成はほぼ共通しています。概要画面ではスイッチと状態、プロキシ画面ではポリシーの選択、設定画面ではサブスクリプション、接続画面では現在の通信、ルール画面ではマッチ結果、ログ画面ではカーネルの動作履歴、設定画面ではポート、TUN、自動起動などのローカルオプションを管理します。
初めてクライアントを開いたときに、設定を一つずつ変更する必要はありません。まず設定をインポートし、プロキシ画面でポリシーグループが生成されていることを確認してから、システムプロキシを有効にするのが安全です。異常がある場合は、接続、ルール、ログの順に確認します。この順序なら、「設定は有効か」「通信はカーネルに届いているか」「ルールはリクエストをどう処理したか」を切り分けられます。
| 画面の区分 | 主な用途 | 初回に操作が必要か |
|---|---|---|
| 概要またはホーム | システムプロキシの有効化、ポート・通信量・カーネルの状態確認 | 必要 |
| プロキシ | ポリシーグループとグループ内のノードを選択 | 必要 |
| 設定 | サブスクリプション設定のインポート、更新、切り替え | 必要 |
| 接続 | 現在の接続、アップロード・ダウンロード量、経由したチェーンを確認 | トラブル対応時に使用 |
| ルール | ドメインやネットワークがどのルールにマッチするか確認 | トラブル対応時に使用 |
| ログ | 設定の読み込み、DNS、接続、カーネルのエラーを確認 | トラブル対応時に使用 |
| 設定 | ポート、TUN、システムプロキシ、自動起動を管理 | 必要に応じて使用 |
概要画面:スイッチ、ポート、動作状態
システムプロキシのスイッチで制御されるもの
概要画面で最もよく使うのが「システムプロキシ」です。有効にすると、クライアントはOSのHTTPおよびHTTPSプロキシアドレスを、たとえば 127.0.0.1:7890 のようなローカルの待受ポートに向けます。その後、ブラウザーやシステムプロキシ設定に従うデスクトップアプリがリクエストをClashカーネルに渡し、カーネルがルールに基づいて直接接続、拒否、またはポリシーグループへの転送を判断します。
システムプロキシのスイッチは、カーネルのスイッチとは別物です。一部のクライアントでは、起動後すでにカーネルがバックグラウンドでポートを待ち受けていても、システムプロキシは無効のままです。その場合、プロキシポートを手動指定したアプリはカーネルを利用できますが、通常のブラウザーの通信は必ずしも経由しません。クライアントを終了する前にシステムプロキシを無効にすると、システム設定を通常の状態に戻せます。一般的なクライアントは正常終了時にも復元処理を行います。
混合ポート、HTTPポート、SOCKSポート
一般的な設定では mixed-port: 7890 を使用し、同じポートでHTTPとSOCKS5のリクエストを受け付けます。port: 7890 と socks-port: 7891 を個別に設定する場合もあります。ポート番号は固定の標準値ではないため、現在のクライアントの設定画面と実際の設定を確認してください。ほかのプログラムが7890を使用していると、カーネルの起動に失敗することがあり、ログには通常、アドレスの重複や待受失敗に関する情報が表示されます。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090
上記の例では、カーネルがローカルの7890番ポートで混合プロキシを提供し、ルールモードで動作しています。また、127.0.0.1:9090 でコントロールAPIを提供します。コントロールAPIはGUIクライアントが接続、ルール、通信量の状態を読み取るためのもので、ブラウザーに入力するプロキシポートではありません。
モード選択とノード選択は別
- ルールモード:
rulesを上から順に照合し、リクエストごとに直接接続、プロキシ、拒否のいずれかのポリシーを適用します。日常利用に適しています。 - グローバルモード:通信をグローバルポリシーグループで処理します。ノードが目的地に接続できるかを一時的に確認するときによく使います。
- ダイレクトモード:プロキシノードを経由せず、目的地へ直接接続します。ネットワークの違いを比較するときに利用できます。
モードが決めるのはルールの処理方法であり、品質の最も高いノードを自動的に選ぶことではありません。ルールモードでも、プロキシ画面を開いて対象のポリシーグループで何が選択されているか確認してください。
プロキシ画面:ポリシーグループとノードの切り替え
まずポリシーグループを確認し、次にノードを見る
プロキシ画面では通常、複数のポリシーグループがカードまたはリストで表示されます。ポリシーグループは設定作成者が定義した出口の選択メニューで、名称は「ノード選択」「自動選択」「ストリーミング」または「最終ルール」などさまざまです。グループ内の項目には実際のノードだけでなく別のポリシーグループも含まれるため、画面上の選択関係が2〜3層になることもあります。
たとえば、あるドメインを Proxy グループに渡し、Proxy が現在 Auto を選択し、さらに Auto が遅延テストでノードを選ぶ構成を考えます。この場合、関係のないグループを直接変更しても、そのドメインには影響しません。正しく確認するには、ルールでマッチしたポリシー名から始め、グループの参照関係をたどって最終的な出口を特定します。
proxy-groups:
- name: Proxy
type: select
proxies:
- Auto
- DIRECT
- Node-A
- name: Auto
type: url-test
proxies:
- Node-A
- Node-B
url: https://www.gstatic.com/generate_204
interval: 300
select グループは手動選択、url-test グループはテスト結果に基づく自動選択、fallback は可用性を重視し、現在のノードが使えなくなると切り替えます。load-balance は設定された方式に従って、複数のノードへ接続を振り分けます。GUIクライアントはこれらの設定構造を表示するだけで、実際の動作はカーネルと設定内容によって決まります。
遅延の数値はどう見るか
プロキシ画面のテスト値は通常、ローカルからノードを経由して指定されたテスト先へアクセスするのにかかった時間で、単位はミリ秒です。80 msと表示されても、その探測に約0.08秒かかったことを示すだけで、ダウンロード速度が一定の数値になるわけではありません。遅延が小さくても帯域が限られているノードはありますし、探測に成功しても目的のWebサイトへの接続に失敗する場合があります。
- 単発のテストより、連続して行った結果のほうが参考になります。数秒間隔で3回ほど確認すると、一時的な揺らぎを見分けやすくなります。
- 「タイムアウト」と表示されたら、テストを何度も繰り返す前に設定を更新し、ノードの有効期限とローカルネットワークを確認してください。
- ノードの切り替えが反映されるのは、その後に新しく作成される接続です。すでに確立している長時間接続は、以前の出口を使い続けることがあります。
- 新しいノードをすぐに確認したい場合は、接続画面で以前の接続を終了し、目的のページを再読み込みしてください。
設定画面:サブスクリプションのインポート、更新、切り替え
設定画面には動作の基準が保存される
設定画面は「Profiles」や「サブスクリプション」と呼ばれることがあります。1つの設定には通常、待受ポート、DNS、ノード、ポリシーグループ、ルールが含まれます。クライアントはその中から1つを現在の設定として選び、処理後の内容をClash Meta(mihomo)などの互換カーネルに渡して読み込みます。プロキシ画面が空、ポリシーグループが不足、またはモードを切り替えられない場合は、まず設定が正常に有効化されているか確認してください。
一般的なインポート手順は「設定」→「新規作成」→「URL」です。サブスクリプションURLを貼り付けて保存します。クライアントによっては「サブスクリプション」→「サブスクリプションを追加」となります。ローカルファイルを読み込む場合はYAMLファイルを選択します。完了後、その設定をクリックするか、「現在の設定にする」を選んで有効化します。ファイルをリストに追加しただけでは、実行中の設定が自動的に置き換わるとは限りません。
更新ボタンで行われる処理
- クライアントがサブスクリプションURLへアクセスし、新しい内容をダウンロードします。
- レスポンスの形式を判別または変換します。対応範囲はクライアントによって異なります。
- 新しいローカルコピーを保存し、クライアントの設定に従ってカーネルを再読み込みします。
- プロキシ画面でポリシーグループとノード一覧を再生成します。
通常の小規模な設定なら、更新は数秒で完了します。更新後もプロキシ画面に変化がない場合は、別の設定へ一度切り替えて戻すか、ログにYAML解析エラー、ネットワークのタイムアウト、HTTPステータスの異常がないか確認してください。サブスクリプションURLは機密性の高い設定情報なので、公開スクリーンショット、ログ共有サイト、質問掲示板などに貼り付けないでください。
設定の更新に失敗したときの確認項目
| 画面に表示される現象 | 考えられる原因 | 優先して確認する項目 |
|---|---|---|
| リクエストがタイムアウトすると表示される | 現在のネットワークからサブスクリプションURLへアクセスできない | ネットワーク接続、システム時刻、URLが完全かどうか |
| ダウンロードは成功したが有効化できない | YAML構文またはフィールドの互換性に問題がある | ログに表示された解析行番号とフィールド名 |
| プロキシ画面にポリシーグループがない | 設定内容が不完全、または有効化されていない | 現在の設定の表示、ファイル内容、更新日時 |
| 更新後も古いノードが表示される | キャッシュが再読み込みされていない、またはリモート側の内容が変わっていない | 更新日時、設定の切り替え、クライアントの再起動 |
クライアントにオーバーライド、スクリプト、設定のマージ機能がある場合、使い始めの段階では無効のままにすることをおすすめします。オーバーライドによってDNS、ルール、ポリシーグループが変わると、トラブル対応では元のサブスクリプションとローカル変更の両方を理解する必要があり、複雑さが大きく増します。
接続画面とルール画面:リクエストの経路を追跡する
接続画面で確認できる3つのポイント
接続画面には、現在進行中または直前に確立されたネットワーク接続が表示されます。一般的な項目は、目的のドメイン、目的IP、プロトコル、ルール、ポリシーチェーン、アップロード量、ダウンロード量、確立時刻です。リクエストがClashに届いたか、どのルールにマッチしたか、最終的にどのノードを使ったかを確認するのに適しています。
- 新しい記録がまったく表示されない:アプリがシステムプロキシを読み取っていないか、TUNによる取り込みが必要な可能性があります。
- 記録にDIRECTと表示される:ルールがリクエストをダイレクト接続と判定しています。通常のプロキシグループに切り替えても結果は変わりません。
- ポリシーチェーンに複数の名称が表示される:リクエストがネストされたポリシーグループを経由しています。最後のノードが実際の出口であることが一般的です。
- ダウンロード量は増え続けるのにページが完了しない:接続自体は確立されています。DNS、目的サーバーの応答、またはアプリ自身の状態を引き続き確認してください。
多くのクライアントでは、接続画面から個別の接続を終了したり、すべての接続を閉じたりできます。ノードを切り替えた後に古い接続を閉じてページを開き直すと、HTTP/2、WebSocket、ダウンロード処理が以前の接続を再利用するのを防げます。ただし、すべての接続を閉じると進行中のダウンロード、同期、オンライン通話が中断されるため、重要な処理がないことを確認してください。
ルール画面でマッチ順を確認する
Clashのルールは設定に記載された順番で照合され、通常は条件に合う最初のルールにマッチした時点で停止します。一般的なルールタイプには DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、IP-CIDR、GEOIP、最終的なフォールバックルールである MATCH があります。ルール画面を使うと、特定のドメインがダイレクト接続や特定のグループになった理由を確認できます。
rules:
- DOMAIN,example.com,DIRECT
- DOMAIN-SUFFIX,example.net,Proxy
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- GEOIP,CN,DIRECT
- MATCH,Proxy
上記の設定では、example.com は直接接続し、example.net とそのサブドメインは Proxy に渡され、ローカルネットワークのアドレスは直接接続します。それ以外で先にマッチしなかったリクエストは最終的に Proxy に入ります。広範囲を対象とするルールを具体的なルールより前に置くと、後ろの具体的なルールが実行されなくなることがあります。
ログ画面:レベルとキーワードから問題を特定する
まず適切なログレベルを選ぶ
一般的なログレベルには silent、error、warning、info、debug があります。日常利用では info で十分です。複雑な接続問題を調べるときだけ、一時的に debug へ切り替えます。デバッグログはより速く生成され、ドメイン、目的アドレス、接続の詳細も多く含みます。確認が終わったら info に戻してください。
一般的なデスクトップクライアントでは、「設定」→「Clash設定」→「ログレベル」から変更できます。一部の画面では「設定」→「カーネル設定」にあります。レベルを変更してから問題を一度再現すると、大量の過去ログを検索するより簡単です。再現時は正確な時刻を記録してください。たとえば14:32:10に対象アプリを開き、その時刻以降のログを確認します。
よくあるログメッセージの読み方
| キーワードまたは現象 | 意味 | 対処の方向性 |
|---|---|---|
address already in use |
待受ポートが別のプロセスによって使用されている | 使用中のプログラムを終了するか、混合ポートを変更する |
connection refused |
目的アドレスが接続を明示的に拒否した | ノードのサービス、目的ポート、上流の状態を確認する |
i/o timeout |
規定時間内にネットワーク処理が完了しなかった | ローカルネットワーク、ノード、DNSを確認する |
yaml と行番号 |
設定ファイルの構文解析に失敗した | インデント、コロン、リスト形式、該当行を確認する |
authentication required |
上流またはローカルインターフェースが認証を要求している | 認証フィールドとサブスクリプションの状態を確認する |
| DNSエラーが繰り返し発生する | ドメイン名前解決の経路が正常に動作していない | DNSセクション、待受ポート、ネットワーク権限を確認する |
1件のエラーログが示すのは、ある時点で発生した結果にすぎず、必ずしも根本原因ではありません。たとえば接続タイムアウトは、ノードに到達できないことが原因の場合もあれば、先にDNSが利用できないアドレスを返したことが原因の場合もあります。トラブル対応では、エラーの前後数行、接続画面のポリシーチェーン、現在の設定を合わせて判断してください。
設定画面:TUN、LAN、起動オプション
TUNモードを有効にするタイミング
システムプロキシは、アプリがOSのプロキシ設定を自発的に読み取ることを前提とします。一部のゲーム、コマンドラインプログラム、ストアアプリ、自前のネットワークスタックを使うソフトウェアは、この設定を無視することがあります。TUNモードは仮想ネットワークインターフェースを通じてIP層でより広範な通信を取り込みます。その分カバー範囲は広がりますが、管理者権限、ルーティングテーブル、DNSハイジャック、ほかのVPNソフトウェアとの互換性も関係します。
一般的な操作手順は「設定」→「Clash設定」→「TUNモード」です。クライアントによっては、先にサービスモードのインストールを求められます。初回の有効化では、システム権限の確認が表示されることがあります。システムプロキシで対象アプリをカバーできるなら、「速くなる」からといってTUNへ変更する必要はありません。TUNが解決するのは取り込み範囲であり、ノードの帯域幅を直接向上させるものではありません。
- 有効化後に完全にインターネットへ接続できなくなった:まずTUNを無効にし、仮想ネットワークアダプター、DNS設定、ほかのVPNとの競合を確認します。
- LAN内の機器にアクセスできない:ルーティングの除外範囲を確認し、一般的なプライベートネットワークをダイレクト接続にしてください。
- クライアント終了後にネットワークが不安定になった:クライアントを再度開き、TUNを正常に無効化してから、システムのルートとDNSを確認します。
- 特定のプログラムだけプロキシを経由しない:まず接続画面を確認し、記録がない場合にTUNを検討します。
LAN接続を許可するとは
allow-lan: true は、同じLAN内にあるほかの機器から、クライアントが待ち受けているプロキシポートへアクセスできるようにします。有効化後は、待受アドレス、ファイアウォール、機器のIPも確認してください。たとえばPCのアドレスが 192.168.1.20、混合ポートが 7890 の場合、スマートフォンの手動プロキシにはサーバー 192.168.1.20、ポート 7890 を入力します。127.0.0.1 ではありません。
LAN共有は信頼できるネットワークでのみ使用してください。クライアントがローカルプロキシ認証に対応している場合は、ユーザー名とパスワードも設定できます。自宅や職場のネットワークを離れるときは、LAN接続の許可を無効にするか、システムファイアウォールでアクセス可能なネットワーク範囲を制限してください。
初回利用時の完全な操作手順
- 設定画面を開き、URLまたはローカルのYAMLから有効な設定を1つインポートします。
- その設定が現在の設定としてマークされていることを確認し、最終更新日時を確認します。
- プロキシ画面を開き、ポリシーグループとノードが表示されていることを確認して、遅延テストを1回実行します。
- 主要な選択グループでノードまたは自動選択グループを選びます。
- 概要画面に戻り、ルールモードのままシステムプロキシを有効にします。
- ブラウザーで目的のページを開き、接続画面に新しい記録が表示されるか確認します。
- 接続に失敗した場合は、マッチしたルール、ポリシーチェーン、ログの該当時刻を確認します。
- 対象アプリがシステムプロキシを読み取らない場合に限り、TUNモードが必要か検討します。
この手順では、設定、ポリシー、通信の取り込み、トラブル対応を個別のステップに分けます。プロキシ画面にはノードがあるのにブラウザーの接続記録がない場合、原因はシステムプロキシまたはアプリの取り込みにある可能性が高いです。接続記録はあるもののポリシーがDIRECTならルールを確認します。ポリシーが正しいのにタイムアウトする場合は、ノード、ローカルネットワーク、DNSを引き続き確認してください。
画面からトラブルを切り分ける基本
Clashクライアントの各画面は、互いに独立しているわけではありません。設定画面がルールとポリシーグループを提供し、プロキシ画面がグループ内の選択を決め、概要画面が通信をカーネルへ渡すか制御し、接続画面がリアルタイムの処理結果を表示し、ログ画面がエラーの詳細を記録します。トラブル対応では、この流れに沿って段階的に確認するほうが、何度も再インストールしたり複数の設定を同時に変更したりするより原因を見つけやすくなります。
日常の操作で使うのは、通常、設定画面、プロキシ画面、概要画面です。接続、ルール、ログ画面は主に異常の原因を確認するために使います。各画面が答える質問を理解しておけば、メニュー構成の異なるClash Meta(mihomo)クライアントに移行しても、対応する機能をすぐに見つけられます。