Clashクライアントの画面ガイド：プロキシ・設定・ログの見方
Clashクライアントの各画面の役割やボタンの場所、設定項目を解説。初めて起動したときにどこを操作すればよいか分かります。
まずは3つの画面を把握：設定・プロキシ・ログ
設定画面では読み込む設定を、プロキシ画面では接続先を選び、ログ画面ではエラーの原因を確認します。初回は「設定をインポート → 有効化 → 接続先を選択 → 通信をプロキシに通す → ログを確認」の順に進めると、設定を片っ端から試すより問題を切り分けやすくなります。
Clashはプロキシコアや関連クライアントのエコシステムで広く使われる名称ですが、すべてのクライアントで画面構成が同じとは限りません。Clash Verge RevやFlClashなどでは、mihomoコアを利用できます。旧バージョンのクライアントでは、メニューや機能が異なる場合があります。この記事では一般的な日本語の呼び方に英語表記を添えています。ボタンの位置は利用中のクライアントで確認してください。特定バージョンの画面を共通仕様として扱うことはできません。
| 画面 | 主な操作 | 最初に確認する項目 |
|---|---|---|
| 設定 / Profiles | 設定のインポート・更新・切り替え | 現在使用中の設定 |
| プロキシ / Proxies | モードの切り替え、グループの接続先選択 | 現在のモードとグループ内の選択項目 |
| 接続 / Connections | リクエスト、ルール、プロキシ経路の確認 | 接続先ドメインがどの経路を通ったか |
| ログ / Logs | コアの動作状況や接続エラーの確認 | エラー発生時刻とエラーメッセージ全文 |
| 設定 / Settings | システムプロキシ、TUN、ポートの管理 | 通信がクライアントに届いているか |
設定画面：サブスクリプションをインポートしたら有効化も確認
サブスクリプションURLから現在の設定まで
サブスクリプションは通常、サービス提供元が発行するURLです。「設定 / Profiles」を開き、URL入力欄または「インポート / Import」を探して、URLを貼り付けてインポートします。ファイルの読み込みに対応したクライアントでは、ローカルの .yaml ファイルも選べます。インポートが完了すると、設定カードまたは設定の一覧が表示されます。
- サービス提供元がClashまたはmihomo対応として案内しているサブスクリプションを使ってください。アカウント管理ページのURLとは異なります。
- 「インポート」をクリックし、ダウンロードと解析が完了するまで待ちます。失敗した場合はエラーメッセージを保存し、同じ設定を何度も登録しないでください。
- 該当する設定カードをクリックするか、「有効化 / 使用」などの操作を選びます。
- プロキシ画面に戻り、インポート完了の表示だけでなく、設定内のプロキシグループやノードが表示されていることを確認します。
「一覧に設定がある」ことと「コアに設定が読み込まれている」ことは別です。通常、選択中の枠線やチェックマーク、「使用中」の表示で有効な設定を確認できます。切り替え後もプロキシ画面が以前の内容のままなら、まず読み込みエラーを確認し、正しい設定を選んだか見直してください。
更新・編集・切り替えの違い
- 更新：リモートのサブスクリプションを再取得します。新しいノードの追加や、使えなくなったノードの反映に使います。
- 編集：保存済みの内容を変更します。サブスクリプションから生成されたファイルを直接編集すると、次回の更新で上書きされる場合があります。
- 切り替え：別の設定を読み込みます。プロキシグループ、ルール、DNS設定も変わる可能性があります。
プロキシ画面：モードで判定方法を選び、グループで接続先を決める
ルール・グローバル・DIRECTはノードの種類ではない
プロキシ画面の「ルール / Rule」「グローバル / Global」「DIRECT / Direct」は通信の処理モードです。普段はルールモードを選び、設定内のルールに従って各リクエストをプロキシグループ経由にするか、直接接続するかを決めます。グローバルモードでは全リクエストに対してグローバル用のプロキシを選択します。短時間の比較テストに適しています。DIRECTモードではプロキシノードを経由しません。
これらのモードが影響するのは、コアに届いた通信だけです。グローバルモードを選んでも、システムプロキシを使わずTUNにも取り込まれていないアプリは、直接インターネットに接続することがあります。そのため「グローバルにしたのにアプリの動作が変わらない」場合、ノードの問題とは限りません。まず、アプリのリクエストがクライアントに届いているか確認しましょう。
ノードを選んだら、実際に使われるグループに属しているか確認
プロキシ画面にある「自動選択」「手動選択」「ストリーミング」などは、通常、設定の作成者が付けたグループ名であり、クライアント共通の機能名ではありません。一般に select グループでは手動で選択できます。url-test グループはテスト結果に応じて自動選択し、fallback グループは通常、順番に利用可能な項目を選びます。グループが別のグループを参照する場合もあるため、1つのリクエストが複数のグループ選択を経由することがあります。
- まずルールがどのプロキシグループを使うか確認し、そのグループを開いてノードを選びます。
- 「遅延テスト」またはテストアイコンをクリックして表示される数値は、特定のテストURLへの応答結果です。
120 msのような表示はダウンロード速度ではなく、すべてのサイトにアクセスできることを保証するものでもありません。ここでは数値の読み方を示す例であり、実測値ではありません。- ノードを切り替えたら、新しいリクエストで確認します。すでに確立している長時間接続は、新しい接続先へすぐに切り替わるとは限りません。
ノードが多数表示されているのに目的のグループが見つからない場合は、設定画面で現在の設定を確認してください。ノードを何度も切り替えても、設定が読み込まれていない、ルールが別のグループを参照している、リクエストがコアに届いていないといった問題は解決しません。
設定画面：システムプロキシ、TUN、ポートの役割
まずシステムプロキシでブラウザーを確認
デスクトップ版クライアントでは通常、「設定 / Settings」または概要画面に「システムプロキシ」の切り替えがあります。オンにするとOSのプロキシ設定が変更され、その設定に従うアプリのリクエストがローカルのプロキシポートに送られます。ブラウザーで動作を確認しやすい一方、一部のゲームやコマンドラインツール、独自のネットワーク機能を持つアプリは自動でこの設定に従いません。
以下はポート設定の例であり、すべてのクライアントの初期値を示すものではありません。mixed-port は1つのポートでHTTPとSOCKSのプロキシ接続を受け付けます。アプリにプロキシを手動設定する場合は、クライアントに表示される実際の待ち受けアドレスとポートを使ってください。
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info実際のポートが 7890 の場合、ローカルアプリにはアドレス 127.0.0.1、ポート 7890 を設定できます。プロキシの待ち受けポートと、コントロールパネル用の external-controller ポートを混同しないでください。後者は管理インターフェース用で、ブラウザーの通信を転送するポートではありません。
TUNは通信を取り込む機能であり、速度を上げるスイッチではない
TUNは仮想ネットワークインターフェースとルーティング設定を使って通信を取り込みます。対象範囲はクライアントの実装、ルート設定、除外項目によって異なります。デスクトップ版ではサービスのインストールや管理者権限が必要な場合があります。モバイル版では、OSのVPN許可を受けてトンネルを作成することがあります。複数の要因が一度に変わらないよう、まずシステムプロキシが正常に動作することを確認してから、必要に応じてTUNを有効にしてください。
「LAN内接続を許可」は別の設定で、ほかのデバイスからこの端末のプロキシ待ち受けサービスにアクセスできるかを制御します。この端末だけで使う場合、通常は有効にする必要はありません。共有する場合は、待ち受けアドレス、ファイアウォール、アクセス制御も確認してください。スイッチの状態だけでは判断できません。
接続画面：通信量のグラフだけでなく、リクエストの行き先を確認
「接続 / Connections」を開き、対象サイトにアクセスして新しい記録を確認します。クライアントによっては、ドメイン、接続先IP、送受信量、適用ルール、プロキシ経路などが表示されます。まず直前に追加された記録を見つけ、DIRECT で接続したのか、ノード経由なのか、REJECT で拒否されたのかを確認しましょう。
- 新しい記録がない：システムプロキシ、アプリ独自のプロキシ設定、TUNの対象範囲を確認します。ページのキャッシュや接続一覧の絞り込み条件も確認してください。
- 記録はあるが直接接続している：適用ルールと動作モードを確認します。まずノードを変更するのは避けましょう。
- 想定したノードを経由しても失敗する：ログ画面に移動し、同じ時刻の名前解決、接続、ハンドシェイクに関するエラーを確認します。
ルールは通常、上から順に判定され、末尾の MATCH がそれ以前のルールに一致しなかったリクエストを処理します。キャッシュや接続の再利用などにより、ドメインへのリクエストが新しい項目としてすぐに表示されないこともあります。接続を作り直すには、該当する接続を閉じるか、対象アプリを再起動します。すべての接続を閉じると、進行中のダウンロードや通話が切断されます。影響を確認してから操作してください。
ログ画面：エラー全文を残して、どの層で起きたかを確認
ログ画面に表示されるのはコアの動作情報で、ブラウザーの閲覧履歴ではありません。問題を調べるときはログレベルを info に保ち、失敗した時刻を控えてから一度再現し、前後のログを確認します。赤字の最後の単語だけを切り取らないでください。エラーの前に記録された接続先、ポート、操作の種類も重要です。
| エラーの一部 | 主な意味 | 最初に確認する項目 |
|---|---|---|
no such host | ドメイン名の名前解決で利用可能な結果を取得できなかった | エラーの対象がノードのドメインか接続先のドメインか、DNS設定も確認 |
i/o timeout | ネットワークの読み書き処理がタイムアウトした | 前後のログ、ノードへの接続性、現在のネットワーク |
connection refused | 接続先のポートに接続を拒否された | 接続先のアドレスとポート、および該当サービスの稼働状況 |
address already in use | ローカルの待ち受けアドレスまたはポートが使用中 | 別のクライアントや古いコアのプロセスが動作していないか |
dial tcp は「TCP接続を開始している」という処理の状況を示すだけで、単独で原因を特定するエラーではありません。後続の接続先アドレスとエラー（タイムアウト、接続拒否、ネットワーク到達不可など）も確認してください。一度のタイムアウトだけでサブスクリプション全体が無効とは判断できません。別のノードや接続先サイトを使って比較しましょう。
詳しく調べる必要がある場合は、ログレベルを一時的に debug にして問題を再現し、終わったら info に戻します。デバッグログにはアクセス先のドメインやIP、ローカルパスが含まれる場合があります。共有する前に機密情報を伏せてください。設定の構文エラーでは、具体的な行番号、フィールド名、インデントを残し、何度も再起動するのではなく設定を修正しましょう。
初回は次の6ステップで動作を確認
- 設定画面でインポート：対応するサブスクリプションURLを貼り付け、インポートの完了と設定の有効化を確認します。
- プロキシ画面でモードを選択：「ルール」を選び、実際に使われている手動選択グループから利用可能なノードを選びます。
- 設定画面で通信を取り込む：デスクトップ版ではまずシステムプロキシを有効にします。モバイル版では、OSの案内に従ってVPN接続を許可します。
- ブラウザーからリクエスト：接続先が明確なページを開き、同時に接続画面で新しい記録を確認します。
- 経路を確認：ルール、プロキシグループ、最終的なノードが想定どおりか確認します。エラーがある場合は同じ時刻のログを確認してください。
- 必要に応じて拡張：システムプロキシに従わないアプリでプロキシが必要な場合に限り、TUNの利用を検討します。
この手順なら、「設定が有効になっていない」「プロキシグループの選択ミス」「通信がコアに届いていない」「ノードへの接続失敗」を切り分けられます。設定を一度に1つだけ変更し、その都度リクエストを再実行して結果を確認しましょう。続けて設定する場合は、サブスクリプションのインポート手順とプロキシモードの解説を参照してください。明確なタイムアウトエラーがある場合は、タイムアウトの診断方法をご覧ください。