Clashのノードの選び方：遅延・倍率・地域・プロトコルの4指標を理解する

まず、ノード選びで解決したいことを明確にする

Clashにサブスクリプションを追加すると、「プロキシ」ページに数十から100以上のノードが表示されることがあります。ノード名には国や地域、回線の略称、倍率、プロトコル、番号などが含まれ、「日本 IEPL 01｜0.8x」や「シンガポール Hysteria2｜1.0x」のように表記されます。これらは単純な速度ランキングではありません。遅延は操作への応答性、倍率は通信量の消費量、地域はアクセス経路と利用可能なコンテンツ、プロトコルは接続確立の方法と通信オーバーヘッドに関係します。

選ぶ前に、まず用途を決めましょう。Web閲覧やリモートターミナルでは低遅延と安定性、サイズの大きなファイルのダウンロードやクラウドストレージの同期では持続的なスループットと倍率が重要です。地域限定コンテンツを見る場合は、先に地域を合わせてから回線を比較します。モバイル回線で頻繁にネットワークが切り替わるなら、パケットロスやローミングへのプロトコルの適応性も確認が必要です。ノード名の「高速」だけを信じたり、遅延テストを1回行っただけで判断したりしても、信頼できる結論にはなりません。

サブスクリプション、プロキシグループ、実際の出口の関係

サブスクリプションにはノード一覧と、場合によってはルールが含まれます。プロキシグループは現在どのノードから選ぶかを決め、プロキシルールはリクエストをそのグループに送るか、直接接続するかを決めます。たとえば動画サービスを「ストリーミング」グループ、Web通信を「ノード選択」グループに割り当てている場合、「ノード選択」でノードを変更しても、動画アプリの出口は変わらないことがあります。

• ノード：サーバーアドレス、ポート、プロトコル、認証パラメータを含む、個別のプロキシ接続先。
• プロキシグループ：手動選択、自動遅延テスト、フォールバック、ロードバランシングに使用するノードの集合。
• ルール：ドメイン、IP、プロセス、ルールセットに応じて、接続を指定したプロキシグループまたは直接接続へ振り分ける設定。
• 出口：リクエストが最終的に経由するサーバー。IP確認サイトやアプリのログで確認できます。

テストを始める前に、「プロキシ」→対象のプロキシグループを開き、別の入れ子グループではなく、特定のノードが選択されていることを確認します。クライアントに現在の経路が表示される場合は、経路の終端が本当に想定した地域になっているかも確認してください。切り分け中はノードを一時的に固定し、自動グループがテスト中に出口を切り替えないようにするのがおすすめです。

指標1：遅延・ジッター・パケットロスを正しく読み取る

ClashのGUIクライアントで行う遅延テストは、通常のICMP Pingとは異なります。クライアントはノード経由でテストURLにHTTPリクエストを送り、接続から応答までの時間を記録します。よく使われるのは、204ステータスを返す軽量なページです。この数値には、ローカルネットワーク、プロキシサーバーまでの回線、プロキシのハンドシェイク、テストサイトの応答時間が含まれます。ノードのダウンロード速度を示すものではありません。

1回だけ遅延が低くても、長期的に安定しているとは限らない

同じ時間帯に3つのノードを測定し、それぞれ68 ms、92 ms、145 msだったとします。68 msのノードが最速に見えますが、5回連続で測ると68、310、75、タイムアウト、240 ms、となり、一方の92 msのノードが88～105 msで安定しているなら、動画、会議、リモート操作には後者のほうが適しています。前者は平均値も最大値も高く、混雑、パケットロス、経路の変動が疑われます。

同じ地域のノードは、次の方法で比較できます。まず進行中の大容量ダウンロードを停止し、同じネットワーク環境で10秒ほど間隔を空けて5回連続測定します。明らかにローカル回線の切断が原因の異常値は1回分として除外し、中央値、最大値、タイムアウト回数を記録します。遅延の中央値が低く、最大値が中央値から大きく離れず、タイムアウトもないノードを優先しましょう。

これらの範囲は、同じネットワーク環境で一次選別するための目安です。中国本土から日本のノードへ接続する場合と、欧州のユーザーが日本のノードへ接続する場合では基準が異なります。家庭のブロードバンド、学校のネットワーク、企業ネットワーク、モバイル回線も単純に比較できません。テストは環境から切り離した固定値を追うのではなく、自分の実際の接続で役立つ情報として行いましょう。

遅延は低いのにダウンロードが遅い主な原因

• テストリクエストが小さく、サーバーの帯域上限や長時間接続時のスループットを反映していない。
• ノードの入口までは近くても、中継回線や対象サイト向けの経路が混雑している。
• サーバーの同時接続数が多く、短いリクエストは処理できても大容量通信が制限されている。
• Wi-Fiの電波が弱い、ルーターの負荷が高い、または通信事業者のピーク時間帯に混雑している。
• ルールによって遅延テストとダウンロードのリクエストが別のプロキシグループに振り分けられている。

一次選別の後は、50 MB～200 MB程度の固定テストファイルを1つ選び、それぞれ30～60秒ダウンロードして速度の安定性を確認します。テストファイルは同じサーバーから取得し、対象サイトの違いによる影響を避けてください。速度テストでも実際の通信量を消費し、倍率付きノードでは倍率分が加算されます。そのため、100以上のノードすべてで大容量テストを行う必要はありません。

指標2：倍率によって通信量の消費量が決まる

ノード名にある0.5x、1x、1.5x、2xなどは、通常、サブスクリプションの通信量に適用される倍率を示します。実際に1 GBのデータを送受信した場合、0.5xノードではプランから0.5 GB、2xノードでは2 GBが差し引かれることがあります。倍率はサブスクリプション提供元が定めるもので、ClashやMihomoが自動計算する性能スコアではありません。ノードの速度を直接示すものでもありません。

具体的な通信量で倍率の適性を判断する

月間プランが100 GBで、動画視聴による実通信量が1日3 GBだとします。1xノードを30日使い続けると約90 GB、1.5xノードでは約135 GBとなり、プランを超過します。0.5xノードなら約45 GBです。Webページをたまに開く程度なら倍率の差は目立たないかもしれませんが、OS更新、クラウドバックアップ、高画質動画を利用するなら、速度より先に倍率を確認しましょう。

1. サブスクリプションの管理画面で倍率の定義を確認し、アップロードとダウンロードの両方がカウントされるか確認する。
2. アプリの再生時間だけでなく、1日の実際の通信量を見積もる。
3. 実際の通信量にノード倍率を掛け、プランの残量と比較する。
4. 高倍率ノードは回線上の明確なメリットがある場合だけ使い、倍率を品質保証と考えない。

低倍率ノードでもピーク時間帯には混雑することがあり、高倍率ノードも単にコストの高い回線にすぎない場合があります。実際の選択では2つのグループに分けるとよいでしょう。0.5xまたは1xの安定したノードを普段の通信に使い、低ジッターや特定地域への接続といった明確な強みを持つ高倍率ノードは、会議、ライブ配信、短時間の作業用に残します。高倍率ノードを常用するより、通信量を管理しやすくなります。

指標3：地域が経路・出口・利用可能なコンテンツに与える影響

ノードの地域には、少なくとも2つの意味があります。1つはサーバーの入口がある地域、もう1つはWebサイトから見える出口IPの所在地域です。多くの場合は一致しますが、中継回線、地域をまたぐ出口、ノード名の誤表記によって異なることもあります。特定地域の出口が必要な場合は、実際のIP位置情報と対象サービスの結果を基準にし、ノード名の国旗や略称だけで判断しないでください。

普段の閲覧では地理的に近い地域を優先する

他の条件が近い場合、距離が近いほど物理的な経路が短くなり、往復時間も小さくなる傾向があります。東アジアのネットワーク環境では、日本、シンガポール、韓国などのノードが低遅延の閲覧に使われます。欧州内のサービスへアクセスするなら、フランクフルト、アムステルダム、ロンドンの出口が目的の経路に適していることがあります。実際の使用感を左右するのは通信事業者間の経路と混雑状況であり、地理的距離は一次選別の条件にすぎません。

まず目的の地域から3～5個のノードを選び、遅延を連続測定します。東京、ロサンゼルス、ロンドンの遅延を同じ一覧に並べ、単純に最小値だけを選ばないでください。用途によって必要な出口が異なるからです。地域限定コンテンツにアクセスする場合は、「地域が正しいか → サービスを利用できるか → 遅延と速度が十分か」の順に確認します。

コンテンツの利用可否が変わる理由

• 出口IPのデータベース上の所属地域と、ノードに表示された地域が一致していない。
• 同じ地域でも、異なるIP帯に対して対象サービスが異なる判定を行っている。
• DNSリクエストはローカルで解決され、実際の通信はプロキシ経由となっているため、地域判定が食い違っている。
• ブラウザーに古いCookie、アカウントの地域設定、位置情報の許可情報が残っている。
• ルールが一部のドメインだけをプロキシ経由にし、ログイン、メディア、APIのリクエストが同じ出口を通っていない。

地域判定が誤る場合は、まず「プロキシ」でノードを固定し、「接続」ページで対象ドメインに適用されたルールとプロキシグループを確認します。その後、対象サイトのデータを削除して再ログインしてください。TUNモードを有効にしている場合は、DNSとルーティングが現在の設定によって同時に管理されているか確認します。システムプロキシだけを使っている場合は、アプリが本当にシステムプロキシ設定に従っているか確認しましょう。

指標4：プロトコルは接続方式に影響するが、速度だけで決まるわけではない

サブスクリプションでよく見かけるプロトコルには、Shadowsocks、Trojan、VMessのほか、MihomoがサポートするVLESS、Hysteria2、TUICなどがあります。プロトコルごとにハンドシェイク、暗号化、トランスポート層、UDP対応が異なりますが、速度はサーバー性能、回線品質、帯域制限、ローカルネットワーク、クライアントのコアにも左右されます。プロトコル名だけを見て「必ず速い」と判断してはいけません。

主要プロトコルで確認したいポイント

Hysteria2とTUICは主にUDP通信を使用します。UDPが許可され、回線との相性がよければ、高遅延や軽度のパケットロスがある環境でも高いスループットを維持できる場合があります。ただし、企業ネットワーク、学校のネットワーク、一部のモバイル回線ではUDPが制限されることがあり、接続不能、ハンドシェイクのタイムアウト、速度の不安定化につながります。その場合は、DNSやルールをすぐにすべて変更するのではなく、まず同じ地域のTCP系ノードへ切り替えて比較してください。

プロトコルの互換性はコアにも左右されます。Clash NyanpasuはMihomoコアと組み合わせて使用できますが、サブスクリプションに含まれる各フィールドが現在のコアのバージョンで認識される必要があります。コアを更新した後も特定種類のノードがすべて失敗する場合は、ログを開き、「unsupported」「authentication failed」「TLS handshake」「timeout」などのメッセージを確認してください。プロトコル非対応、認証エラー、回線タイムアウトは別々の問題であり、対処方法も異なります。

TUNモードを有効にしてもノードが自動的に速くなるわけではない

TUNモードは仮想ネットワークインターフェースを通じて、より多くのアプリの通信を取り込みます。システムプロキシ設定に従わないターミナル、ゲームランチャー、一部のデスクトップアプリに適しています。変わるのは通信がClashへ入る方法であり、プロキシサーバーの帯域が増えるわけではありません。TUNを有効にして速度が低下した場合は、二重プロキシ、MTUの不適合、DNSの迂回、安全ソフトによる遮断が発生していないか確認してください。

デスクトップ版の一般的なレイアウトでは、「設定」→「Clash設定」→「TUNモード」で状態を確認できます。ノードの切り替えは「プロキシ」→プロキシグループ→ノード名から行います。バージョンによって表示名は多少異なる場合があります。比較テストではモードを統一してください。ノードAはシステムプロキシ、ノードBはTUNというように変更すると、結果に通信の取り込み方式の差まで含まれてしまいます。

繰り返し実行できるノード選びの手順

大量のノードがあっても、すべてを一つずつ完全測定する必要はありません。用途、地域、倍率で候補を絞り、短時間のテストで明らかな異常を除外し、最後に実際のアプリで検証します。次の手順なら、通常10分ほどで数十個のノードから普段使いのメインノードと予備ノードを選べます。

1. 用途を決める：Web閲覧、動画、ダウンロード、リモート接続、特定地域のサービスのどれに使うか明確にする。
2. 地域を絞る：必要な出口を提供できる地域から5～10個のノードを残す。
3. 倍率を確認する：プラン残量を基準に、長期利用に向かない高倍率ノードを除外する。
4. 遅延を連続測定する：候補ごとに5回測定し、中央値、最大値、タイムアウトを記録する。
5. 短時間のスループットを測る：残った2～3個のノードを同じファイルで30～60秒テストする。
6. 実際のアプリで検証する：対象のWebページを開く、動画を再生する、またはリモート接続を確立する。
7. 予備ノードを残す：メインノードと予備ノードは、異なるサーバーまたは異なる回線から選ぶのが望ましい。

自動プロキシグループの設定方法

サブスクリプションでローカル設定の上書きが許可されている場合は、url-testを使って候補ノードから遅延の低いものを定期的に選択できます。次の例では300秒ごとにテストし、許容差を50 msに設定しています。複数ノードの差が小さい場合、許容差によって頻繁な切り替えを抑えられます。ノード名は設定内に実際に存在する名前へ置き換えてください。

proxy-groups:
  - name: 日常用自動選択
    type: url-test
    proxies:
      - 日本-01
      - 日本-02
      - シンガポール-01
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

url-testは主にテストURLの応答時間を基準にノードを自動選択し、倍率、地域によるコンテンツ対応、大容量ファイルのスループットは考慮しません。候補リストは事前に絞り、すべての地域と倍率を混在させないでください。可用性を優先する場合はfallbackも検討できますが、実際の用途での検証に代わるものではありません。

よくある誤解とトラブルの切り分け

遅延テストはタイムアウトするのに、Webページは開ける

テストURLが一時的に到達不能、接続元ネットワークによる制限を受けている、またはクライアントのテストタイムアウトが短すぎる可能性があります。その場合でも、ノード自体は他のサイトへのプロキシとして機能することがあります。まずテスト先を安定した軽量ページに変更し、実際の接続とログで判断してください。すべてのノードが同時にタイムアウトするなら、ノードを一つずつ削除するのではなく、ローカルネットワーク、サブスクリプションの状態、コアプロセス、ファイアウォールを優先して確認します。

ノードを選択しても出口が変わらない

最も多い原因は、切り替えるプロキシグループを間違えていることです。「接続」を開き、対象リクエストに適用されたルール、プロキシグループ、ノード経路を確認してください。ルールがリクエストを「ストリーミング」に送っているのに、「ノード選択」だけを変更しても、出口は当然変わりません。ブラウザーで独自のプロキシ拡張機能が有効になっていないか、ターミナルにHTTP_PROXY、HTTPS_PROXY、ALL_PROXYの環境変数が設定されていないかも確認しましょう。

自動選択がいつも複数のノード間を行き来する

ノード間の遅延差がわずか10～30 msの場合、ネットワークの小さな変動だけで順位が入れ替わります。テスト間隔を300～600秒に設定し、約50 msの許容差を設けると、明確なメリットのない切り替えを減らせます。リモートターミナル、会議、長時間接続が必要な作業では、最低遅延を頻繁に追うより、安定したノードを手動で固定するほうが適しています。

同じ地域名のノードなのに性能差が大きい

日本やシンガポールにあるからといって、同じ通信事業者、入口、国際回線、サーバー負荷とは限りません。ノード番号も品質ランクを意味しません。安定しているノードは専用のプロキシグループに記録し、別回線のノードを1つ予備に残しましょう。夕方以降の混雑時間帯にもう一度測定すると、日中の1回だけのテストより長期的な使用感を正確に把握できます。

最後は4つの記録で判断する

ノード選びは、次のような簡単な記録にまとめられます。遅延には中央値と最大値、倍率には実際の消費ルール、地域には実際の出口と対象サービスの結果、プロトコルには現在のネットワークでの接続安定性を記録します。たとえば「日本-02：遅延中央値86 ms、最大112 ms、1x、出口は日本、Trojan、60秒連続ダウンロードが安定」と記録すれば、「日本のノードは速い」より後から比較しやすくなります。

普段使いのメインノードが、すべての指標で1位である必要はありません。安定していて、倍率も許容範囲で、用途に合う出口を使え、実際のアプリで継続利用できるなら、より実用的な選択です。ネットワーク状況は通信事業者の経路、サーバー負荷、時間帯によって変化します。明らかな遅延や停止が出たときに短時間の再テストを行い、毎日ノードを頻繁に切り替えるのは避けましょう。