Clashノードの選び方：遅延・通信量倍率・地域・プロトコルを比較

用途を決めてからノードを絞り込む

ノードとは、クライアントが接続するプロキシサーバーの接続先です。サブスクリプションを使うと、複数のノードと関連設定がクライアントに登録されます。ノードを選ぶことは、どのプロキシ経由で通信を目的のWebサイトへ送るかを選ぶことです。名前に含まれる地域・倍率・回線の表記は絞り込みの手掛かりになりますが、サービス提供元が付けた名称だけで実際の接続結果は判断できません。

次の順に確認するのがおすすめです。まず目的のサービスで必要な出口地域を確認し、次に通信量倍率を見ます。その後、遅延と安定性を比較し、最後に現在のクライアントとネットワークでプロトコルが正常に動作するかを確かめます。すべてのノードを遅延順に並べて先頭を選ぶより、手間を抑えられます。

• 普段のWeb閲覧：応答が安定し、倍率が適切なノードを優先し、予備も1つ確保します。
• 大容量ファイルのダウンロード：継続的な転送速度と残りの通信量を重視します。低遅延はあくまで目安です。
• 動画視聴：まず目的のコンテンツにアクセスできるか確認し、画質・再生開始までの時間・バッファリングを見ます。
• 音声通話・ゲーム：ジッターやパケット損失、UDP対応を確認し、アプリの通信が実際にプロキシを経由しているかも確かめます。

ポイント1：遅延は応答速度だけでなく変動も確認

遅延の数値はダウンロード速度とは別

Clashクライアントで一般的な遅延テストは、指定したHTTPまたはHTTPSアドレスへプロキシ経由でアクセスし、リクエストにかかった時間を計測します。単純なICMP pingとは異なります。テストURLや接続の再利用、コアの実装、その時点の負荷によって結果は変わり、すべてのWebサイトでの実際の応答時間を示すものでもありません。

たとえば、あるノードが45 ms、別のノードが110 msと表示されても、今回のテスト条件では前者の応答が速かったというだけです。前者のダウンロード速度が必ず速いとは限りません。ダウンロード速度は回線帯域、サーバー負荷、接続先の速度制限、夜間の混雑にも左右されます。

同じ条件で3回連続して測定

1. 同じネットワークとテストアドレスを使い、ダウンロードやクラウドストレージの同期は一時停止します。
2. 候補ノードを約10秒間隔で3回測定し、タイムアウトの有無を記録します。
3. 候補を2つ選び、それぞれ普段使うWebサイトを開いて、最初の画面表示と連続したリクエストの応答を確認します。
4. 普段使う時間帯にも再測定します。特に20:00〜23:00の夜間は確認しておきましょう。

3回の測定は候補を絞るためのもので、信頼できるパケット損失率を算出するには不十分です。ビデオ会議やゲームの品質を判断する場合は、アプリ内のネットワーク統計を確認してください。HTTPテストに成功してもUDP転送が正常とは限らず、ゲームサーバーへの通信が必ず同じ経路を通るとも限りません。

ポイント2：倍率は通信量の消費に関わり、速度のランクではない

ノード名にある「0.5×」「1×」「2×」は、一般にサービス提供元が設定する通信量の換算倍率です。倍率に応じて課金される場合、2×のノードで3 GBを転送すると、通信量は約6 GB分として差し引かれます。0.5×なら約1.5 GB分です。アップロードとダウンロードを合算するか、端数をどう処理するかは、サブスクリプションサービスの説明を確認してください。

倍率はClashコアが定める速度設定ではありません。2×だから帯域が2倍になるわけではなく、0.5×でも速度が半分に制限されるわけではありません。クライアント上のノード名に古い表記が残ることもあるため、プランのページや通信量の明細を確認するのが確実です。

大容量通信の前に通信量を確認

• 20 GBを転送する場合、1×のルールでは約20 GB分、2×では約40 GB分が消費されます。
• 残りの通信量が30 GBしかない場合は、必要な作業を先に済ませてから高倍率の回線を検討します。
• 速度テストでも通信量を消費します。大容量ファイルを使ったテストを繰り返すと、プランの通信量に加算されることがあります。

倍率が低く安定したノードはダウンロード用に、応答性のよいノードは操作が多い用途に残しておくのがおすすめです。速度テストの数値を上げるためだけに高倍率の回線へ切り替えるのは避けましょう。一度の最高速度より、実際の作業を安定して完了できるかが重要です。

ポイント3：出口地域を確認し、ノード名は手掛かりとして使う

入口はデバイスがプロキシサービスに接続する場所、出口は接続先のWebサイトから見えるグローバルIPの場所です。中継回線では、近くの入口から接続して別の地域を出口としてWebサイトにアクセスすることがあります。そのため、入口が近いことと出口が近いことは同じではありません。

ノード名に「日本」とあれば、通常は出口地域を示していますが、すべてのWebサイトが日本からのアクセスと判定するとは限りません。IPアドレスデータベースの更新状況は異なり、接続先のサービスがアカウントの地域、支払い情報、デバイスの位置情報、過去のセッションを参照することもあります。目的のサービスで実際にどう判定されるかを基準に地域を選びましょう。

出口地域を確認する手順

1. クライアントの「プロキシ」画面で、目的のルールが使うプロキシグループを開き、候補ノードを手動で選びます。
2. 「接続」画面を開いて目的のWebサイトへアクセスし、一致したルールとプロキシ経路を確認します。
3. 信頼できるIPアドレス確認ページにアクセスし、リクエストがプロキシを経由していることと出口情報を確認します。
4. 目的のサービスを開き直し、コンテンツの地域やサービスの利用可否を確認します。必要に応じて古い接続を終了してから再試行してください。

ここでの「プロキシ」「接続」は一般的な画面名です。クライアントやバージョンによっては「プロキシグループ」「接続一覧」と表示されることがあります。該当する項目が見つからない場合は機能を目印に探してください。基本設定については使い方ガイドも参照できます。

地域を固定したいサービスには、複数の国や地域を混在させた自動選択グループではなく、地域ごとのプロキシグループを個別に作るのが適しています。自動切り替えで出口地域が変わると、ログイン認証やコンテンツの利用可否に影響することがあります。

ポイント4：まずコアの対応状況を確認し、次にネットワーク条件を見る

Shadowsocks、Trojan、VMess、VLESS、Hysteria2、TUICなどは、それぞれ異なるプロキシプロトコルまたはプロトコル系列です。プロトコルはクライアントとサーバー間のデータ転送方式を定めますが、ノードの速度は回線やサーバー負荷にも左右されます。プロトコル名だけで一律に速度を順位付けすることはできません。

Clashはクライアントのエコシステムで広く使われる名称で、実際に対応するプロトコルは利用するコアとそのバージョンによって異なります。mihomoはこのエコシステムのコアで、以前はClash Metaという名称が使われていました。旧版のClashコアと現在のmihomoでは対応機能が異なります。サブスクリプションをダウンロードできても、登録されたすべてのノードを現在のコアが読み込めるとは限りません。

Hysteria2とTUICはUDPベースの通信を使用するため、UDPが制限されたオフィスや公共のネットワークでは接続に失敗することがあります。その場合は、同じネットワーク上で利用可能なTCP通信のノードも試し、ログを確認してください。クライアントを何度も再起動する必要はありません。

TUNは仮想ネットワークインターフェースを使って、より多くのアプリの通信を取り込み、ルール処理に渡す方式です。プロキシプロトコルではなく、サーバー側のUDP対応を補う機能でもありません。システムプロキシの影響を受けるのは、通常その設定に従うアプリだけです。ゲームの通信がプロキシを経由していない場合は、ノードの品質を比べる前に通信の取り込み状況を確認してください。

手動選択・url-test・フェイルオーバーの使い分け

手動選択グループは、地域や用途を固定したい場合に便利

selectは手動選択型のプロキシグループです。出口地域を固定したい場合や、2つの回線を比較したい場合、倍率の異なるノードを使い分けたい場合は、手動選択なら結果を管理しやすくなります。まずメインのノードを1つ選び、別回線の予備を1つ確保しておくのがおすすめです。

url-testは同じ条件のノード同士で応答を比較するのに便利

url-testは指定したアドレスと間隔で候補ノードをテストし、その結果に基づいてノードを選択します。地域・倍率・用途が近いノードを登録するのに適しており、サブスクリプション内の全ノードをまとめて登録する用途には向きません。自動選択で主に考慮されるのは遅延で、プランのコストや目的のプラットフォームでコンテンツを利用できるかまでは判断されません。

以下は設定に追加できるプロキシグループの例です。ノード名は現在の設定と完全に一致させてください。「日本-01」と「日本-02」は例示用の名前なので、使用前にサブスクリプションに登録されている実際の名前に変更します。また、ルールからこのグループを参照する必要があります。プロキシグループを作成しただけでは、通信経路は自動で変わりません。

proxy-groups:
  - name: 日本自動選択
    type: url-test
    proxies:
      - 日本-01
      - 日本-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

• interval: 300：テスト間隔を300秒に設定します。実際の実行タイミングはコアや遅延テストの動作にも左右されます。
• tolerance: 50：切り替えの許容差を50 msに設定し、わずかな遅延差による頻繁なノード切り替えを防ぎます。実際の切り替え動作は利用中のコアの実装に従います。
• url：すべての候補ノードで同じテストアドレスを使います。実際のネットワークでそのアドレスにアクセスできることを確認してください。

この内容でサブスクリプションファイル全体を上書きしないでください。また、同じYAMLの最上位にproxy-groupsキーを重複して記述しないでください。クライアントに上書きやマージ機能がある場合は、それを使ってローカル設定を保存すると、サブスクリプション更新時の置き換えを防げます。具体的な設定場所は使用中のクライアントで確認してください。

fallbackは優先順位に沿って予備を使う場合に便利

fallbackはフェイルオーバー型のグループで、通常はリスト順に、利用可能と判定されたノードを選びます。遅延が最も低いノードを継続的に選ぶ方式ではありません。「メイン回線を優先し、使えない場合は予備に切り替える」用途に適しています。ただし、テストアドレスに接続できても目的のサービスが使えるとは限らないため、実際のWebサイトでも予備を確認してください。

5分でできるノードの一次選定

1. 設定を確認：サブスクリプションが正常に更新され、プロキシ画面にノードが表示されていること、解析エラーがないことを確認します。
2. 候補を絞り込む：出口地域、倍率、コアの対応状況を基準に、ノードを2〜3個残します。
3. 条件をそろえて遅延を測定：同じネットワークで3回続けて測定し、タイムアウトや大きな変動を記録します。
4. 実際の用途で試す：普段使うWebサイトを開き、約2分間動画を再生するか、約30秒の小規模なダウンロードで持続速度を確認します。
5. ルールと予備を確認：接続画面でプロキシ経路を確認し、メインと予備のノードを決めてから、夜間の混雑する時間帯に再測定します。

すべてのノードが同時にタイムアウトする場合は、まずローカルネットワーク、サブスクリプションの有効期限、テストアドレスへの接続可否、コアのログを確認します。特定のノードだけ失敗する場合は、そのノードのプロトコル設定やサーバーの状態を調べます。遅延は正常なのに特定のWebサイトが開けない場合は、対象リクエストのルール、出口地域、古い接続を確認してください。

一覧の最小値を追い求める必要はありません。地域が用途に合い、倍率を許容でき、普段使う時間帯に安定し、現在のネットワークでプロトコルが使える。この4つを満たすノードが、普段使いに適した候補です。一次選定の後は目的のない切り替えを減らし、再現可能な比較記録を残すと、その後のトラブル対応が容易になります。