Clash初回接続ガイド：ノード選択・遅延テスト・プロキシ有効化の確認

接続前にサブスクリプションの読み込みを確認する

Clashを初めて使うときは、手順を「設定が有効」「ノードが利用可能」「ポリシーグループを選択済み」「システム通信が接続済み」の4段階に分けて確認しましょう。クライアントに「実行中」と表示されても、カーネルプロセスが起動しただけで、ブラウザーの通信がプロキシ経由になったとは限りません。

設定名と更新日時を確認する

以下では、Clash Verge Rev 2.4.x と mihomo 1.19.x の一般的な画面を例に説明します。クライアントによってボタン名は多少異なりますが、「設定」「プロキシ」「接続」「設定」各ページの役割は基本的に共通しています。

1. 「サブスクリプション」または「設定」ページを開き、読み込んだ設定が一覧に表示されていることを確認します。
2. 設定カードをクリックして、現在の有効設定にします。ローカルにダウンロードしただけで選択していない場合、カーネルはその中のノードやルールを使用しません。
3. 更新日時を確認します。数週間前の日付になっている場合は、まず「サブスクリプションを更新」を実行してください。
4. 「プロキシ」ページを開き、ポリシーグループとノード名が表示されていることを確認します。空の一覧ではいけません。

カーネルを起動してエラーを確認する

「設定」→「Clash設定」または「設定」→「カーネル設定」に戻り、現在のカーネルが mihomo になっていることを確認します。起動に成功すると、ログには通常、設定の読み込み、待受ポート、ルール初期化に関する情報が表示されます。一般的なローカル待受値はHTTPポート 7890、SOCKS5ポート 7891、または mixed-port: 7890 の統合設定です。

ログに address already in use と表示された場合は、ポートが別のプログラムに使用されています。YAML解析エラーが表示された場合は、設定形式に問題があります。この段階でノードのテストを続けず、まずカーネルを安定して動作させてください。

正しいポリシーグループでノードを選ぶ

Clashの「プロキシ」ページには、ノードとポリシーグループが同時に表示されることがよくあります。ノードは具体的な回線、ポリシーグループは特定の通信を最終的にどの回線へ渡すかを決める仕組みです。初回接続で起こりやすいのは、ノードが未選択なのではなく、実際の振り分けに使われないグループで選択してしまうことです。

まずポリシーグループの種類を見分ける

まず「ノード選択」「手動選択」などの名前のグループ、または PROXY グループを開き、たとえば「日本 01」「シンガポール 02」のように地域が明記されたノードを1つ選びます。その後、ページ上部またはメインのポリシーグループがこのグループを参照しているか確認してください。メインのグループが DIRECT のままだと、ノードカードが選択状態でも出口は変わりません。

初回テストはルールモードを使う

「設定」→「システム設定」、またはクライアントのホーム画面でプロキシモードを開き、「ルール」を選択します。ルールモードでは、設定内のルールを上から順に照合します。ローカルネットワークや一般的な中国本土向けアドレスは通常直接接続し、プロキシが必要な宛先はポリシーグループへ渡し、最後に MATCH が未一致の通信を処理します。

• ルールモード：日常利用に適しており、サブスクリプションの振り分けが正常かどうかも確認できます。
• グローバルモード：ほとんどの通信をグローバルポリシーグループへ渡します。短時間だけルールの問題を切り分ける場合に適しています。
• ダイレクトモード：プロキシを迂回します。このモードを誤って選ぶと、IP確認では常にローカルの出口が表示されます。

遅延テストでは遅延・タイムアウト・変動幅を見る

クライアントの遅延テストは通常、ICMP Pingではありません。Clashが指定されたノードを経由してテストURLへアクセスし、接続確立、TLSネゴシエーション、またはレスポンス受信までの時間を記録します。プロキシの可用性に近い結果ですが、ダウンロード速度を示すものではありません。

比較可能な一括テストを1回実行する

1. 「プロキシ」ページを開き、現在使用しているポリシーグループを探します。
2. グループ右上の速度テストボタンをクリックし、すべてのノードのテストが終わるまで待ちます。連続して何度もクリックしないでください。
3. 遅延、タイムアウトしたノード数、同じノードを3回連続で測定した結果の変化を記録します。
4. 遅延が妥当で変動の小さいノードから1つ手動で選び、ウェブテストを行います。

たとえばノードAが3回の測定で86、91、89 ms、ノードBが52、420、77 msだったとします。ノードBの最低値は小さいものの、初回接続のテスト対象には通常ノードAのほうが適しています。一時的な低遅延より、安定性のほうが参考になります。

遅延は正常なのにウェブ表示が遅い原因

遅延が示すのは短いリクエストの応答時間だけです。回線帯域、混雑する時間帯、対象サイトの速度制限、パケットロス、端末性能なども実際の体感に影響します。65 msのノードでもスループットが低いことがあり、150 msのノードのほうが大きなファイルを安定して転送できる場合もあります。

テスト先のアドレスに到達できるかも確認します。mihomoの設定では、ヘルスチェック先として https://www.gstatic.com/generate_204 がよく使われます。現在のネットワーク環境でテスト先自体がブロックされていると、すべてのノードがタイムアウトになることがありますが、それだけで全回線が同時に停止したとは限りません。

システムプロキシを有効にしてブラウザーの通信をClashへ渡す

ノードを選んだら、アプリの通信をClashのローカル待受ポートへ送る必要があります。一般的なブラウザーはシステムプロキシで接続できますが、ゲーム、コマンドラインプログラム、ストアアプリ、一部のUDP通信を使うソフトはシステムプロキシを無視することがあります。その場合はTUNモードやアプリ側のプロキシ設定が必要です。

WindowsとmacOSでシステムプロキシを確認する

クライアントのホーム画面で「システムプロキシ」を有効にします。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」で手動プロキシの状態を確認できます。一般的なアドレスは 127.0.0.1、ポートは 7890 です。クライアントが別の mixed-port を使う場合、システム設定のポートも一致させてください。

macOSでは「システム設定」→「ネットワーク」→「Wi-Fi」→「詳細」→「プロキシ」でWebプロキシと保護されたWebプロキシを確認します。通常はクライアントが自動設定するため、クライアントの実行中に別のプロキシツールで同じ項目を変更することはおすすめしません。

競合する可能性のあるネットワークツールを先に終了する

• 7890、7891、または同じコントロールポートを使用している他のプロキシクライアントを終了します。
• ブラウザー内で個別に設定したプロキシ拡張機能を一時停止し、リクエストが別のアドレスへ送られないようにします。
• システム時刻が正確か確認します。時刻が大きくずれていると、HTTPS証明書の検証に失敗します。
• 初回検証では、アプリ内のカスタムDNSやプロキシチェーン設定を一時的に無効にして、確認する変数を減らします。

出口IPでプロキシの有効化を確認する

ウェブページを開けても、リクエストが必ずプロキシ経由とは限りません。最も直接的な確認方法は、Clashを有効にする前後でパブリックIPを調べ、アドレス、通信事業者、地域情報を比較することです。同じブラウザー、同じネットワーク環境でテストしてください。

ブラウザーで確認する手順

1. クライアントの「システムプロキシ」を一時的に無効にし、IP確認ページを開いて、元のパブリックIPの前半2ブロックと地域を記録します。
2. システムプロキシを再び有効にし、モードが「ルール」または「グローバル」であること、先ほどテストに合格したノードが選択されていることを確認します。
3. 新しいシークレットウィンドウを開き、異なる2つのIP確認ページを表示します。
4. 2つのページに同じプロキシノードの地域が表示され、IPも元の出口と異なっていれば、ブラウザーのプロキシは基本的に有効です。
5. Clashの「接続」ページに戻り、確認ページを再読み込みします。該当するドメイン、宛先アドレス、ポリシーグループ、ノード名が表示されるか確認してください。

たとえばプロキシ無効時の出口が 203.0.113.24、有効時に 198.51.100.76 へ変わり、接続記録にそのリクエストが PROXY に一致して「シンガポール 02」へ渡されたと表示されれば、ブラウザーの通信はClashに入っています。これらのアドレスは判定方法を説明するための例です。

コマンドラインで直接接続とプロキシ接続を比較する

Windows 11、macOS、一般的なLinuxディストリビューションでは通常 curl を使用できます。ローカルの混合ポートが 7890 の場合は、次のように実行します。

curl https://api.ipify.org
curl -x http://127.0.0.1:7890 https://api.ipify.org

1つ目のコマンドは現在のシステムとターミナル環境からアクセスし、2つ目はClashのHTTPプロキシを明示的に指定します。返されたIPが異なれば、ローカルプロキシポートがリクエストを転送できています。ブラウザーだけ元のIPを表示する場合は、ノードを何度も変更するのではなく、システムプロキシまたはブラウザー側の設定を確認してください。

接続記録も同時に確認する

クライアントの「接続」ページを開きます。正常なリクエストには通常、ホスト名、送信元アドレス、アップロード・ダウンロード量、適用ルール、ポリシーチェーン、最終ノードが表示されます。接続を1件クリックすると、DIRECT、REJECT、または特定のプロキシノードのどれを経由したか確認できます。

IP確認ページが DIRECT に一致する場合は、まずグローバルモードに切り替えて比較します。グローバルモードで出口が変わるなら、ノードとシステムプロキシは利用可能で、問題はルールまたはポリシーグループにあります。グローバルモードでも接続記録が出ない場合は、通信が現在のClashインスタンスに入っていません。

システムプロキシが効かない場合にTUNモードを有効にする

TUNモードはmihomoが仮想ネットワークインターフェースを作成し、ネットワーク層で通信を受け取る機能です。システムプロキシを読み取らないプログラムや、より多くのUDP通信に適しています。初回接続で全機能を同時に有効にする必要はありません。まず通常のシステムプロキシを確認し、必要なアプリに応じてTUNを有効にすると、トラブル対処が容易になります。

TUNを有効にする順序

1. 「設定」→「Clash設定」→「TUNモード」を開きます。
2. クライアントの案内に従ってサービスモードをインストールまたは有効にします。Windowsでは初回インストールに管理者権限が必要になることがあります。
3. TUNを有効にしたら仮想インターフェースが作成されるまで待ち、その後IP確認ページへアクセスします。
4. 「接続」と「ログ」を確認し、対象アプリのリクエストが記録されていることを確認します。
5. ネットワークに異常が出たら、まずTUNを無効にしてネットワークが復旧するか確認し、その後DNSとルーティング設定を確認します。

mihomoのTUNはDNSハイジャック、自動ルート、厳格ルートと組み合わせて使うことがよくあります。クライアントによって、これらのパラメーターはスイッチとしてまとめられています。初めて使う場合、設定の出所を理解しないままインターフェース名、MTU、ルートテーブル、DNS待受ポートを同時に変更することはおすすめしません。

DNSの問題かどうかを判断する

特定のIPにはアクセスできるのにドメイン名ではサイトを開けない、またはログに名前解決エラーが繰り返し表示される場合は、DNSに問題がある可能性があります。Fake-IPモードでは、DNSモジュールがまずマッピングアドレスを返し、カーネルが元のドメイン名に基づいてルールを照合します。198.18.0.0/16 の範囲のマッピングアドレスが表示されても、対象サイトが実際にそのネットワークにあるとは限りません。

まずクライアントにあるDNSキャッシュ削除機能を1回実行するか、カーネルを再起動してから再テストします。Windowsではターミナルで ipconfig /flushdns を実行してシステムキャッシュを削除することもできます。特定のドメインだけ失敗する場合は、すべての通信を直接グローバルに変更するのではなく、接続ログで一致したルールとDNSの応答結果を確認してください。

Clash初回接続に失敗したときの早見表

接続完了と判断する最低限の基準

• 現在の設定が選択され、更新時に形式エラーが返されていない。
• mihomoカーネルが安定して動作し、ローカル待受ポートが確立している。
• 少なくとも1つのノードで3回連続してタイムアウトせず、遅延の変動が許容範囲に収まっている。
• 実際の振り分けに使われるポリシーグループが、そのノードを選択しており、DIRECT ではない。
• ブラウザーのリクエストが「接続」ページに表示され、最終的に使用されたノードが確認できる。
• 独立した2つのIP確認結果が、プロキシ無効時の結果と異なる。

この6項目を満たせば、初回接続は完了です。その後、自動速度テスト、ポリシーグループの細分化、ルール調整、サブスクリプションの自動更新、TUNの常時有効化などの上級設定に進みましょう。変更は毎回1つだけにし、接続記録と出口IPで結果を確認すると、問題をより早く特定できます。