Clashのノード選び方|レイテンシ・通信量倍率・接続先地域・プロトコルを比較
レイテンシ測定の見方、通信量倍率の計算、出口地域の選び方、プロトコルの比較まで、使えるノードを選ぶ手順を解説します。
接続先地域と互換性を確認してから、レイテンシとコストを比較
Clashのノード一覧にある数値や名称だけでは、判断できることに限りがあります。レイテンシが低くてもダウンロードが速いとは限らず、「日本」と表示されていても接続先サイトが日本からのアクセスと認識するとは限りません。プロトコル名だけで回線の品質も判断できません。用途を明確にしたうえで、同じ条件で比較しましょう。
一般的なWeb閲覧では接続成功率と応答速度、動画視聴ではサービスの利用可否と安定した通信速度が重要です。オンライン会議ではUDP対応やジッター、実際の通話品質も確認しましょう。1回の測定結果だけで並べ替えると、短時間の応答は速くても夜間に頻繁に途切れる回線を選んでしまうことがあります。
- 目的を明確にする:必要な出口地域、UDPの要否、サービスのアカウント地域制限を確認します。
- 互換性を確認する:サブスクリプションを正常に読み込めること、使用中のコアがノードのプロトコルと追加パラメーターに対応していることを確認します。
- 条件をそろえて測定する:同じネットワーク、同じ測定先、同じ時間帯で、レイテンシと実際の用途での動作を比較します。
- 料金を確認する:サービス提供元が公開している倍率、通信量の集計方法、残量を確認します。
- 予備を確保する:出口または経路が異なる、利用可能なノードを1つ以上残しておきます。
レイテンシの測り方:同じ測定先に3回連続で接続
HTTPレイテンシは帯域幅でも、単純なICMP Pingでもない
Clashやmihomoで一般的なレイテンシ測定では、指定したプロキシ経由で測定用URLにアクセスし、リクエストにかかった時間を記録します。結果は測定先、DNS、接続確立、TLSハンドシェイク、コアの実装などに左右されます。接続の再利用といった条件によっても変わることがあり、プロキシサーバーまでの物理的な往復時間と同じではありません。
そのため、クライアントAで80 ms、クライアントBで150 msと測定されても、すぐにAのノードのほうが優れているとは判断できません。まず両方で同じURL、タイムアウト設定、ネットワークを使っているか確認しましょう。測定先を変更した場合は、以前の結果も測り直してください。
- 同じWi-Fiまたは有線ネットワークで測定し、ダウンロードやクラウドストレージの同期を一時停止します。
- 候補ノードを約10秒間隔で3回続けて測定し、中央値とタイムアウト回数を記録します。
- 普段使う時間帯と夜20:00~23:00にそれぞれ再測定し、負荷の低い時間帯の結果だけで判断しないようにします。
- タイムアウトした場合は再試行してから、実際に使うWebサイトにもアクセスします。測定用URLに接続できなくても、すべての用途で使えないとは限りません。
ばらつきと実際のダウンロード速度を記録
以下は判断方法を示すための例であり、当サイトでの実測値でも、特定のサービス提供元を評価するものでもありません。ダウンロードテストには、テスト利用が許可された同じファイルを使い、回数を制限してください。測定自体もサブスクリプションの通信量を消費します。
| 候補ノード | 3回のレイテンシ測定 | 連続ダウンロードの例 | 判断 |
|---|---|---|---|
| ノードA | 42 / 180 / タイムアウト | 2 MB/s、何度も停止 | 最低値は良好だが、安定性に難あり |
| ノードB | 91 / 95 / 93 ms | 12 MB/sで60秒間連続 | 普段使いの候補として適している |
| ノードC | 168 / 172 / 170 ms | 20 MB/sで60秒間連続 | 応答はやや遅いが、大容量データの転送速度は良好 |
MB/sは1秒あたりのメガバイト、Mbpsは1秒あたりのメガビットで、数値は約8倍異なります。12 MB/sは約96 Mbpsです。測定結果のスクリーンショットを比べる前に単位をそろえ、家庭の回線速度やWi-Fiの電波状況がボトルネックになっていないかも確認しましょう。
通信量倍率の計算方法:サービス提供元の集計基準を確認
ノード名にある「0.5×」「1×」「2×」は通常、その回線にサービス提供元が設定した通信量の課金倍率を示します。速度の倍率でも、Clashのコアが自動適用する速度制限の設定でもありません。名称はあくまでラベルなので、実際の適用倍率はプランの説明と管理画面の通信量を確認してください。
アップロードとダウンロードの合計通信量で課金されるサービスの場合、基本的な計算式は消費通信量 =(アップロード量 + ダウンロード量)× ノード倍率です。たとえばダウンロードが10 GB、アップロードが0.2 GBで、2×のノードを使うと、消費量は約20.4 GBです。0.5×のノードなら約5.1 GBになります。実際の値は集計の反映時間、単位換算、サーバー側の計測方法によって変わる場合があります。
- 大容量ファイルやOSアップデート:十分な持続通信速度があり、倍率の低い回線を優先します。
- Web閲覧やメッセージのやり取り:通信量は比較的少ないため、応答速度と安定性を優先できます。
- 倍率の高い専用回線:利用するサービスで実際に改善が見られる場合に限り、追加の通信量に見合う価値があります。
まずサービス提供元の管理画面に表示される使用量を記録し、約200 MBのダウンロードを1回行って、使用量の更新後に消費量を確認します。クライアントのセッション通信量とプラン残量を直接照合して正確な値を出すのは避けましょう。集計対象が異なる場合があり、管理画面への反映にも時間がかかることがあります。
出口地域の選び方:接続先サービスの判定を優先
ノード名には、入口の場所、出口の場所、または事業者独自の回線名が表示されることがあります。「香港中継、日本出口」と表示された回線でも、クライアントが最初に接続するサーバーが日本にあるとは限りません。ただし、接続先サイトから見えるのは通常、最終的な出口IPアドレスです。地域制限のあるサービスを使う場合は、名称だけで判断せず出口を確認しましょう。
地域とサービスの利用可否を3ステップで確認
- 確認中に自動グループが回線を切り替えないよう、プロキシグループで候補ノードを手動選択します。
- IPアドレスの確認ページで出口アドレスと地域を確認し、接続履歴でそのアクセスが想定したノードを経由したことも確認します。
- 実際に使うサービスを開き、トップページが表示されるかだけでなく、ログイン、再生、必要な機能が使えるか確認します。
IPアドレスのデータベースによって地域判定が異なる場合があります。動画、決済、一部のオンラインサービスでは、アカウント登録地域、支払い方法、端末の位置情報、不正利用対策の判定も利用条件に影響します。IP確認ページで特定の地域と表示されても、すべてのサービスがその地域として認識するとは限りません。
距離の近い出口はレイテンシが低くなりやすい一方、迂回経路、ネットワーク間の混雑、中継経路によって結果は変わります。オンライン会議では近隣地域から試し、接続先地域が指定されたサービスでは、まず出口の条件を満たしてからレイテンシを比較しましょう。頻繁にログインする重要なアカウントでは、不要な地域切り替えを避け、出口をなるべく固定するのがおすすめです。
プロトコルの比較:まずコアの対応状況を確認し、次に回線との相性を見る
Clashはクライアントエコシステムで広く使われる名称ですが、実際に利用できるプロトコルは、動作中のコアとそのバージョンによって異なります。Clash Metaは後継のmihomoとして開発が続いていますが、GUIクライアントを使っていても、サブスクリプション内のすべてのプロトコルにコアが対応しているとは限りません。問題を調べる前に、クライアントの「バージョン情報」またはコア情報で完全なバージョン番号を確認し、該当バージョンのドキュメントと照らし合わせてください。
| プロトコルの種類 | 主な確認項目 | 選ぶ際の注意点 |
|---|---|---|
| Shadowsocks | 暗号化方式、プラグイン、UDP対応 | サーバーとコアで同じ暗号化方式がサポートされている必要があります |
| VMess / VLESS | 転送方式、TLS、認証、追加パラメーター | プロトコル名だけで判断せず、設定全体の互換性を確認します |
| Trojan | TLS、サーバー名、証明書の検証 | 証明書エラーが出たら設定を確認し、検証を安易に無効化しないでください |
| Hysteria2 / TUIC | コアの対応状況、UDP経路、サーバーパラメーター | UDPに依存するため、制限のあるネットワークでは接続できない場合があります |
同じプロトコルでも回線が違えば通信環境は大きく異なり、同じ高品質な回線で複数のプロトコルが提供されることもあります。夜間の混雑、サーバー負荷、ネットワーク間の品質のほうが、プロトコル名より実際の使用感に影響する場合も少なくありません。「新しいプロトコルならどのネットワークでも速い」とは限りません。
ノード選択後に確認すること:ルールの適用先と予備回線
ルールモードでは、「プロキシ」グループでノードを手動選択しても、そのグループを実際に参照する通信にしか影響しません。動画、ダウンロード、特定のドメインは別のプロキシグループを使う場合や、DIRECTに振り分けられる場合があります。ノードを切り替えても出口が変わらないときは、サブスクリプションをすぐ再読み込みするのではなく、接続詳細でドメイン、適用ルール、ポリシーチェーンを確認してください。
切り替え後に確認する4項目
- 通信の取り込み:システムプロキシが有効か、必要に応じてTUNが有効か確認します。システムプロキシ設定を参照しないアプリもあります。
- ポリシーチェーン:接続先サイトを開き、接続一覧から該当する通信を探して、最終的なノード名を確認します。
- 接続のやり直し:既存の長時間接続では、切り替え前のノードが使われ続けることがあります。リクエストを再実行し、必要であれば該当する既存接続を閉じてから測定してください。
- 実際の用途で確認:Webページの読み込み、対象サービス、必要なUDP機能をそれぞれ確認し、測定ボタンの結果だけで判断しないでください。
自動グループの選択基準も把握しておきましょう。url-testは主に指定URLのレイテンシ結果をもとに候補を選び、許容差や測定設定の影響を受けます。fallbackは設定順に、ヘルスチェックで利用可能と判定された候補を選びます。いずれも「ダウンロード速度が最速のノードを自動選択する」機能ではなく、通信量倍率やサービスの地域要件も自動確認しません。
普段使いでは、動作を確認した回線を2つ確保しておくと安心です。1つを通常用、もう1つを出口または上流回線が異なる予備用にします。名称が違うだけで実際には同じ経路を共有するノードでは、十分な冗長性を確保できないことがあります。サブスクリプションの更新後はノード名とグループ内の選択を確認し、元のノードが削除された後に別の回線へ誤って切り替わらないようにしましょう。
最終的な選び方は、対象サービスが使える → 接続が安定している → 応答速度と通信速度が要件を満たす → 倍率に納得できるの順です。測定日、ネットワーク環境、3回分のレイテンシ、用途を記録しておくと、最低値だけを記録したスクリーンショットより継続的な比較に役立ちます。さらに確認する場合は、接続チェックの説明とカスタムルールの説明をご覧ください。