Clashノードの選び方：遅延・倍率・地域・プロトコルの判断基準

目的を確認してから速度テストの数値を見る

Clashノードを選ぶとき、最小遅延が必ずしも最高の使い心地につながるとは限りません。Webページの表示、動画のバッファリング、オンライン会議、ファイルダウンロード、ゲーム接続では、回線に求められる条件が異なります。テストを始める前に、応答速度、持続帯域、出口の地域、通信量のどれを重視するかを決めておきましょう。

たとえば、同じサブスクリプションに48 msの香港ノードと82 msの日本ノードがあるとします。前者は通常Webページへの応答が速い一方、夜間の混雑時にパケットロスが目立つなら、動画再生は後者のほうが安定する場合があります。160 msと表示される米国ノードは低遅延の操作には向きませんが、米国限定コンテンツへのアクセスでは正しい選択になる可能性があります。

用途別に優先すべき指標

• 日常のWeb閲覧：遅延、接続成功率、夜間の混雑時の安定性を優先し、通常は地理的に近い地域を選びます。
• 高画質動画：持続ダウンロード速度とジッターを重視します。一時的な測定値が高くても、速度低下を頻繁に繰り返す回線は適していません。
• 音声会議：往復遅延、ジッター、パケットロスを優先します。遅延が80 msで安定しているほうが、35 msから180 msの間を頻繁に変動する回線より使いやすいのが一般的です。
• 大容量ダウンロード：持続スループット、倍率、プランの残り通信量を確認し、最低遅延だけを追い求める必要はありません。
• 地域限定コンテンツ：まず出口となる国や地域を決め、その条件を満たすノード同士で安定性を比較します。
• 不安定なモバイル回線：プロトコルの挙動、再接続の速さ、UDPが利用できるかを重点的に比較します。

遅延テストの数値の読み方

ClashのGUIクライアントで行う遅延テストでは、通常、非常に小さいテスト用URLへリクエストを送り、接続開始から応答を受信するまでの時間を測定します。クライアント、設定ファイル、プロキシ提供元によってテスト先が異なる場合があるため、異なるソフトの結果をそのまま比較することはできません。

遅延の結果は、DNS名前解決、TLSハンドシェイク、テストサーバーの位置、ローカルWi-Fi、ノードの現在の負荷にも左右されます。42 msと一度測定できても、その時点の小さなリクエストが速く完了したことを示すだけで、継続的に高速ダウンロードできる証明にはなりません。

数値を実用的に分ける目安

これらの区分は固定された基準ではありません。中国本土から香港、日本、シンガポールのノードへは35～120 ms程度、欧州や北米のノードへは140～260 ms程度になることがあります。通信事業者、所在地、入口回線、国際経路によって結果は変わります。

少なくとも3回連続でテストする

1. 実行中の大容量ダウンロード、クラウドストレージの同期、システム更新を停止します。
2. 候補ノードを3～5回連続でテストし、各回の間隔を約5秒空けます。
3. 最小値、最大値、タイムアウト回数を記録し、最良の1回だけを残さないようにします。
4. 日中と20:00～23:00にそれぞれ1回テストし、混雑時の差を比較します。
5. 候補を2～3個に絞り、1080p動画の再生や200 MB前後のテストファイルのダウンロードを実際に行います。

ノードAの5回の結果が46、49、51、48、50 ms、ノードBが32、37、145、タイムアウト、41 msだったとします。ノードBの最小値は低いものの、ノードAの変動幅は5 msしかなく、実際のWeb閲覧や会議ではより安定することが多いでしょう。この場合はノードAを優先します。

遅延・ジッター・パケットロス・速度の違い

遅延はリクエストの待ち時間を左右する

遅延は主に短時間の接続や頻繁な操作に影響します。小さなリソースを多数含むWebページを開くと、接続やリクエストのたびにネットワークの往復を待つ必要があります。リモートターミナル、オンラインドキュメント、音声通話も遅延の影響を受けやすい用途です。遅延が50 msから180 msに増えると、ダウンロード帯域が同じでも操作時の待ち時間をより強く感じます。

ジッターは遅延の安定性を示す

ジッターは、複数回の遅延値の変動幅と考えることができます。連続結果が70、73、76 msなら、40、160、55 msより通常は安定しています。音声やリアルタイム動画は時系列にデータを受信し続けるため、ジッターが大きいと音声の途切れ、映像の停止、一時的な無音が起こりやすくなります。

パケットロスは再送や品質低下を引き起こす

TCP通信ではパケットロスが発生すると通常は再送が行われ、ダウンロード速度が低下します。UDPの通信では一部データがそのまま失われることがあり、リアルタイム音声やゲームはこの影響を受けやすくなります。家庭内Wi-Fiの干渉、ローカル通信事業者の混雑、ノード入口の過負荷、遠隔回線のいずれもパケットロスの原因になります。

帯域は継続転送の上限を決める

遅延95 msで持続ダウンロード速度が80 Mbpsのノードは、遅延45 msでも混雑時に6 Mbpsしか維持できないノードより、高ビットレート動画の再生に向く場合があります。速度テストでは少なくとも30～60秒観察し、一時的なピークと持続速度を区別しましょう。8 Mbpsは理論上1秒あたり約1 MBの転送量に相当しますが、実際にはプロトコルのオーバーヘッドが差し引かれます。

クライアントの遅延テストが正常なのにブラウザが遅い場合は、まず別のテスト先に切り替え、DNS、ルールのマッチ、システムプロキシを確認します。TUNモードを有効にした場合は、通信が本当にClashへ渡っているか、未処理のアプリが別のネットワークインターフェースから直接接続していないかも確認してください。

ノード倍率がプランの通信量に与える影響

倍率は通常、プロキシサービス提供元の課金設定であり、Clashプロトコル自体の機能ではありません。「0.5×」は実際に1 GB通信するとプランから約0.5 GB差し引かれることを、「2×」は約2 GB差し引かれることを意味します。具体的な集計方法はサブスクリプションの管理画面を確認してください。上り、下り、プロトコルのオーバーヘッドを同時に計算するかどうかもサービスによって異なります。

低倍率ノードが必ず遅いとは限らず、高倍率ノードだから遅延が低いとも限りません。倍率には回線コスト、入口品質、地域リソース、運用方針などが反映される場合があります。選択時は性能ランクではなく、「通信量1単位あたりのプランコスト」として考えましょう。

月間通信量から許容できる倍率を逆算する

月200 GBのプランで、日常の動画視聴とダウンロードに実際に120 GB使うとします。すべてを1.5×ノード経由にすると理論上の課金量は約180 GBとなり、残りは20 GBしかありません。80 GBを0.5×ノード、残り40 GBを1.5×ノードに振り分ければ、計算上の課金量は約100 GBです。大容量の用途には低倍率のポリシーグループを個別に割り当てるほうが、頻繁に手動切り替えするより管理しやすくなります。

設定に「日常」「ダウンロード」「地域サービス」の3つのポリシーグループを作成できます。日常グループには安定した1×ノード、ダウンロードグループには低倍率ノード、地域サービスグループには出口条件を満たすノードだけを登録します。ルールでドメインやアプリごとの通信を適切なポリシーグループへ振り分ければ、ノード選択を管理しやすくなります。

地域の選択は出口と経路で決まる

ノード名に含まれる香港、日本、シンガポール、米国などの表記は、通常プロキシサーバーの出口位置を示します。ただし、入口や中継経路まで正確に表すとは限りません。同じ日本ノードでも、異なる通信事業者や中継回線を経由する場合があり、遅延や混雑時の挙動に大きな差が出ることがあります。

距離の近さは、あくまで出発点

• 香港：地理的に近く、日常のWeb閲覧や待ち時間を抑えたい用途に使われますが、混雑時の性能は入口回線に左右されます。
• 日本：遅延が中程度になりやすく、日本の出口を必要とするコンテンツに適しています。東アジアでの日常利用にも候補になります。
• シンガポール：東南アジア向けサービスに適しており、中国南部からの接続で良好な場合があります。
• 米国：米国の出口を必要とするサービスに適していますが、物理的な距離により基本遅延は東アジアのノードより高くなるのが一般的です。
• 欧州：特定地域へのアクセスに主に利用します。日常操作の遅延は高くなりやすいため、経路の安定性を優先して確認してください。

地域制限のあるコンテンツへアクセスする場合、ノード名より出口IPの所属地域が重要です。接続後、一般的なIP検索ページで国、地域、ネットワーク事業者を確認できます。出口が正しくてもコンテンツを利用できない場合は、アカウントの登録地域、決済情報、ブラウザの位置情報、DNSの結果、サービス側のIPデータベース更新状況などが原因の可能性もあります。

自動選択グループでは候補地域を限定する

Clashのurl-testポリシーグループは候補ノードを定期的にテストし、遅延の低いノードを選べます。ただし、すべての地域を同じグループに入れると、自動選択によって米国ノードから香港ノードへ切り替わり、出口地域が変わる可能性があります。地域を固定する場合は、「日本自動選択」「米国自動選択」のようにポリシーグループを分けて作成します。

proxy-groups:
  - name: 日本自動選択
    type: url-test
    include-all: true
    filter: "(?i)日本|JP|Japan"
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 日常手動選択
    type: select
    proxies:
      - 日本自動選択
      - DIRECT

この例では、日本を示す名前のノードを300秒ごとにテストします。tolerance: 50は、わずかな遅延変動による頻繁な切り替えを抑えるための設定です。Clash Meta（mihomo）のバージョンやクライアントによって設定項目の対応範囲が異なる場合があるため、インポート前に使用中のコアのドキュメントとサブスクリプション生成結果を確認してください。

不安定な回線ではプロトコルの違いが表れやすい

サブスクリプションのノードでは、Shadowsocks、Trojan、VLESS、VMess、WireGuard、Hysteria2、TUICなどのプロトコルが使われる場合があります。Clash Meta（mihomo）が対応する具体的なプロトコルと通信方式の組み合わせは、コアのバージョンによって異なります。速度を決めるのはプロトコルだけではなく、サーバー性能、入口帯域、経路品質、パラメータ設定も同じように重要です。

TCP系の通信：互換性は安定しやすいが、パケットロス時に速度低下

Trojan、一部のVLESSやVMessノードは、TCPとTLSの上で動作することが多いプロトコルです。TCPは多くのネットワークで通りやすく、接続動作も安定しやすい一方、回線でパケットロスが発生すると下位のTCPが再送を行い、送信速度を下げます。プロキシトンネル内の通信自体もTCPの場合、深刻なパケットロスによって速度低下や遅延の蓄積が起こることがあります。

Shadowsocks：実装が成熟しており、性能は回線に左右される

Shadowsocksの追加オーバーヘッドは通常抑えられており、クライアントとサーバーの実装も広く普及しています。一般的なブロードバンドでの体感は、暗号化方式、サーバー負荷、ネットワーク経路に大きく左右されます。SS、Trojan、VLESSという表示だけで、プロトコル名による絶対的な性能順位を決めるべきではありません。

Hysteria2とTUIC：UDP/QUICを利用する通信

Hysteria2とTUICはUDP/QUICを基盤とし、高遅延である程度のパケットロスが発生する回線では、輻輳制御や接続移行によってスループットをより滑らかに保てる場合があります。ただし、学校や企業のネットワーク、公共Wi-Fi、モバイルネットワークではUDPが制限されることがあり、接続不能、ハンドシェイクのタイムアウト、突然の速度低下として現れる可能性があります。

WireGuard：安定したトンネル用途に適する

WireGuardはUDPを使用し、プロトコル構造がシンプルで、ネットワーク全体のトンネルに使われることが多い方式です。システム時刻、MTU、UDPの到達性の影響を受けやすい特徴があります。Webページは開くのに一部サイトだけ止まる場合は、MTUを確認してください。1280、1380、1420などがよく試される値ですが、最終的には固定値をそのまま使わず、実際の経路でテストして決めます。

不安定な回線のテストにはネットワーク切り替えも含める

1. 家庭のWi-Fi、スマートフォンのテザリング、モバイルネットワークで同じノードをそれぞれテストします。
2. 10分間動画を再生し、頻繁に再バッファリングが発生しないか確認します。
3. 2分間画面をロックしてから復帰し、接続が速やかに再構築されるか確認します。
4. Wi-Fiからモバイルネットワークへ切り替え、アクセスが復旧するまでの時間を記録します。
5. UDPプロトコルでタイムアウトが続く場合は、TCP系ノードでもテストし、ネットワークによる制限かどうかを確認します。

AndroidでVpnServiceを使用する場合や、デスクトップでTUNモードを有効にする場合、ネットワーク切り替え後にシステムがデフォルトルートを再構築するまで時間がかかることがあります。このとき一時的に通信が途切れても、必ずしもノード障害とは限りません。まず5～10秒待ってから、クライアントログでタイムアウト、DNSエラー、インターフェース再構築の記録を確認してください。

ポリシーグループでノードの手動選択を減らす

サブスクリプションに数十個のノードが含まれている場合、1つずつクリックしてテストするのは非効率です。用途別にポリシーグループを作る方法が実用的です。地域グループは出口を限定し、自動グループは遅延を比較し、手動グループは最終的な選択権を残し、フォールバックグループはメインノードが使えないときに予備へ切り替えます。

4種類のポリシーグループの使い分け

• select：ノードや別のポリシーグループを手動で選択します。地域限定コンテンツや出口を固定したいアカウントに適しています。
• url-test：定期的にテストし、遅延の低いノードを優先します。日常のWeb閲覧に適しています。
• fallback：利用可能なノードを上から順に使用し、メイン回線が失敗したときに予備回線へ切り替えます。
• load-balance：設定した方式に従って複数ノードへ接続を分散します。固定出口IPが必要なログインセッションには適していません。

自動テストの間隔も調整が必要です。10秒に設定すると探測リクエストが頻繁に発生し、ノードが何度も切り替わる可能性があります。一般的な利用には300～600秒が適しています。toleranceを設定すると、2つのノードの差が5～20 msしかない場合の頻繁な切り替えを防げます。ログイン、ショッピングカート、リスク管理の影響を受けやすいサービスでは、固定ノードまたは地域固定のポリシーグループを使用してください。

サブスクリプションの更新後は、ノード名が変わることがあります。正規表現で地域を絞り込む場合は、日本語、英語の略称、サービス提供元でよく使われる名称を同時に対象にします。たとえば日本ノードなら「日本」「JP」「Japan」にマッチさせます。結果が空になった場合は、まず実際のノード名を確認してから式を修正し、空のポリシーグループをそのままルールの出口に指定しないでください。

再現可能なノード選択手順

1. 用途を決める：日常のWeb閲覧、ダウンロード、会議、地域限定コンテンツ、モバイル回線のどれに使うかを明確にします。
2. 地域で絞る：出口の条件を満たすノードを残し、出口IPで実際の地域を確認します。
3. 倍率を確認する：プランの残量を基準に、長期利用に向かない高倍率ノードを除外します。
4. 遅延を連続測定する：3～5回テストし、変動、タイムアウト、混雑時の結果を記録します。
5. 実際の用途で試す：Web閲覧、動画、ダウンロードの少なくとも1つをテストし、URL Testだけに頼らないようにします。
6. プロトコルを比較する：現在のネットワークでTCP系ノードとUDP/QUIC系ノードをそれぞれテストします。
7. ポリシーグループを作る：最終候補のノードを手動、自動、フォールバックのいずれかのグループに登録します。
8. 予備を残す：メインノードとは別に、異なる入口または異なるプロトコルの予備ノードを少なくとも1つ用意します。

最終的な選択は、地域が正しく、接続が安定し、倍率が許容範囲に収まることを確認したうえで、遅延をできるだけ低くするという順番で考えられます。日常のWeb閲覧なら60～100 msで安定する近距離ノードで十分なことが多く、高画質動画では持続帯域を優先して確認します。特定地域のコンテンツでは出口を変えず、不安定な回線では実際のネットワーク切り替えで再接続性能とジッターへの耐性を確認しましょう。

ノードの品質は時間とともに変化します。回線調整、夜間の混雑、通信事業者の経路、サーバーメンテナンスによって、先週の最良ノードが今日の平均的なノードになることもあります。1～2週間ごとに候補グループを再テストし、明らかに遅くなったときはまず予備ノードへ切り替え、その後にローカルネットワーク、DNS、ルール、TUNによる取り込み状態を確認すると、不要な切り分けを減らせます。