Clashの初回接続を確認する方法：ノードを選択し、遅延を測定して出口IPを確認するまで

1. 設定の読み込みを確認する：サブスクリプションの登録だけでは不十分

サブスクリプションが一覧に表示されても、接続中とは限りません。初回接続では、使用する設定が選択されていること、プロキシコアが起動していること、設定内のプロキシグループが読み込まれていることを確認します。Clashは設定とコアからなるエコシステムの総称で、Clash Verge RevなどのクライアントがGUIを提供し、mihomoが設定の解析、プロキシ接続の確立、ルールの適用を担います。画面上のボタンの位置はクライアントによって異なりますが、確認すべき点は共通です。

1. クライアントの「サブスクリプション」または「設定」画面を開き、追加した設定を選択して、現在使用中の表示があることを確認します。
2. 「プロキシ」画面を開き、サブスクリプション名だけでなく、プロキシグループと選択可能なノードが表示されているか確認します。
3. 「ログ」画面を開き、設定の解析失敗、未対応のプロキシ種別、待ち受けポートの競合などのエラーが繰り返し出ていないか確認します。

サブスクリプションの更新に成功したのにプロキシ画面にノードが表示されない場合は、取得した内容がクライアント対応の設定形式か確認してください。完全なClash YAML設定と、Base64形式のノードリンク一覧は別の入力形式です。ダウンロード可能なURLでも、ログイン画面やエラーメッセージが返されることがあります。設定が読み込まれる前にシステムプロキシを何度も切り替えるのは避けましょう。

2. 実際に接続に使うノードを選ぶ

「プロキシ」画面を開いたら、まずルールが参照するメインのプロキシグループを探します。「プロキシ選択」「PROXY」など、グループ名は設定の作成者によって異なり、ソフトウェア共通のメニュー名ではありません。ネストされたグループでノードを選択しても、実際の通信で使われるとは限りません。上位グループが別の自動選択グループを参照していたり、アクセス先に専用のプロキシグループが割り当てられていたりする場合があります。

初回テストでは手動選択で条件を絞る

• 手動選択できるプロキシグループで、実際のノードを1つ選びます。候補が別のグループなら、そのグループをたどって最終的にどのノードが選ばれるか確認してください。
• DIRECTとREJECTは避けましょう。前者は直接接続、後者は接続拒否を意味し、どちらもリモートのプロキシノードではありません。
• プロバイダーが利用可能と明記している、地理的にも適した経路を優先します。ノード名に含まれる地域名はあくまで目安です。実際の出口は後で確認してください。
• 初回テストではプロキシクライアントを1つだけ起動し、ほかのVPNやプロキシツールはいったん終了します。システムプロキシの設定が競合するのを防げます。

url-testの自動選択グループでは、ノードをクリックしても一時的な選択にとどまることがあり、クライアントの動作や設定にも左右されます。最終的にどのノードが使われているかは、ノード横の選択アイコンだけで判断せず、接続画面に表示される実際のプロキシチェーンを確認してください。

3. 遅延の数値が示すもの

ノード一覧の遅延は通常、そのノード経由で指定のテストURLにアクセスするのにかかった時間です。サーバーへのICMP pingと同じものではありません。測定結果はローカルネットワーク、プロキシのハンドシェイク、テスト先、サーバー負荷、キャッシュ状態などの影響を受けます。クライアントやテスト先が異なる数値は、単純に比較できない場合があります。

表の数値は読み方を示す例で、実際の回線速度ランキングではありません。約5秒間隔で3回連続して測定し、安定して完了し、変動が小さいノードを優先しましょう。1回目が45 msで残り2回がタイムアウトするノードより、3回とも100 ms前後で安定するノードのほうが、普段使いに適している場合があります。

速度テストに成功しても、実際のサイトで確認する

テストURLはHTTP 204のような、ごく小さなレスポンスを返すだけの場合があります。基本的なリクエスト経路の確認には使えますが、動画の転送速度、アカウントの地域判定、目的のサイトへのアクセス確認の代わりにはなりません。一方、テスト先が制限されていると遅延テストに失敗しても、実際のサイトにはアクセスできることがあります。その場合は表示色だけで判断せず、ログに記録された接続先とエラーの種類を確認してください。

4. システムプロキシを有効にして、最小限の経路で確認する

初回確認ではシステムプロキシを使い、システムプロキシ設定に従うブラウザーからClashへ接続する方法がおすすめです。最初からTUNを併用するのは避けましょう。TUNは仮想ネットワークインターフェースを通じて通信を取り込み、ルーティング、DNS、権限の設定も関わるため、基本的な接続を確認した後に必要に応じて設定します。モバイル端末は通常、システムのVPNインターフェースを使って通信を取り込むため、デスクトップのシステムプロキシを有効にする手順とは異なります。

1. デスクトップクライアントのメイン画面で「システムプロキシ」を有効にし、コアが引き続き動作中であることを確認します。
2. クライアントのポート設定を開き、HTTPポートまたは混合ポートを確認します。ここでは例として7890を使います。実際のポートは画面の表示に従ってください。
3. macOSでは「システム設定」→「ネットワーク」→現在のネットワークサービス→「詳細」→「プロキシ」で確認できます。Windows 11では「設定」→「ネットワークとインターネット」→「プロキシ」で確認してください。
4. ブラウザー拡張機能で別のプロキシを設定している場合は、いったん無効にするか、システム設定に従うようにしてから、新しいタブでテストします。

普段使いにはルールモードが適しています。プロキシルールに一致したリクエストだけがプロキシ経由になります。ルールの影響を切り分けるには、一時的にグローバルモードへ切り替え、グローバル用のプロキシグループでテストノードを明示的に選びます。確認後はルールモードに戻してください。グローバルモードで変わるのはコアに届いた通信の経路選択です。すべてのアプリを自動的に取り込むわけではなく、もともとClashを通らない接続がコアに入るようになるわけでもありません。

5. 出口IPと接続画面で相互に確認する

出口IPの確認には比較できる条件が必要です。見慣れないIPアドレスが表示されただけでは、選択したノードを通った証拠にはなりません。元のIPアドレスが表示されても、検出サイトのドメインがルールで直接接続に設定されている可能性があり、プロキシの不具合とは限りません。確実に確認するには、モード、接続先ドメイン、適用ルール、プロキシチェーンをあわせて記録します。

次の順番で比較する

1. 直接接続のテストが許可されているネットワーク環境でシステムプロキシを無効にし、TUNやほかのVPNも通信を取り込んでいないことを確認します。同じIP確認サービスを使って、基準となるアドレスを記録します。すでに基準値がある場合は省略できます。
2. システムプロキシを有効にし、一時的にグローバルモードへ切り替えてノードを選び、もう一度確認します。ブラウザーのアドレスバーでhttps://api.ipify.orgを開くと、グローバルIPv4アドレスを確認できます。
3. すぐにクライアントの「接続」画面を開き、api.ipify.orgを検索して、接続先、ルール、プロキシチェーン、通信量を確認します。リクエストはすぐに終了することがあるため、事前に画面を開き、切断済み接続の記録も確認してください。
4. ルールモードに戻してもう一度確認します。結果が変わった場合は、該当ドメインにDIRECTが適用されたか、別のプロキシグループに振り分けられたかを確認してください。

接続が有効であることを示す主な証拠は、確認リクエストが接続画面に記録され、プロキシチェーンに想定したノードが含まれ、サービスからその経路に対応したグローバルIPアドレスが返されていることです。基準値と異なるアドレスは有用な手がかりですが、それだけが判断材料ではありません。複数のノードが同じ出口IPを共有する場合もあります。IP情報データベースの国、都市、通信事業者の情報は更新が遅れることがあるため、都市名だけで経路の誤りを判断しないでください。

IPv4とIPv6も区別する必要があります。IPv4の確認だけではIPv6の経路はわかりません。異なるIPアドレスファミリーを使う2つの確認サイトで、異なるアドレスが表示されることもあります。IPv6を確認する場合は、IPv6対応の接続先を個別にテストし、接続記録、クライアントの通信取り込み範囲、DNS設定を照らし合わせてください。

6. コマンドラインでローカルポートの問題を切り分ける

ブラウザーでの結果がはっきりしない場合は、curlからローカルのHTTPポートまたは混合ポートを明示して接続できます。ブラウザー拡張機能やシステムプロキシ設定を経由せずに確認できます。以下の127.0.0.1:7890は例です。クライアントに混合ポートとして7897と表示されている場合は、コマンドのポートを7897に変更してください。SOCKS専用ポートをHTTPプロキシとして使わないでください。

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

Windows PowerShellではcurl.exeを使って同じオプションを実行すると、古い環境でのコマンドエイリアスの違いを避けられます。このコマンドはプロキシの接続先を明示しますが、コアに入った後のリクエストには現在のルールモードが適用されます。ルールによる直接接続を除外するには、前述の一時的なグローバルモードでテストし、接続画面も確認してください。

• Failed to connect：まずコアの起動状態、ローカルの待ち受けポート、アドレスが正しいか確認し、リクエストがローカルプロキシに到達しているかを調べます。
• 約20秒後にタイムアウトする：今回の制限時間内に処理が完了しなかったことを示します。コアのログでリモート接続、DNS、TLSに関するエラーを確認してください。
• IPアドレスは返るがブラウザーでは接続できない：まずブラウザー固有のプロキシ設定、拡張機能、古い接続を確認します。この場合、少なくとも今回のコマンドラインリクエストはローカルプロキシポートで処理できています。

証明書検証を無効にする方法を、通常の解決策として使わないでください。証明書の時刻に関するエラーが出る場合は、まずOSの日付、タイムゾーン、自動時刻設定を確認します。特定のサイトだけ失敗する場合は、そのサイトの証明書や経路を調べ、ブラウザー全体のセキュリティ設定を安易に下げないでください。

7. よくある結果と確認手順

各回で変更する条件は1つだけにします。たとえばノードを固定したままルールモードとグローバルモードを切り替え、次にモードを固定したまま別のノードに変更します。DNS、TUN、ポート、ノードを同時に変えて接続が復旧しても、どの層に原因があったのか特定しにくくなります。

8. 初回接続後に記録しておくこと

接続を確認できたら、長期利用するルールモードに戻し、直接接続されるはずのサイトとプロキシ経由になるはずのサイトを1つずつ開いて、接続記録を確認します。直接接続のリクエストがDIRECT、プロキシ経由のリクエストが想定したプロキシチェーンになっていれば、設定の意図どおりに振り分けられています。両方のサイトが開けるだけでは、ルールが正しいとは確認できません。

• クライアント名、コア名、使用中の設定名、ローカルの待ち受けポートを記録します。
• テストしたドメイン、モード、最終的に選択されたノード、出口IP、テスト日時を記録しておくと、後で比較できます。
• TUNは必要な場合に個別に有効にし、対象サイトへの接続と出口IPを再確認します。既存のVPNや仮想ネットワークアダプターとの競合も確認してください。
• 後日問題が起きた場合は、まずこの最小限の確認手順を再現してから、アプリ固有の設定を調べます。

初回接続で重視するのは、最小の遅延を記録することではありません。設定が読み込まれている、ノードに接続できる、リクエストがコアに届く、正しいルールが適用される、接続先のサービスが応答するという、繰り返し確認できる証拠をそろえることです。各項目を個別に確認しておけば、サブスクリプションやクライアントを変更した後も同じ手順を使えます。