Clash 初回接続の手順:ノード選択・遅延テストから接続確認まで

サブスクリプションをClashに読み込んだ後、多くの人がノード一覧の前で手が止まります。長い名前のリストに数字が並んでいて、どれを選ぶべきか分からないのです。この記事では、ノード一覧を開くところから、実際にトラフィックがプロキシを通っていることを確認するところまで、最初から最後まで通しで解説します。専門用語を知っていることは前提にしていません。

まずクライアント画面の各エリアを把握する

プラットフォームごとのClashクライアント(Clash Verge、ClashX、Clash for Windowsなど)は細部が異なりますが、基本構造はほぼ共通しており、通常は次の4つに分かれています。

• プロキシ(Proxies):ノード一覧が表示される画面。サブスクリプション内のグループごとに表示され、本記事の中心テーマです。
• ルール(Rules):現在適用されている振り分けルールを表示し、どのトラフィックがプロキシ経由で、どれが直接接続かを決定します。
• 接続(Connections):現在確立されているネットワーク接続をリアルタイムに表示し、プロキシが実際に機能しているか判断する重要な入口です。
• 設定(Settings/General):システムプロキシのON/OFF、TUNモードの切替、ミックスポートなどの基本設定はここにあります。

初めて使う場合は、まず「システムプロキシ」または「TUNモード」のいずれかがオンになっているかを確認してください。ノードを選んでもトラフィックを引き受ける仕組みが有効になっていなければ、ブラウザは依然としてプロキシを経由しません。システムプロキシはOSのHTTP/HTTPSプロキシ設定を通じて機能し、設定が簡単で、大半のWebブラウジングやアプリには十分です。一方TUNモードはネットワーク層で全トラフィックを引き受けるため互換性が高く、システムプロキシ設定を読まないアプリに特に有効ですが、通常は追加の権限承認が必要です。

ポリシーグループの意味を理解してからノードを選ぶ

ノード一覧は単なる平坦なリストではなく、「ポリシーグループ」ごとに整理されています。よくある分類ロジックは次の通りです。

• Proxy / 手動選択グループ:任意の具体的なノードを手動でクリックして選べます。選択後、このグループは固定でそのノードを使い続け、自動で切り替わることはありません。
• Auto / 自動最適選択グループ:クライアントが遅延テストの結果に基づいて現在最適なノードを自動選択し、サブスクリプションで設定された周期で再テスト・切替を行います。
• Fallback / フェイルオーバーグループ:通常はメインノードを使用し、メインノードが利用不能になると自動でバックアップノードに切り替わります。
• Select 分類グループ(「海外ストリーミング」「国内サービス」など、サブスクリプションのルールファイルの設計次第):用途別にトラフィックを異なるポリシーへ振り分け、それぞれ個別にノードを選べます。

初めて使う人にとって最もシンプルな方法は、メインのポリシーグループ(通常はProxy、または配布元が独自に命名したもの)を見つけ、ドロップダウンを開いて、緑色表示または遅延値が低いノードを手動で選ぶことです。まずこのグループが正常に通信できることを確認し、その後自動最適選択に切り替えるかを検討してください。サブスクリプションファイルが用途別に複数のグループへ分割されている場合は、各グループで現在選択中のノードが利用可能かを一通り確認することをお勧めします。ある分類が常に既に無効なノードを指し続けている、という事態を避けられます。

遅延テストを実行し、表示される数値を読み解く

ノード名の右側には通常、ミリ秒(ms)単位の遅延値が表示されます。ノード一覧ページの「テスト」ボタン、または個別ノード右側の更新アイコンをクリックすると、手動で遅延テストを実行できます。この数値を理解する際は次の点に注意してください。

1. テスト対象は遅延測定用のアドレスであり、実際にアクセスしたい特定のサイトではありません。クライアントはあらかじめ設定されたテストアドレス(一般的には安定してアクセスできる特定のドメイン)にリクエストを送り、往復時間を計測します。この値はノードからテストアドレスまでのネットワーク状況を概ね反映しますが、特定のサイトへアクセスする際の実際の速度と完全に一致するわけではありません。
2. 数値の目安:200ms以内であれば概ね快適。200~500msでも利用可能ですが、ページ読み込みや動画バッファリングにわずかな遅れを感じる場合があります。800msを超える、またはタイムアウト表示の場合はノードの変更を推奨します。
3. 「タイムアウト」や赤色表示は必ずしもノードが使えないことを意味するわけではありません。テストリクエスト自体が途中のネットワークで破棄された可能性もありますが、実際にノードが失効している可能性もあります。原因を深く追わず、遅延が正常なノードに直接切り替えることをお勧めします。
4. 遅延は時間帯によって変動します、特にピーク時間帯は変動しやすくなります。通常は安定しているノードが突然高い値を示した場合は、数分後に再テストして一時的な変動でないか確認してください。

ノード切替後にやるべき確認作業

新しいノードを選択した直後にすぐ有効になったと決めつけず、次の順序で確認してください。

1. ノード一覧でそのノードが実際に「選択中」の状態(通常はハイライトやチェックマークで表示)になっているか確認する。
2. 設定画面に戻り、システムプロキシがオンになっているか、またはTUNモードが有効になっているかを確認する。どちらか一方が有効であれば十分で、両方同時にオンにする必要はありません。
3. 「接続」ページを開き、新しい接続記録が現れるか、記録中のターゲットドメインと使用中のノード名が想定通りかを確認する。

ノードを切り替えた後にページの読み込みが明らかに遅い、または読み込めない場合は、まず遅延テストに戻ってそのノードが正常かを確認し、その上でルールによってこの種のトラフィックが別のグループに振り分けられ、別のノードを経由していないかを検討してください。

ブラウザでプロキシが機能しているか確認する

最も分かりやすい方法は、現在の出口IPと地理的位置を表示するページにアクセスすることです。手順は次の通りです。

1. プロキシを有効にする前に一度IP確認ページへアクセスし、表示されたアドレスと地域を記録します。これが直接接続時の出口情報です。
2. Clashでノードが選択され、システムプロキシまたはTUNモードが有効になっていることを確認します。
3. 同じIP確認ページを再読み込みします(ブラウザキャッシュを避けるため強制リロードを推奨)。表示されるアドレスと地域が変化したかを比較します。

地域情報がノードの所在地に変わっていれば、プロキシは正しく機能しています。もしローカルネットワークのアドレスがそのまま表示されている場合は、システムプロキシがオンになっていない可能性が高いか、ブラウザ側で独自のプロキシ設定がされている可能性があります(一部のブラウザはシステムプロキシとは別に個別設定を許可しているため、上書きされていないか確認してください)。

また、クライアントの「接続」ページを開き、ページにアクセスしながら該当するドメインの接続記録がリアルタイムに現れるか、その記録に記されているノードが先ほど選択したものと一致しているかを確認できます。この手順では、実際にどのノードがこのリクエストを処理しているかを、IP確認より正確に判断できます。

コマンドラインでプロキシが機能しているか確認する

コマンドラインでの確認は、ターミナルでの調査に慣れているユーザーに適した方法で、特にブラウザのキャッシュや拡張機能の干渉で結果が分かりにくい場合に信頼性が高くなります。macOSやLinuxでよく使われるcurlコマンドを例にします。

curl -x http://127.0.0.1:7890 https://ifconfig.me

このコマンドはローカルのHTTPプロキシポートを経由してリクエストを送信し、戻り値として出口IPアドレスが返されます。ポート番号はクライアントの設定画面に表示されているミックスポートまたはHTTPポートを確認してください。クライアントによってデフォルト値が異なるため、例の数字をそのまま使わず、実際の画面表示に従ってください。

システムプロキシポートではなくTUNモードを有効にしている場合は、-xパラメータを付けずに直接リクエストを送信できます。TUNモードはすでにネットワーク層でトラフィックを引き受けているためです。

curl https://ifconfig.me

プロキシを有効にする前後の2回のIPを比較し、アドレスが変化し、かつ選択したノードの地域と一致していれば、プロキシ経路は正しく機能しています。コマンドがタイムアウトしたり接続が拒否された場合は、まずポート番号が正しいかを確認し、次にクライアントのプロキシリスニングサービスが起動中かを確認してください。

確認に失敗したときの調査順序

上記の手順を行ってもプロキシが機能していない場合は、複数の設定を同時に変更するのではなく、次の順序で一つずつ切り分けてください。

• まずノード自体を確認:遅延テストは正常か、たまたま失効したノードを選んでいないか。遅延が正常な別のノードに切り替えて再テストします。
• 次に引き受け方式を確認:システムプロキシとTUNモードの状態を確認し、少なくとも一方が有効であること、かつシステム設定の「プロキシを無視する例外リスト」にテスト対象のドメインが含まれていないことを確認します。
• 次にルールのマッチングを確認:ルール画面を開き、テストしているドメインがプロキシのポリシーグループに振り分けられているか、直接接続(DIRECT)にマッチしていないかを確認します。一部のサブスクリプションはデフォルトでローカルネットワークや特定地域のドメインを直接接続に設定しているため、この場合はプロキシが正常でもIPの変化は見られません。
• 最後にクライアントのプロセスを確認:Clashのコア(core)プロセスが正常に稼働しているか、終了・クラッシュしていないかを確認します。コアが異常終了した場合でも画面上は選択状態がそのまま残ることがあり、「すでに有効になっているように見える」という誤解を招きやすいです。

一つずつ切り分けが終わったら、前述のブラウザまたはコマンドラインでの確認手順をもう一度繰り返し、問題が実際に解決したことを確かめてください。「たぶん直っただろう」という感覚だけで判断しないようにしましょう。

シンプルな日常確認の習慣をつける

初回設定が成功した後は、ノードを切り替えたりクライアントを再起動したりするたびに毎回フルの手順を行う必要はなく、簡単な確認動作だけを残しておくと便利です。「接続」ページを開いて新しい接続が生成されているか見る、または以前記録したコマンドをすぐに実行する、といった方法なら数秒で経路が通っているか確認できます。この習慣は「なぜ急につながらなくなったのか」を調査する際に特に役立ちます。正常な状態で何が表示されるべきかをすでに把握しているため、異常な状態を一目で判別できるようになります。