Clash ノード選択ガイド:レイテンシ・倍率・地域・プロトコルの4指標で選ぶ方法

ノードリストの表示情報が示すもの

クライアントのプロキシグループ画面を開くと、各ノード名の後ろに数値やマークが表示されます。レイテンシの数値、倍率のバッジ、地域コードなどです。これらの情報は一見シンプルですが、解釈を誤ると「速そうに見える」ノードを選んでも実際には頻繁にカクつくことになります。ノードを正しく選ぶには、まずこれらの指標がそれぞれ何を測っているのかを理解する必要があります。各指標は測る軸が異なり、互換性はありません。

ノードリストの本質はサブスクリプションが提供する設定ファイルであり、各項目は config.yaml の proxies フィールド下にある1つのアウトバウンド設定に対応し、サーバーアドレス、ポート、プロトコル種別、認証パラメータを含みます。クライアントが行っているのは、これらの項目を選択可能なリストとして描画し、その上に自前で実装した速度測定と状態検知のロジックを重ねることです。そのため同じサブスクリプションでも、クライアントが異なればノード数やパラメータは一致していてもレイテンシの数値が変わることがあります。測定先のアドレス、測定頻度、タイムアウトの閾値がクライアントごとに統一されていないためです。

レイテンシ測定が示す意味と、低レイテンシが高速度を保証しない理由

クライアントに表示されるレイテンシの数値は、多くの場合1回のHTTPまたはTCP探測の往復時間(RTT)です。探測対象は通常固定のテストアドレスで、軽量なエンドポイントにリクエストを送り、最初のバイトが返るまでの時間を記録するのが一般的な方式です。この数値は「接続を確立して最初のレスポンスを得る」までにかかる時間をミリ秒単位で表したもので、数値が小さいほど端末からプロキシサーバー、テスト対象までのハンドシェイクが速いことを意味します。

しかし低レイテンシは高いダウンロード速度を意味しません。これは別々の指標です。レイテンシは往復時間を測るもので、速度は単位時間あたりに転送できるデータ量を測るものであり、後者は帯域幅、同時接続数、サーバーの現在の負荷、経路の混雑状況など複数の要因に左右されます。典型的な例として、あるノードのレイテンシが80msと理想的に見えても、サーバーの出口帯域が多数のユーザーに占有されており実際のダウンロード速度は数百KB/sしかない、というケースがあります。一方でレイテンシ250msのノードでも出口帯域に余裕があれば、ダウンロード速度は帯域上限まで出ることもあります。つまりレイテンシは選別の最初のふるい(タイムアウトやレイテンシ1000ms超えなど明らかに使えないノードを除外する)にしか使えず、唯一の並べ替え基準にはできません。

また、測定頻度がノードの生存状態に与える影響にも注意が必要です。自動測定機能を備えたクライアントもありますが、間隔を短く設定しすぎるとサーバーに無用なリクエスト負荷をかけ、サーバー側のレート制限に異常なトラフィックと誤認されて一時的に制限されることもあります。手動測定、あるいは10数分ごとの自動測定で十分であり、数秒おきに間隔を設定する必要はありません。

流量倍率の計算方法と実際の消費量への影響

ノード名の後ろにある倍率表示(x0.5、x1、x2やパーセント表記が一般的)は、そのノードがサブスクリプションの流量をどれだけ消費するかを示す係数です。倍率は速度の速さを示すものではなく、課金の重みです。x0.5倍率のノードで1GBダウンロードすると、実際に流量パッケージから減るのは0.5GBのみです。x2倍率のノードで1GBダウンロードすると、2GB分が減算されます。

倍率が異なる主な原因には、ノードが位置する地域の帯域コストが高い(海外の主要出口など)、ピーク時間帯限定の割引措置である、あるいは事業者が倍率を使って負荷が軽い拠点にユーザーを誘導し負荷を分散させている、といったケースがあります。低倍率ノードは負荷が重かったり回線が混雑している拠点に対応することが多く、高倍率ノードは回線品質が良い分コストも高くなる傾向があります。これはトレードオフの関係であり、「倍率が低くて回線も良い」という都合の良い話は基本的に存在しません。

• 日常のWebブラウジング・メッセージアプリ: 速度への要求は高くないため、低倍率ノードを優先すれば月間流量パッケージの利用期間を大きく延ばせます。
• 大容量ファイルのダウンロード・高画質動画・クラウド同期: 倍率が中程度でもレイテンシと速度の実測が良好なノードを優先し、流量を節約しようとして接続を長時間占有し体感が悪化するのを避けましょう。
• 緊急対応・短時間の優先タスク: 倍率を気にせず、最も安定して動作するノードを直接選んで構いません。

プロキシグループでは、低倍率ノードを「日常グループ」、高倍率・高品質のノードを「高負荷グループ」としてまとめ、ルールベースの振り分けと組み合わせてアクセス先のドメインやアプリの種類に応じて適切なグループへ自動的に割り振るのがおすすめです。すべての通信を同一ノードに通す必要はありません。

地域別ノードの選び方と、解除できるコンテンツの違いが生じる理由

ノード名にある地域コード(HK、SG、JP、USなど)は、サーバーが物理的に設置されている地域を示しています。これは2つの点に直接影響します。よく使うサービスまでの物理的な経路距離と、アクセスできるコンテンツライブラリのバージョンです。地理的に近いほど経路のホップ数は少なくなり、レイテンシの基礎値も低くなる傾向があります。これが近隣地域のノードがレイテンシランキングの上位によく登場する理由です。

解除できるコンテンツの違いの本質は、対象サービスがアクセス元の出口IPから地域を判定し、地域ごとに異なるコンテンツライブラリや機能を提供している点にあります。つまり、サブスクリプション上の地域コードがある国を示していても、サーバーの実際の出口IP帯が対象サービスに別の地域と判定されたり、データセンター/プロキシのIP帯としてマークされていたりすれば、解除は失敗します。逆に言えば、同じ地域コードでも事業者が調達しているIP帯の品質はまちまちであり、名前だけを見て解除効果が同じだと判断することはできません。

地域ノードを選ぶ実践的な考え方:

1. まず主な用途が「近い地域でレイテンシを下げること」か「特定地域のコンテンツにアクセスすること」かを明確にします。両者の優先順位は異なります。
2. レイテンシ重視の場合は、地理的に近くレイテンシの基礎値が低い地域を優先します。
3. コンテンツアクセス重視の場合は、候補ノードで実際にアクセステストを行い、対象コンテンツが正常に表示されることを確認します。ノード名の地域タグだけを見て判断してはいけません。
4. 同じ地域に複数のノードがある場合は、順番に速度と安定性を実測し結果を記録しておくと、毎回感覚だけで試行錯誤するのを避けられます。

各プロトコルの安定性と速度のトレードオフ

ノード項目のプロトコル種別は、接続の実装方式を決定します。プロトコルごとに耐干渉性、伝送効率、ハンドシェイクコストの重視点が異なるため、選択時にはネットワーク環境と組み合わせて判断する必要があり、あるプロトコルが絶対的に他より優れているとは言えません。

選択の原則を簡単にまとめると次のとおりです。ネットワーク制限が少ない環境であれば、Shadowsocksはハンドシェイクが速くCPU負荷も低いため、レイテンシの面で最も直接的な選択肢になります。回線が干渉を受けやすい、あるいはディープパケットインスペクションが存在する環境では、TLS偽装ベースのプロトコル(Trojan、VLESS+TLSなど)の方が安定しますが、ハンドシェイク段階で数十ミリ秒のコストが増えます。パケットロス率が高いネットワーク(基地局の切り替えが頻繁なモバイル回線など)では、QUICベースのプロトコルの方が純粋なTCP方式より再送回復効率が高い傾向があり、予備グループとして採用する価値があります。

mihomoカーネル(Clash Metaブランチ)はプロトコル対応の範囲がより広く、Hysteria2、TUIC、VLESS、Shadowsocks 2022といった比較的新しい実装をカバーしています。サブスクリプションがこれらのプロトコルのノードを提供しているのにクライアントで接続が常に失敗する場合は、まずクライアントに内蔵されているのがmihomoカーネルかどうかを確認してください。オリジナルのClashカーネルはこれらの新しいプロトコルに対応していません。

4つの指標を組み合わせた再現可能なノード選択フロー

レイテンシ、倍率、地域、プロトコルのいずれか1つだけを見ても、ノードの良し悪しを決定するには不十分です。実際の運用では以下の順序で一通り確認し、主観的な感覚を再現可能な判断ステップに置き換えることをおすすめします。

1. ステップ1:レイテンシで一次選別する。 プロキシグループを開き、全体の速度測定を一度実行し、レイテンシが1000msを超えるまたはタイムアウトを示すノードを除外します。残る候補プールは通常全ノードの3〜5割程度になります。
2. ステップ2:用途に応じて地域範囲を絞る。 今回解決したいのが「日常アクセスのレイテンシを下げる」ことか「特定地域のコンテンツにアクセスする」ことかを明確にし、用途に応じて候補プールを対応する地域に絞り込みます。
3. ステップ3:プロトコルとネットワーク環境が合っているか確認する。 現在のネットワークに明らかな干渉や高いパケットロスがある場合は、TLS偽装系またはQUIC系プロトコルのノードを優先して残し、現在の環境で接続失敗を繰り返すプロトコル種別を除外します。
4. ステップ4:流量予算に応じて倍率の方針を決める。 月間の流量パッケージに余裕があれば倍率を気にする必要はありません。逼迫している場合は低倍率ノードをデフォルトグループに設定し、高倍率ノードは重要なタスク用に残しておきます。
5. ステップ5:実測ダウンロード速度で最終確認する。 残った2〜3件の候補それぞれでテストファイルを1回ダウンロードし、速度が安定していて変動が小さいものを常用ノードに選びます。レイテンシの数値が最も小さいものを選ぶわけではありません。

このフローを毎日繰り返す必要はありません。サブスクリプションが更新されたときや、明らかにカクつきを感じたときに一通り実行すれば十分です。結果をプロキシグループに固定し、ルールベースの振り分けと組み合わせて異なる種類の通信を適切なグループに自動的に落とし込む方が、毎回手動でノードを切り替えるより手間がかかりません。

よくある誤解とトラブルシューティングの考え方

ノード選択で陥りやすい誤りは、いくつかのタイプに集中しています。

• レイテンシランキングの1位だけを信じる。 ランキング1位は多くの場合短時間の探測結果であり、継続的な負荷下での実際のパフォーマンスを表すものではありません。前述の実測ダウンロード速度と合わせて判断することをおすすめします。
• プロキシグループの策略種別を無視する。 プロキシグループ自体にも策略の種類があり、たとえば自動選択グループはレイテンシに応じて自動的に切り替わり、フェイルオーバーグループはノードが失活すると次のノードへ自動的に切り替わります。手動で特定のノードを固定選択したのに常に自動的に切り替えられてしまう場合は、まずこのグループの策略種別を確認してください。何度も手動で選び直す必要はありません。
• 地域コードを解除の保証だと思い込む。 前述のとおり地域コードはサーバーの設置場所を反映するだけで、実際の解除効果は出口IP帯によって決まります。解除に失敗した場合はまず同じ地域の別のノードに切り替えて試し、いきなりその地域を諦めないようにしましょう。
• 倍率が低ければ低いほど良いという誤った直感。 低倍率は通常負荷の重さを伴うため、長期的に最低倍率のノードだけを使うとピーク時の混雑に遭遇する回数が増えます。用途に応じてグループを使い分けることをおすすめします。画一的に扱わないようにしましょう。

あるノードが長期間にわたって異常な状態(レイテンシが不安定、頻繁に切断される)を示す場合は、まずノードや回線自体の問題を疑い、同じ地域の別のノードに切り替えて検証してみてください。それでも解決しなければ、ローカルのネットワーク環境やクライアントの設定を確認することを検討しましょう。