Clashノードの選び方：遅延・倍率・地域・プロトコルで判断する実践ガイド

「遅延が最も低ければ最適」という選び方をまず見直す

Clashクライアントのノード一覧では、遅延の数値が目立つ位置に表示されることがよくあります。香港Aが58 ms、シンガポールBが91 ms、米国Cが168 msと表示されると、多くの人はそのまま58 msを選びます。この方法は初期選別には向いていますが、最終判断には不十分です。遅延が示すのは1回のテストリクエストが完了するまでの速さだけで、ノードの空き帯域、ピーク時間帯の混雑、通信量倍率、出口地域、プロトコルの互換性、コンテンツサービスの利用可否までは分かりません。

ノード選びは、必須条件のある並べ替え問題に近いものです。まず現在のカーネルがプロトコルをサポートしていること、地域がアクセス目的に合っていること、倍率がプランの予算内であることを確認し、そのうえで遅延と実際の通信性能から常用ノードを決めます。一時的なウェブ閲覧なら遅延を重視しても構いませんが、4K動画、リモート開発、大容量ファイルの同期が目的なら、持続的なスループット、パケットロス、回線の変動も含めて判断する必要があります。

ここからは、画面上で確認しやすい順に、遅延・倍率・地域・プロトコルを分けて解説します。最後に4項目を実行しやすい選択手順へまとめます。

視点1：遅延は初期選別に使い、最低3回は連続測定する

クライアントが実際に測っているもの

一般的なClash対応GUIクライアントでは、カーネルがテストURLへHTTPまたはHTTPSリクエストを送り、接続開始から有効なレスポンスを受け取るまでの時間を記録します。ポリシーグループの url-test も同様の考え方で、設定した間隔ごとに再測定します。この数値には通常、端末からプロキシ入口まで、プロキシサーバーの処理、プロキシ出口からテストサイトまでの経路、ハンドシェイクにかかる時間が含まれます。

これは完全な速度測定ではありません。ノードが60 msと表示されても、100 Mbpsを継続して出せるとは限りません。逆に、140 msのノードでも回線が安定し帯域に余裕があれば、ピーク時間帯に混雑する60 msのノードより大容量ファイルを速くダウンロードできる場合があります。

範囲で判断し、5 msの差を追いかけない

この範囲は経験的な目安であり、合否の基準ではありません。北京から東京と広州から香港では物理的な経路が異なり、モバイル回線、家庭用ブロードバンド、企業ネットワークでも結果は変わります。2つのノードが61 msと67 msなら、差は通常ほとんど判断材料になりません。一方が安定して90 ms、もう一方が45～320 msの間で変動するなら、前者を優先すべきです。

3回測定する方法

1. クライアントで「プロキシ」→対象のポリシーグループを開き、候補ノードをすべて測定します。
2. 5～10秒間隔を空けてさらに2回測定し、最後の結果だけでなく3回分を記録します。
3. 中央値を基準にし、最大値と最小値の差も確認します。
4. 差が150 msを超える、頻繁にタイムアウトする、または時折数秒と表示されるノードは予備に回します。
5. ピーク時間帯の20:00～23:00にも再測定し、空いている時間帯のデータだけで判断しないようにします。

たとえば3つのノードを3回測定した結果が、A：62、65、63 ms、B：41、286、79 ms、C：96、101、99 msだったとします。Aはインタラクティブな作業のメインノードに最適です。Cは数値こそ低くありませんが変動が小さく、長時間接続にも向いています。Bは最低値だけを見ると最も魅力的ですが安定性が低く、41 msという結果だけで首位にすべきではありません。

自動選択グループの設定を過敏にしない

mihomoおよびClash互換設定では、url-test ポリシーグループを使って低遅延ノードを定期的に選択できます。次の設定では300秒ごとに測定し、50 msの許容差を設けてノードの頻繁な切り替えを抑えます。

proxy-groups:
  - name: Auto
    type: url-test
    proxies:
      - HK-A
      - HK-B
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - DOMAIN-SUFFIX,github.com,Auto
  - MATCH,Auto

tolerance: 50 は速度を上げるためではなく、十数ミリ秒の変動で近い2つのノードが何度も切り替わるのを防ぐための設定です。頻繁な切り替えは既存の接続を中断し、ログインセッション、ダウンロード、動画のバッファリングに影響する可能性があります。テストURLには、安定していてレスポンス本文が小さく、実際に到達できるアドレスを選びます。テストURLを変えれば数値も変わります。

視点2：倍率はプランの消費量を決めるが、速度ランクではない

倍率は通信量の課金係数です。ノードに0.5倍、1倍、1.5倍、2倍と表示されている場合、通常は実際に10 GB通信すると、プランからそれぞれ5 GB、10 GB、15 GB、20 GBが差し引かれます。具体的な精算方法はサブスクリプション提供元の説明に従う必要がありますが、基本的な考え方は同じです。倍率は利用可能な通信量のコストに影響し、帯域幅や遅延を直接決めるものではありません。

低倍率のノードでも高速な場合があれば、ピーク時間帯に混雑する場合もあります。高倍率のノードはより良い越境回線を使っていることもあれば、地域リソースのコストが高いだけの場合もあります。「2倍」をそのまま「2倍速」と考えてはいけません。倍率に見合うかは具体的な用途で判断します。同じ30 GBのファイルを1倍ノードでは20分、2倍ノードでは16分で完了できるとしても、急いでいなければプランから追加で30 GB差し引かれる価値は通常ありません。

用途別にポリシーグループを分ける

より堅実なのは、低倍率ノードと高品質ノードを分けてグループ化する方法です。大容量通信には低倍率グループを手動で選び、会議、リモートターミナル、重要なアップロードには安定回線グループを使います。ルールで用途に応じたグループへ振り分ければ、毎回数十個のノードから探し直す必要がありません。

proxy-groups:
  - name: Bulk-Traffic
    type: select
    proxies:
      - HK-LowRate
      - SG-LowRate
      - DIRECT

  - name: Stable-Line
    type: select
    proxies:
      - HK-Premium
      - JP-Premium
      - SG-Premium

rules:
  - DOMAIN-SUFFIX,example-download.com,Bulk-Traffic
  - DOMAIN-SUFFIX,example-meeting.com,Stable-Line
  - MATCH,Stable-Line

視点3：地域は出口の識別情報と経路の迂回に影響する

ノード名にある香港、日本、シンガポール、米国などは、通常プロキシの出口がある地域を示します。アクセス先のウェブサイトからはその出口アドレスに見えるため、地域は検索結果、ローカライズされたコンテンツ、アカウントのリスク判定、ストアの地域、ストリーミングの配信ライブラリに影響します。また、地域によって、ローカルネットワークからプロキシ入口を経由して対象サーバーへ向かう大まかな経路も変わります。

近い地域が最短とは限らないが、初期候補には向いている

中国本土のユーザーは、まず香港、日本、シンガポールなど近隣地域をテストすることが多いでしょう。物理的な距離が近いため、平均遅延は欧州や北米のノードより低い傾向があります。ただし、通信事業者間の接続品質、入口の場所、回線制御によって大きく迂回することがあります。たとえばローカル環境から香港ノードへ接続する際に別地域を経由し、最終的な遅延が東京ノードより高くなるケースもあります。地図上で最寄りを選ぶ方法は候補を絞るためだけに使い、最終的には実測してください。

• ウェブ閲覧とメッセージング：安定性が高く遅延の小さい近隣地域を優先し、通常は香港、日本、シンガポールから試します。
• 地域限定コンテンツ：目的のコンテンツに対応する地域を直接選び、その出口で実際に利用できるか確認します。
• 海外通販とアカウントへのログイン：普段使う地域をできるだけ固定し、数分の間に複数の国を切り替えないようにします。
• コードホスティングとソフトウェアリポジトリ：対象サイトからの実際のダウンロード速度を比較し、ノード一覧の遅延だけで判断しないでください。
• 大陸間のリモートデスクトップ：リモートホストに近い側の地域を優先し、マウスやキーボード操作の応答とパケットロスを確認します。

利用可否はノード名だけでは判断できない

「米国ノード」と書かれていても、特定の動画サービス、AIサービス、ストアがそのアドレスを必ず受け入れるとは限りません。データセンターのアドレスとして認識され、サービス側で制限されることもあります。同じ地域でもノードごとに結果は異なります。このようなノードを選ぶときは、サブスクリプション名に「ストリーミング対応」と書かれているかだけでなく、対象サービスのトップページ、ログイン、再生、画質切り替えを実際に確認してください。

テスト時にはDNSの場所による影響も切り分ける必要があります。クライアントでmihomoのFake-IP DNSやTUNモードを有効にすると、名前解決と通信の取り込み方が変わります。「ノードの地域は合っているのにコンテンツが一致しない」場合は、まず「設定」→「ネットワーク」→「TUNモード」が有効か確認し、設定内の dns、nameserver、proxy-server-nameserver とルールのヒット記録を確認します。TUNはより多くのシステム通信を取り込む機能であり、ノード品質を自動的に高めるものではありません。

視点4：プロトコルは互換性とネットワークへの適応力に影響する

プロトコルは必須条件です。サブスクリプションにノードが存在していても、現在のクライアントカーネルが正しく利用できるとは限りません。従来のClashカーネルとmihomoでは対応範囲が異なり、GUIクライアントに組み込まれたカーネルのバージョンも異なる場合があります。すべてのノード測定がタイムアウトする、インポート後にノードが表示されない、接続直後に失敗するといった場合は、測定ボタンを連打せず、まずクライアントのカーネル種別と実行ログを確認してください。

よく使われるプロトコルで確認すべき点

プロトコル名だけで速度差をすべて予測することはできません。回線の良好なShadowsocksノードが、混雑したHysteria2ノードより安定することもありますし、逆もあります。実際の体感を左右するのは、プロトコルの実装、サーバー負荷、入口と出口の回線、ローカルネットワークによるTCPまたはUDPの扱い、設定パラメータの一致状況です。

UDPプロトコルは実際のネットワークで検証する

Hysteria2とTUICはUDPに依存します。家庭用ブロードバンドで良好でも、企業Wi-Fi、学校ネットワーク、ホテルのネットワーク、スマートフォンのテザリングでも同じとは限りません。UDPを制限したり、セッション維持時間を短くしたり、高頻度のUDP通信を制御したりするネットワークもあります。症状としては、測定のタイムアウト、接続数秒後の切断、ウェブページは時々開くのに継続通信だけ失敗するといった現象が現れます。

検証方法は簡単です。同じネットワークでTCP系ノードとUDP系ノードを1つずつテストし、動画を10分間連続再生した後、500 MB前後のテストファイルを転送します。UDPノードの速度が頻繁にゼロになり、TCPノードが安定しているなら、そのネットワークではTCPノードを通常のフォールバックにします。スマートフォンのテザリングに切り替えると、結果が大きく変わることもあります。

4つの視点を選択手順にまとめる

手順1：互換性のない候補を整理する

サブスクリプションを一度更新したら、「プロキシ」→「ポリシーグループ」を開き、ノードがすべて表示されているか確認します。候補ノードを測定し、カーネルログで unsupported、timeout、TLSハンドシェイク失敗、DNS名前解決失敗などを確認します。3回連続で接続を確立できないノードは、まず候補から外してください。自動選択グループの判断を妨げないようにします。

手順2：用途に合わせて地域を絞る

通常の閲覧では香港、日本、シンガポールなど近隣の2～3地域を残し、地域限定コンテンツでは目的の地域だけを残します。最初から20～30個のノードを遅延値だけで選ばせないでください。地域ごとに担う役割が異なるためです。Daily、Streaming-US、Development などのポリシーグループを作り、地域と用途を明確に分けると管理しやすくなります。

手順3：倍率の予算を計算する

プランの残りが120 GBで、今月あと20日あると仮定すると、1日の平均予算は約6 GBです。2倍ノードを長時間使うと、1日に実際に3 GB通信しただけで約6 GBが差し引かれます。25 GBのシステムイメージを一度ダウンロードすれば、約50 GB消費する可能性があります。この場合、ダウンロードには低倍率ノードを使い、会議、リモート接続、緊急作業には高倍率でも安定した回線を残す方法が有効です。

手順4：遅延で初期選別した後、実際の用途でテストする

1. 3回連続で測定し、変動の小さい3～5個のノードを残します。
2. 普段使うウェブサイトを開き、初回接続とページ間の連続遷移がスムーズか確認します。
3. 1080p動画を少なくとも10分再生します。通常は継続して約8～12 Mbpsが必要ですが、具体的な値はサービスのエンコード方式によって異なります。
4. 4Kが必要な場合は、約25 Mbps以上のスループットを継続できるか確認し、画質が何度も下がらないかにも注意します。
5. 500 MB～1 GBのファイルをダウンロードし、ピーク値だけでなく速度が安定しているかを記録します。
6. 実際に利用する時間帯に再測定し、ピーク時間帯に速度が落ち続けるノードは予備グループに回します。

最終的には、メインノードと、異なる回線またはプロトコルの予備ノードを1つずつ残すのが理想です。メインノードは通常の通信を担当し、タイムアウト、パケットロス、対象サービスの利用不可が発生したら手動で予備へ切り替えます。自動の fallback グループでも可用性を確保できますが、ノードを切り替えても既存の接続がすべて維持されるわけではありません。進行中のダウンロードやセッションは再接続になる可能性があります。

よくある4つの用途別おすすめ構成

ウェブ閲覧とメッセージング

優先順位は、安定性、遅延、倍率、地域です。まずは50～120 msで、3回測定時の変動が40 ms未満の近隣地域ノードを選び、倍率は1倍前後に抑えます。プロトコルは新しさより、現在のネットワークとカーネルで安定して接続できることを重視します。地域を頻繁に切り替えると、ウェブサイトで再認証を求められることがあります。

ストリーミングと長時間動画

優先順位は、地域での利用可否、持続スループット、倍率、遅延です。まず目的の地域のコンテンツを再生できることを確認し、10～20分の間に画質低下やバッファリングが発生しないか観察します。80 msと130 msの差より、安定した30 Mbpsと5～60 Mbpsで変動する通信速度の差のほうが重要な場合が多いです。大容量の視聴前には倍率を計算し、4K動画を数本見ただけでプランを使い切らないようにします。

リモート開発、SSH、リモートデスクトップ

優先順位は、変動、パケットロス、遅延、プロトコルです。ターミナル入力では高帯域幅はあまり必要ありませんが、遅延が突然80 msから800 msへ跳ね上がると大きな支障になります。3回の測定結果が安定し、長時間接続がリセットされないノードを選びます。企業ネットワークを使う場合は、UDPが制限されたときすぐ切り替えられるようTCP系の予備ノードを用意します。

大容量ダウンロードとクラウドストレージ同期

優先順位は、倍率、持続スループット、安定性、遅延です。まず0.5倍または1倍のノードを選び、500 MB以上の通信をテストします。遅延が150 msでも20 MB/sを安定して維持できるノードは、遅延50 msでも速度が1～30 MB/sの間で何度も変動するノードより、大容量ファイルに適していることが多いです。

よくある思い込み

• 1回しか測定しない：1回の結果はDNSキャッシュ、接続の再利用、一時的な混雑の影響を受けやすくなります。
• 倍率を速度だと考える：倍率は課金係数であり、帯域幅の倍率ではありません。
• 地域名だけで利用可能だと判断する：出口アドレスが対象サービスに受け入れられるかは、実際にアクセスして確認する必要があります。
• 新しいプロトコルなら必ず速いと考える：プロトコルは経路の一要素にすぎず、回線と負荷のほうが重要な場合が多くあります。
• TUNを有効にして再測定すれば完了だと考える：TUNはシステム通信の取り込み範囲を変えるだけで、混雑したノードを改善するものではありません。
• ポリシーグループを頻繁に切り替える：自動切り替えは長時間接続を中断することがあります。許容差と測定間隔は控えめに設定してください。
• 利用時間帯を無視する：深夜の測定では高速だったノードが、ピーク時間帯にはまったく違う挙動を示すことがあります。

ノード選びに永続的な正解はありません。ネットワークの入口、サーバー負荷、対象サイトへの経路は変化します。より効果的なのは、互換性の確認をプロトコルの最初の条件とし、用途に地域を合わせ、倍率でコストを管理し、遅延で初期選別し、最後に実際の用途で確認する固定手順を持つことです。サブスクリプションのノード名や数が変わっても、数分でメインノードとフォールバックノードを選び直せます。