プロキシノードの選び方｜遅延テスト・通信量倍率・接続先地域・プロトコルを比較

まず接続の可否を確認し、遅延とコストを比較

ノードは、まず目的のサービスに接続できるか、次に接続が安定しているか、通信量の消費に無理がないかを確認し、最後に遅延を比べましょう。Clashのノード一覧に表示されるミリ秒数は、その時点での測定値にすぎず、ダウンロード速度や出口の地域、サービスの利用可否まで示すものではありません。普段のウェブ閲覧、動画再生、リモートターミナルでは、求められるネットワーク性能も異なります。

比較を始める前に、クライアントが使用するコアを確認してください。オリジナル版ClashとClash Meta（現名称：mihomo）では、対応するプロトコルが異なります。サブスクリプションにHysteria2やREALITYパラメーター付きのVLESSノードが含まれる場合は、それらのプロトコルに対応したコアが必要です。ノードをインポートできない場合は、互換性または設定の問題であり、回線品質が悪いとすぐに判断しないでください。

1. 用途を決める：ウェブ閲覧では最初の表示と応答速度、動画では継続的な通信速度、SSHなどの対話型接続では遅延の変動や切断の有無を確認します。
2. 条件をそろえる：同じ端末、同じWi-Fiまたは有線ネットワークで比較し、クラウドストレージの同期やバックグラウンド更新は一時停止します。
3. 経路を固定する：比較対象のノードに通信が実際に流れていることを確認します。DIRECTルールで直接接続されていたり、別のプロキシグループが選ばれていたりしないようにしてください。
4. 予備を確保する：メインのノードに加え、別回線または別サーバーのノードも用意します。名前が異なっていても、同じ障害箇所を共有している場合があります。

1. 遅延テスト：テストURL、測定結果のばらつき、実際の通信を確認

ミリ秒数はダウンロード速度でもICMP pingの値でもない

mihomoのURLテストでは、指定したプロキシ経由でテスト先にアクセスし、HTTPリクエストの所要時間を測定します。結果には、クライアントからノードまでの経路、プロキシのハンドシェイク、ノードからテスト先までの経路、テスト先の応答速度が影響します。新しい接続と既存接続の再利用でも結果が変わるため、ノード一覧の数値を純粋なネットワーク往復遅延とみなすことはできません。

たとえば、テストURLにhttps://www.gstatic.com/generate_204を指定した場合、測定結果が示すのは、そのノードからこの接続先にアクセスしたときの状態です。テストに成功しても、別のウェブサイト、動画サービス、APIにも接続できるとは限りません。タイムアウトも、ノードが完全にオフラインとは限りません。テスト先へのアクセス制限、名前解決の異常、一時的な混雑でも失敗することがあります。

• ノードを比較するときは、テストURLとタイムアウト条件を統一します。
• 各ノードで5回連続して測定し、成功回数、代表的な所要時間、最大所要時間を記録します。最速の1回だけで判断しないでください。
• 平日の昼と夜にそれぞれ測定します。負荷の低い時間帯だけ快適なノードが、夜の動画視聴にも適しているとは限りません。
• 画面にtimeoutと表示されたら、まずそのノードから実際の接続先にアクセスし、テスト先の問題か回線の問題かを確認します。

たとえば、あるノードの5回の測定値が80、82、85、83、900ミリ秒、別のノードが110、112、109、115、111ミリ秒だったとします。前者は最小値こそ短いものの、1回だけ大きく遅延しています。対話型の接続では、すぐに80ミリ秒を基準に並べるのではなく、この遅延の急増が繰り返し発生するか確認しましょう。

curlで同じリクエストが通るローカルポートを確認する

次のコマンドは、ローカルのHTTPプロキシ127.0.0.1:7890に明示的に接続します。クライアントが実際にこのアドレスでHTTPまたはmixed-portを提供していることが前提です。ポートが7890以外の場合は、現在の設定に合わせて変更してください。Ruleモードでは、ローカルプロキシを明示してもルールが適用されます。最終的な出口のポリシーは、クライアントの接続一覧で確認してください。

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

これはmacOSとLinuxでの書き方です。Windowsではcurl.exeを使い、/dev/nullをNULに置き換えます。ほかの引数はそのままです。このテスト先が正常に応答する場合、通常はHTTP 204が返ります。time_starttransferは最初の1バイトを受信するまでの時間、time_totalはリクエスト全体の所要時間です。どちらも「ノードへのping」そのものではありません。

204レスポンスは本文がごく小さいため、リクエストが完了するかの確認には適していますが、通信速度の測定には向きません。ダウンロード速度を測る場合は、信頼でき、サイズが明確で、測定に利用できるファイルを使い、ファイルと測定時間を統一してください。単位もそろえましょう。1 MB/sは約8 Mbpsです。異なる単位の数値をそのまま比較することはできません。

2. 通信量倍率：消費量を計算してから用途を決める

通信量倍率は事業者の課金ルールであり、プロトコルのパラメーターでも速度倍率でもありません。倍率が2倍のノードでも、通常のノードの2倍の速度が出るわけではありません。一般的な計算方法は「課金対象の通信量 × 倍率」ですが、アップロードが課金対象か、GBとGiBをどう定義するか、時間帯によって倍率が変わるかは、事業者の説明を確認してください。

残りの容量から利用可能な通信量を計算する

プランの残量が60 GBで、倍率2倍のノードを使う場合、前述の課金対象通信量だけを差し引く計算では、課金対象となる通信量を約30 GB利用できます。倍率0.5倍なら約120 GBに相当します。この計算はコストの目安に役立ちますが、プランの有効期限や速度制限、その他の利用規約は変わりません。

• ウェブ閲覧・メッセージ：通常は応答速度と安定性を重視します。信頼できる回線なら、倍率が高くても選ぶ価値があります。
• 動画・大容量ファイル：まず倍率を確認し、そのうえで長時間の通信速度を測定します。速度測定自体で通信量を消費する場合もあります。
• バックグラウンドのバックアップ：プロキシ経由にする必要があるか確認し、大容量アップロードが高倍率の回線に流れるルールになっていないか注意してください。

3. 地域の選び方：ノードの接続先、出口IP、利用先サービスを区別する

地域は地図上で近い場所を選ぶのではなく、利用するサービスの要件に合わせて選びます。サブスクリプション名に「日本」とあっても、それが出口の地域を示すだけで、クライアントが接続するサーバーも日本にあるとは限りません。中継回線では、まず国内の入口に接続し、その後、海外の出口に転送する場合があります。物理的に近いノードでも、通信事業者の経路が遠回りになれば、より遠いノードより遅くなることがあります。

まず利用先サービスから見える出口を確認する

1. 現在のプロキシグループで確認対象のノードを選び、利用先のウェブサイトを開いて新しい接続を発生させます。
2. クライアントの接続一覧で、そのリクエストに適用されたルールとプロキシチェーンを確認し、別の経路を通っていないことを確かめます。
3. 信頼できるIP確認サイトで出口IPと地域を確認し、利用先サービスが想定どおりのコンテンツを提供するかも調べます。
4. 既存の長時間接続が以前の出口を使い続ける場合は、関連アプリを終了してから再起動してください。クライアントによっては、既存の接続を切断する機能もあります。

IPデータベースと利用先サービスでは、地域の判定が異なることがあります。確認サイトで日本と表示されても、すべての動画配信、決済、アカウントシステムが日本と判定するとは限りません。サービスによっては、アカウントの地域、支払い情報、端末の位置、ログイン履歴、IPのリスク情報なども参照します。接続先の国を変えるだけでアクセス制限が解除されるとは限りません。

用途に合わせて異なる地域のノードを確保する

• リモートワーク：組織の接続ポリシーを優先し、出口をできるだけ安定させます。頻繁に地域を変えてログインすると、追加認証が求められる場合があります。
• 地域限定コンテンツ：トップページが開くかだけでなく、目的のコンテンツを利用できるか直接確認します。
• 一般的なウェブ閲覧：接続可能なノードのピーク時の状態を比較し、地域名は補助的な条件として扱います。
• ゲーム：ゲームの通信が実際にプロキシを通るか、ノードとルールが必要なUDP通信に対応しているかを先に確認します。ブラウザーでウェブサイトを開けても、ゲームの通信が使えるとは限りません。

ブラウザーとコマンドラインで出口が異なる場合は、ブラウザーのプロキシ拡張機能、システムプロキシ、TUNルーティング、アプリ独自のプロキシ設定を確認してください。通信経路が定まらないままノードを何度も変更すると、ノードそのものではなく、異なる通信経路を比較することになります。

4. 通信プロトコル：Trojan・VLESS・Hysteria2の選び方

プロトコルは接続の確立方法とデータの転送方法を決めますが、回線品質を保証するものではありません。同じプロトコルでも、サーバーやネットワークの構成は異なります。同じサーバーが複数のプロトコルを提供する場合もあります。まずクライアントの対応状況を確認し、自分のネットワーク環境で接続成功率、継続的な通信速度、切断後の復旧を比較してください。

TrojanとVLESS：プロトコル名だけで判断しない

TrojanノードはTCPとTLSの組み合わせが一般的です。VLESSでは、セキュリティ層と転送設定も確認する必要があります。REALITYはセキュリティ層の方式であり、「通信速度の段階」ではありません。WebSocketやgRPCなどの転送方式によっても、接続の特性は変わります。「VLESSのほうがTrojanより新しい」という理由だけで、現在のネットワークで速いとは判断できません。

インポート後にTLSやハンドシェイクのエラーが出る場合は、システム時刻、サーバーアドレス、ポート、SNI、認証情報、サブスクリプションが完全かどうかを確認してください。REALITYを使う場合は、サーバー側で要求される関連パラメーターも一致させる必要があります。エラーを解消するために証明書の検証を無効にせず、まずアドレス、証明書、パラメーターの不一致を修正してください。

Hysteria2：まずUDP接続を確認し、その後に通信速度を測る

Hysteria2は、高遅延またはパケットロスのある一部のネットワークで、良好な通信速度を得られる場合があります。ただし、結果はネットワークとサーバーの設定によって異なります。大学や企業のネットワーク、公衆Wi-FiでUDPが制限されていると、TCP系のノードは使えてもHysteria2では接続できないことがあります。その場合は別のネットワークでも試し、利用可能なTCP系ノードも確保してください。

帯域幅のパラメーターは、大きくすればよいわけではありません。設定する場合は、実際の回線能力とサーバー側の制限に合わせてください。値が高すぎると、混雑を悪化させることがあります。まず事業者が提供する有効な設定を使い、関連する輻輳制御の設定を理解したうえで調整してください。自分の回線と無関係な「高速化設定」をそのまま適用するのは避けましょう。

4つの観点を使って再現性のある方法でノードを選ぶ

最初の選別ですべてのノードの帯域幅を測り切る必要はありません。少数の候補で基本項目を確認してから、普段利用するサービスでテストします。次の手順は、手動でノードを選ぶ場合にも、自動選択グループが要件に合っているか確認する場合にも使えます。

1. 候補を3つ選ぶ：利用先の地域要件を満たし、倍率が許容範囲内で、使用中のコアに認識されるノードを選びます。できるだけ異なる回線を含めてください。
2. ルールを確認する：対象リクエストに適用されるルールと出口を確認します。一時的にGlobalモードで比較する場合は、テスト後に元のRuleモードへ戻してください。
3. 短いリクエストを繰り返す：同じテストURLを各ノードで5回測定し、失敗回数とばらつきを記録します。
4. 実際の用途で試す：よく使うウェブサイトを開く、同じ動画を再生する、またはリモートターミナルに接続し続けるなどして、切断や再接続の状況を確認します。
5. 混雑する時間帯にも測る：普段もっともよく利用する時間帯に、少なくとももう一度測定します。昼間の結果だけで終日を判断しないでください。
6. メインと予備を決める：メインは安定性とコストの条件を満たし、予備はメインに障害が起きた際に同じ用途をこなせるものを選びます。

自動選択グループが利用先サービスに最適とは限らない

mihomoのurl-testグループは、設定されたテストURL、テスト間隔、許容差などをもとにノードを選択します。最適化されるのはテスト結果であり、動画配信の地域、通信量倍率、アカウントのログイン状況まで自動で判断するわけではありません。倍率や地域の異なるノードを同じグループに入れると、自動切り替えによって出口や費用が変わる場合があります。

より確実なのは、用途に合わせて候補を絞ってから、その候補内で自動選択グループを使う方法です。たとえば、特定地域のサービスには同じ地域のノードを、大容量通信には課金条件が許容できるノードを用意します。設定項目の意味はサイト内の応用設定を、初回のインポートやプロキシモードの操作は使い方ガイドを参照してください。

最終的な記録に複雑なスコア付けは必要ありません。ネットワーク環境、測定日時、利用先サービス、成功回数、ばらつき、倍率を記録しておけば十分です。普段利用する時間帯に安定して目的を果たせ、費用も予測しやすいノードのほうが、まれに最小遅延を記録するノードより日常使いに向いています。

技術資料と確認先

クライアントによってボタン名は異なる場合があります。プロトコルやテストの動作は、使用中のコアのドキュメントを優先して確認してください。以下の資料では、URLテストの設定項目、プロキシプロトコルの設定、Hysteria2の帯域幅設定を確認できます。特定のノードの品質を保証するものではありません。

• mihomoドキュメント：自動選択グループ url-testで、テスト先、間隔、許容差を確認できます。
• mihomoドキュメント：アウトバウンドプロキシで、Trojan、VLESS、Hysteria2の設定項目と対応状況を確認できます。
• Hysteria 2ドキュメント：クライアント設定の全項目で、QUICや帯域幅関連の設定を確認できます。Hysteria 2のネイティブクライアント用設定形式は、mihomoのYAMLにそのまま貼り付けられません。