画面ごとの役割：設定・ポリシー・通信の入口
Clashのデスクトップクライアントを開いたら、まず3つの役割を区別しましょう。プロファイル画面では設定ファイルを読み込み、プロキシ画面ではポリシーグループを確認して接続先を選びます。システムプロキシやTUNモードは、アプリの通信をコアに取り込むための機能です。設定をインポートできても、ブラウザーがプロキシを使っているとは限りません。
Clash Verge RevやClash NyanpasuなどのGUIクライアントでは、メニュー名や配置が異なります。以下では一般的なサイドバーの機能を順に説明し、特定のクライアントのボタン配置を共通仕様として扱いません。英語メニューの場合は、Profiles、Proxies、Connections、Rules、Logs、Settingsを、それぞれプロファイル、プロキシ、接続、ルール、ログ、設定に対応させて確認してください。
| 画面・スイッチ | 主な用途 | これだけでは判断できないこと |
|---|---|---|
| プロファイル / Profiles | プロファイルのインポート・更新・有効化 | インポートできても、ノードが使えるとは限らない |
| プロキシ / Proxies | ポリシーグループの確認、ノード切り替え、遅延テスト | テストに成功しても、すべてのアプリがプロキシを使っているとは限らない |
| 接続 / Connections | コアを経由する接続とポリシーチェーンの確認 | 記録がなくても、ノードの障害とは限らない |
| ログ / Logs | コアの動作、ルールの適用、エラー情報の確認 | 警告が1件あっても、ネットワーク全体が使えないとは限らない |
| システムプロキシ / TUN | アプリの通信をコアに取り込む方法を制御 | 有効にしても、有効な設定と利用可能な接続先が必要 |
プロファイル画面：インポート・有効化・更新
インポート後に、選択中のプロファイルを確認する
「プロファイル / Profiles」を開き、「インポート」またはURL入力欄にサブスクリプションURLを貼り付けます。ダウンロード完了後、選択マークが付いたプロファイルカードを確認してください。インポート時に自動で有効になるクライアントもあれば、カードをクリックするか、メニューの「有効化」を選ぶ必要があるものもあります。リストにファイルがあることと、コアがそのファイルを読み込んでいることは別の状態です。
- Clashまたはmihomoに対応するプロファイルのサブスクリプションは、サービス提供元から取得してください。アカウント管理ページのURLをサブスクリプションURLとして使わないようにしましょう。
- インポート後は、プロファイル名、更新日時、エラーメッセージを確認します。解析エラーが出た場合は、システムプロキシを何度も切り替えないでください。
- 目的のプロファイルを有効にしてからプロキシ画面を開き、ポリシーグループとノードが表示されるか確認します。
- ノードを更新する場合は、プロファイルカードの「更新」を実行し、結果を確認してください。
サブスクリプションの原本とローカルでの変更は分けて管理
リモートのサブスクリプションを更新すると、ダウンロードした設定ファイルへの直接編集が上書きされることがあります。カスタムルールを保持するには、クライアントが対応するオーバーライド、マージ、スクリプト機能を使い、どの設定に適用されるか確認してください。実装はクライアントごとに異なります。初めて使う場合は、まずサブスクリプションを変更せず、基本的な接続を確認してから一つずつ調整しましょう。
プロキシ画面：プロキシモードとポリシーグループの選択
まずRule・Global・Directを確認
「ルール / Rule」は現在の設定に基づいてポリシーを選択します。「全般 / Global」は通常、コアに取り込まれた通常のプロキシ通信をGLOBALポリシーに渡します。「直接接続 / Direct」では、その通信をプロキシ経由にせず接続します。グローバルモードでも、コアに取り込まれていないアプリの通信は自動的に処理されません。つまり「すべてのアプリがプロキシ経由になる」という意味ではありません。使い始めは、通信の振り分けを確認しやすいルールモードのままにしておくのがおすすめです。
次にポリシーグループの種類と選択内容を確認
select：手動選択。ノードまたは子ポリシーグループをクリックすると、以降の新しい接続に選択内容が適用されます。url-test：設定されたテストURL、間隔、許容範囲などに基づいて自動選択します。テスト結果によって選択先が変わることがあります。fallback：候補の順序とヘルスチェックの結果に基づいて利用可能な項目を選びます。単純に遅延が最小のノードを選ぶ方式ではありません。load-balance：設定された負荷分散方式で接続を振り分けます。すべてのリクエストが同じノードを通るとは限りません。
ルールによって、異なるポリシーグループが選ばれることがあります。たとえば、あるドメインへのアクセスが「ストリーミング」グループに一致した場合、「デフォルトプロキシ」だけを変更しても接続先は変わらないことがあります。まず接続画面で適用されたポリシーチェーンを確認し、対応するグループを操作してください。グループ内に別のグループが表示される場合は、最終的なノードが見つかるまで展開します。
速度テストのボタンは通常、指定されたテストURLへの応答を確認するもので、ダウンロード速度の測定とは異なります。Timeoutが表示されたら、テスト先に到達できるか、ノードが利用可能か、同時にテストしすぎていないかも確認してください。1回のタイムアウトだけで設定全体を削除しないようにしましょう。
設定画面：システムプロキシ・ポート・TUN
システムプロキシとローカルの待ち受けポート
「設定」から「システムプロキシ」と「ポート」を探します。システムプロキシのスイッチは、ホーム画面やトレイメニューにあるクライアントもあります。システムプロキシを有効にするとOSのプロキシ設定が変更され、その設定に従うアプリがローカルのプロキシ入口に接続します。実際のポートは使用中のクライアントと有効な設定によって異なり、すべてのソフトで同じ値とは限りません。
たとえば、次の設定例はローカルで7890の混合ポートを開き、HTTPとSOCKSのプロキシ接続を受け付けます。ポートの意味を示す例であり、単独でインポートできる完全な設定ではありません：
mixed-port: 7890
allow-lan: false
mode: rule
log-level: infoアプリ側でHTTPプロキシを個別に設定でき、上記のポートが実際に有効な場合は、ホストに127.0.0.1、ポートに7890を指定できます。ターミナルのプログラムはシステムプロキシを参照しないことがあり、ブラウザー拡張機能がシステム設定を上書きする場合もあります。「ブラウザーは使えるが、コマンドラインは使えない」ときは、まずアプリ独自のプロキシ設定を確認してください。
TUNは別の通信取り込み方式
TUNモードは仮想ネットワークアダプターやルーティングなどを使い、条件に合う通信を取り込みます。システムプロキシに従わないアプリで使われることがあります。サービスモードや管理者権限が必要な場合があり、ルーティング、DNS、除外設定の影響も受けます。スイッチが見つからない場合は、クライアントがTUNに対応しているか、サービスが正常にインストールされているかを確認してください。「LAN接続を許可」をTUNのスイッチと混同しないようにしましょう。
接続画面：リクエストが通ったポリシーを確認
接続画面には、コアが現在把握している接続が表示されます。主な項目は、接続先のドメインまたはIPアドレス、ポート、送受信バイト数、適用ルール、ポリシーチェーンです。プロセス名が表示されるかどうかは、OSの権限、コアの設定、プラットフォームの対応状況によって異なります。プロセス名がなくても、通信がプロキシに取り込まれていないとは限りません。
- テストするドメインを控え、ブラウザーから新しいリクエストを1回送信します。
- 「接続 / Connections」を開き、ドメインで検索するか、新しく追加された記録を確認します。
- 接続先のポートを確認します。HTTPSでは
443がよく使われます。続けてルールとポリシーチェーンを確認してください。 - 最終的な接続先が
DIRECTの場合は、ルール画面に戻って適用された理由を確認します。ノード名が表示されている場合は、そのノードの接続結果を確認してください。
ノードを切り替えても、確立済みのTCP接続やアプリの接続プールが以前の経路を使い続けることがあります。新しい選択を確認するには、対象の接続を閉じてからリクエストを再送信します。進行中のダウンロードや通話が中断されるため、最初からすべての接続を切断する必要はありません。クライアントによっては切り替え時に接続を自動で閉じる設定もあります。有効にする前に、どのセッションに影響するか確認してください。
接続リストが空の場合は、アプリが新しいリクエストを送信したか、ブラウザーのキャッシュが使われていないか、通信がコアに取り込まれているかを確認します。ここで確認できるのはコアに入ったリクエストだけです。「記録がない」ことをノードの故障と決めつけると、誤った方向にトラブル対処を進めてしまいます。
ルール画面：適用順と接続先を確認
ルールは通常、上から順に照合され、最初に一致したルールのポリシーが適用されます。ルール画面では、読み込み結果やドメインルールを確認し、適用順を調べられますが、直接編集できるとは限りません。画面が読み取り専用の場合は、ルール項目を何度もクリックせず、プロファイルまたは対応するオーバーライド機能から変更してください。
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,PROXYこの例では、example.comとそのサブドメインは直接接続し、一致しなかったリクエストはPROXYに渡します。PROXYは完全な設定内で定義済みのノード名またはポリシーグループ名である必要があります。ルールだけをコピーして、対応する定義を忘れないでください。MATCHは最後に適用されるルールです。他のルールより前に置くと、後続のルールが一致しなくなります。
ルールセットを使う設定では、RULE-SETが表示されることもあります。具体的な項目は関連付けられたルールプロバイダーから取得するため、ルールセットの更新状況も確認してください。「特定のサイトがなぜ直接接続されるのか」を調べる場合は、ルール画面でサイト名を検索するだけでなく、接続画面に表示された実際の適用結果を起点にするほうが確実です。
ログ画面：エラーが発生した段階を特定
通常はinfo、再現時だけ短時間debug
一般的なログレベルにはsilent、error、warning、info、debugがあります。「ログ」画面または「設定」でログレベルを変更した後、コアに新しい値が適用されているか確認してください。一部のクライアントではフロントエンドのログとコアのログが分かれています。通信のトラブル対処では、まずコアのログを確認しましょう。
通常の利用ではinfoで十分です。問題を再現する場合に限り、一時的にdebugへ切り替え、時刻を記録して対象のリクエストを1回だけ送信し、その前後のログを確認します。終わったらログレベルを元に戻し、詳細な記録がたまり続けないようにしてください。画面の「表示をクリア」は、ディスク上のログファイルも必ず削除するという意味ではありません。
| よくある手がかり | まず確認する項目 |
|---|---|
address already in use | 該当する待ち受けポートが別のインスタンスや他のプログラムに使用されていないか |
connection refused | エラーに記載された接続先のアドレスとポートを確認し、ローカルの入口での問題か、リモートサービスによる接続拒否かを見分ける |
timeout | タイムアウトが発生したのは、DNS、ノードへの接続、テストリクエスト、接続先サイトへのアクセスのどの段階か |
| YAMLの解析エラーまたは設定の検証エラー | 設定の形式、インデント、参照名、コアが各項目に対応しているか |
タイムアウトが表示されたら、前後にある接続先アドレスと処理内容を確認します。同じtimeoutでも、DNSの応答がない場合とノードへのTCP接続がタイムアウトした場合では、対処方法が異なります。ログを共有するときは、時刻、エラーの種類、関連する前後の情報を残し、サブスクリプションのトークン、パスワード、個人のアドレス情報は隠してください。最後の単語だけを切り取っても、原因の判断には不十分です。
初回利用時の確認手順
これまで紹介した画面を順につなげると、決まった操作手順になります。初回インストールだけでなく、設定を移行した後の基本確認にも使えます。
- プロファイル画面：有効な設定をインポートして有効化し、解析エラーがないことを確認します。
- プロキシ画面：ルールモードを選び、実際に使うポリシーグループで接続先を確認します。
- 設定画面：ローカルポートを確認してシステムプロキシを有効にし、ほかの通信取り込み方式はまだ併用しません。
- 接続画面：新しいリクエストを送信し、接続先と適用されたポリシーチェーンが表示されることを確認します。
- ログ画面：失敗した場合は、設定をいくつも同時に変えず、同じリクエストに関するエラーを確認します。
クライアントのインストール、サブスクリプションのインポート、システムプロキシの設定を確認する場合は、使い方ガイドをご覧ください。DNS、ルール、TUNの連携については、設定の応用ガイドで解説しています。まず通信の入口と接続先を決めるルールを確認してから、個々の設定を調整すれば、各画面の役割が明確になります。