Clashの画面と機能を解説

設定・プロキシ・通信の入口を切り分ける

Clashの画面を理解するには、「設定をどこから読み込むか」「リクエストをどこに処理させるか」「アプリの通信がクライアントに届いているか」を分けて考えることが大切です。設定画面ではノード、プロキシグループ、ルールを読み込み、プロキシ画面ではグループを確認して出口を選択します。システムプロキシやTUNは、アプリの通信をコアに取り込む方法を決めます。ログ画面は処理の経過や問題の手がかりを確認する場所で、これらの設定を代替するものではありません。

Clashはプロキシコアや関連クライアントの一般的な呼称で、mihomoはClash Metaから派生したコアです。GUIクライアントによって、メニュー名やボタンの位置、コアの機能は異なります。以下では「メインウィンドウ → 設定」「メインウィンドウ → プロキシ」のように機能の場所を示します。実際の画面では「サブスクリプション」「Profiles」「Proxies」などと表示される場合があるため、完全に同じボタン名を探すのではなく、機能を照らし合わせてください。

設定画面：追加した設定が有効か確認

初めて使うときは、まず「メインウィンドウ → 設定」を開き、「インポート」または「新規作成」を選びます。リモートのサブスクリプションは通常URLの入力が必要です。ローカル設定の場合はYAMLファイルを選択します。サブスクリプションURLには個人用の認証情報が含まれることがあるため、安全な場所に保管し、スクリーンショットや公開の問い合わせに貼り付けないでください。

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

1. インポート：リモート設定やローカルファイルをリストに追加します。設定カードが表示されても、クライアントに設定の入口が保存されたことを示すだけです。
2. 有効化：設定を選択し、コアに読み込ませます。選択状態、現在の設定名、読み込みエラーの有無を確認してください。
3. 更新：リモートの内容を再取得します。完了後に更新時刻と読み込み結果を確認し、必要に応じて再度有効化します。再読み込みの方法はクライアントによって異なります。

たとえば、サブスクリプションの更新後にノードが増えたのにプロキシ画面に古いリストが表示される場合は、別の未有効化カードを更新していないか確認してください。有効化時にYAMLの解析エラーが出たら、表示された行番号やインデント、フィールドの型を確認します。更新を何度もクリックしても解決しません。ネットワーク要求の失敗と設定の解析エラーは別の問題です。前者はサブスクリプションURL、ネットワーク、サーバーの応答を確認し、後者は取得した内容が有効な設定かを確認してください。

ローカル編集とサブスクリプション更新の注意点

リモート設定のキャッシュを直接編集すると、次回の更新で変更が上書きされることがあります。クライアントに「オーバーライド」「マージ」「拡張スクリプト」などの機能がある場合は、実行順序を確認してから、継続して使いたいローカルルールを適切な仕組みに設定してください。オーバーライドの形式はクライアントごとに異なります。あるクライアントのスクリプトを、mihomoのYAMLフィールドとしてそのまま使うことはできません。

プロキシ画面：モードを確認してからグループを見る

「メインウィンドウ → プロキシ」を開いても、すべてのボックスがサーバーとは限りません。画面には通常、まずプロキシグループが表示され、次にグループ内で選べるノードや別のグループが並びます。ルールが特定のグループを参照している場合、最終的な出口はそのグループの種類と現在の選択で決まります。そのため、ノードをクリックしただけでは、リクエストがそのノードを通るとは限りません。ルールとの照合も確認が必要です。

3つのモードで変わる選択範囲

• ルールモード：設定内のルールを順番に照合し、リクエストを直接接続、プロキシ経由、または拒否に振り分けます。特定のグループを選択しても、そのグループに一致した通信だけが利用します。
• グローバルモード：コアに届いたリクエストをグローバルポリシーで処理します。短時間の比較や切り分けに便利ですが、コアに届いていないアプリの通信まで自動的にプロキシ経由になるわけではありません。
• ダイレクトモード：コアに届いた接続を直接接続として処理します。クライアントによっては独立したボタンがないため、実際に対応している範囲を確認してください。

手動選択と自動ポリシーの違い

select型では手動で選択できます。url-testは定期的なテスト結果に基づいて出口を選び、fallbackは利用可能な候補を順番に選択し、load-balanceは設定したポリシーに従って接続を振り分けます。自動ポリシーで一時的な手動選択ができるか、どうすれば自動選択に戻るかは、コアと画面の実装によって異なります。カードの見た目だけで判断しないでください。

たとえば、ルールの接続先が「Webプロキシ」グループなのに「メディアプロキシ」グループを変更しても、通常はWebアクセスに影響しません。その場合はノードを手当たり次第に切り替えるのではなく、接続画面で実際に適用されたグループを確認します。グループが別のグループを参照していることもあるため、プロキシチェーンをたどって最終ノードまで確認してください。

遅延テスト：タイムアウトと実際のダウンロード速度を区別

プロキシ画面の「遅延テスト」は通常、指定されたテスト先にリクエストを送り、応答を確認するまでの時間をミリ秒で表示します。継続的なダウンロード速度の測定ではなく、ネットワーク層のICMP pingとも異なります。テスト先、タイムアウト時間、ノードの接続状態、現在のネットワーク環境によって結果は変わります。

たとえば、テスト結果がそれぞれ85 msと210 msなら、指定された条件では前者の応答確認が速かったとわかるだけです。数値は読み方を示す例であり、本サイトでの実測値ではありません。大容量ファイルのダウンロード速度、動画の安定性、特定サイトへの接続可否を示すものではありません。timeoutと表示された場合は、ノードへの接続失敗、テスト先に到達できないこと、待ち時間の設定が短すぎることを切り分けてください。

1. まず、使う予定のノードを1つ選んでテストし、結果が返ることを確認します。
2. 実際に使うアプリで対象サイトにアクセスし、問題が起きた時刻を記録します。
3. 接続画面で対象の通信が先ほどのノードを通っているか確認し、同じ時間帯のログも確認します。

多数のノードを連続して一括テストすると、追加の接続が発生します。トラブル対処では候補を少数に絞ると比較しやすく、テスト通信とアプリの実際の通信が混ざるのも防げます。画面でテスト先を変更できる場合は、変更後に比較の基準を取り直してください。異なる条件で測った数値をそのまま並べて比較しないでください。

接続画面：ルールと最終出口を確認

「接続」画面では、「このアプリの通信が実際にどこを通ったか」を確認できます。クライアントを有効にした状態で新しいアクセスを行い、ドメイン、接続先IP、プロセス名などで絞り込みます。プロセス情報が表示されるかどうかは、OSの権限、通信の取り込み方法、コアの設定によって異なります。空欄でも接続異常とは限りません。

• 接続先：ドメインまたはIPアドレスと接続先ポートを確認します。HTTPSでよく使われる接続先ポートは443で、クライアントのローカル待ち受けポートとは異なります。
• ルール：一致したルールの種類や条件を確認します。たとえば、ドメインサフィックスのルールや末尾のMATCHなどです。
• プロキシチェーン：最終出口がDIRECTか、プロキシグループとその選択ノードのどちらかを確認します。
• 接続状態：経過時間とアップロード・ダウンロード量から、リクエストがまだ処理中かを確認します。列名はクライアントによって異なる場合があります。

ポリシーを切り替えても、すでに確立した接続が新しい出口へ移るとは限りません。ブラウザーが既存の接続を再利用することもあるため、新しい接続を確立してから確認してください。クライアントに「接続を閉じる」機能があれば、対象の接続だけを閉じて再アクセスできます。すべての接続を閉じるとダウンロードや会議が中断されるため、影響を確認してから操作してください。

接続先が一覧にまったく表示されない場合は、まずアプリがシステムプロキシに従っているか、別のネットワーク経路を使っていないか確認します。アプリのキャッシュによって、新しいリクエストが発生していない可能性もあります。一覧が空というだけでノードの障害と判断しないでください。

ログ画面：レベル別にエラーを確認し、1行だけで判断しない

「メインウィンドウ → ログ」を開き、画面上のフィルターを解除するか現在時刻を記録してから、問題を再現します。ログにはコアの動作イベントや接続処理の情報が記録されますが、すべてのリクエストの履歴が保存されるとは限りません。ログ画面を開いている間だけリアルタイムの記録を受け取るクライアントもあります。長期間保存する場合は、ファイルへのログ出力に対応しているか確認してください。

よくあるエラーの3つの原因

• address already in use：通常、待ち受けアドレスまたはポートが使用中です。まず該当するポートとプロセスを特定してください。すぐにサブスクリプションを変更する必要はありません。
• i/o timeout：ネットワーク処理のタイムアウトを示します。接続先、接続段階、前後の状況を確認してください。サブスクリプションの期限切れとは限りません。
• connection refused：接続先のポートで待ち受けていない場合や、接続を明示的に拒否された場合によく発生します。エラーがローカルインターフェース、上流ノード、接続先サービスのどれを指しているか確認してください。

設定のlog-levelは出力レベルを制御します。ログ画面のプルダウンメニューは、受信済みの情報を絞り込むだけの場合もあります。コアがエラーしか出力していない場合、画面のフィルターを「すべて」にしても、生成されていない通常ログは表示されません。詳細が必要なときは、コアのログ設定を変更したか確認し、再読み込み後に問題をもう一度再現してください。

設定画面：ポート・システムプロキシ・TUNを分けて確認

設定画面にあるローカルポートは、アプリがクライアントに接続するための入口です。コントロールポートは、画面や管理ツールからコアのAPIを呼び出すために使います。用途は異なります。たとえば、mixed-port: 7890は同じポートでHTTPとSOCKSのプロキシリクエストを受け付ける設定です。127.0.0.1:9090はローカルのコントロールインターフェースの例としてよく使われますが、すべてのクライアントに共通する既定値ではありません。

以下はフィールドの意味を示す例であり、サブスクリプションとそのまま置き換えられる完全な設定ではありません。GUIクライアントの設定画面からこれらの値を上書きできる場合もあるため、実際に適用されている値を確認してください。

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

システムプロキシとTUNは別の設定

システムプロキシは通常、OSのプロキシ設定を変更します。その設定に従うアプリだけが、指定された入口を利用します。TUNは仮想ネットワークインターフェースとルーティングを使って通信を取り込みます。より高い権限が必要になることが多く、DNSやルーティングの設定も関係します。TUNを有効にした後は、サービスに必要な権限があるか、仮想インターフェースが正常に作成されたか、ルールが想定どおりかを確認してください。あらゆる接続問題を解決するスイッチではありません。

設定項目を編集できるクライアントでは、「設定 → パラメーター設定」からポートを探します。この項目がなければ、「ポート」または「コア設定」を確認してください。7890を変更した場合は、手動で設定したブラウザープロキシ、ターミナルの環境変数、ほかのアプリの設定も合わせて変更します。クライアントが自動管理するシステムプロキシも同期して更新されているか、OS側で確認してください。

設定からログまで、順を追って確認する

「ノードの遅延テストは成功するのにWebページを開けない」ときは、次の順に確認すると問題の箇所を絞り込めます。複数の設定を同時に変更する必要はありません。

1. 設定画面：対象の設定が有効になっていて、読み込みエラーがないことを確認します。サブスクリプションの更新時刻は手がかりにはなりますが、読み込み結果の代わりにはなりません。
2. プロキシ画面：ルールモードになっていることを確認し、対象のプロキシグループとノードを調べます。比較が必要な場合だけ短時間グローバルモードに切り替え、元の設定を記録しておきます。
3. 設定画面：アプリの通信がシステムプロキシまたはTUN経由になっていることと、実際の待ち受けポートを確認します。アプリが古い7890を参照していないか注意してください。
4. 接続画面：対象に再アクセスし、新しい接続が表示されるか確認します。適用されたルールと最終出口も記録してください。
5. ログ画面：同じ時刻のログを確認し、DNS、上流への接続、TLS、ローカルの待ち受けのどの段階で起きた問題かを切り分けます。
6. 設定を元に戻す：トラブル対処が終わったら、一時的に変更したモードやログレベルを元に戻し、必要な記録は機密情報を伏せて保存します。

普段の操作は「設定画面で読み込み元を確認 → プロキシ画面でポリシーを確認 → 接続画面で結果を検証 → ログ画面で問題を分析」の順に進めるとわかりやすくなります。各フィールドの詳細は設定リファレンスをご覧ください。初回のインポートとアプリの接続手順は、クイックスタートに沿って進められます。