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

画面・コア・通信の入口を確認する

Clash系のGUIクライアントは、設定の表示やプロキシの切替、システムプロキシの制御を担います。ルール判定や通信の転送を実行するのはコアです。Clash Verge Rev、ClashX系、モバイル版ではメニュー名が異なる場合があります。この記事では「プロキシ」「設定」「接続」「ログ」「設定」の5つの機能に分けて説明します。画面上では Proxies、Profiles、Connections、Logs、Settings と表示されることもあります。ボタン名を一字一句探すのではなく、機能を目印にしてください。

初めて起動したら、まずホーム画面または設定画面でコアの状態を確認し、現在の設定が正常に読み込まれているか確かめましょう。ウィンドウが開くのはGUIが起動したことを示すだけです。コアの起動失敗、ポートの競合、設定の解析エラーがあると、プロキシ画面に以前のノード一覧が残っていても、転送が正常とは限りません。

プロキシ画面：プロキシグループ、ノード、動作モード

グループ名とグループ内の選択肢を確認

プロキシ画面には通常、プロキシグループごとにカードが表示されます。カードのタイトルは設定内の proxy-groups 名に対応し、グループ内には単一のノード、別のプロキシグループ、DIRECT などの組み込みポリシーが含まれます。サブスクリプションの「自動選択」「手動選択」「海外通信」などはグループ名にすぎません。動作を判断するには、名称から推測せず、グループの type を確認してください。

• select：手動選択。項目を選ぶと、その後にグループを利用する新しい接続には通常、新しい選択が適用されます。
• url-test：テスト結果に基づいて自動選択します。切替動作はテスト間隔や許容差などの設定にも左右されます。
• fallback：設定された順に利用可能な出口を選択します。単純に遅延が最も小さいノードを選ぶ方式ではありません。
• load-balance：設定した振り分け方式で接続ごとの出口を選択します。1つのダウンロード接続に複数ノードの帯域を合算するものではありません。

あるグループが別の自動選択グループを参照している場合、自動選択グループを選ぶと、次の選択はそのグループに委ねられます。問題を調べるときは最終ノードまで展開し、プロキシ経路全体を記録しましょう。「海外通信 → 自動選択 → ノードA」のように記録すれば、「自動を選択済み」とだけ記すより再現しやすくなります。

Rule・Global・Directが変えるもの

通常のルールベースの振り分けには Rule を使います。コアはルールを上から順に照合し、指定されたポリシーに通信を渡します。現在のリクエストに適用されていないグループを変更しても、そのリクエストの出口は変わりません。Global はコアに入った通信をグローバルポリシーに渡すため、グローバルグループの選択も確認が必要です。Direct ではコアに入った通信が直接接続されます。Globalに切り替えても、もともとシステムプロキシを使わないアプリが自動的にコアへ接続されるわけではありません。

1. プロキシ画面でモードを Rule にし、対象の通信を処理するプロキシグループを設定内で確認します。
2. 手動選択グループを開き、ほかのグループは変更せず、ノードを1つ選びます。
3. 以前のテスト接続を終了してから、もう一度アクセスし、接続画面で実際のプロキシ経路を確認します。
4. 以前の接続がまだ元の出口を使っている場合は、接続画面の終了機能でそのテスト接続を切断してください。すべての接続を先に終了する必要はありません。

遅延の数値は1回分のテスト結果

プロキシ画面に表示されるミリ秒の値は、通常、指定されたテストURLへの接続にかかった時間であり、固定のICMP ping値ではありません。テストURL、タイムアウト、同時実行数の設定はクライアントによって異なります。たとえば同じテストで85 msと140 msが出た場合、前者の所要時間がその条件下で短かったことを示すだけで、動画の実効速度が必ず高いとは限りません。「タイムアウト」はテスト先に到達できない、DNSに失敗した、ノードとのハンドシェイクに失敗した場合などにも発生します。ログと照らし合わせて原因を切り分けましょう。

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

設定画面では、サブスクリプションURL、ローカルのYAMLファイル、クライアントが提供するマージやオーバーライドの設定を管理します。初回は有効な設定元をインポートし、解析の完了を待ってから、現在の設定として有効になっていることを確認してください。インポート後に自動で有効になるクライアントもあれば、設定カードや「使用」をクリックする必要があるものもあります。現在の有効表示とプロキシ画面に出ているグループ名を基準に判断してください。

1. インポート：「設定」または Profiles を開き、URLからインポートするか、ローカルファイルを読み込みます。サブスクリプションURLにアクセストークンが含まれる場合があるため、公開スクリーンショットに貼り付けないでください。
2. 有効化：使う設定を選び、再読み込みが完了するまで待ちます。プロキシ画面に、その設定で定義されたグループが表示されることを確認してください。
3. 更新：対象のサブスクリプションを更新し、実行時刻と結果を確認します。新しい内容をダウンロードできても、設定の解析や再読み込みに失敗していないか確認してください。
4. 復元：変更前に、正常に使えるローカルコピーを保存しておきます。エラーが発生したら、まず動作確認済みの設定に戻し、その後で変更点を1つずつ比較してください。

サブスクリプションカードの「残り通信量」「有効期限」は、通常、サーバーから返されるサブスクリプション情報に基づきます。表示されなくてもクライアントでプロキシを利用できないとは限りません。通信量が表示されていても、今回の接続が必ず使えるとは限りません。ローカルファイルには通常こうしたサーバー情報がないため、ファイルの内容と読み込み状態を確認します。

更新で上書きされるサブスクリプション内容を直接編集しない

リモートサブスクリプションからダウンロードしたYAMLを直接編集すると、次回の更新で変更が上書きされることがあります。ルールを継続的に追加する場合は、現在のクライアントがオーバーライド、マージ、スクリプト処理に対応しているかを確認し、どの設定に適用されるかも確かめましょう。処理形式はクライアントごとに異なるため、別のクライアント用スクリプトをそのまま貼り付けないでください。一時的な検証にはローカル設定へコピーできますが、そのコピーにサブスクリプションの新しいノードが自動で追加されることはありません。

設定画面：ポート、システムプロキシ、TUNを確認

ローカルポートはアプリとプロキシコアをつなぐ入口です。設定例の mixed-port: 7890 は、同じポートでHTTPプロキシとSOCKSプロキシの接続を受け付けることを示します。実際のポートは環境によって異なるため、現在の実行設定を確認してください。プロキシを手動設定する場合、ホストには 127.0.0.1、ポートには実際の待ち受けポートを指定します。サブスクリプションサーバーのアドレスをローカルプロキシのホストに指定してはいけません。

Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」でシステムプロキシを確認できます。macOS 13以降では「システム設定」→「ネットワーク」→使用中のネットワークサービスの「詳細」→「プロキシ」を開きます。管理対象デバイスでは、メニューや権限が異なる場合があります。クライアント終了後もブラウザーが閉じたローカルポートを参照していると、接続に失敗します。その場合はサブスクリプションを何度も更新するのではなく、システムプロキシの設定が残っていないか確認してください。

TUNの利用には通常、追加のシステム権限、サービスコンポーネント、またはネットワーク拡張機能が必要です。必要なものはクライアントの実装やOSによって異なります。原因を調べるときは、まずブラウザーとシステムプロキシで基本的な経路を確認し、その後でシステムプロキシに従わないアプリを検証しましょう。TUN、DNS、ルールを同時に変更すると、問題の原因を特定しにくくなります。

接続画面：リクエストに実際に適用されたルールを確認

接続画面は、プロキシ画面とログ画面の間で状態を照合する場所です。接続先のドメインまたはIP、アップロード・ダウンロード量、接続時間、適用ルール、プロキシ経路などが表示されます。クライアントによってはプロセス名も表示されますが、利用可否は権限、プラットフォーム、プロセス検索の設定に左右されます。プロセス欄が空でも、接続に異常があるとは限りません。

• 接続先の記録がない：もう一度リクエストを送り、画面のフィルターが解除されているか確認します。それでも表示されない場合は、アプリがプロキシの入口を通っているか調べてください。
• DIRECTと表示される：適用ルールを確認し、想定どおりの直接接続か判断します。ノードが選択済みというだけで、そのリクエストがプロキシを通ると決めつけないでください。
• プロキシ経路は正しいのにアクセスできない：該当時刻のDNS、ハンドシェイク、接続エラーを確認し、必要に応じてノードを1つ指定して再テストします。
• ノードを切り替えても出口が変わらない：既存のTCP接続や長時間接続では、以前の出口が引き続き使われることがあります。テスト接続を終了して新しく接続し、切替が反映されたか確認してください。

ブラウザーで1つのページを開くと、ページ本体、画像、APIなど複数のドメインに接続する場合があります。それぞれ異なるルールが適用されることもあります。問題を調べるときは、失敗したドメインを具体的に記録し、直結の記録1件だけでページ全体の出口を判断しないでください。

ログ画面：レベルで絞り込み、時刻から探す

ログ画面には通常、レベルやキーワードによる絞り込み、スクロールの一時停止、表示内容の消去などの機能があります。「表示フィルター」と「コアのログレベル」は別です。画面のフィルターを Debug にしても、コアが記録していなかった過去のデバッグ情報は表示されません。クライアントに実行時のログレベル設定があればそこで変更するか、有効な設定で log-level を指定してください。

再現前に、たとえば14:32:10のように時刻を控え、対象へのリクエストを1回だけ送ります。その前後数秒のログから関連ドメインを探してください。connection refused が表示された場合は、接続先アドレスでサービスが待ち受けているか確認します。timeout は、ある段階が期限内に完了しなかったことを示すだけです。名前解決、接続、ハンドシェイクのどこで発生したかは、前後のログと合わせて判断してください。サブスクリプション取得時に401や403が記録された場合は、振り分けグループを変更する前に、サブスクリプションの認証情報を確認します。

最小構成で設定項目と画面表示の対応を確認

以下は画面の見方を確認するためのローカル設定例です。これらの基本項目に対応する Clash または mihomo クライアントに、単独でインポートして使えます。直接接続のみを設定しており、リモートノードは含みません。実際のサブスクリプションの代わりにはなりません。テストには新しいローカル設定を使い、使用中のサブスクリプションを上書きしないでください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: 手動出口
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動出口

• 設定画面：インポートして有効化した後、現在の設定がこのローカル設定例になっていることを確認します。
• プロキシ画面：「手動出口」グループが表示され、選択肢が DIRECT だけであることを確認します。
• 接続画面：コアに入った新しいリクエストは、末尾の MATCH ルールから「手動出口」に渡され、最終的に直接接続されます。
• ログ画面：基本のログレベルは info です。クライアントにグローバルな上書き設定がある場合、実際の値はファイルの設定と異なることがあります。

7890番ポートを別のプロセスが使用している場合は、クライアントの設定またはテストファイルで空きポートを選び、アプリ側のプロキシ設定も同じ値に変更します。GUIクライアントの多くは、全般設定とサブスクリプションの内容をマージします。エディター上のYAMLだけで判断せず、画面に表示される実際の待ち受けポートと動作モードも確認してください。

初回利用時に確認する6つの手順

1. コアを確認：正常に動作しており、起動エラーや設定の解析エラーがないことを確認します。
2. 設定を確認：サブスクリプションをインポートしたら、有効な設定を確認し、プロキシ画面にグループが表示されているか確かめます。
3. 入口を確認：まずブラウザーでシステムプロキシを使い、実際のローカルアドレスとポートを記録します。
4. 選択を確認：Ruleモードを使い、対象ルールが参照するグループ内で出口を選択します。
5. 接続を確認：リクエストを再送信し、接続先ドメイン、適用ルール、最終的なプロキシ経路を確認します。
6. ログを確認：同じ時刻のエラーを探し、設定を1つだけ変更してから再テストします。

この順序で確認すれば、「設定が有効になっていない」「アプリの通信がコアに入っていない」「ルールで直結になっている」「出口への接続に失敗している」を切り分けられます。追加のインストールや権限設定が必要な場合は設定ガイドを参照してください。プロキシグループ、ルール、TUNなどの用語は用語クイックガイドで確認できます。