Clashのノード選び方：レイテンシ、通信量倍率、地域とプロトコルの見方

まず用途を決めてから、一覧の数値を比較する

Clashのノードは、設定で選択するプロキシの出口です。クライアントはノード一覧を表示し、コアが接続を確立します。接続先や出口、経路、料金体系を決めるのはサービス提供元です。ノード名にある「日本」「専用線」「0.5倍」などは通常、提供元が付けた説明であり、コアが性能を検証した結果ではありません。

ノードを選ぶ前に、Web閲覧、大容量ファイルの転送、地域制限のあるサービス、リアルタイム通信のどれを重視するか整理しましょう。Web閲覧では接続確立の速さ、ダウンロードでは安定した転送速度、地域制限のあるサービスでは実際の出口が重要です。音声通話やゲームではUDP対応に加え、ジッターやパケットロスも確認します。レイテンシの数値ひとつですべては判断できません。

• 普段のWeb閲覧：安定して使え、応答のばらつきが小さいノードを優先し、予備の出口も用意します。
• 動画視聴・ダウンロード：夜間の持続速度と通信量倍率を確認し、一度だけの最高速度で判断しないようにします。
• 地域限定サービス：出口IPの地域と、対象サービスに実際にアクセスできるかを確認してから速度を比較します。
• 音声通話・ゲーム：アプリの通信がプロキシを経由していることと、ノードがUDPに対応していることを確認し、アプリ側でレイテンシやパケットロスを調べます。

レイテンシの数値：テスト先・タイムアウト・ばらつき

一覧のミリ秒表示でわかること

Clash系クライアントでは、指定したURLへのプロキシ接続可否と応答時間を測定するのが一般的です。サーバーへのICMP pingや帯域測定とは異なります。結果は、端末から入口までの接続、プロキシのハンドシェイク、出口からテスト先までの経路、接続の再利用状況などに左右されます。クライアントやコアのバージョンによって、計測方法の細部も異なることがあります。

たとえば、テスト先に対してノードAが68 ms、ノードBが126 msと表示された場合、このテストではAの応答が速かったということしかわかりません。実際に使うサイトがBの出口に近ければ、Bのほうが快適な可能性もあります。特定のテスト用ドメインでの順位を、あらゆるWebサイトの速度順位とみなさないでください。

1回の順位より、繰り返し測定した結果が役立つ

1. 同じネットワークとテストURLを使い、大容量ファイルのダウンロードやクラウド同期は一時停止します。
2. 候補の各ノードを約10秒間隔で5回測定し、成功回数と数値の幅を記録します。
3. 普段使うWebサイトを開き、初回表示の速さや連続操作時の引っかかりを確認します。
4. 20:00〜23:00など、普段使う時間帯にも測定し、混雑時の変動を確認します。

以下は判断方法を示すための例であり、本サイトによる特定回線の実測値や性能保証ではありません。

timeoutでも、サブスクリプションが無効になったとは限りません

タイムアウトの原因には、ノードの停止、テスト先への接続不可、DNS名前解決の失敗、ハンドシェイクの失敗、タイムアウト設定が短すぎることなどがあります。まず他のノードも同時に失敗しているか確認し、実際に使うWebサイトでも試してみましょう。すべてのノードで失敗する場合は、端末のネットワークと設定を確認します。特定のノードだけ失敗する場合は、そのノードの接続ログを調べてください。HTTPテストに成功しても、UDP通信が正常とは限りません。

通信量倍率：使用量の計算に使われ、帯域幅を示すものではない

「0.5×」「1×」「2×」は通常、サービス提供元が通信量の課金に適用する倍率です。Clash共通のプロトコル項目ではなく、ノード名に「2×」と書かれていても、コアが帯域幅を自動で2倍にするわけではありません。正確な計算方法は、提供元の利用量に関する説明やアカウント画面で確認してください。

通信量の計算例

提供元が送受信の合計通信量に倍率を掛けてプラン残量から差し引く場合、課金対象の通信量は次のように計算できます：課金通信量 = 実測通信量 × ノード倍率。実測通信量が8 GBの場合、倍率ごとの差し引き量は以下のとおりです。

実際の差し引き量は、送受信の集計方法、GBとGiBの単位差、プロトコルのオーバーヘッド、請求情報の更新遅延にも左右されます。クライアントに表示されるダウンロード量が、アカウント画面の数値と完全に一致するとは限りません。「倍率0」と表示されている場合も、適用期間や速度制限、通信量のルールを確認し、ノード名だけで判断しないでください。

速度測定でも通信量を消費する

小さなデータを使うURLレイテンシ測定の通信量は通常わずかですが、帯域幅の本格的なテストでは大量のデータを転送する場合があります。平均50 Mbpsで30秒ダウンロードすると、データ量は約50 ÷ 8 × 30 = 187.5 MBです（追加のオーバーヘッドは含みません）。ノード倍率が2倍なら、この計算方法では約375 MBが差し引かれます。何十ものノードで一斉に帯域幅を測定すると、プランの残量をすぐに消費する可能性があります。

ノードの地域：入口・出口・Webサイト側の判定を区別する

「香港入口｜米国出口」と表示されたノードは、近くのサーバーに接続してから中継回線を経由し、米国から対象サイトにアクセスする構成の場合があります。入口は端末からの接続経路に影響し、出口によってWebサイトに表示されるIPが決まります。設定にあるサーバーのドメイン名やアドレスは入口を示すだけの場合があり、それだけでは最終的な出口の国を判断できません。

アクセス先に合わせて地域を選ぶ

• 一般的なWebサイト：まず接続経路が短そうな地域を試し、ほかの地域とも比較します。物理的に近くても、通信事業者の経路が短いとは限りません。
• 特定地域向けのコンテンツ：ノード経由で出口IPを調べ、対象サービスへのアクセス結果を確認します。IPデータベースの更新には時間がかかることがあります。
• 同じアカウントを継続利用：出口の地域をなるべく固定し、地域を頻繁に切り替えて追加の本人確認が発生するのを避けます。
• 海外のファイルをダウンロード：実速度は出口とダウンロード元の接続状況にも左右されます。端末に近いノードだけでなく、配信元に近い出口も比較しましょう。

地域が合っていても、特定のサービスを必ず利用できるとは限りません。サービス側はデータセンターのIP、アカウントの地域、支払い情報、その他のリスク要因をもとにアクセスを制限することがあります。「動画配信サービス対応」などのノード表示は変わる可能性があるため、対象サービスで現在の利用可否を確認し、利用規約を守ってください。

「専用線」「直結」「中継」の表示を確認する

これらはサービス提供元が回線構成を説明するための表示で、クライアント共通の検証基準があるわけではありません。中継によって混雑が改善することもあれば、余計な経路が増えることもあります。「専用線」という名称だけで、高負荷時の性能がわかるわけではありません。ノード名だけで比べず、入口のネットワーク、測定時刻、実際の出口、安定性を記録して比較しましょう。

プロトコルの種類：まずコアとの互換性、次にネットワーク環境を確認

Clashはクライアントのエコシステムで広く使われる名称ですが、クライアントによって採用するコアは異なります。mihomoは旧Clash Metaプロジェクトを引き継いだもので、対応プロトコルや設定項目は旧版Clashコアと完全には同じではありません。まずクライアントの「バージョン情報」やコア情報で、コアの名称とバージョンを確認します。そのうえで、該当バージョンのドキュメントとサブスクリプションのtype項目を照らし合わせましょう。クライアントの外側のアプリでYAMLを読み込めても、コアがすべてのノードを使えるとは限りません。

プロトコル名だけでは速度を比較できない

同じサーバーでプロトコルを切り替えた結果と、異なるサーバー同士の比較は別の話です。回線容量、サーバー負荷、輻輳制御、利用中の通信事業者の経路は、プロトコル名以上に速度を左右することがあります。Hysteria2やTUICが快適に使えるネットワークもありますが、UDPが制限されていると接続できない場合があります。一方、別のネットワークではTCPベースの方式のほうが安定することもあります。

ノードのトランスポートプロトコルと、アプリのUDP対応は分けて考えましょう。プロトコルがUDPを運べても、サービス提供元がUDPを開放しているとは限らず、現在の設定で有効とは限りません。ブラウザーでWebページが開けても、ゲームや音声通話の通信が同じノードを通るとは限りません。

手動選択と自動テスト：プロキシグループの役割

ノードは出口そのもの、プロキシグループは利用する出口を決める仕組みです。手動選択グループは地域やアカウントを固定したい場合に便利です。url-testは指定URLのテスト結果をもとに自動選択し、fallbackは通常、利用可能なノードを順番に使います。こうした機能は主に接続可否や応答時間への対応を目的としており、ダウンロード速度が最速のノードを自動で選ぶものではありません。

mihomoのプロキシグループ設定例

以下の例では、既存の設定に「日常用-A」と「予備-B」という2つのノードが定義されているものとします。プロキシグループだけを示した例で、サブスクリプション全体ではありません。実際のノード名が異なる場合は、既存の名前に合わせて変更してください。変更しないと、存在しないプロキシを参照するエラーが発生します。

proxy-groups:
  - name: 日常用自動
    type: url-test
    proxies:
      - 日常用-A
      - 予備-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 手動選択
    type: select
    proxies:
      - 日常用自動
      - 日常用-A
      - 予備-B

interval: 300はテスト間隔を300秒に設定する項目です。実際のテスト実行タイミングは、コアの遅延テストなどの動作にも左右されます。tolerance: 50は切り替えの許容差を50 msに設定し、小さな差による頻繁な切り替えを抑えます。例のテスト先URLにもノード経由でアクセスするため、接続できるかどうかが判定に影響します。用途に合わせて、安定したテストURLを選んでください。

通信にこのグループを使うには、該当するルールの転送先を「手動選択」または「日常用自動」に設定する必要があります。プロキシグループを追加しただけでは、既存のルールは変わりません。サブスクリプション管理型のクライアントでは、更新時に元ファイルが上書きされることがあります。クライアントのオーバーライドやマージ機能でカスタム設定を保存してください。詳しい手順は設定ガイドをご覧ください。

TUNは速度を上げるスイッチではない

TUNは、より多くのアプリの通信を取り込むための機能です。一方、システムプロキシは通常、プロキシ設定に従うアプリにのみ適用されます。TUNを有効にすると、どの通信がコアに入るかは変わりますが、ノード回線の帯域幅が増えるわけではありません。ブラウザーは正常なのに他のアプリがプロキシを経由しない場合は、通信の取り込み方法を確認しましょう。同じノードを経由していることを確認しても遅い場合は、回線や接続先を比較してください。速度測定の方法を一律にTUNの切り替えで判断しないようにしましょう。

10分でノードを選ぶ：繰り返し使える確認手順

1. 設定を確認：サブスクリプションが読み込まれていること、コアがノードのプロトコルに対応していること、プランの残量と有効期限に問題がないことを確認します。
2. 地域と倍率で絞り込む：用途に合わせて候補を2〜3個選び、出口の地域と課金倍率を記録します。
3. 接続可否を測定：同じURLを使って5回連続で測定し、頻繁にタイムアウトするノードや数値の変動が大きい候補を除外します。
4. 実際の用途で試す：普段使うページを開く、動画を再生する、同じファイルを短時間ダウンロードするなどして、速度の最高値だけで使い心地を判断しないようにします。
5. 接続先を確認：接続画面でルール、プロキシグループ、最終的なノードを確かめ、直接接続の結果をプロキシ経由の結果と比べないようにします。
6. 予備を用意：普段使うノードを1つと、異なる回線の予備ノードを1つ決め、混雑する時間帯に再確認します。

記録は簡単で構いません。日付、ネットワークの種類、ノード名、5回分のレイテンシ、30秒間の平均速度、倍率、対象サービスの利用可否を残します。MbpsとMB/sは異なります。オーバーヘッドを含めない場合、100 Mbpsは約12.5 MB/sです。単位をそろえて比較すれば、表示方法の違いを8倍の性能差と誤解せずに済みます。

同じ時間帯にすべての候補が遅くなった場合は、別のローカルネットワークでも比較し、バックグラウンドのアップロード、端末のDNS、通信の取り込み設定を確認します。特定のノードだけ遅い場合は、出口を変えて比較するのが有効です。原因をさらに調べるには、トラブル対処をご覧ください。ノードを選ぶときに重視すべきなのは、実際の用途で安定して使えるか、料金に見合うかです。一覧で最も小さい数値だけを基準にしないでください。