Clashクライアントの画面ガイド：プロキシ・プロファイル・ログの使い方

まずはプロファイル・出力先・通信の入口を整理

Clashクライアントのサイドバーには通常、プロキシ、プロファイル、接続、ログ、設定があります。それぞれ別の役割を持っています。プロファイルでは読み込むノード、プロキシグループ、ルールを管理し、プロキシ画面では各グループで使う出力先を選択します。接続画面には処理中のリクエストが表示され、ログ画面にはコアの動作イベントが記録されます。システムプロキシやTUNモードは、通信をコアへ取り込むための機能です。

クライアントによって、Proxiesは「プロキシ」または「プロキシグループ」、Profilesは「プロファイル」または「サブスクリプション」と表示されることがあります。ここでは「プロキシ → プロキシグループを選択」のように操作階層を示しますが、メニュー名はクライアントごとに異なります。まず英語名と機能で画面を見分け、実際のボタンに置き換えて操作してください。

プロファイル画面：サブスクリプションの追加と有効化

追加できても、設定が有効とは限らない

サブスクリプションURLは通常、リモート設定の取得に使われますが、ノード一覧だけを提供する場合もあります。クライアントに直接追加できるかどうかは、応答形式とクライアントの対応状況によります。WebページのURL、サブスクリプションURL、ノード共有リンクは別のものです。プロバイダーのログインページをサブスクリプション欄に貼り付けると、コアが必要とするYAMLではなくHTMLが返されることがあります。

1. 「プロファイル / Profiles」→「インポート」またはサブスクリプションURLの入力欄を開き、プロバイダーが提供する対応URLを貼り付けます。
2. ダウンロードと解析が終わるまで待ち、プロファイルのカードが表示されたか、構文エラーが報告されていないか確認します。
3. プロファイルを選択し、選択中のマークや現在のプロファイル名が変わったことを確認します。
4. プロキシ画面を開き、想定したプロキシグループとノードが表示されるか確認します。古い内容のままなら、プロファイル画面に戻って有効状態を確認してください。

同じクライアントに複数のプロファイルを保存できますが、通常、有効になるメインプロファイルは1つだけです。クライアントによっては、設定のマージ、オーバーライド、スクリプト処理にも対応しています。そのため、ディスク上のサブスクリプション原文と、コアが最終的に読み込む設定は異なる場合があります。設定項目を調べるときは、クライアントの実行時設定やプレビューを確認してください。

サブスクリプションの更新とルールセットの更新は別の操作

プロファイルカードの「更新」は、通常、リモート設定を再取得します。proxy-providersを使う設定では、ノードプロバイダーを個別に更新できる場合もあります。rule-providersを使う設定では、ルールセットに独立したダウンロード周期が設定されていることがあります。メインのサブスクリプションを更新しても、すべてのプロバイダーリソースが同時に更新されるとは限りません。

• ノード名や件数が想定と異なる：サブスクリプションの更新時刻と、対象のノードプロバイダーの更新結果を確認します。
• ルールの動作が変わらない：現在有効なプロファイル、ルールの順序、ルールセットの読み込み状態を確認します。
• 手動で変更しても元に戻る：リモート更新で元ファイルが上書きされることがあります。クライアントが対応する永続的なオーバーライド方法を使ってください。

サブスクリプションURLには認証トークンが含まれていることがよくあります。設定画面のスクリーンショットを共有する際は、URL全体、QRコード、認証情報を隠してください。サポートを依頼する場合は、エラー文、コア名、関連する設定項目だけを共有し、サブスクリプションURL全体は公開しないでください。

プロキシ画面：モードとプロキシグループの選択

ルール・グローバル・DIRECTで経路が決まる

ルールモードでは、設定内のルールを上から順に照合し、指定された出力先またはプロキシグループにリクエストを渡します。グローバルモードでは通常、リクエストをグローバル選択グループに渡しますが、実際にプロキシを経由するかは、そのグループで選択したメンバーによって決まります。DIRECTモードでは、コアが処理する通信を宛先へ直接接続します。どのモードも、すべてのアプリを自動的に捕捉するわけではありません。通信がコアに入るかどうかは、システムプロキシ、TUN、またはアプリ側の設定によって決まります。

普段はルールモードを使います。一時的にグローバルモードへ切り替えると、通信の振り分け結果を比較できます。ただし、テスト後は元のモードに戻してください。DIRECT接続にするはずのリクエストまで経路が変わる可能性があります。モードを切り替えたら、新しいリクエストで確認してください。すでに確立した長時間接続だけを見ても判断できません。

手動選択グループと自動選択グループの違い

selectグループではメンバーを手動で選択できます。url-testグループは設定されたテスト結果に応じて自動選択します。fallbackグループは、利用可能かどうかとメンバーの順序に基づいて切り替えます。load-balanceグループは、設定された方式に従って接続を振り分けます。自動選択グループを外側の手動選択グループから選んでも、内部のノードを固定する操作ができるとは限りません。

プロキシグループが別のプロキシグループを参照する場合があります。たとえば「Webアクセス」で「自動選択」を選び、「自動選択」がさらに特定のノードを使う構成です。実際の出力先を確認するには、この参照先を順にたどってください。外側のグループ名だけでは判断できません。設定内のDIRECTは直接接続、REJECTは拒否を意味し、どちらもプロキシサーバーではありません。

遅延テストは候補を絞るための目安

「速度テスト」をクリックすると、通常、指定URLへの接続性や遅延を測定します。通信帯域を総合的に測るテストではありません。たとえば画面に80 ms、別のノードに120 msと表示された場合、その測定条件では前者の応答が速かったことを示すだけです。動画の再生速度や、1秒あたりのダウンロード量を推定することはできません。この数値は読み方を説明するための例であり、本サイトでの実測値ではありません。

タイムアウトが発生したら、まずテスト先のURL、ネットワーク環境、ノードの状態を確認します。すべてのノードを短時間に何度もテストするのは避けてください。同時に多数の接続テストを行うと負荷が増え、普段の使い心地も判断しにくくなります。

設定画面：システムプロキシ・TUN・混合ポートの確認

「設定 / Settings」やホーム画面の概要には、通常、システムプロキシ、TUNモード、ポートの設定があります。システムプロキシは、OSのプロキシ設定に従うアプリに適しています。TUNは仮想ネットワークインターフェースとルーティングを使って対象の通信を取り込みます。必要な権限があり、別のVPNとルートが競合する場合もあります。初回設定では、複数のスイッチを同時に変更せず、まず1つの通信入口で動作を確認してください。

混合ポートは、同じ待ち受けポートでHTTPプロキシとSOCKSプロキシの接続を受け付けます。以下の例では、ローカルの混合ポートを7890に設定しています。これは説明用の設定であり、すべてのクライアントが標準でこのポートを使うわけではありません。また、ノードやルールを含む完全な設定でもありません。

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

現在のクライアントが実際に7890で待ち受けている場合は、ターミナルで次のコマンドを使い、HTTPプロキシを明示してローカルのプロキシ経路だけを確認できます。実行前にポートを確認してください。例のポートをそのまま実際の値として使わないでください。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

• HTTPレスポンスヘッダーが返る：指定したプロキシポートを経由して応答があったことを示します。他のアプリもシステムプロキシに従っているとは限りません。
• 127.0.0.1:7890に接続できないと表示される：コアの実行状態、実際のポート、待ち受け設定を確認してください。
• ローカルポートに接続できてもタイムアウトする：接続先へのアクセス、ルール、DNS、上流ノードを確認してください。システムプロキシの切り替えを繰り返すだけでは解決しません。

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

接続画面では、リクエストがコアに入ったか、どのルールに一致したか、最終的にどの出力先を使ったかを確認できます。主な項目は、接続先のドメイン名またはIPアドレス、ポート、ネットワーク種別、ルール、プロキシ経路、送受信量です。プロセス名が表示されるかは、OSの権限、コアの機能、クライアントの実装によって異なります。空欄でも必ずしも異常ではありません。

1. 「接続 / Connections」を開き、まず接続先ドメインで絞り込みます。バックグラウンド通信の影響を減らせます。
2. ブラウザーで対象ページを開き、新しい接続が表示されるか確認します。HTTPSの接続先ポートは通常443ですが、ポートだけでアプリの種類を判断することはできません。
3. 接続の詳細を開き、一致したルール、ルールのペイロード、プロキシ経路を記録します。
4. 結果がDIRECTの場合は、すぐにプロキシの障害と決めつけず、DIRECTルールに一致していないか確認してください。

ノードを切り替えても、既存の接続では以前の出力先が使われ続けることがあります。HTTPの長時間接続、WebSocket、ストリーミングのセッションは、しばらく維持される場合があります。再確認するには、対象アプリの接続を閉じるか、接続画面で該当項目を終了してから、新しいリクエストを送ってください。「すべての接続を閉じる」と他のダウンロードやセッションも中断されるため、影響範囲を確認してから実行してください。

接続一覧が空でも、すぐにノードが原因とは限りません。アプリが新しいリクエストを送っていない、キャッシュを使っている、システムプロキシを経由していない、またはリクエストがすぐに終了して現在の表示に残っていない可能性があります。何度も一覧を更新するより、明確な新規リクエストを送り、ログと合わせて確認する方が効果的です。

ログ画面：時刻から設定読み込みや接続エラーを探す

ログ画面に記録されるのはイベントであり、通信内容をすべて記録したものではありません。コアやクライアントによってログの文言は異なりますが、確認する順序は同じです。まず設定の読み込み、次にDNS、ルールリソース、上流への接続を確認します。ログレベルには通常、silent、error、warning、info、debugがあります。選択できる項目は使用中のコアによって異なります。

問題を1つずつ再現する

1. 「ログ / Logs」を開き、表示を消去するか現在時刻を記録します。
2. クライアントでログレベルを変更できる場合は、まずinfoに設定します。情報が足りなければ、一時的にdebugへ切り替えてください。
3. 対象のWebサイトに一度だけアクセスし、その時間帯の関連エラーと前後のログをコピーします。
4. 調査が終わったら、普段使うログレベルに戻してください。リクエスト情報を長時間にわたって過剰に記録するのを防げます。

mihomo（旧Clash Metaコア）を使う場合は、設定が拡張フィールドに依存していないか確認してください。クライアントの見た目が似ていても、コアの機能が完全に同じとは限りません。問題を報告する際は、「クライアントのバージョン + コア名 + コアのバージョン」を記録してください。通常は「概要 / About」またはコア情報の画面で確認できます。「最新版」とだけ書くのは避けてください。

初回設定とトラブル対処のチェックリスト

画面ごとの役割を順に確認すれば、根拠のない設定変更を減らせます。以下は「サブスクリプションを追加したのにWebページを開けない」場合によく使う確認手順です。

1. プロファイル画面：対象のプロファイルが有効で、読み込みエラーがなく、プロキシ画面に対応するプロキシグループが表示されていることを確認します。
2. プロキシ画面：ルールモードを使い、対象の通信に対応するプロキシグループを確認します。DIRECTや利用できないメンバーを誤って選択していないか確認してください。
3. 設定画面：システムプロキシまたはTUNの状態を確認します。ターミナルでテストするときは、実際に使われている混合ポートを明示してください。
4. 接続画面：新しいリクエストを送り、適用ルールとプロキシ経路を確認します。記録がなければ通信の入口を、記録があれば出力先を調べます。
5. ログ画面：再現した時刻とログを照らし合わせ、設定解析、DNS、接続試行のエラーを切り分けます。関連する設定は一度に1つだけ変更してください。

プロキシ画面では出力先を選び、プロファイル画面では設定の取得元を管理し、接続画面では実際の経路を確認し、ログ画面では動作イベントを調べます。リクエストがどの段階で止まっているかを確認してから、該当する画面で対処してください。この方法は、別のクライアントに切り替えた後も使えます。