Clashの初回接続ガイド｜ノードの選び方・遅延測定・プロキシ接続の確認

初回接続のポイント：安定したノードを選び、実際の通信で確認する

初回接続では、ノード一覧から最も遅延の小さいものを探す必要はありません。まず、現在のルールで使われるプロキシグループから、テストが連続して成功し、アクセスしたいWebページも開けるノードを選びます。次に接続履歴で、そのノードが実際のリクエストに使われたことを確認します。最後に出口IPを調べ、外部サイトから見える接続元を確認しましょう。3つの結果が一致すれば、遅延の数値が緑色で表示されているだけの場合より確実です。

この記事は、Clash または Clash Meta（mihomo）コアを使う一般的なクライアントを対象としています。クライアントによって日本語訳や画面構成が異なるため、機能の場所は Profiles、Proxies、Connections、Logs などの画面名で説明します。特定クライアントのスイッチ位置を共通仕様として扱うことはありません。すでに TUN や社内ネットワークの設定を使っている場合は、現在の状態を記録し、ルートを削除したりセキュリティソフトを無効にしたりしないでください。

1. サブスクリプション追加後に設定とプロキシグループを確認する

サブスクリプションを追加しても、ノードが使われているとは限らない

サブスクリプションにはノードやルールなどの設定が含まれ、クライアントが設定を読み込み、コアが接続を処理します。ノードが一覧に表示されるのは、ノード情報が読み込まれたことを示すだけです。古い設定が有効なままだったり、実際のルールが別のプロキシグループを参照していたりすると、遅延テストを実行してもWebサイトの出口は変わりません。

Profiles（設定）を開き、新しく追加した設定が有効になっていることを確認します。サブスクリプションの更新日時や、解析失敗・ダウンロード失敗などの表示も確認してください。
Proxies（プロキシ）を開き、動作モードを Rule（ルール）に設定します。Global（グローバル）は通常、通信をグローバルプロキシグループに送ります。Direct（直結）ではノード経由のプロキシ接続を確認できません。
ルールが実際に参照している選択グループを探します。プロキシグループが階層化されている場合は、選択項目をたどって最終的なノードを確認してください。「自動選択」の段階で止めないようにしましょう。
初回の診断では、ノードを手動で固定できる select グループを使うのがおすすめです。自動選択グループはヘルスチェックで切り替わることがあり、前後のテストで同じ出口を比較できなくなる場合があります。

たとえば、ルールが最終的に「プロキシ選択」を参照していて、そのグループで DIRECT が選ばれている場合、別のノードが 80 ms と表示されていても、ルールの通信が自動的にそのノード経由になるわけではありません。設定に手動選択グループがない場合は、サブスクリプション全体をむやみに書き換えないでください。まず自動選択グループで現在選ばれているノードを記録し、接続の詳細から実際の経路を確認します。

通信の取り込み設定とローカル待受ポートを確認する

ブラウザーで確認する準備として、クライアントのシステムプロキシを有効にし、ブラウザーがシステムのプロキシ設定を使っていることを確認します。ブラウザー拡張機能、個別のプロキシ設定、別のVPNによって経路が変わることがあります。ターミナルのプログラムはシステムプロキシを参照しない場合があるため、後半ではプロキシを明示するコマンドで個別に確認します。

ローカルアドレスは通常 127.0.0.1 ですが、ポートは実際の設定に合わせてください。以下はポートの意味を示す例にすぎず、接続可能な設定一式ではありません。ノードやサブスクリプションも含まれていません。

# 設定例：サブスクリプション全体を上書きしない
mixed-port: 7890
allow-lan: false
mode: rule

mixed-port: 7890 は、この待受ポートで HTTP と SOCKS の両方のプロキシリクエストを受け付けることを示します。設定によっては port と socks-port を個別に使います。コントロール用ポートをプロキシポートと間違えないでください。また、例に 7890 と書かれていても、正常に動作している待受設定を変更する必要はありません。

2. ノードの遅延テストで測定しているものと、比較方法

クライアントで表示されるノードの遅延は、通常、そのノード経由で指定されたテストURLにアクセスするまでの時間です。OSの ICMP ping やダウンロード速度とは異なります。テスト先、DNS、接続の再利用、ノードの負荷、クライアントの実装によって結果が変わるため、異なるクライアントの数値を共通の基準として直接比較することはできません。

設定によっては、接続テスト先に https://www.gstatic.com/generate_204 を使います。このURLへのアクセスが特定の回線で制限されていると、ノードがタイムアウトと表示されても、ほかのサイトには接続できることがあります。反対に、テストURLへの接続に成功しても、目的の動画サイト、業務システム、ゲームサービスが必ず使えるとは限りません。

表示結果	判断できること	次に行うこと
数値が連続して返る	テスト先にノード経由で接続でき、現在のテスト経路が応答している	実際の対象サイトにアクセスし、プロキシチェーンを確認する
遅延は小さいのにWebページの表示が遅い	短いリクエストが速くても、転送速度や対象サイトの応答が速いとは限らない	対象サイト、帯域幅、パケットロス、混雑時の負荷を確認する
ときどきタイムアウトする	テストが不安定な可能性がある。テスト先が制限されている場合もある	時間を空けてテストし、別のノードと実際のWebページを比較する
すべてタイムアウトする	共通の障害が起きている可能性があり、すべてのノードが使えないとは限らない	ローカルのネット接続、サブスクリプションの状態、DNS、エラーログを確認する

1回の順位ではなく、3回の結果で比較する

候補を2～3個に絞り、100個以上のノードへ一斉にテストを送って現在のネットワークに余計な負荷をかけないようにします。
ネットワークとテスト先を同じにして、約10秒間隔で1回ずつ、合計3回テストします。
タイムアウトの有無と数値の変動を記録し、同じ対象のWebページにも実際にアクセスします。

以下は判断方法の例であり、本サイトでの実測値ではありません。ノード A は3回の結果が 68、240 ms、タイムアウト、ノード B は 105、112、109 ms でした。初回接続では、Aの最低値だけを見るより、再現性のある基準を作れるBから試すのが適切です。両方のノードが安定している場合は、対象サービスが求める地域に接続でき、実際のアクセスも快適な方を選びましょう。地理的に近くても、通信事業者間の経路が短いとは限りません。

3. ブラウザーで確認する：ページが開くだけではプロキシ経由とは限らない

ブラウザーで確認するときは、実際のネットワークリクエストを使います。すでに開いているページはキャッシュから表示されている可能性があり、一部のリソースは Service Worker が返している場合もあります。ページが表示されているだけでは、新しい設定が有効になった証拠にはなりません。開発者ツールの Network（ネットワーク）パネルで Disable cache（キャッシュを無効化）を一時的にオンにし、開発者ツールを開いたまま再読み込みして、テスト時刻を記録してください。

実際にアクセスする必要のあるドメインを1つ選び、無関係なタブを閉じてバックグラウンドの通信を減らします。
ブラウザーの設定を開き、システムプロキシを使う設定になっていることを確認します。プロキシ拡張機能を使っている場合は、現在の状態を記録してから一時的に無効にし、設定の上書きを防いでください。
対象のWebページを再読み込みし、メインドキュメントから実際に応答が返ったか、プロキシ接続エラーや証明書エラーが発生していないかを確認します。
すぐにクライアントの Connections（接続）画面に戻り、ドメイン名または時刻で直前のリクエストを探します。

ブラウザーでページが開くことは機能確認の一部ですが、開けないからといってノードの障害とは限りません。プロキシチェーンに一致していて、ほかのサイトには正常に接続できる場合は、対象サイトの障害、地域制限、アカウントの状態、DNSの結果をそれぞれ確認してください。

4. 接続履歴とログでルール・プロキシグループ・ノードを確認する

Connections と Logs は役割が異なります。前者はリクエストの経路確認に、後者はハンドシェイク失敗、名前解決失敗、接続拒否などの原因特定に適しています。クライアントによって表示項目は異なりますが、対象のドメイン名またはIPアドレス、適用されたルール、最終的なプロキシチェーンの3点は確認してください。

対象：記録が直前にアクセスしたドメインのものか確認します。ブラウザーのテレメトリーや別のバックグラウンドアプリの通信と取り違えないでください。
ルール：ドメインルール、ルールセット、最後の MATCH など、適用されたルールの種類と内容を確認します。
プロキシチェーン：プロキシグループの最終的な接続先が選択したノードであり、DIRECT、REJECT、別の自動選択グループではないことを確認します。
通信量：アップロード・ダウンロードのバイト数が増えていれば、接続中の通信を確認する手がかりになります。ただし、バイト数が増えたことだけでは対象ページの読み込み完了を保証できません。

接続画面にアクティブな接続しか表示されない場合、短いリクエストは一瞬で消えることがあります。先に接続画面を開いてからWebページを再読み込みするか、クライアントが対応している接続履歴を使ってください。Logs 画面では一時的に info レベルに切り替えて経路を確認できます。それでも情報が足りない場合は、短時間だけ debug を有効にし、調査後に元へ戻してください。ログが大量に蓄積し続けるのを防げます。

結果に応じて切り分け、一度に複数の項目を変更しない

該当する記録がない：通信がコアに届いているか、ブラウザーがプロキシを迂回していないか、リクエストがキャッシュから返されていないかを優先して確認します。
記録はあるが DIRECT に一致：ルールの順序とプロキシグループの選択を確認します。ルールは通常、上から順に評価され、先に一致したルールで経路が決まることがあります。
ノードに一致するが接続できない：エラー内容から、ノードサーバーへの到達不能、認証失敗、TLSの問題、対象への接続タイムアウトを切り分けます。
ノードを切り替えても出口が変わらない：既存の長時間接続が以前の経路を使い続けている可能性があります。対象のタブを閉じるか、関連する接続だけを終了してから新しいリクエストを送ってください。ほかの通信を止めないよう、すべての接続を一括で切断するのは避けましょう。

スクリーンショットやログを共有する前に、サブスクリプションURL、トークン、ノードサーバーのアドレス、個人のネットワーク情報を隠してください。サブスクリプションURLにはアクセス認証情報が含まれることが多いため、公開の掲示板にそのまま貼り付けないでください。

5. 出口IPとプロキシを明示したコマンドで相互確認する

出口IPは、確認サービスから見えるリクエスト元のIPアドレスです。自宅回線の出口とノードの出口を区別するのに役立ちますが、IPの位置情報データベースは更新が遅れることがあり、同じノードでも複数の出口を使う場合があります。接続履歴と合わせて判断し、都市名だけで経路の問題と決めつけないでください。

直結とプロキシ接続を同じ条件で比較する

個人のネットワークで可能な場合は、プロキシと TUN を無効にし、ほかのVPNにも通信を取り込まれていない状態で出口を記録します。その後、プロキシを有効にして同じサービスで再確認してください。TUN や別のシステムレベルのトンネルが動作したままだと、HTTPプロキシを使わないリクエストも引き続き取り込まれることがあり、直結時の基準として使えません。

以下では、HTTPプロキシに対応したローカルの 127.0.0.1:7890 を例にします。実際のポートが一致する場合に限り、そのまま実行してください。これらのコマンドはシステム設定を変更しません。Windows PowerShell では、環境によって curl が別のコマンドとして解釈される場合があるため、curl.exe と入力してください。

# curlで明示的なプロキシを使わない設定。TUNを迂回できるという意味ではありません
curl --noproxy "*" --connect-timeout 10 --max-time 20 https://api.ipify.org

# 指定したHTTPプロキシポートを必ず経由して同じ確認サービスにアクセスする
curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 https://api.ipify.org

--noproxy "" は、今回のリクエストでプロキシを迂回するリストを空にし、既存の NO_PROXY 設定の影響を避けるために使います。確認サービス自体に接続できない場合は、信頼できる別の出口確認サービスを使ってください。サービスが1つタイムアウトしただけで回線全体の障害と判断するべきではありません。公開IPを調べると、接続先のサービスに今回の通信の出口アドレスが知られます。

実際の HTTPS リクエストと所要時間を確認する

curl --noproxy "" --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --output /dev/null --write-out "HTTP=%{http_code} total=%{time_total}s\n" https://example.com/

macOS と Linux では上記の /dev/null を使えます。Windows では NUL に置き換え、curl.exe を使用してください。例のドメイン名はコマンドの構成を示すためのものです。業務上のトラブルシューティングでは、実際の接続先に置き換えてください。HTTP 200 は、そのリクエストが正常な応答を受け取ったことを示すだけで、すべてのWebサイトにアクセスできる保証ではありません。403 や 429 の場合も、プロキシ経由でサイトに到達したうえで、サイト側のポリシーにより拒否されている可能性があります。

time_total は応答の転送時間を含むリクエスト全体の所要時間です。クライアントのノード遅延テストと同じ指標ではありません。プロキシを明示したコマンドは成功するのにブラウザーでは失敗する場合は、ブラウザーのプロキシ設定とルールの違いを優先して確認します。コマンドで 127.0.0.1:7890 に接続できないと表示された場合は、まずコアの動作状態とポートを確認し、すぐにリモートノードを変更しないでください。

6. 初回接続でよくある結果と対処の順序

遅延は測定できるのに対象のWebページが開かない

まず、そのWebページの通信がテストしたノードを経由しているか確認し、次にDNSエラー、接続タイムアウト、HTTPによる拒否を切り分けます。テスト先と実際の対象サイトが異なるため、テストサーバーへの経路が正常でも、すべての接続先で問題がないとは限りません。特定のドメインだけで問題が起きる場合は、別のノードと比較し、ブラウザー、ルール、テスト時間を同じ条件にそろえてください。

ブラウザーはプロキシ経由だが、ターミナルの出口が変わらない

システムプロキシは通常、すべてのデバイス通信を強制的に取り込むものではありません。多くのコマンドラインツールでは環境変数や専用のプロキシ引数が必要です。まずは上記の --proxy を使って明示的に確認してください。システムプロキシに従わないプログラムの通信も取り込む必要がある場合に限り、TUN の利用を検討します。TUN はルーティング、DNS、権限、ほかのVPNとの互換性に関わるため、初回の遅延テストと同時に有効にするのは避けてください。

出口IPは変わったが、想定した地域ではない

確認リクエストのプロキシチェーンを調べ、自動選択グループを誤って選んでいないか、古い接続が再利用されていないかを確認します。次に、IPv4 と IPv6 で異なる経路を使っていないか調べます。デュアルスタックネットワークでは、対応するアドレスファミリーの確認サービスをそれぞれ使ってテストしてください。1回の検索結果に表示された地域名だけでは、すべての通信の出口を判断できません。

すべてのノードがタイムアウトする

「ローカルでインターネットに接続できるか → コアが動作しているか → サブスクリプションが有効か → テスト先に接続できるか → ログにDNSまたは認証エラーがあるか」の順に確認します。同じネットワーク上のほかのデバイスでも同じ問題が起きる場合は、クライアントを何度も再インストールするのではなく、共通する条件を優先して調べてください。

初回接続の確認基準は明確です。対象のWebページから正常な応答があり、接続の詳細に想定どおりのルールとノードが表示され、出口IPもプロキシチェーンと一致すること。この3つを確認してから、自動選択、アプリごとのルール振り分け、TUN の適用範囲を検討しましょう。遅延の最小値を追い続けるより、その後のトラブルシューティングが容易になります。