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

用途に合わせて候補を絞り、遅延を比較する

サブスクリプションをClashに読み込むと、ノード一覧には地域、倍率、回線名、プロトコルが並びます。すべてのノードで速度を測る必要はありません。まず接続先の地域を確認し、通信量のコストが合わないノードを除外してから、接続性と安定性を比べましょう。無駄なテストを減らせます。

この記事でいう「プロキシサービス」とは、プロキシ用サブスクリプションを提供する事業者を指します。ノード名は事業者が設定するもので、クライアントが認証した回線情報ではありません。「専用回線」「高速」「ネイティブ」などの表記は候補選びの手がかりにとどめ、実際の接続状況や出口IP、事業者の説明で判断してください。

• Web閲覧・情報収集：リクエストが安定して処理され、ページをすばやく開けるノードを優先しましょう。最高速度にこだわる必要はありません。
• 動画視聴・大容量ファイルの転送：まず倍率と利用可能な通信量を確認し、そのうえで持続的な転送速度を比べましょう。数十ミリ秒の差は、通常、決め手にはなりません。
• リモートデスクトップ・音声通話：遅延の変動、接続切れ、UDP対応を確認しましょう。アプリの通信がプロキシ経由になっているかも別途確認が必要です。
• 利用地域の条件があるサービス：まずサービス側で認識される出口地域とアカウントの条件を確認し、遅延の順位はそのあとに見ましょう。

Clashの遅延測定でわかること

Clashやmihomoクライアントの遅延テストでは通常、指定したプロキシ経由でテストURLにHTTPまたはHTTPSリクエストを送り、応答までの時間を測ります。ノードサーバーにICMP Pingを送るだけのテストでも、ダウンロード帯域の測定でもありません。テストURL、接続の再利用方法、コアのバージョン、クライアントの設定が異なると、結果を直接比較できない場合があります。

低遅延でもダウンロードが速いとは限らない

接続確立やTLSハンドシェイク、応答待ちも測定値に影響します。小さなリクエストがすぐ完了しても、混雑時に十分な帯域があるとは限りません。逆に、距離の遠い回線は遅延が大きくても、継続的なダウンロードが安定する場合があります。

たとえば候補Aが45 ms、候補Bが95 msでも、わかるのは今回のテスト条件で応答時間に差があったことだけです。Aのダウンロード速度がBの2倍とは限りませんし、特定の動画サービスをAで問題なく視聴できるとも限りません。

同じ条件で3回測定する

1. システム更新、クラウドストレージの同期、ほかのダウンロードを一時停止し、同じWi-Fiまたは有線ネットワークを使います。
2. クライアントの「プロキシ」画面で比較するプロキシグループを開き、グループ内の遅延テストボタンを使います。クライアントによっては画面名が「プロキシグループ」の場合があります。
3. 候補ノードを約10秒間隔で3回続けて測定し、タイムアウトの回数と数値の幅を記録します。最小値だけを採用しないでください。
4. 候補ノードに切り替えて対象のWebサイトを開き、初回表示、ログイン、その後の操作が正常に行えるか確認します。

たとえば3回の結果が62、65、63 msのノードと、40、260 ms、タイムアウトのノードなら、前者のほうが通常は操作に向いています。数値は測定例であり、当サイトが特定の回線を実測・保証したものではありません。unified-delayなど遅延計算に影響するオプションを有効にしている場合は、同じ設定にそろえて比較してください。

通信量倍率の計算方法：0.5倍・1倍・2倍

倍率は通常、事業者が定める通信量の課金係数であり、通信速度の倍率ではありません。2倍のノードでも、1倍のノードの2倍の帯域があるとは限りません。0.5倍でも通信速度が半分になるわけではありません。上り・下りのどちらを基準にするか、または合算するかは、事業者の通信量に関する説明を確認してください。

上の表では計算例として、事業者の課金対象通信量を一律10 GBとしています。実際に10 GBのファイルをダウンロードすると、アップロード分やプロトコルのオーバーヘッド、再試行による通信も発生することがあります。管理画面の統計反映にも時間がかかるため、クライアントの表示とアカウント画面の数値がすぐに1バイト単位で一致するとは限りません。

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

10進数で概算すると、100 Mbpsで60秒間ダウンロードした場合のデータ量は約750 MBです。すべてが2倍課金の対象なら、通信量を約1.5 GB消費します。数十ノードの帯域を一括で測ると、遅延テストを数回行うより多くの通信量を使います。

• まず遅延と実際のWebサイト表示で候補を2～3個に絞り、その後、短時間だけ転送速度を測りましょう。
• 倍率を確認する場合は、ほかの端末の通信を止め、管理画面の残量を記録してから、条件をそろえて一度ダウンロードします。統計の更新を待ってから数値を比較してください。
• サブスクリプションを更新したらノード名と事業者の説明を確認しましょう。倍率がずっと同じとは限りません。

ノードの地域の選び方：入口・出口・接続先サービス

ノード名の「香港」「日本」「米国」などは、通常、出口の地域を示します。ただし、クライアントが最初に接続する入口のアドレスがその地域にあるとは限りません。中継回線では、近くの入口に接続してから別の経路を通り、海外の出口に到達する場合があります。地理的な距離は目安にすぎず、実測の代わりにはなりません。

通常のWeb閲覧ではネットワーク経路を確認する

中国本土から利用する場合、香港、日本、シンガポールなどを候補の出発点にできます。ただし、結果は通信事業者、利用地域、接続する時間帯によって変わります。午後9時の状態と午前10時の状態が異なることもあります。普段利用する時間帯にも少なくとも一度測定し、日中の一回の結果を長期的な評価として扱わないようにしましょう。

地域制限のあるサービスでは、表示ラベルより出口の判定を確認する

同じ出口IPアドレスでも、データベースによって地域の判定が異なることがあります。また、サービス側がアカウントの地域、支払い方法、端末の位置情報、過去のログイン履歴をもとに利用条件を判断する場合もあります。ノードに特定の地域が表示されていても、その地域向けのコンテンツをすべて利用できるとは限りません。

• 対象サービスを実際に開いて確認し、IPアドレス確認ページの結果だけで判断しないでください。
• 対象サービスへの通信が選択したポリシーグループを通っているか確認しましょう。確認ページだけがプロキシ経由で、対象アプリは直接接続している場合があります。
• ログインや決済では、できるだけ同じ出口を使いましょう。地域を頻繁に切り替えると追加認証が求められる場合があります。
• 予備回線を用意するなら、番号が近いノードより、入口や出口の異なる回線を優先しましょう。

Trojan・VMess・Hysteria2の違いと選び方

プロトコルはクライアントとプロキシサーバーの通信方法を定めます。一方、回線品質は入口の混雑、国際経路、サーバー負荷、出口帯域にも左右されます。特定のプロトコルを「最速」と決めつけることはできません。プロトコルを比較する前に、現在のクライアントコアがサブスクリプション内の設定項目に対応しているか確認してください。

UDPが制限されている場合、Hysteria2のノードを何度も切り替えるだけでは解決しない

一部のオフィスネットワーク、ゲストWi-Fi、通信事業者の経路ではUDPが制限されます。同じネットワークで複数のHysteria2ノードが使えず、TCP系のノードは使える場合は、まずスマートフォンのテザリングに切り替えて比較してください。Hysteria2は一部の不安定なネットワークで良好な場合がありますが、パケットロスや速度制限がある環境で常に優れているとは限りません。

ポート番号が同じでも、通信方式は同じとは限らない

TrojanはTCP 443、Hysteria2はUDP 443で運用できますが、具体的なポートはサーバー側の設定によります。TCP 443が許可されていても、UDP 443が許可されているとは限りません。ブラウザーでHTTPSサイトを開けても、Hysteria2に必要なUDP経路が使える証明にはなりません。

Hysteria2を使うには、現在そのプロトコルに対応しているmihomoなどのコアが必要です。クライアント名にClashとあるだけで、古いコアも設定を読み込めるとは限りません。読み込み後に「サポートされていないプロキシタイプ」と表示されたら、まずクライアントの「バージョン情報」画面でコアの情報を確認してください。その後、対応するクライアントに更新するか、事業者に互換性のある設定を問い合わせましょう。ノードの種類名だけを書き換えるのは避けてください。

候補ノードをポリシーグループに追加し、ルールが実際に適用されているか確認する

ノードを選んでも、アプリの通信がそのノードを通るとは限りません。Clashのルールモードでは、接続はルールで指定されたポリシーグループに振り分けられます。「手動選択」グループを切り替えても、ほかのグループまで切り替わるわけではありません。問題を調べるときは、速度テストの結果より先に、接続記録のルールと経路を確認しましょう。

1. クライアントで「ルール」モードを選び、「プロキシ」画面を開いて対象ルールが使用するポリシーグループを確認します。
2. 対象のポリシーグループを候補ノードに切り替えます。グループ内に入れ子のポリシーグループがある場合は、次の階層の選択も確認してください。
3. 対象のWebページの既存の接続を閉じてから再読み込みします。必要に応じて「接続」画面で該当する接続を切断し、以前の経路を使うセッションが残らないようにしてください。
4. 「接続」画面で対象ドメイン、適用されたルール、プロキシチェーンを確認し、実際の出口が想定どおりか確かめます。

手動選択・自動遅延テスト・フォールバックの違い

• select：候補を手動で選択します。出口を固定したい場合や、候補を一つずつ比較する場合に適しています。
• url-test：設定されたテストURLとポリシーに基づいてノードを選びます。通常はテスト遅延の低さを重視し、通信量倍率やコンテンツの地域制限は評価しません。
• fallback：候補の順番とヘルスチェックの結果に基づいて利用可能な項目を探します。優先順位を決めて予備回線を用意する場合に適しています。

自動遅延テストのグループは、遅延が低くても倍率の高いノードや、地域要件に合わない出口を選ぶ場合があります。同じ用途で使い、倍率と地域の条件を満たすノードだけをまとめると、すべてのノードを一つの自動グループに入れるより管理しやすくなります。

普段使いのノード選び：5つの確認項目

1. 用途を決める：Web閲覧、継続的なダウンロード、特定地域のサービスなど、目的を明確にして条件に合わない候補を先に除外します。
2. コストを計算する：倍率、残りの通信量、課金方法を確認します。帯域の速度テストを通信量の予算の代わりにしないでください。
3. 安定性を確認する：同じ条件で遅延を3回測定し、普段使う時間帯にも試して、タイムアウトや変動を記録します。
4. 実際のサービスで試す：ログイン、動画再生、ダウンロードを実行し、ルールの適用先と出口の地域を確認します。一覧の緑色の数値だけで判断しないでください。
5. 予備を確保する：異なる回線の候補を残しておきます。問題が起きたらまず切り替えて比較し、ローカルネットワーク、サブスクリプション設定、サーバー障害のどれが原因か切り分けましょう。

最終的な選択を、いつまでも変わらない順位表にする必要はありません。普段使いなら、応答が安定し、倍率が許容範囲で、出口が要件に合うメインノードと、動作確認済みの予備ノードがあれば、毎日最低遅延を追いかけるより実用的です。ネットワークを変更したとき、サブスクリプションを更新したとき、混雑が発生したときに、5つの手順で簡単に見直しましょう。