Clashクライアント画面ガイド:プロキシ・設定・ログ各画面の役割

クライアント画面をブロックごとに解説。プロキシ画面のグループ切替、設定画面のサブスク管理とルール読込、ログ画面の接続記録による原因調査を紹介し、初心者向けに全体像を整理します。

Clash系クライアント(Clash Verge Rev、Clash Nyanpasu、FlClash、Clash Meta for Windowsなど)は画面レイアウトが多少異なりますが、コアとなる機能ブロックはほぼ共通しており、基本的に「プロキシ」「設定」「ログ」の3つを中心に、システムレベルの設定を行う「設定」画面が加わる構成です。各ブロックの役割を理解しておくことは、特定クライアントのボタン位置を覚えるより有用です。クライアントを乗り換えても、この心的モデルはそのまま使えます。

メイン画面の全体構成:まず3つの入口を確認

クライアントを開くと、サイドバーや上部に固定の入口がいくつか並びます。一般的な名称と役割は次の表の通りです。

ブロック一般的な名称主な役割
プロキシ画面Proxies / プロキシポリシーグループ確認、ノード切替、速度測定
設定画面Profiles / 設定サブスクリプションリンク管理、設定切替、ルール更新
ルール画面Rules / ルール現在有効な振り分けルール一覧の確認
接続/ログ画面Connections、Logsリアルタイム接続と動作ログの確認、異常調査
設定(システム)画面Settings / 設定システムプロキシ、TUNモード、自動起動など

トラブルシューティングでは前の4つのブロックがほとんどで、設定(システム)画面は一度設定すれば触ることは少なくなります。以下、使用頻度の高い順に解説します。

プロキシ画面:ポリシーグループ、ノード一覧、遅延数値

プロキシ画面は日常的に最も頻繁に開くブロックで、主に2層構造になっています。

ノードをクリックすると現在のグループをそのノードに切り替えられますが、これは select タイプのグループでのみ有効です。url-test グループは自動的に最低遅延のノードを選択するため、手動選択は通常反映されないか、次回の測定で上書きされます。ノードが使用可能か確認したい場合は、画面上の「速度測定」または「URL Test」ボタンで一括検査を実行しましょう。自動更新をただ待つ必要はありません。

注意:プロキシ画面に表示される遅延は、測定用ターゲットアドレスへの往復時間にすぎず、実際に特定のサイトを開く速度を表すものではありません。この数値は測定サーバー、ネットワークの揺れ、パケットロス率の影響を大きく受けるため、数値が低くても快適さが保証されるわけではなく、一時的に数値が高くなってもすぐにノードを切り替える必要はありません。

あるグループにノードが全く表示されない、またはノード一覧がサブスクリプションの説明と一致しない場合は、設定画面側のサブスクリプションが未更新、または読込に失敗している可能性が高いです。プロキシ画面で何度も更新するより、設定画面で対処すべきです。

設定画面:サブスクリプションリンク、ルールセット、設定切替

設定画面(Profiles)は「どの設定ファイルを使うか」を管理する画面で、主な操作は次の3種類です。

  1. サブスクリプション追加:サブスクリプションリンクを貼り付けると、クライアントが対応するYAML設定ファイルをダウンロードし、ノード・ポリシーグループ・ルールを解析します。
  2. サブスクリプション更新:設定項目の更新ボタンをクリックすると、リモートの内容を再取得し、サービス提供元側の最新ノードとルール変更を反映します。
  3. 設定の切替/有効化:複数の設定(個人用サブスクリプション+ローカルテスト用設定など)を保存している場合、目的の設定を「有効化」またはダブルクリックで切り替える必要があります。クライアントは新しい設定のルールに従って動作します。

ルール読込失敗でよくあるのは、サブスクリプション更新後にプロキシ画面のノード一覧が変わらない、またはルール画面のルール数が0と表示されるケースです。これは通常次のいずれかに該当します。

多くのクライアントは更新失敗時に通知を出すか、ログ画面にエラー記録を残します。「ノードが変わらない」と感じたら、まず設定画面で更新タイムスタンプを確認し、次にログ画面で具体的なエラー原因を確認する方が、クライアントを再インストールするより効率的です。

ルール画面:振り分けロジックはどこで決まるか

ルール画面には、現在の設定で実際に有効な振り分けルール一覧が表示されます。よくあるルールタイプには、ドメインマッチ(DOMAIN-SUFFIX)、IPレンジマッチ(IP-CIDR)、プロセスマッチ(PROCESS-NAME)、ルールセット参照(RULE-SET)などがあります。ルールは上から順にマッチが試され、最初に一致したルールがすぐに適用され、以降のルールは判定されません。設定の末尾には通常 MATCH というフォールバックルールがあり、どのルールにも一致しなかった通信の扱いを決定します。

ルール画面はほとんどの場合、確認用であって手動編集する場所ではありません。GUIクライアントは通常ルール画面で直接ルール内容を変更できず、ルールの追加・削除・変更はサブスクリプション元に戻るか、ローカル設定ファイルを調整して再インポートする必要があります。特定のサイトの振り分け先が想定と違う場合は、まずルール画面で対応するドメインを検索し、どのルールに該当しているか確認した上で、ルールを調整するかポリシーグループを切り替えるか判断しましょう。

ログ画面と接続画面:トラブル時に最も見るべき場所

接続画面(Connections)には現在アクティブおよび最近終了したすべてのネットワーク接続が記録され、各記録には通常、宛先アドレス、使用ノード、マッチしたルール、所要時間などの情報が含まれます。ログ画面(Logs)にはクライアント動作中のイベントの流れが記録され、ルールマッチ結果、DNS解決結果、サブスクリプション更新状況、TUNモードの起動停止などが含まれます。両者を組み合わせれば、ほとんどの接続異常を特定できます。

  1. まず接続画面で対象サイトやアプリの接続記録を探し、どのルールにマッチしたか、どのノードを使ったかを確認する;
  2. 接続記録で対象ノード自体が使用不可またはタイムアウトと表示されている場合、プロキシ画面に戻り別の使用可能なノードに手動で切り替えて検証する;
  3. 接続記録がそもそも表示されない場合、通信がClashを経由していない可能性があるため、設定(システム)画面に戻ってシステムプロキシまたはTUNモードが正しく有効になっているか確認する;
  4. より詳細な情報(具体的なDNS解決結果やハンドシェイク失敗の原因など)が必要な場合は、ログレベルを debug に変更し、問題を再現してからログ内容を確認する。

ヒント:多くのクライアントはキーワードで接続記録やログ内容を絞り込めます。トラブル時は対象ドメインを直接検索する方が、1件ずつ確認するより効率的です。

設定(システム)画面:設定後は基本的に触らない

設定(システム)画面には、システムプロキシのオン/オフ、TUNモード、混合ポート、DNSオーバーライド、自動起動などのオプションが集中しています。これらは通常、初回インストール時に必要に応じて一度設定すれば十分です。例えば、HTTP/SOCKSプロキシ設定に対応しないアプリを含むすべてのシステム通信を制御したい場合はTUNモードを有効化し、起動時に毎回自動接続したい場合は自動起動をオンにします。設定(システム)画面での変更はすぐにプロキシ画面や接続画面の動作に反映されるため、特定の通信が常にプロキシを回避している場合は、まずここのシステムプロキシとTUNモードの状態を確認し、ルールやノードをむやみに調整しないようにしましょう。

よくある質問

プロキシ画面のノードが全部タイムアウト表示になるのは設定が壊れたということ?

まず全ノードが同時にタイムアウトしているか確認してください。全ノードなら、ローカルのネットワーク問題かサブスクリプション提供元側の障害の可能性が高いです。一部のノードだけなら通常の変動範囲内なので、使用可能なノードに切り替えれば十分です。

設定を切り替えてもプロキシ画面が変わらないように見える場合は?

設定画面で対象の設定が実際に「有効」状態になっているか確認してください。一部のクライアントでは設定切替後に手動で更新ボタンを押す必要があり、それでポリシーグループとノード一覧が同期更新されます。

クライアントをダウンロード