まず理解したいクライアントの4層構造
一般的なClashのGUIクライアントは、名称やレイアウトが異なっていても、基本的に4つの層で構成されています。設定がプロキシノードとルールを決め、プロキシ画面がプロキシグループで使用する出口を決め、接続画面がコアを通過中のセッションを表示し、ログ画面がコアによる処理内容を記録します。システムプロキシ、TUNモード、ポート設定はさらに下位の層にあり、デバイスの通信をClashまたはmihomoコアへ渡します。
mihomoコアを採用したデスクトップクライアントを例にすると、左側には通常「概要」「プロキシ」「設定」「接続」「ログ」「設定」が並びます。設定を「サブスクリプション」、プロキシを「ルール」や「ポリシー」と呼ぶクライアントもあれば、コア設定を独立した「サービス」画面にまとめるものもあります。名称は変わっても、データの流れはほぼ同じです。
| 画面エリア | 主な用途 | 初心者がよく行う操作 |
|---|---|---|
| 概要画面 | 稼働状態、リアルタイム速度、累計通信量、現在のモードを確認する | コアが起動していることを確認し、上り下りの通信が発生しているかを見る |
| プロキシ画面 | プロキシグループ、ノード、遅延、現在の選択を表示する | 「ノード選択」グループで出口を切り替え、遅延をテストする |
| 設定画面 | サブスクリプション設定、ローカルYAMLファイル、更新日時を管理する | サブスクリプションを追加し、設定を更新して現在の設定にする |
| 接続画面 | アクティブな接続、宛先、適用ルール、経路を表示する | 特定のアプリがプロキシを経由しているか確認する |
| ログ画面 | DNS、ルールの適用、接続確立、エラー情報を記録する | WarningまたはErrorで異常を絞り込む |
| 設定画面 | システムプロキシ、TUN、ポート、自動起動、コアパラメーターを管理する | システムプロキシを有効にし、混合ポートを確認する |
概要画面は「通信が入っているか」の確認に向いています
概要画面には通常、コアの状態、アップロード速度、ダウンロード速度、アクティブな接続数、メモリ使用量が表示されます。システムプロキシを有効にして新しいページを開いたとき、接続数が0から6に増え、ダウンロード速度が一時的に320 KB/sになれば、少なくともコアに通信が入ったと判断できます。ただし、これはアプリとClashの間に接続が確立したことを示すだけで、リモートのプロキシノードが利用可能だと単独で証明するものではありません。
概要画面が常に0 B/sのままなら、ノードを何度も切り替える前に、システムプロキシのスイッチとリスニングポートを確認します。概要画面に通信があるのにウェブページを開けない場合は、プロキシ画面、接続画面、ログ画面でノードのタイムアウト、DNSエラー、ルールの誤適用を調べます。
プロキシ画面:プロキシグループとノードは別の階層です
プロキシ画面は最も誤解が生じやすい場所です。画面上の大きなカードは通常プロキシグループで、グループを展開して表示されるのがノードまたは別のプロキシグループです。設定ファイルでは proxy-groups がこの関係を定義します。ルールは通常、特定のノードではなくプロキシグループ名を参照します。
たとえば、あるルールが通信を「ノード選択」に渡し、そのグループで「自動選択」が選ばれ、「自動選択」が遅延テストによって「東京 02」を選ぶ場合があります。実際の経路は「ノード選択 → 自動選択 → 東京 02」と表示されます。接続詳細に複数階層の経路が見えるのは正常です。
代表的なプロキシグループの種類
- 手動選択:
selectに対応し、ユーザーがノードまたは下位のプロキシグループを指定します。選択は設定の再読み込み、選択肢の無効化、またはクライアントによる状態リセットまで維持されます。 - 自動テスト:
url-testに対応し、テストURLと間隔に基づいてノードを測定します。通常は遅延が低く、テストに成功した結果を選びます。 - フォールバック:
fallbackに対応し、リストの前方にあり、ヘルスチェックに合格したノードを優先して使用します。 - 負荷分散:
load-balanceに対応し、設定した方式に従って複数の利用可能なノードへ接続を分散します。 - 直接接続と拒否:
DIRECTは宛先へ直接接続し、REJECTは一致した通信を遮断します。
遅延の数値はどう読むべきか
ノードの右側に表示される38 ms、126 ms、Timeoutなどは、通常1回のHTTPヘルスチェックの結果です。ウェブページ全体の読み込み時間でも、ICMP Pingと同じものでもありません。テストにはDNS、TCP、TLS、HTTP応答の時間が含まれることがあり、具体的な範囲は設定されたテストURLとクライアントの実装によって異なります。
| テスト結果 | 一般的な意味 | 次の対応 |
|---|---|---|
| 35–90 ms | テスト先からの応答が速い | ウェブページを開いて実際のアクセスを確認する |
| 100–250 ms | 接続はできるが、距離または負荷が高い | 同じ地域の他のノードと安定性を比較する |
| 500 ms以上 | 経路の混雑、ノード負荷の高さ、またはテスト先の応答遅延 | 2〜3回再テストして変動を確認する |
| Timeout | 設定したタイムアウト時間内に期待した応答を得られない | ログでDNS、ハンドシェイク、接続エラーを確認する |
ノードを切り替える安全な手順
- プロキシ画面で、ルールが実際に参照しているメインのプロキシグループ(「ノード選択」や「プロキシ」など)を見つけます。
- まず遅延テストを1回実行し、Timeoutと表示されたノードを除外します。
- 1回のテストで最小の数値だけを比べず、遅延が安定しているノードを選びます。
- 新しいブラウザータブを開き、以前の接続が元の経路を再利用しないようにします。
- 接続画面を開き、新しい接続のプロキシチェーンに選択したノードが含まれているか確認します。
設定画面:サブスクリプション、ローカルファイル、現在の設定
設定画面で管理するのはコアへの入力です。完全な設定には通常、ポート、DNS、プロキシノード、プロキシグループ、ルールが含まれます。サブスクリプションURLは設定の取得元の1つで、ローカルYAMLファイルも別の取得元です。サブスクリプションをクライアントに追加しただけでは、設定項目が保存されただけです。現在の設定に指定して正常に読み込まれて初めて、プロキシ画面に対応するプロキシグループが表示されます。
設定カードの情報が示す内容
- 設定名:取得元を識別しやすくする名前です。クライアントが自動生成した名前の場合も、手動で変更した名前の場合もあります。
- 更新日時:設定の取得または保存が最後に成功した時刻です。その時点ですべてのノードが利用可能だったことを示すものではありません。
- 更新間隔:クライアントがサブスクリプションを再取得する周期です。6時間、12時間、24時間がよく使われます。
- 現在の設定:コアがこの設定を使用中であることを示します。カードを選択しただけで読み込んでいない場合、状態は変わらないことがあります。
- 通信量情報:サブスクリプションの一部のレスポンスヘッダーには、使用済み通信量、総容量、有効期限が含まれます。提供されていない場合、クライアントには表示できません。
一般的な操作手順は「設定」→「新規作成」→「URLからインポート」です。サブスクリプションURLを貼り付けて保存し、その後、設定カードのメニューで「現在の設定にする」または「有効化」を選びます。クライアントによっては「サブスクリプション」→「追加」と表示されます。更新時はカードの更新ボタンを使い、何度も削除して再インポートするのは避けてください。
ローカルYAML設定は細かな制御に適しています
ローカルファイルならフィールドを直接確認・編集できます。YAMLはスペースで階層を表すため、Tabによるインデントや階層のずれで読み込みに失敗することがあります。以下は画面間の関係を説明するための簡略化した構造です。ポート、プロキシグループ、ルールはそれぞれ設定画面、プロキシ画面、接続詳細に対応します。
mixed-port: 7890
mode: rule
log-level: info
proxies:
- name: example-node
type: socks5
server: 127.0.0.1
port: 1080
proxy-groups:
- name: ノード選択
type: select
proxies:
- example-node
- DIRECT
rules:
- DOMAIN-SUFFIX,example.com,ノード選択
- MATCH,DIRECT
mixed-port: 7890 は、HTTPとSOCKSのインバウンドで7890ポートを共用することを示します。mode: rule はルールに従って接続を処理する設定です。最後の MATCH,DIRECT はフォールバックルールで、前のルールに一致しない場合に直接接続します。実際のサブスクリプション設定には通常、DNS、ルールセット、provider、その他のプロキシグループも含まれます。
設定を更新すると選択が変わる理由
サブスクリプションの更新によって、ノードが追加、削除、改名されることがあります。プロキシグループで以前選択していたノードが存在しなくなると、コアはグループ内で利用可能な選択肢に戻ります。具体的な結果は、クライアントの状態保存とプロキシグループの種類によって異なります。プロキシ画面が突然「東京 02」から「自動選択」に変わっても、スイッチの故障とは限らず、新しい設定に同名のノードがない可能性もあります。
更新後は3つの場所を確認します。設定画面で更新日時が変わったこと、プロキシ画面でグループの内容が更新されたこと、ログ画面で設定の再読み込みにエラーがないことを確認してください。「ダウンロード成功」と表示されただけでは不十分です。ダウンロード完了とコアへの読み込み成功は別の段階だからです。
接続画面:特定のアプリが実際にどこを経由したか確認する
接続画面は、トラフィックの振り分け結果を確認する最も直接的な場所です。各レコードには通常、送信元アドレス、宛先ドメインまたはIP、ネットワーク種別、アップロード・ダウンロード量、適用ルール、プロキシチェーン、確立時刻が含まれます。ブラウザーで1ページを開くだけでも十数件の接続が作られることがあるため、リストの先頭だけを見るのではなく、ドメインで絞り込んでください。
重点的に確認する4つのフィールド
- Hostまたは宛先アドレス:テスト中のウェブサイトに属する記録か確認します。IPしか表示されない場合、DNSの解決方式やアプリのプロトコルがドメイン名を提供していない可能性があります。
- Rule:
DomainSuffix、GeoIP、RuleSet、最終フォールバックルールなど、適用されたルールを表示します。 - Chains:プロキシグループから最終ノードまでの選択経路を表示します。例:「ノード選択 → 香港 01」。
- Process:システムと権限が許可する場合、プロセス名を表示します。TUNモードでプロセスを識別できるかどうかは、プラットフォームとクライアントの実装によって異なります。
example.com にアクセスした後、接続詳細のルールが DomainSuffix、プロキシチェーンが「ノード選択 → シンガポール 03」と表示されたとします。この場合、新しい接続がドメインルールによって指定したプロキシグループに入り、最終的にシンガポール 03を使用したと確認できます。プロキシチェーンが DIRECT の場合は、ルールの順序、動作モード、設定が切り替わっているかを確認します。
既存の接続は古いノードを使い続けることがあります
プロキシグループを切り替えても、確立済みのTCP接続が強制的に移行するわけではありません。ブラウザーがHTTP/2やHTTP/3のセッションを再利用することもあるため、ノードを切り替えてすぐにページを更新しても、接続画面に一時的に古い経路が表示されることがあります。該当する接続を閉じる、新しいプライベートウィンドウを開く、または古いセッションが終了するまで待ってからテストしてください。「すべての接続を閉じる」は進行中のダウンロードや他の通信タスクを中断するため、慎重に操作します。
ログ画面:レベルとキーワードでエラーを特定する
ログ画面にはコアの動作過程が記録されます。通常のアクセスでは接続、ルールの適用、アウトバウンド情報が表示され、設定やネットワークに異常があると解析失敗、接続拒否、タイムアウト、TLSハンドシェイク失敗などが記録されます。ログが多い場合は、まずレベルで絞り込み、次にドメイン、ポート、プロキシグループ名で検索すると、行を順にスクロールするより効率的です。
| ログレベル | 用途 | 適した場面 |
|---|---|---|
| Debug | 内部処理をより詳しく出力する | 複雑な問題を短時間だけ再現し、完了後にInfoへ戻す |
| Info | 通常の接続と動作状態を記録する | 日常利用と基本的なトラブルシューティング |
| Warning | 復旧可能だが注意が必要な異常を記録する | DNS、ルールリソース、接続の変動を絞り込む |
| Error | 操作失敗につながるエラーを記録する | 設定を読み込めない、ポートのバインドに失敗するなどの問題を調べる |
| Silent | ログ出力をできるだけ減らす | 安定稼働していて、当面診断が不要なとき |
よくある3つのエラーと確認ポイント
- connection refused:宛先ポートが明確に接続を拒否しています。ノードサービスが待ち受けていない、アドレスが間違っている、またはローカルから接続する制御ポートが起動していない可能性があります。
- i/o timeout:制限時間内に読み書きが完了していません。DNS、TCP接続確立、TLSハンドシェイク、リモート側の応答のどの段階で止まったかを切り分ける必要があります。
- address already in use:待ち受けポートが別のプロセスに使用されています。混合ポートを7890に設定している場合は、別のプロキシクライアントが7890を使用していないか確認します。
トラブルシューティングでは、まず現在のログを消去し、Infoレベルを有効にしてから問題を1回だけ再現します。たとえば、ログを消去して対象ドメインへアクセスし、5秒待ってスクロールを止め、そのドメインを検索します。これにより、古い記録やバックグラウンドアプリの接続による判断への影響を避けられます。Infoで足りない場合のみ、一時的にDebugへ切り替えてください。Debugを常時有効にするとログ量が大幅に増えます。
設定画面:システムプロキシ、TUN、ポートはそれぞれ別の層を担当します
設定画面は、通信がどのようにコアへ入るかを決めます。システムプロキシはOSのHTTP、HTTPS、SOCKSプロキシ設定を変更し、システムプロキシに従うブラウザーやデスクトップアプリに適しています。TUNモードは仮想ネットワークインターフェースを作成して、より広い範囲をカバーします。システムプロキシ設定を読まないアプリも扱えますが、適切なシステム権限と正しいルーティング、DNS設定が必要です。
ポートの項目を混同しない
- Mixed Port:混合プロキシポートです。一般的な値は
7890で、HTTPとSOCKSの接続を受け付けます。 - HTTP Port:HTTPプロキシ専用です。
7890を使う設定もあります。 - SOCKS Port:SOCKS5プロキシ専用です。従来の設定では
7891がよく使われます。 - External Controller:GUIやDashboardからコアを制御するための項目です。一般的なアドレス形式は
127.0.0.1:9090です。ブラウザー用のプロキシポートではありません。
クライアントが混合ポート7890を使用する場合、ターミナルプログラムのHTTPプロキシは通常 http://127.0.0.1:7890 を指定し、制御ポート9090は指定しません。具体的な値は現在の設定と設定画面を基準にしてください。ポートを変更したら、システムプロキシのアドレス、ブラウザーの手動プロキシ、ターミナルの環境変数も合わせて更新します。
システムプロキシとTUNの選び方
初回は、まずシステムプロキシを有効にして基本経路を確認することをおすすめします。ブラウザーの通信が発生し、プロキシ画面のノードが利用可能で、接続画面にルールの適用が表示されれば、設定と出口はおおむね正常です。アプリがシステムプロキシに従わない場合に、TUNの有効化を検討します。これにより、「ノードが利用できない」問題と「TUNのルーティング異常」を分けて対処できます。
一部のデスクトップクライアントでは、TUNを安定した権限で有効にするため、先にサービスモードをインストールする必要があります。一般的な手順は「設定」→「サービスモード」→「インストール」と進み、その後「設定」→「TUNモード」に戻って有効にします。実際の手順はクライアントのバージョンによって異なります。有効化後は、新しい仮想ネットワークアダプターが表示されるか、DNSを解決できるか、LANやローカル開発サービスへ想定どおりアクセスできるか確認してください。
10分で画面を一通り確認する
初めて設定をインポートしたら、決められた順番で確認できます。この順番なら設定の取得元から始め、ノード選択と通信の入口を経て、最後に接続とログで結果を検証できるため、複数の画面を何度も行き来せずに済みます。
- 1分目:設定画面を開き、サブスクリプションまたはローカルファイルが存在し、現在の設定として指定されていることを確認します。
- 2分目:更新を1回実行し、更新日時が変わったことと、設定の解析に関する警告がないことを確認します。
- 3〜4分目:プロキシ画面を開き、メインのプロキシグループで遅延テストを実行し、2回連続で応答が安定したノードを選びます。
- 5分目:設定画面を開き、コアが動作していること、混合ポートとシステムプロキシのアドレスが一致していることを確認します。
- 6分目:システムプロキシを有効にし、新しいブラウザーウィンドウでテストページを開きます。
- 7〜8分目:接続画面を開き、対象ドメインで絞り込んで、適用ルールと最終ノードを確認します。
- 9分目:概要画面に戻り、接続数と上り下りの通信量が変化していることを確認します。
- 10分目:ログ画面でWarningとErrorを絞り込み、ポート、DNS、タイムアウトのエラーが継続して発生していないことを確認します。
問題が起きたら現象に対応する画面へ戻る
| 現象 | 最初に確認する項目 | 重点フィールド |
|---|---|---|
| プロキシ画面にノードが1つもない | 設定画面 | 現在の設定、読み込み状態、更新日時 |
| すべてのノードがTimeoutになる | ログ画面 | DNS、接続タイムアウト、テストURL |
| ブラウザーでアクセスしても接続数が0のまま | 設定画面 | システムプロキシ、リスニングアドレス、混合ポート |
| 接続はあるがDIRECTになっている | 接続画面と設定画面 | 適用ルール、動作モード、ルールの順序 |
| ノードを切り替えても古い出口が表示される | 接続画面 | 古い接続、プロキシチェーン、新規作成時刻 |
| TUNを有効にするとドメインを解決できない | ログ画面と設定画面 | DNSモード、仮想ネットワークアダプター、ルーティング状態 |
画面の役割を理解すると、トラブルシューティングは1本の流れに整理できます。設定画面で「何を読み込んだか」、プロキシ画面で「何を選んだか」、設定画面で「通信がどう入るか」、接続画面で「実際にどこを経由したか」、ログ画面で「なぜ成功または失敗したか」を確認します。この5つの問いが5つの画面に対応し、初回接続で起こる問題の大部分をカバーします。