Clashのプロキシノードの選び方｜遅延・倍率・地域・プロトコルを比較

まず用途を決め、4つの指標を比較する

サブスクリプションから候補ノードを2～3個選び、遅延一覧の最上位をそのまま常用に設定するのは避けましょう。普段のWeb閲覧、大容量ダウンロード、地域限定サービス、リモート接続では、必要なネットワーク性能が異なります。速度テスト用のURLをすばやく開けても、すべてのサイトで同じように使えるとは限りません。

Clashクライアントは設定の表示や切り替えを担い、ClashまたはClash Meta（mihomo）カーネルがプロキシ接続の確立とルールの照合を行います。サブスクリプションに記載されたノード名、倍率、地域情報はサービス提供元によるものです。カーネルがラベルの正確さを自動で検証したり、プラン残量に応じて最も通信量を節約できる経路を選んだりすることはありません。

指標	確認するポイント	誤解しやすい点
遅延	連続測定の結果、失敗回数、実際の用途での応答	一度の最小値だけでは、終日安定しているとは言えない
倍率	サービス提供元の課金ルールと残り通信量	倍率が高くても速度が速いとは限らない
地域	実際の出口IPと接続先サービスの判定結果	ノード名と実際の出口地域が一致するとは限らない
プロトコル	カーネルの対応状況、ネットワーク制限、サーバー側の実装	プロトコル名だけで性能の優劣は決められない

遅延の見方：最低値だけでなく、ばらつきも確認する

クライアントの速度テストはダウンロード帯域の測定ではない

一般的なノード遅延テストでは、プロキシ経由で指定URLにアクセスし、リクエストの完了までにかかった時間を測定します。テスト先のURL、接続の再利用、DNSキャッシュ、カーネルの実装、クライアントの表示方法などが結果に影響します。サーバーへのICMP pingとは異なり、画面に表示された80msから1秒あたりのダウンロード量を換算することもできません。

ノードを比較するときは、テストURL、タイムアウト値、ローカルネットワークの条件をそろえます。まず1回測定し、約30秒空けて再測定する作業を繰り返し、最低5回分を記録してください。大容量ファイルのダウンロードは同時に行わないでください。ローカルWi-Fiの混雑や上り回線の飽和でも、ノードの速度が不安定に見えることがあります。

中央値を確認：5回分の結果を並べ、中央の値を確認します。一度だけ出た異常に低い値に惑わされません。
ばらつきを確認：70msから900msまで変動するノードより、約180msで安定するノードのほうが快適に操作できる場合があります。
失敗回数を確認：タイムアウトを0msとして扱わず、失敗として記録し、回数を別に集計します。
時間帯を変えて測定：平日の日中と、現地の夜間ピーク時にそれぞれ測定します。テスト条件はそろえてください。

「速い気がする」ではなく、測定結果で比べる

以下は計算方法を示すための例であり、本サイトが実際の経路を測定した結果ではありません。ノードAの5回分の結果は62、65、71、680、タイムアウト。ノードBは165、172、178、181、190msでした。Aは成功時の値こそ低いものの、1回のタイムアウトと大きな遅延の跳ね上がりがあります。Webフォーム、リモートデスクトップ、頻繁なAPIリクエストでは、Bのほうがさらに検証する価値のある候補と言えるでしょう。

続いて、実際の用途で確認します。よく使うページを3つ開く、ログインを1回行う、動画を10分間続けて視聴する、またはリモート接続を15分間維持するなどの方法があります。速度テスト用URLには接続できても、目的のサービスで失敗する場合は、接続先の制限、出口IPの評価、ルールの適用先、地域判定などが原因かもしれません。「ノードの遅延が大きすぎる」とすぐに結論づけないでください。

通信量の倍率の計算方法：まずプランの消費ルールを確認

倍率は通常、サービス提供元が定める課金上の目安であり、Clashカーネルの標準的な性能指標ではありません。サービス提供元が実際の課金対象通信量に倍率を掛けてプラン残量から差し引く場合、課金対象の通信量が1GBなら、倍率2倍のノードで約2GB、0.5倍のノードで約0.5GBが消費されます。ただし、これはサービス提供元がその計算式を採用している場合に限ります。

プラン消費量 = サービス提供元が集計した課金対象通信量 × ノード倍率

課金対象通信量 10GB × 0.5倍 = 消費量 5GB
課金対象通信量 10GB × 1倍   = 消費量 10GB
課金対象通信量 10GB × 2倍   = 消費量 20GB

実際の消費量には、アップロード通信量、プロトコルのオーバーヘッド、集計の更新間隔、GBとGiBの単位の違いなども影響します。プラン管理画面に記載されたルールと利用記録を確認し、クライアントの接続統計をそのまま請求額と見なさないでください。名称に「標準」「専用線」「高速」とあっても、共通の課金基準があるわけではありません。

大容量通信には低倍率が向くが、安定性も確認する

動画視聴、OSアップデート、クラウドストレージからのダウンロード：低倍率の経路を優先してテストし、速度を維持できるか確認します。
Web閲覧、メッセージ、コードリポジトリ：通信量が少ないため、接続成功率と操作時の遅延を優先できます。
特定地域向けのサービス：まず出口地域の条件を満たしてから倍率を比べましょう。通信量を節約できても、サービスを使えなければ意味がありません。

たとえば、倍率2倍の経路が12MiB/s、倍率1倍の経路が8MiB/sだとします。これは速度と通信量のトレードオフであり、前者が必ず優れているわけではありません。バックグラウンドでのダウンロードなら、完了まで時間がかかっても通信量を節約するほうが得策かもしれません。急ぎのファイルを一時的に取得する場合は、高倍率の経路が選択肢になります。速度テストのダウンロードでも通信量を消費するため、数GBのテストファイルを何度も取得する必要はありません。

ノードの地域の選び方：名前だけでなく出口を確認

ノード名にある「香港」「日本」「米国」は、出口の場所を示す場合もあれば、単なる製品の分類名の場合もあります。接続入口、国境をまたぐ伝送経路、最終的な出口がそれぞれ別の場所にあることもあります。入口が近くても出口が近いとは限らず、入口までの遅延が小さくても、接続先サービスまでの経路全体が短いとは限りません。

候補ノードを手動で選び、接続パネルで、確認先のサイトへの通信がDIRECTや別のプロキシグループではなく、そのノードを通っていることを確認します。
その接続経由でパブリックIPアドレスを調べ、IPアドレス、地域データベースの判定結果、ネットワーク事業者の情報を記録します。
実際に利用するサービスを開き、表示内容、地域に関する案内、ログイン結果を確認します。データベースの判定はあくまで参考です。
接続し直して出口が変わるか確認します。動的な出口は普段の閲覧に適している場合もありますが、アカウントで普段と異なる地域からのログインとして検知されることがあります。

地域制限のあるサービスでは、IPの種類、アカウントの登録地域、支払い情報、デバイスの位置情報も確認されることがあります。IPデータベースに「日本」と表示されても、すべてのサービスが日本のIPとして認識するとは限らず、その出口から利用できる保証もありません。クライアントで地域を切り替えても、変わるのはネットワーク出口に関する条件の一部だけです。

プロトコルの比較：まずカーネルとネットワーク環境を確認

プロトコルによって接続方法や一部の通信特性は異なりますが、ノードの性能はサーバー負荷、入口の帯域幅、ルーティング、輻輳制御、クライアント端末の性能にも左右されます。プロトコル名を速度のランクと見なさないでください。同じプロトコルでも、経路が異なれば、異なるプロトコル間より体感の差が大きくなることがあります。

プロトコル	確認事項	選ぶ際のポイント
Shadowsocks	暗号化方式、プラグイン、カーネルの対応状況	設定が一致し、実際の経路が安定していること
Trojan	TLS、サーバー名、証明書の設定	ハンドシェイクに成功し、証明書が正常に検証されること
VLESS	トランスポート方式、TLSまたはREALITYのパラメーター	必要な機能に対応したカーネルを使用すること
Hysteria2	UDPの到達性、認証、TLSのパラメーター	制限のあるネットワークで接続を確立できるか
TUIC	UDPの到達性、サーバーとクライアントの互換性	セッションの安定性とデバイスのリソース使用量

Hysteria2とTUICはQUICベースのトランスポートを使用するため、下位層のUDPに依存します。UDPが制限されている公衆Wi-Fiや企業ネットワークでは、接続自体に失敗することがあります。だからといって、サブスクリプション内のノードがすべて使えないとは限りません。同じネットワークで比較できるよう、TCPを使う候補経路も残しておきましょう。

VLESS、Hysteria2、TUICなどのノードでは、使用するカーネルが対応しているか確認してください。クライアント画面にノード名が表示されていても、現在のカーネルですべてのプロトコルパラメーターを正しく読み込めるとは限りません。カーネル名、設定の読み込みログ、エラー内容を確認しましょう。旧版のClashとmihomoの機能を混同しないでください。アップグレードを検討する場合は、まずクライアント選びガイドを参考にし、現在の設定をバックアップしてください。

プロトコル層でUDPを使うことと、アプリの通信をUDPでプロキシ経由にすることは別の問題です。たとえばゲームのUDP通信では、ノードの対応状況、ルール、通信を取り込む方法も関係します。TUNを有効にしても、サーバーのUDP非対応、出口の制限、経路の混雑は自動では解消されません。

同じ手順でノードを検証し、プロキシ経路の取り違えを防ぐ

手順1：プロキシグループとテスト先を固定する

クライアントのノード画面で、対象のプロキシグループを手動選択に切り替えます。url-testによる自動選択が有効なままだと、測定中にノードが切り替わることがあります。接続パネルで接続先ドメイン、適用ルール、プロキシチェーンを確認し、今回のリクエストが候補ノードを経由していることを確かめてください。ルールモードは有効のままで構いませんが、テスト用ドメインが想定したプロキシグループに振り分けられている必要があります。

システムプロキシの設定が反映されるのは、その設定を参照するアプリだけです。ターミナルのコマンドはブラウザーと同じ設定を使うとは限らないため、ローカルのHTTPポートまたはmixedポートを明示的に指定できます。以下はクライアントの待ち受け先が127.0.0.1:7890の場合の例です。現在の設定でportまたはmixed-portを確認し、実際のポートが異なる場合はコマンドを合わせて変更してください。

curl --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 \
  --max-time 20 \
  --output /dev/null \
  --silent --show-error \
  --write-out "HTTP=%{http_code} TTFB=%{time_starttransfer}s TOTAL=%{time_total}s\n" \
  https://www.example.com/

これは一般的なUnixシェル向けのコマンド例で、アドレスにはドキュメント用ドメインを使用しています。実際に比較する際は、普段利用していてアクセスが許可されているHTTPSページに置き換えてください。Windows PowerShellではcurl.exeを使い、コマンドを1行で記述して、出力先をNULに変更できます。プロキシを明示するとローカルのプロキシポートには接続できますが、最終的な出口はカーネルのルールによって決まります。接続パネルも必ず確認してください。

time_starttransferはリクエスト開始から最初の1バイトを受信するまでの時間で、接続確立などの段階も含みます。time_totalはリクエスト全体にかかった時間です。クライアントのノード速度テストを厳密に再現する値ではなく、実際のリクエスト経路を確認するための補助指標です。HTTP 403が返された場合、リクエストは接続先サイトに到達したうえで拒否された可能性があります。200以外の応答をすべてプロキシの切断と見なさないでください。

手順2：条件をそろえて比較結果を記録する

同じ端末、同じネットワーク、同じテスト先を使い、ほかの大容量通信は一時停止します。
各ノードについて、遅延を5回測定し、失敗回数、倍率、実際の出口地域を記録します。
同じ用途で10～15分間テストし、遅延や再接続、ログイン時の異常を記録します。
夜間のピーク時にも測定を繰り返し、安定して使えたノードを残します。一度だけ出た最高値で順位を決めないでください。

候補のノードがすべて失敗する場合は、まずサブスクリプションの残量、設定の有効状態、ローカルの待ち受けポート、ネットワーク接続を確認し、その後DNSとルールを調べます。ブラウザーだけ、またはターミナルだけで失敗する場合は、まずプロキシの入口を確認してください。詳しくはトラブル対処をご覧ください。DNS、TUN、ルール、ノードを同時に変更すると、どの変更で解決したのか分からなくなります。

普段使い・地域指定・予備の3種類を残す

テスト後に、何十もの経路を登録しておく必要はありません。普段使いには、ピーク時も安定し、倍率が適切なノードを1つ選びます。地域指定の用途には、実際のサービスで検証済みの出口を1つ残します。予備には入口やネットワーク経路が異なるノードを選び、現在のネットワークで単独でも使えることを確認してください。

普段のWeb閲覧：安定した応答を優先し、倍率は適度なものを選びます。数十ミリ秒の差を追って頻繁に切り替える必要はありません。
動画・ダウンロード：継続的な通信速度と通信量の消費を重視し、短いリクエストの速度テストだけで判断しないでください。
リモートワーク：長時間接続の安定性と出口地域の固定を優先し、重要な操作の前に現在の出口を確認します。
制限のあるネットワーク用の予備：同じ経路の別名を複製するだけでなく、実際に使えると確認済みの異なる通信方式を残します。

自動切り替えを使う場合、url-testは測定結果をもとにノードを選び、fallbackは通常、リストの順に利用可能なノードを探します。どちらもテストURLへの到達性に依存し、通信量の倍率、アカウントの地域制限、サービスへのログイン状態までは判断しません。load-balanceは設定した方式に応じて接続を振り分ける機能であり、1回のダウンロードで全ノードの帯域幅を合算できるわけではありません。出口が重要な用途では、手動でノードを固定すると管理しやすくなります。

サブスクリプションを更新したら、ノード名、倍率、プロキシグループの選択をもう一度確認してください。既存ノードが削除、改名されたり、出口が移転したりしている場合があります。最終的に残すべきなのは「遅延が最小」の唯一のノードではなく、用途が明確で、コストを把握でき、経路を検証できるノードの組み合わせです。使い心地が変わったときも同じ手順で再確認すれば、ローカルネットワーク、経路の負荷、接続先サービスのどれが影響しているか見分けやすくなります。