Clashの初回接続ガイド：ノード選び・遅延テスト・プロキシ経由の確認

まず結論：ノードに数値が表示されても、アプリがプロキシ経由とは限らない

初回の確認は、設定が有効か確かめ、使えるノードを選び、システムプロキシを有効にしてから、新しいリクエストの接続記録を確認する順で進めましょう。出口IPの確認は最後です。TUNの有効化、DNSの変更、ルールの編集、ノードの切り替えを同時に行うと、ページが表示されても何が効いたのか判断しにくくなります。

Clashは、クライアントやコアのエコシステムを指す一般的な呼び名です。mihomoコアを使うクライアントは、画面のボタンや機能の細部が異なる場合がありますが、確認すべき点は共通しています。サブスクリプションがノードとルールを提供し、プロキシグループが使用するノードを決め、通信の入口がアプリのリクエストをコアに届けます。サブスクリプションの読み込みに成功しても、この3つがすべて機能しているとは限りません。

1. 設定が有効になっていることを確認します。サブスクリプション一覧に名前が表示されるだけでは不十分です。現在の実行設定が、読み込んだ設定になっているかも確認してください。
2. 動作モードをルールモードに設定します。初回確認では既存のルールを維持し、すべての通信を強制的にプロキシへ流さないようにします。
3. 実際に使われているプロキシグループでノードを選びます。ルールの振り分け先が「海外サイト」や「ストリーミング」など複数のグループに分かれている場合があります。参照されていないグループだけを変更しても効果はありません。
4. システムプロキシを有効にし、新しいリクエストを送信します。接続画面を開いたままにして、リクエストがコアに届いた後の経路を確認します。

遅延テストで測定されるもの：条件をそろえてノードを比較

ノード一覧に表示されるミリ秒数は、多くの場合、コアがそのノード経由で指定URLにリクエストを送るのにかかった時間です。ICMP pingの値やダウンロード速度と同じではありません。接続確立、プロキシプロトコルのハンドシェイク、TLSネゴシエーション、HTTP応答待ちなどが含まれる場合があります。計測範囲はコアやテストの実装によって異なります。

同じグループを比較するなら、テスト条件をそろえる

クライアントの遅延テスト設定、または設定内の url-test プロキシグループを確認します。よく使われるテスト先は、HTTP 204を返すURLです。たとえば https://www.gstatic.com/generate_204 があります。テスト先によってネットワーク上の位置や到達性が異なるため、あるURLで測った80ミリ秒と、別のURLで測った120ミリ秒をそのまま順位付けすることはできません。

• テスト先を固定：比較中は同じURLを使い、途中で別のサイトに変更しないでください。
• 3回に分けてテスト：たとえば各回の間隔を10秒にして、連続した結果を記録します。これは手動で傾向を見る方法であり、コアのタイマー設定を変更する必要はありません。
• 大容量通信は一時停止：ダウンロード、クラウドストレージの同期、システム更新はローカル回線を使うため、結果に影響します。
• ネットワーク環境を記録：同じノードでも、自宅のWi-Fi、スマートフォンのテザリング、職場のネットワークでは結果が大きく異なることがあります。

表の数値は読み方を説明するための仮例であり、当サイトが特定のサービスを実測して順位付けしたものではありません。3回の結果はノード選びの参考になりますが、長期的なパケット損失率の算出や、混雑時間帯の品質保証には使えません。

タイムアウトしても、ノードが完全に使えないとは限らない

テスト先への接続がブロックされている、名前解決に失敗している、ノードの認証情報が無効になっている、ローカルネットワークが切断されているなど、さまざまな原因でタイムアウトが発生します。すべてのノードが同時にタイムアウトする場合は、まずネットワークとテストURLを確認してください。特定のノードだけ失敗し続ける場合は、別のノードと比較します。テストに成功しても目的のサイトが開かないときは、そのサイト自体への接続を確認してください。204が返っただけで、すべてのサイトにアクセスできるとは限りません。

用途に合わせてノードを選ぶ：遅延・安定性・出口地域を分けて確認

まず、複数回のテストで応答が安定しているノードを選び、実際の用途に合わせて絞り込みましょう。ノード名に含まれる地域名、倍率、「専用回線」などの表記は、プロバイダー側のラベルです。出口の確認に代わるものではなく、回線品質を保証するものでもありません。クライアントに低遅延と表示されても、特定サイトの地域制限やアカウントの利用可否が保証されるわけではありません。

• ウェブ閲覧・オンライン文書：ページを最初に開くときの速さや、続けて操作したときにエラーが出ないかを確認します。ときどき速くても頻繁にタイムアウトするノードより、遅延が中程度でも安定したノードのほうが使いやすいでしょう。
• 動画再生・ファイル転送：実際のバッファリング状況と、長時間の転送速度を確認します。短時間のリクエストテストでは、長時間転送時の性能はわかりません。ダウンロードテストの前に、通信量の上限や課金条件を確認してください。
• 会議・リアルタイム通信：ジッター、パケット損失、UDP対応、アプリの通信がプロキシに入っているかも確認します。HTTPテストに成功しても、音声通話が使えるとは限りません。
• 特定地域が必要なサービス：出口地域、サイトのルール、サービス独自の利用条件をあわせて確認します。IPデータベースが示す国と、サイト側の判定が異なることがあります。

初回の確認では、ノードを1つ手動で固定する

url-test はテスト結果に応じて経路を自動選択し、fallback グループは通常、設定順に利用可能な項目を選択します。手動選択グループでは、ユーザーがノードを指定します。自動選択が切り替わると、前後のリクエストが異なる出口を使うことがあります。結果を再現しやすくするには、設定で可能な場合、確認中だけ該当する選択グループを同じノードに固定し、終了後に自動選択へ戻します。

プロキシグループが入れ子になっていないかも確認してください。たとえば「海外サイト」が「自動選択」を選び、その「自動選択」が具体的なノードを選ぶ構成があります。画面に表示される外側のグループ名が最終的な出口とは限りません。後ほど接続の詳細で選択経路を確認します。

確認方法1：接続画面で対象ドメインとプロキシ経路を確認

接続画面は、通信経路を確認するうえで最も直接的な手がかりです。クライアントで「接続」または「Connections」と表示される画面を開いたまま、ブラウザーで対象サイトにアクセスします。メニュー名はクライアントによって異なります。ノードの遅延一覧ではなく、接続先、通信量、ルールが表示されるアクティブな接続一覧を探してください。

1. ほかのダウンロードを一時停止し、接続一覧で対象ドメインを検索します。
2. 新しいページまたはシークレットウィンドウを開いて、実際にリクエストを送信します。キャッシュ済みのページを見るだけでは、新しい接続が発生しないことがあります。
3. 新しく追加された記録を開き、対象ドメインまたはIP、適用ルール、プロキシ経路、送受信バイト数を確認します。
4. プロキシ経路の最終接続先が意図したノードであり、DIRECT や REJECT ではないことを確認します。

DIRECT が適用されている場合、リクエストはコアに届いていますが、ルールによって直接接続されています。これは「ブラウザーがClashを経由していない」場合とは別の問題です。前者ではルールの順序やプロキシグループの接続先を確認し、後者ではシステムプロキシ、ブラウザー拡張機能、アプリ独自のプロキシ設定、TUNのルーティングを確認します。

1つのウェブページが1つの接続だけで構成されているとは限りません。メインページ、画像、ログインAPI、動画でドメインが異なり、適用されるルールも別々になることがあります。メインサイトのドメインだけを確認しても、動画が再生できない理由はわかりません。再生に失敗したリソースのリクエストも確認してください。

確認方法2：ログで入口・ルール・上流のエラーを切り分ける

接続画面では経路を、ログでは処理の流れを確認できます。まずログレベルを info にして問題を一度再現してください。情報が足りない場合に限り、短時間だけ debug に上げます。確認後は通常のレベルに戻し、大量の記録で必要な手がかりが埋もれないようにしましょう。

ログの形式はコアのバージョンによって異なるため、まったく同じ英文を探す必要はありません。操作した時刻、対象ドメイン、選択中のノードを記録し、問題を一度だけ再現して同じ時間帯のログを確認するのが効果的です。スクリーンショットを共有する前に、サブスクリプションURL、認証情報、ノードのサーバーアドレス、関係のないアクセス先ドメインを隠してください。

ログにも接続一覧にも該当するリクエストがない場合は、まず確認中のクライアントが実際に動作しているコアか確かめてから、アプリの通信経路を確認します。通信がコアに届いていない段階でサブスクリプションのルールを何度も変更しても、通常は解決しません。

確認方法3：出口IPを照合する。ただし確認サイトだけで判断しない

IP確認サイトでわかるのは、「その確認サービスへのアクセスに使われた出口」です。すべてのアプリが同じノードを経由していることや、すべてのプロトコルがプロキシに取り込まれていることまでは証明できません。ルールモードでは、IP確認サイトへの通信が直接接続され、目的のサイトへの通信だけがプロキシ経由になることがあります。IPの結果は、確認サイトへのリクエストの接続記録とあわせて判断してください。

プロキシを明示するコマンドでブラウザー設定を切り分ける

以下ではWindowsの curl.exe を例に、リクエストをローカルの 7890 ポートへ明示的に送ります。macOSとLinuxでは通常 curl を使い、オプションは同じです。このポートではHTTPプロキシまたは混合プロキシが動作している必要があります。SOCKS専用ポートをそのまま指定することはできません。

curl.exe --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org
curl.exe --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org

1つ目のコマンドはHTTPプロキシを明示し、2つ目はcurlがアプリケーション層のプロキシを使わないようにします。どちらも接続確立のタイムアウトは10秒、全体のタイムアウトは20秒です。IP確認サービスは第三者が運営しており、このアクセスの出口IPを確認できます。結果を公開する必要はありません。

• 明示的なプロキシ接続は成功するが、ブラウザーは失敗する：コマンドで使用した経路は利用できています。ブラウザーの通信経路、拡張機能、関連ドメインのルールを確認してください。
• 接続拒否と表示される：まずクライアントが動作中か、ポート番号が正しいか確認します。リクエストがノード選択まで到達していない可能性があります。
• 2つの出口IPが異なる：それぞれのリクエストで別の出口が使われています。プロキシ経由のリクエストで実際に適用された経路は、接続画面で確認してください。
• 2つの出口IPが同じ：すぐに失敗と判断しないでください。確認サイトのドメインがルールで直接接続されている場合や、TUN、別のVPN、同じパブリックIPが使われている場合があります。

確認サイトのドメインがルールによって実際にプロキシへ振り分けられている場合に限り、ローカルポートへの明示的な接続は、その先もプロキシノードを経由します。ローカルのプロキシポートへ接続できるかと、最終的にリモートの出口を使うかは、別々に判断する必要があります。

ブラウザーは使えるのに他のアプリは接続できない：TUNと個別のプロキシ設定を確認

システムプロキシですべてのプログラムの通信を強制的に取り込めるわけではありません。環境変数を使うターミナルツール、独自のHTTP・SOCKS設定を持つアプリ、システムプロキシを参照しないアプリもあります。ブラウザーは使えるのに他のアプリの接続記録がない場合は、まずそのアプリがプロキシに対応しているかを確認し、そのうえでTUNを有効にするか判断してください。

TUNは通信を取り込む範囲を広げる機能であり、遅延を改善するスイッチではない

TUNは仮想ネットワークインターフェースとルートを使って、より多くの通信をコアへ送ります。ただし、実際に動作するかどうかは、管理者権限、サービスの状態、ルーティング設定、DNSの取り込みにも左右されます。ノードが速くなる保証はなく、ルールモードが自動的にグローバルプロキシへ切り替わるわけでもありません。TUN経由でコアに入った通信も、ルールによっては直接接続されます。

1. 元の設定を保存し、DNSモードやサブスクリプションを同時に変更せず、TUNだけを有効にします。
2. 仮想インターフェースの作成に成功したとクライアントに表示されるか、必要な権限やサービスが満たされているかを確認します。
3. 対象アプリを再起動するか既存の接続を切断し、新しいリクエストを送ってから接続画面を確認します。
4. 会社のVPNやほかのトンネルツールと競合する場合は、設定を元に戻してから個別にテストします。システムルートをむやみに削除しないでください。

UDPを使うアプリでは、ノードのプロトコル、サーバー、本体側の設定すべてがUDP転送に対応している必要があります。TUNにアプリの接続が表示されても、HTTPの遅延値だけでゲームや会議の品質は判断できません。アプリにネットワーク統計機能がある場合は、パケット損失とジッターを確認し、プロキシを使わない場合の結果と比較してください。

設定方法や基本用語は、入門ガイドとユーザーマニュアルのプロキシモード解説をご覧ください。安定して使えている接続なら、テストの数値を下げるために複数の設定を一度に変更する必要はありません。

初回接続の確認リスト

次の5項目を確認するほうが、スクリーンショットに小さなミリ秒数が表示されることより重要です。ネットワーク環境、対象ドメイン、ノード名、実際の出口、確認時刻を記録しておくと、次回問題が起きたときに同じ条件で再テストできます。

• 設定：想定したサブスクリプションが動作中で、ノードとルールが読み込まれている。
• ノード：同じテストURLに複数回応答し、実際に使うサイトも正常に開ける。
• 通信の入口：ブラウザーまたは対象アプリの新しいリクエストが接続画面に表示される。
• 経路：想定したルールが適用され、プロキシ経路の最終接続先が選択したノードになっている。意図しない直接接続ではない。
• 出口：IP確認結果と対象リクエストの接続記録が一致し、ほかのアプリは個別に確認している。

いずれかの確認に失敗したら、その段階に絞って調べましょう。接続記録がなければ入口を、接続記録はあるのに直接接続されているならルールを、ノードを選択しても失敗するなら上流を確認します。変更は一度に1つに絞ると、すべてのスイッチを切り替えるより原因を特定しやすくなります。