Clashのプロキシノード選び方|遅延測定・通信量倍率・地域表示・プロトコルを解説
Clashの遅延測定値の見方と限界、ノード名の倍率・地域表示、プロトコルごとの速度やバッテリー消費への影響を解説。用途に合ったノード選びに役立ちます。
ノード選びは利用可否を確認してから、安定性とコストを比較
サブスクリプションを読み込むと、ノード一覧に地域、倍率、回線、プロトコル名が並ぶことがあります。ClashのGUIクライアントにはこうした情報が表示されますが、ノード名は通常、サブスクリプション提供元が付けたもので、コアが検証した回線情報ではありません。ノードを選ぶときは、まず目的のサービスに接続できるか確認し、そのうえで遅延の変動、通信を続けたときの速度、通信量のコストを比べましょう。一覧で最も小さいミリ秒数を選ぶだけより確実です。
- 設定とモードを確認:読み込んだ設定を有効にし、ルールモードを選択します。アクセス先のサイトに適用されるルールが、テスト対象のプロキシグループを指していることを確認してください。
- 候補を絞る:まずは3つのノードを選び、2つの地域または異なる回線種別を含めます。数百のノードを一度にテストするのは避けましょう。
- 遅延を複数回測定:同じネットワーク、同じテストURLで5回測定し、最速値だけでなく失敗回数と中央値を記録します。
- 実際の用途で確認:よく使うサイトを開く、動画を再生する、サイズの分かっているファイルを転送するなどして、継続速度や途中で通信が途切れないかを確認します。
- メインと予備を用意:普段使いのノードを1つ選び、異なる回線の予備ノードも残しておきます。夜間の混雑時間帯にも再確認しましょう。
Clashの遅延測定:ミリ秒の数値が示すもの
Clashやmihomoで一般的な遅延テストは、指定したプロキシ経由でテストURLにHTTPリクエストを送る方式です。ノードサーバーに通常のICMP pingを送るわけではありません。測定値はプロキシ接続の確立、回線の往復、接続先サイトの応答、キャッシュやコネクションの再利用などに左右されます。計測の細部はコアとクライアントの実装によって異なります。
たとえば表示が80 msなら、このテスト経路では応答が比較的速かったと分かります。しかし、ダウンロード速度が必ず速いとは限らず、別のサイトでも同様に快適とは限りません。テスト先に接続できない、DNSの名前解決に失敗する、ノードの認証情報が無効といった原因でもタイムアウトすることがあります。クライアントに表示されるtimeoutは今回のテストが失敗したことを示します。原因はログとあわせて確認してください。
テスト先とネットワークを固定し、5回測定
自動遅延テストでは、https://www.gstatic.com/generate_204のように小さな応答を返すURLがよく使われます。2つのノードを比べるときは、テストURL、Wi-Fi、ルール設定を同時に変えないでください。以下は結果の読み方を示す仮のデータであり、本サイトによる実測値でも、特定のサブスクリプションサービスの性能を示すものでもありません。
| 候補ノード | 5回の測定結果 | 選定のポイント |
|---|---|---|
| 候補A | 72、76、74、79、75 ms | 中央値75 ms、変動は小さい |
| 候補B | 39、240、タイムアウト、310、46 ms | 最速値は低いものの、失敗と大きな変動がある |
| 候補C | 118、121、119、124、120 ms | 中央値120 ms。継続的な通信速度をさらに確認 |
メッセージアプリや操作の多いWebページでは、応答の安定性が重要です。この例では、最速値だけで選んだBよりAを先に試すのがよいでしょう。大容量ファイルの転送ではスループットも確認が必要です。遅延がやや高いCでも、利用できる帯域が広ければ、継続的な通信速度は上回る可能性があります。5回のテストはあくまで候補を絞るためのもので、長期的な信頼性を判断することはできません。
自動遅延テスト用グループの設定
以下のmihomoのプロキシグループ設定例では、既存の2つのノードをurl-testで比較します。設定内にHK-01とJP-01が定義されている場合に限り、この例を有効な参照として使えます。実際に使う際はサブスクリプションに記載されたノード名に置き換え、既存のproxy-groups一覧に追加してください。
proxy-groups:
- name: Auto
type: url-test
proxies:
- HK-01
- JP-01
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
interval: 300はテスト間隔が300秒であることを示します。すぐにテストが実行されるかどうかは、遅延読み込みなどの設定にも左右されます。tolerance: 50は切り替え時の許容値です。遅延のわずかな変化による頻繁な切り替えを抑えるためのもので、ノードのタイムアウト上限ではありません。- 自動選択の基準は指定したテストURLへの遅延です。動画サービスの利用可否、アカウントの不正利用判定、ダウンロード速度などは自動評価されません。
GUIクライアントでは、サブスクリプションの上書き機能や拡張設定でプロキシグループを管理する場合があります。サブスクリプションからダウンロードしたファイルを直接編集すると、次回の更新時に変更が上書きされることがあります。クライアントのローカル上書き機能を確認してから、カスタムのテストグループを保存しましょう。ルールからプロキシグループを参照する方法は、ルールによる振り分けガイドをご覧ください。
通信量倍率:ノード名とサブスクリプションの容量消費
ノード名にある0.5x、1x、2xは、通常、サービス提供元が定める通信量の換算倍率を示します。Clashコアの速度設定でも、帯域幅の倍率でもありません。2xだから速度が2倍になるわけではなく、0.5xでも通信速度が半分になるわけではありません。実際の容量消費の計算方法は提供元によって異なるため、案内やアカウントの使用量表示を確認してください。
実際の使用量からコストを見積もる
あるサービスがアップロードとダウンロードの合計通信量に倍率をかけて容量を消費すると明記しているとします。この場合、合計4 GBの通信で、0.5倍のノードなら約2 GB、1倍なら約4 GB、2倍なら約8 GBが消費されます。ここでは同じ単位を使って概算しています。サービス側が10進数のGBと2進数のGiBのどちらを使うか、また集計方法の違いによって表示量は変わることがあります。
- 長時間の動画視聴やOSアップデート:通常倍率のノードで安定した通信速度を優先して確認し、高倍率の回線は必要な用途に限って使います。
- 地域限定サービスをたまに使う場合:手動選択用のグループを分け、すべての通信が高倍率ノードを通らないようにします。
- ノード名の表示と管理画面が一致しない場合:サブスクリプションを更新して提供元のお知らせを確認し、古いノード名から現在の料金体系を推測しないでください。
地域表示:接続先の入口、出口IP、利用するサービス
「香港」「日本」「米国」といった表示は、出口の地域を示す場合もあれば、回線のマーケティング上の名称にすぎない場合もあります。中継ノードでは、接続の入口と、Webサイトへアクセスする際の出口が別の地域にあることもあります。クライアントに表示される接続先サーバーの情報だけでは、アクセス先サイトから見た出口の場所は証明できません。
地域名や国旗だけでなく、利用するサービスで出口を確認
- アクセス先サイトに適用されるプロキシグループで、候補ノードを手動選択します。
- 既存の接続を終了してページを開き直します。必要に応じてアプリを完全に終了してから再起動し、以前のセッションが使われないようにします。
- 信頼できるIPアドレス確認サービスで出口IPと地域を調べ、実際に利用するサービスでも接続できるか確認します。
- 両者の判定が異なる場合は、IPデータベースの更新遅れ、アカウントの地域、支払い情報、サービス独自の制限などを確認してください。
表示地域が合っていても、サービスを利用できるとは限りません。サービス側がデータセンターのIPを検出したり、アカウントの地域との一致を求めたり、同じ出口からの大量アクセスを制限したりすることがあります。DNS設定がサービスの接続先に影響する場合もありますが、DNSを変更しても出口IPの国を変えることはできません。ログイン地域を固定する必要があるアカウントでは、出口をできるだけ固定し、自動テストグループによる国をまたいだ頻繁な切り替えを避けてください。
「専用線」「中継」「直結」も意味を分けて考えましょう。直結ノードは通常、利用者のネットワークから遠隔サーバーへ直接接続します。中継回線は転送用の入口を経由します。専用線が具体的に何を指すかはサービス提供元のプランによって異なります。名称だけではエンドツーエンドの経路を証明できません。混雑、迂回、パケットロスの有無は、時間帯を変えて実際の用途で確認してください。
プロトコルの種類:互換性、UDP、モバイル端末のバッテリー消費
ClashのGUIクライアントは画面表示と設定管理を担いますが、対応プロトコルは実行するコアとそのバージョンによって異なります。オリジナルのClashとClash Meta(現mihomo)では対応機能が異なります。サブスクリプション変換を行っても、古いコアにないプロトコル実装が自動で追加されるわけではありません。「不明なプロキシタイプ」などの設定エラーが出たら、同じ種類のノードを次々と切り替えるのではなく、まずコアのバージョンを記録し、プロトコルの対応状況を確認してください。
| プロトコル | 接続の特徴 | 確認事項 |
|---|---|---|
| Shadowsocks | TCPに対応。UDPへの対応はノード設定と実行環境によって異なる | 暗号化方式、プラグインの要否、クライアントとの互換性 |
| Trojan | 一般的な実装ではTLSを使って接続を確立 | サーバー名、証明書、UDP対応、サーバー側の設定 |
| VMess / VLESS | 異なるトランスポート層やセキュリティ設定を組み合わせ可能 | トランスポート設定、TLSまたはREALITYの設定、コアの対応状況 |
| Hysteria2 | QUICベース。下位層のUDP通信が可能であることが必要 | ネットワークでUDPが制限されていないか、サーバー設定、帯域幅の設定 |
| TUIC | QUICベース。下位層のUDP通信が可能であることが必要 | コアの実装、プロトコルのバージョン、サーバーとの互換性 |
プロトコル名だけで速度を順位づけることはできない
プロトコルの性能は、サーバー負荷、ネットワーク品質、輻輳制御、トランスポート層のカプセル化、端末の処理能力などに左右されます。同じプロトコルでもノードによって大きな差が出ることがあります。UDPが制限されたネットワークでは、Hysteria2やTUICが接続を確立できない場合がありますが、別のネットワークでは良好に動作することもあります。ゲームや音声通話などのUDPアプリでは、ノード、ルール、端末の接続方式がすべて該当する通信に対応している必要があります。ブラウザーでWebページを表示できるだけでは、UDP経路が正常とは判断できません。
バッテリー消費は同じ用途で比較
スマートフォンのバッテリー消費は暗号化だけで決まりません。電波が弱い状態、通信の再送、頻繁な速度テスト、バックグラウンド接続、大量のデータ通信も消費を増やします。TUNモードは通信を取り込むための仕組みであり、新しいプロキシプロトコルではありません。より多くのアプリ通信がプロキシコアを通るようになる場合があるため、消費量の変化を選択したノードのプロトコルだけに結びつけることはできません。
- 同じWi-Fi、近い画面輝度、同じ用途で比較します。たとえば、同じ画質で動画を20分間連続再生します。
- 不要な高頻度テストを停止し、モバイル回線やバッテリーへの影響を減らします。
- OSのバッテリー使用状況と端末の温度を確認します。短時間のバッテリー残量の変化は、あくまで大まかな目安です。
- 特定のノードだけで発熱や通信切断が目立つ場合は、再接続のログとサーバー負荷を確認してから、プロトコルを変更するか判断してください。
実効速度の確認:ローカルポートと再現可能な記録
クライアントの「遅延が小さい」というテストだけでは、ダウンロードを続けたときの速度は分かりません。まずよく使うサイトで応答を確認し、その後、短時間かつサイズを固定した転送で実効速度を確認します。テスト中はOSの更新やほかのダウンロードを一時停止し、ネットワーク、日時、ノード、倍率、用途を記録してください。夜間の混雑時間帯にも同じ方法で再測定します。
ローカルHTTPプロキシ経由でリクエストを確認
現在の設定でmixed-portが実際に7890なら、以下のコマンドでローカルプロキシ経由のサンプルサイトにアクセスできます。Windowsでは明示的にcurl.exeを使います。macOSやLinuxでは通常curlを使います。ポートが7890以外の場合は、クライアントに表示されている値に変更してください。
curl -x http://127.0.0.1:7890 -o /dev/null -sS \
--connect-timeout 10 --max-time 30 \
-w "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" \
https://example.com/
上記はmacOS/Linux向けのコマンドです。Windowsでは次の1行を使用できます。
curl.exe -x http://127.0.0.1:7890 -o NUL -sS --connect-timeout 10 --max-time 30 -w "connect=%{time_connect}s first_byte=%{time_starttransfer}s total=%{time_total}s\n" https://example.com/
ここでのtime_connectは主にローカルHTTPプロキシへの接続時間であり、遠隔ノードへの遅延ではありません。time_starttransferには最初の1バイトを受信するまでの複数の処理時間が含まれます。これは小さなリクエストによる確認であり、帯域幅テストではありません。また、実際の送信先はコアのルールに従って選ばれます。「接続」画面で対象ドメインに適用されたプロキシグループをもう一度確認してください。
単位をそろえて速度の読み違いを防ぐ
ダウンロードツールではMB/s、ネットワーク帯域幅ではMbit/sがよく使われます。10進数で換算すると10 MB/sは約80 Mbit/sです。100 Mbit/sの回線は理論上12.5 MB/sに相当しますが、実際の速度はプロトコルのオーバーヘッドや回線のボトルネックにも左右されます。大きなファイルをテストするときは、接続直後の瞬間的なピークではなく、速度が安定した区間を確認してください。
よくあるトラブル:遅延は正常なのにアクセスできない
ノードの遅延測定は正常なのに、特定のサイトを開けないのはなぜ?
テストURLとアクセス先のサイトは別のサービスです。まず対象の接続に適用されたルールとプロキシ経路を確認し、その後、接続先のDNS、出口地域による制限、サーバーからの応答を調べます。ログに証明書エラーがある場合は、システム時刻、サーバー名、サブスクリプションの設定を確認してください。証明書の検証を無効にする方法を、通常の解決策として使うべきではありません。
ノードを切り替えてもサイトの地域表示が変わらないのはなぜ?
すでに確立した接続は、以前のノードを使い続けることがあります。ブラウザーやアプリにセッション情報が保存されている場合もあります。関連する古い接続を終了してリクエストし直し、ルールが切り替え後のプロキシグループを実際に指しているか確認してください。出口IPが変わってもページの地域表示が変わらない場合は、アカウント設定、キャッシュ、サイト独自の地域判定方法を確認します。
自動遅延テストはすべての用途に適している?
遅延が小さく利用可能なノードを自動選択したい普段のWeb閲覧には向いています。利用国や出口IPを固定したい場合、または長時間のセッションが必要な用途では、手動選択グループを使うか、同じ地域で用途が合うノードだけを自動グループに入れましょう。自動グループに高倍率のノードが含まれると、切り替えによって通信コストが変わることもあります。
日常のノード選びは、ノード名、出口地域、倍率、5回分の遅延、実際の用途での結果、テスト日時を記録するだけでも整理できます。まず失敗や大きな変動のあるノードをデータから除外し、用途に合わせてメインと予備を残しましょう。クライアントのインストールや接続方法はプロキシ接続ガイドをご覧ください。プロキシグループとTUNの違いが分からない場合は、先に用語解説をご確認ください。