Clash クライアント画面ガイド:プロキシ・設定・ログ、3大パネルの役割

クライアントを開いてまず見るべき場所:画面全体のレイアウト

Clash クライアント(オリジナルコアベースでも Clash Meta/mihomo コアベースでも)は外観デザインが多少異なりますが、画面の機能区分はおおむね共通で、サイドバーやタブでいくつかのセクションに分かれています:概要(またはホーム)、プロキシ、設定、ルール、接続、ログ、さらに設定画面。初心者にとって実際に毎日開くのは3つだけで、プロキシページはノードの選択、設定ページはサブスクリプションの管理、ログページは問題の確認を担当します。この3つを把握すれば、日常利用の9割はカバーできます。

本題に入る前に一つ理解しておきたいことがあります。クライアント自体はあくまでグラフィカルな外殻であり、実際にトラフィックの転送処理や振り分けルールの実行を担うのは背後のコアプログラム(コア)です。画面上に見えるスイッチやログはすべて、コアの状態表示、あるいはコア設定への変更を反映したものにすぎません。これを理解しておくと、「画面表示は正常なのにネットが繋がらない」といった状況に遭遇したとき、コアのログを確認すべきだとわかり、画面自体を何度も再起動するような無駄な対応を避けられます。

プロキシページ:ノードグループ、遅延テスト、手動切り替え

プロキシページは最も利用頻度の高いパネルで、表示の中心単位は「プロキシグループ」(Proxy Group)です。1つのサブスクリプション設定には通常あらかじめ複数のグループが用意されており、例えば地域別の「香港ノード」「日本ノード」、用途別の「グローバルプロキシ」「動画配信解除」「広告ブロック」などがあります。各グループの内部には具体的なノードと、選択ロジックを決める戦略タイプが含まれます。

• select グループ:手動選択型。クリックしたノードがそのまま使われるため、使いたい経路が明確な場合に向いています。
• url-test グループ:自動計測型。クライアントが定期的にグループ内ノードへ遅延テストを行い、自動的に最適なノードへ切り替えます。
• fallback グループ:メイン・バックアップ型。リストの先頭ノードを優先的に使用し、使用不可になった場合のみ順に後方へフォールバックします。
• load-balance グループ:負荷分散型。ルールに従って接続を複数ノードへ分散させます。

プロキシページの各ノードの後ろには通常ミリ秒単位の遅延値が表示されます。これはクライアントがノードに計測リクエストを送って得た往復所要時間で、値が低いほど応答が速い傾向がありますが、遅延が低いことと転送速度が速いことは必ずしも一致しません。両者は別の指標であり、ノード選びの際は遅延を最初のふるい分けとして使い、速度や安定性については実際にしばらく使ってみないとわからない部分もあります。「速度測定」ボタンをクリックすれば手動でまとめて再計測できます。一部のクライアントでは自動計測の間隔も設定画面で調整できます。

ノードの手動切り替え方法はシンプルです。対象グループに入り、使いたいノードをクリックするだけです。切り替えは通常即時に反映され、クライアントの再起動やシステムプロキシの再接続は不要です。切り替えてもページが開かない場合、多くはノード自体の問題ではなく、システムプロキシのオン/オフや振り分けルールの問題であるため、この場合はログページで具体的な接続記録を確認するべきです。

設定ページ:サブスクリプション管理、更新周期、設定の切り替え

設定ページ(クライアントによっては「サブスクリプション」や「Profiles」と表記)が管理するのは、それぞれ完全な YAML 設定ファイルであり、各設定にはノード情報、グループルール、振り分けルールが含まれています。多くの人の設定は、サービス提供元や自前のノード運営者が提供するサブスクリプションリンクから取得され、クライアントは定期的にこのリンクへリクエストを送り、最新のノードリストを取得します。

このページで主に行うのは次の3つです。

1. サブスクリプションの追加:サブスクリプションリンクを貼り付けると、クライアントが一度ダウンロード・解析を行い、利用可能な設定エントリを生成します。
2. 手動/自動更新:サブスクリプションの内容は固定ではなく、提供元が不定期にノードを入れ替えたり帯域配分を調整したりします。設定ページには通常「今すぐ更新」ボタンがあり、自動更新周期(1日ごと、あるいは数時間ごとが一般的)も設定できます。
3. 複数設定の切り替え:複数のサブスクリプションやカスタム設定を保存している場合、設定ページにリスト形式で表示され、いずれかをクリックすればその設定に切り替わります。現在有効な設定には通常わかりやすいマークが付きます。

注意すべき点として、設定の切り替えやサブスクリプションの更新後、プロキシページで手動選択していたノードは通常グループのデフォルト選択にリセットされます。これは新しい設定でグループやノードリストが変わっている可能性があるためで、クライアントは古い選択状態を無理に維持しません。「サブスクリプションを更新するとノードがデフォルトに戻る」という現象は正常なので、プロキシページに戻って選び直せば問題ありません。

また、設定ファイルには DNS 設定や TUN モード関連のフィールドも含まれることが多いです。TUN モードはシステムのネットワーク層に仮想ネットワークカードを作成し、全トラフィックを引き受ける動作方式で、通常のシステムプロキシモードと比べて適用範囲が広く、システムプロキシ設定に従わないプログラムのトラフィックも処理できます。ただし対応するスイッチや状態は通常設定画面や概要ページにあり、設定ページ自体ではありません。設定ページの役割は、これらのフィールドをサブスクリプションと一緒に反映させることに限られます。

ログページ:接続記録、ルールマッチング、トラブル対応の手がかり

問題を調査するとき最初に見るべきなのは設定画面ではなくログページです。クライアントが各ネットワーク接続を処理するリアルタイムの過程を記録しており、典型的な1行のログにはおおむね次の情報が含まれます。

[Info] [TCP] example.com:443 match Rule(DOMAIN-SUFFIX,example.com) using 香港ノード01

分解すると、このログは4つのことを示しています:接続先のアドレスとポート、この接続がどの振り分けルールに一致したか、ルールの具体的なマッチ方式(ここではドメイン末尾によるマッチ)、そして最終的にこの接続がどのノードに割り当てられたか。この4要素を対応させれば、「あるサイトがなぜこのノードを通ったのか」「あるルールが実際に機能しているのか」を概ね判断できます。

ログページはログレベルによる絞り込みにも対応していることが多く、一般的なレベルは低いものから Debug、Info、Warning、Error の順です。ネットがつながらない問題を日常的に調査する場合、レベルを Debug に設定するとより完全な接続試行の過程が見えるようになり、接続確立の失敗や DNS 解決の異常といった詳細も含まれるため、問題特定の効率が明らかに上がります。ただしログの更新も大幅に速くなるため、調査が終わったらデフォルトのレベルに戻し、リソースを不要に消費しないようにすることをお勧めします。

もう一つよくある要望は「接続」パネルの確認です(クライアントによっては接続リストとログを2つの子ページに分けています)。接続パネルには現在アクティブな接続と履歴の接続リストが表示され、各接続の発生元プロセス、宛先アドレス、使用ノード、累積トラフィックが確認できます。特定のプログラム(ブラウザや特定のクライアントソフトなど)のトラフィックが実際にプロキシを通っているか、それともプロキシを迂回して直接接続しているかを確認するのに向いています。

3大パネルを組み合わせて使う際のちょっとしたコツ

3大パネルそれぞれの役割を理解したところで、日常使いで役立つ組み合わせ方をいくつか補足します。