まずクライアント・設定・コアを区別する
Clash Plus、Clash Verge Rev、FlClash などのデスクトップアプリはクライアントの外枠であり、画面の表示や設定の管理、プロキシコアの呼び出しを担います。実際にルール判定、DNS 解決、接続の転送、TUN の制御を行うのは、通常 Mihomo コアです。クライアントによってサイドバーのアイコン、メニュー名、並び順は異なりますが、中心となる役割は4つに整理できます。プロキシ画面は通信をどのポリシーへ渡すか、設定画面はどのルールセットを読み込むか、接続画面は現在進行中のセッション、ログ画面はコアがセッションをどう処理したかを示します。
この役割分担を理解すれば、操作の順序も明確です。まず設定画面でサブスクリプションを読み込み、適用します。次にプロキシ画面で動作モードとポリシーグループを確認し、システムプロキシまたは TUN を有効にします。最後に接続画面とログ画面で結果を確認します。プロキシ画面でノードだけを何度も切り替え、現在の設定や通信の取り込み方式を確認しないのは、初心者によくある効果のない操作です。
| 画面エリア | 主な対象 | よく行う操作 | 担当しないこと |
|---|---|---|---|
| プロキシ画面 | 動作モード、ポリシーグループ、ノード | ノード選択、ポリシー切り替え、遅延テスト | サブスクリプション内容の更新 |
| 設定画面 | ローカル YAML、リモートサブスクリプション、設定プロバイダー | 設定の読み込み、更新、適用 | 個別の接続がどのルールに一致したかの判定 |
| 接続画面 | 現在の TCP・UDP セッション | 宛先アドレス、ルール、プロキシチェーン、通信量の確認 | 長期保存用の完全な診断記録 |
| ログ画面 | コアの動作イベント | DNS、ルール、ダイヤル、設定エラーの確認 | サブスクリプションエディターの代用 |
| 設定画面 | システムプロキシ、TUN、ポート、コアパラメータ | アプリが通信を取り込む方法の決定 | プロキシ画面でのポリシーグループ選択の代用 |
プロキシ画面：モード・ポリシーグループ・ノードの選択
プロキシ画面は単なるサーバー一覧ではありません。設定ファイルの proxy-groups が表示され、各グループには役割があります。たとえば「ノード選択」は手動選択グループ、「自動選択」は url-test グループ、「フォールバック」は fallback グループに相当します。最終的にどの経路で接続するかは、動作モード、ルールの一致結果、ポリシーグループの入れ子構造、現在の選択内容によって決まります。
3つの動作モードの役割
- Rule：設定内のルールを上から順に照合します。ドメインは
DOMAIN-SUFFIX、IP アドレスはIP-CIDRに一致することがあり、どのルールにも一致しない通信は最終的にMATCHへ進みます。日常利用で最も一般的なモードです。 - Global：大半の接続をグローバルポリシーグループへ一括して渡し、通常のルールによる振り分けを行いません。指定したノードで特定のウェブサイトへ接続できるか一時的に確認する用途には向いていますが、ルールモードの長期的な代替には適しません。
- Direct：通常、接続はプロキシノードを経由せず、宛先へ直接送信されます。ローカルネットワークとの比較テストに使えますが、有効にするとプロキシ画面でノードを選んでいても、実際の通信が
DIRECTと表示される場合があります。
ウェブページが常に直接接続される場合は、まず画面上部または設定エリアで現在のモードが Direct になっていないか確認します。すべてのサイトが同じノードを経由する場合は、Global に誤って切り替えていないか確認してください。クライアントを再起動すると通常は前回の状態が復元されるため、トラブル対処では記憶だけで現在のモードを判断しないことが大切です。
ポリシーグループの種類で選択方法が決まる
| グループの種類 | 画面上の動作 | 適した用途 |
|---|---|---|
select |
ユーザーがノードまたは下位のポリシーグループを手動で選択 | 地域や回線を固定したい場合、手動で制御したい場合 |
url-test |
テスト先への遅延結果から自動選択 | 同種のノードから応答の速いものを選択 |
fallback |
利用可能なリストの上位ノードを優先して使用 | 主回線の障害時に予備回線へ切り替え |
load-balance |
設定したポリシーに従って接続を振り分け | 複数ノードへ通信を分散するが、帯域幅の合算ではない |
遅延の数値は、テスト URL に対するその時点の応答時間を示すだけです。80 ms のノードが 120 ms のノードより必ず速くダウンロードできるとは限りません。実速度は出口帯域、パケットロス、接続先の場所、混雑状況にも左右されます。テスト失敗も、ノードが完全に使えないことを意味するとは限りません。テスト先のブロック、DNS 解決の失敗、プロバイダー未更新などでもタイムアウトになります。
設定画面：サブスクリプションの読み込み・更新・適用状態
設定画面で管理するのは、動作に必要な入力全体です。リモートサブスクリプションは通常 Clash YAML 設定として取得され、ポート、DNS、ノード、ポリシーグループ、ルール、ルールプロバイダーなどが含まれます。一部のサービスは汎用的な Base64 ノード一覧だけを返すため、Clash の設定画面で直接解析できるとは限りません。読み込み時に「形式エラー」と表示されたり、ノードだけが現れてルールグループが表示されなかったりする場合は、まずサブスクリプション形式を確認してください。
読み込み成功と適用済みは別
多くのクライアントでは複数の設定を同時に保存できます。新しいサブスクリプションを読み込んだ後は、設定カード、ラジオボタン、または「適用」ボタンを操作して現在の設定にする必要があります。切り替えを確認するには、プロキシ画面に戻ってポリシーグループ名が変わったか確認するか、ログ画面で設定の再読み込み記録を探します。新旧のサブスクリプションに同名のポリシーグループがある場合、プロキシ画面の見出しだけでは不十分です。設定画面の選択状態と更新日時も確認してください。
- 「設定」または「Profiles」画面を開きます。
- サブスクリプション入力欄に
https://で始まる完全な URL を貼り付けます。 - 「読み込み」「ダウンロード」、またはプラスボタンをクリックし、解析が完了するまで待ちます。
- 新しく表示された設定カードを選び、現在の設定として適用します。
- 更新ボタンをクリックし、更新日時が変わったことを確認します。
- プロキシ画面に戻り、ポリシーグループとノードが想定どおり表示されるか確認します。
自動更新とローカル編集の境界
自動更新の間隔は24時間が一般的ですが、6時間、12時間、48時間に設定できるクライアントもあります。更新日時はクライアントが取得を試みた時刻であり、上流の内容が変わったことを示すものではありません。サーバーが 401 または 403 を返す場合は、サブスクリプションの期限、認証パラメータの欠落を確認します。タイムアウトの場合は DNS、現在のネットワーク、サブスクリプションのドメインへ到達できるかを確認してください。
リモートサブスクリプションから生成された YAML を直接編集する場合は、上書きに注意が必要です。次回の更新で、ローカルの変更がリモート版に置き換えられることがあります。カスタムルールを長期的に保持するには、ローカル設定としてコピーするか、クライアントのオーバーライド、スクリプト、Merge、Mixin 機能を利用します。項目は「設定」→「オーバーライド」または「設定」→「設定管理」にある場合があります。編集前に正常に読み込める設定を1つ保存しておくと、構文エラー時に戻せます。
mixed-port: 7890
mode: rule
log-level: info
allow-lan: false
rules:
- DOMAIN-SUFFIX,example.com,DIRECT
- MATCH,ノード選択上の例にある mixed-port: 7890 は、HTTP と SOCKS のインバウンドで 7890 番ポートを共有することを示します。ただし、これはよくある設定であり固定値ではありません。チュートリアルの画像より、クライアントの設定画面に表示される実際のポートを優先してください。ブラウザー、ターミナル、その他のアプリにプロキシを手動設定する場合は、現在の動作設定を確認し、すべてのクライアントが 7890 を使うと決めつけないでください。
接続画面：通信が実際にどこへ向かったかを確認
接続画面は、動作状況を直接確認できる情報源です。通常は送信元アドレス、対象ホスト、対象 IP、ネットワーク種別、アップロード・ダウンロード量、適用ルール、ポリシーグループ、プロキシチェーンが表示されます。ブラウザーで1つのウェブページを開くと、本文、画像、スクリプト、フォント、計測 API がそれぞれ異なるドメインへ接続することがあります。そのため、一覧に十数件のセッションが表示されても異常ではありません。
4つの項目を重点的に確認
- Host または対象ドメイン：確認中の接続が対象アプリのものか確認します。IP アドレスだけでドメイン名がない場合は、アプリが IP へ直接アクセスしているか、ドメインのスニッフィングで結果を取得できなかった可能性があります。
- Rule：
DOMAIN-SUFFIX、GEOSITE、IP-CIDR、MATCHなど、一致したルールの種類を表示します。ルールの内容は通常、隣接する項目に表示されます。 - Chains：ポリシーグループから最終出口までの経路を表示します。たとえば「海外サイト → 自動選択 → HK-01」のように示されます。最終結果が
DIRECTなら直接接続、REJECTならルールにより拒否されたことを表します。 - Network：TCP と UDP を区別します。ウェブページの本体は TCP または UDP ベースの QUIC を使うことが多く、音声、ゲーム、DNS でも UDP セッションが発生する場合があります。
ルールを調べるときは、まずフィルターを解除し、検索欄に対象ドメインを入力します。ウェブページを開き直して新しい接続を確認してください。プロキシを通るはずなのに DIRECT になっている場合は、ルールの順序を確認します。Clash は通常、上から順に照合し、最初に一致したルールを適用します。広範囲の直接接続ルールの後ろにカスタムルールを置くと、構文が正しくても実行されません。
接続画面では、ノード切り替えが反映されたかも確認できます。旧経路が「ノード選択 → JP-01」で、SG-02 へ切り替えた場合、既存の長時間接続は JP-01 のまま表示され、新しい接続だけが「ノード選択 → SG-02」になることがあります。接続の再利用による正常な挙動です。「すべての接続を閉じる」をクリックすると現在のセッションが切断され、ダウンロード中のファイル、リモートターミナル、オンライン会議にも影響します。
ログ画面：症状から具体的な処理箇所を特定
ログ画面には、コアの起動、設定の読み込み、DNS クエリ、ルール判定、プロキシ接続、エラーイベントが記録されます。接続画面が「この通信はどこを通ったか」に答えるのに対し、ログ画面は「なぜ接続を確立できなかったか」を確認する画面です。トラブル対処ではまず info レベルを使い、通常のログでは情報が足りない場合だけ一時的に debug へ切り替えます。調査が終わったら info に戻してください。
よくあるログキーワードと対処の方向性
| ログの断片 | 通常の意味 | 次に行うこと |
|---|---|---|
connection refused |
宛先ポートが接続を拒否 | ノードのアドレス、ポート、サービスの状態を確認 |
i/o timeout |
接続または読み込みが制限時間内に完了しなかった | ネットワークまたはノードを切り替え、パケットロスと接続先への到達性を確認 |
no such host |
ドメインの名前解決に失敗 | DNS 設定、上流サーバー、ネットワーク権限を確認 |
address already in use |
待ち受けポートが別のプロセスに使用されている | 使用中のアプリを終了するか、mixed・HTTP・SOCKS ポートを変更 |
proxy provider の更新に失敗 |
ノードプロバイダーのファイルを取得できなかった | provider URL、更新間隔、アクセス経路を確認 |
| YAML の行番号またはフィールドエラー | 設定の構文またはフィールド構造を解析できない | 設定画面で保存したコピーに戻し、インデントとフィールド階層を確認 |
ログを共有して相談する前に、サブスクリプション URL、ノードサーバーのアドレス、認証パラメータ、ローカル IP、アクセス先ドメインが含まれていないか確認してください。ページ全体を貼り付けるより、障害の発生前後およそ20〜50行を残し、操作時刻、クライアント名、コアのバージョン、動作モード、通信の取り込み方式を添えるほうが有効です。
設定画面：システムプロキシ・TUN・ポートの連携
プロキシ画面でノードを選んでも、通信をコアへ取り込む必要があります。一般的な方法はシステムプロキシと TUN の2つです。システムプロキシでは、クライアントが OS の HTTP、HTTPS、または SOCKS プロキシをローカルポートへ向けます。ブラウザーなどシステム設定に従うアプリは利用できますが、ターミナルツール、ゲーム、一部の独立したネットワークスタックはシステムプロキシを読み取らないことがあります。
TUN モードは仮想ネットワークインターフェースを通じて、より広い範囲の通信を取り込みます。システムプロキシを読み取らないアプリに適していますが、システム権限、ルーティング、DNS 設定への依存度は高くなります。Windows で TUN を有効にすると、管理者権限やサービスモードのインストールを求められる場合があります。システムプロキシと TUN はクライアント側で連携できますが、トラブル対処中はどちらに依存しているかを明確にし、複数の項目を同時に変更しないようにしてください。
覚えておきたいローカルポート
7890：HTTP と SOCKS の接続を同時に受け付ける、よく使われる mixed ポートです。実際の値は設定画面を確認してください。7891：一部の古い設定では SOCKS ポートとして使われますが、新しい設定で同じ割り当てが残っているとは限りません。9090：クライアント画面がコアの制御 API に接続するためによく使われる external controller ポートです。ブラウザーに入力するプロキシポートではありません。53：標準 DNS ポートです。TUN や拡張 DNS の設定では、内部待ち受けや転送を通じてクエリを処理する場合があるため、ポート番号だけで動作の成否を判断しないでください。
「クライアントは実行中なのにウェブページが開けない」場合は、「設定」→「ポート設定」で mixed ポートを確認し、システムプロキシのアドレスが 127.0.0.1 と同じポートを指しているか確認します。ログに address already in use と表示される場合は、ポートの待ち受けに失敗しています。システムプロキシが有効でも、アプリからコアへリクエストを渡せません。
安定した日常操作の流れ
画面に慣れれば、毎回すべての画面を確認する必要はありません。通常は決まった手順に絞り、異常が起きたときだけ通信経路に沿って順番に確認します。
- 設定画面：サブスクリプションの更新日時と、現在適用されている設定を確認します。サブスクリプションを変更したら、まず更新し、新しいポリシーグループが表示されるか確認してください。
- プロキシ画面：Rule モードを使い、必要なポリシーグループまたはノードを選択します。遅延テストは利用可能性を判断する目安にとどめます。
- 設定画面：アプリの種類に応じてシステムプロキシまたは TUN を有効にし、ローカルの待ち受けポートを確認します。
- 接続画面：対象サイトへアクセスし、ドメインで新しいセッションを絞り込み、ルールとプロキシチェーンを確認します。
- ログ画面：接続を確立できない場合は、発生時刻を手がかりに DNS、タイムアウト、接続拒否、設定エラーを調べます。
ブラウザーではアクセスできるのに、ターミナルのコマンドだけが直接接続になる場合は、ターミナルがシステムプロキシを読み取っているかを確認するか、TUN を使います。すべてのアプリに接続記録がない場合は、システムプロキシ、TUN、ポートの待ち受けを優先して確認します。接続画面に記録はあるものの経路が DIRECT の場合は、プロキシモードとルール順序を見直します。指定ノードまで到達しているのにタイムアウトする場合は、ノードへの到達性、DNS、対象サイトの状態を調べてください。