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

用途を決めてから、ノードの数値を確認する

Clashのノード一覧に表示される遅延は、あくまでテスト結果の一つであり、総合評価ではありません。用途に合うかどうかは、接続先のサイト、実効速度の安定性、変動幅、出口の地域、通信量の倍率にも左右されます。まず目的のサービスに接続できないノードを除外し、安定性とコストを比べてから、最後に遅延で候補を絞りましょう。

候補はまず3つに絞るのがおすすめです。普段使いのメイン、異なる経路の予備、特定地域の出口が必要な場合の専用ノードです。ノード名にある「専用回線」「ネイティブ」「高速」などはサービス提供者による表記で、実際のテストに代わるものではありません。名称だけで回線の構成を判断することもできません。

• Web閲覧・リモート操作：初回応答の速さ、連続リクエスト時の停止の有無、夜間の混雑時間帯における変動を確認します。
• 動画視聴・大容量ファイル：継続的なダウンロード速度、バッファリング、通信量倍率を確認します。一度の低遅延だけでは、実効速度は判断できません。
• 地域制限のあるサービス：まず出口IPがサービスにどう認識されるかを確認し、その後に速度を見ます。ノード名に記載された地域と、サービスが判定する地域は一致するとは限りません。
• ゲーム・リアルタイム音声通話：アプリの通信が実際にプロキシを経由していることと、ノードが必要なUDP転送に対応していることを確認します。一般的なWebサイトの遅延は、ゲーム内の通信指標の代わりにはなりません。

遅延テストの見方：測定対象・繰り返し結果・実際のリクエスト

Clashに表示されるミリ秒数の測定内容

一般的なノードの遅延テストでは、指定したプロキシ経由でテストURLにアクセスし、コアが記録したリクエストの所要時間を測定します。ノードサーバーに対するICMP pingとは限りません。テスト先のURL、接続の再利用方法、コアの実装が異なれば、結果も変わります。そのため、クライアントやテスト先が異なる数値を単純に比較するのは適切ではありません。

あるテストで80 ms、別のテストで130 msと表示された場合、前者がその測定時に速かったことしか分かりません。実際のWebサイトでは出口への経路が異なる場合があり、DNS名前解決、TLSハンドシェイク、サーバー側の処理時間も加わります。テストURLに接続できても、すべてのサイトに接続できるとは限りません。

条件をそろえて繰り返し測定し、最小値だけで判断しない

1. 同じ端末、同じネットワーク、同じテスト先を使います。大容量ファイルのダウンロードは一時停止し、回線を使い切らないようにします。
2. 候補ごとに約10秒間隔で5回測定し、中央値、最大値、タイムアウト回数を記録します。
3. 普段使う時間帯と夜間の混雑時間帯に分けて再測定します。たとえば10:00と21:00です。時刻は測定条件の記録であり、性能を保証するものではありません。
4. 実際に使うWebサイトを開き、ページを続けて再読み込みするか同じ操作を行い、ページ内のリソースも読み込めるか確認します。

たとえば、ノードAの5回の結果が65、70、68、900 ms、タイムアウトで、ノードBが115、120、118、125、122 msだったとします。Bは中央値が高い一方、このサンプルではより安定しています。これらの数値は読み方を示す例であり、本サイトの回線で測定した結果ではありません。サンプルが少ないため、長期的な稼働率も推定できません。

通信量倍率：請求ルールに沿って計算し、速度とは区別する

通信量倍率は通常、サービス提供者がプランの通信量をどう消費量に換算するかを示すもので、Clashのコアを高速化する設定ではありません。上りと下りの合計通信量で課金される場合、実際の通信量が合計5 GBなら、倍率2倍のノードでは約10 GB、倍率0.5倍のノードでは約2.5 GBが消費されます。詳細はサービス提供者の請求明細を確認してください。クライアントの接続統計だけで、請求に誤りがあると判断することはできません。

倍率が高くても低遅延とは限らず、倍率が低くても必ず遅いとは限りません。実際の通信量が1日4 GBなら、30日間で120 GBです。すべて倍率2倍のノードを使うと、上記のルールでは約240 GBが消費されます。選ぶ前に月間使用量を見積もり、プランの容量で足りるか確認しましょう。月の途中で容量不足に気づく事態を避けられます。

速度テストでも通信量を消費します。平均80 Mbpsで30秒間ダウンロードすると、他の通信を除いても約300 MBを転送します。数十個のノードすべてで最大速度テストを行う必要はありません。まず軽量な遅延テストで候補を絞り、2～3個のノードで短時間の速度確認を行いましょう。

接続地域の選び方：入口・出口・サイトの判定を区別する

端末が接続するサーバーアドレスは入口の一部と考えられますが、接続先のWebサイトに通常見えるのは出口IPです。中継回線では入口と出口が異なる地域にある場合があります。ノード名に「日本」とあっても、端末から日本のサーバーまでが直結とは限らず、接続先アドレスだけで最終的な出口を判断することもできません。

地理的に近くても、経路が短いとは限らない

地理的な距離は伝送遅延に影響しますが、通信事業者間の接続、迂回経路、混雑によっても通信状況は変わります。同じノードでも、自宅の固定回線、会社のネットワーク、スマートフォンのテザリングでは結果が異なる場合があります。ネットワークを変えたらメインノードも再確認し、別の回線での測定結果をそのまま当てはめないようにしましょう。

地域制限のあるサービスは、利用するサービス上で確認する

• 候補のノードに接続したら、対象サービスへのリクエストがルールによってDIRECTにされず、実際にそのノードを経由していることを確認します。
• 対象サービスが表示する地域情報や利用可能なコンテンツを確認します。IP検索サイトのデータベースと対象サービスでは、判定結果が異なる場合があります。
• アカウントの登録地域、支払い情報、端末の位置情報、過去のセッションも判定に使われる場合があります。出口を変更しても結果が変わるとは限りません。
• 長期間ログインするサービスでは、できるだけ出口を固定しましょう。地域を頻繁に切り替えると、サービスから追加認証を求められることがあります。

通常のWeb閲覧だけなら、まず経路状況の良い近隣地域から試すとよいでしょう。特定地域の出口が明確に必要な場合に限り、その用途専用のノードを確保します。地域の選択肢が多ければ、必ず使いやすくなるわけではありません。

プロトコルの選び方：コアの対応状況と利用中のネットワークを確認

Clashはクライアントのエコシステムで広く使われる名称ですが、クライアントによって使用するコアは異なります。Clash Meta（現在は一般にmihomoと呼ばれます）が対応するプロトコルは、旧版Clashと完全には一致しません。サブスクリプションをインポートできても、設定が読み込まれたことを示すにすぎません。ノードの種類、設定項目、通信方式が現在のコアでサポートされているかも確認が必要です。

現在のネットワークでUDPが制限されていると、UDPを必要とする通信は接続できないことがあります。一方、同じサブスクリプション内のTCP系ノードなら正常に使える場合があります。逆に、遅延が大きい環境やパケットロスがある環境では、適切に設定されたQUIC系の通信が良好な場合もあります。同じネットワークでテストして判断し、プロトコル名だけで順位を決めないでください。

「高速化」のために証明書の検証を安易に無効化しないでください。証明書エラーが発生したら、端末の時刻、サーバー名、サブスクリプションの設定を確認し、必要に応じてサービス提供者に問い合わせましょう。プロトコルの接続成功と証明書の正しい検証は別の問題です。検証を回避する方法は、一般的なトラブルシューティングではありません。

Clashでの確認方法：通信が実際にどのノードを経由しているか

ノードを選択しても遅い場合、目的のリクエストが選択したプロキシグループを通っていないことがあります。ルールモードではルールが順番に照合され、一致したルールに応じて処理されます。一部のドメインはDIRECTに設定されていたり、別の自動選択グループに割り当てられていたりする場合があります。クライアントの「接続」またはログ画面で、対象ドメイン、一致したルール、実際のプロキシ経路を確認してください。画面の名称や場所はクライアントによって異なります。

まずノードを固定して選び、その後で自動選択を比較する

mihomoのselectグループは候補ノードを手動で固定する場合に便利です。url-testはテストURLの結果に基づいてノードを選び、fallbackは候補の順番に利用可能なものを選択します。自動テストで分かるのはテスト先への接続状況であり、動画の画質、アカウントの地域、通信量倍率まで自動で判断するわけではありません。

以下は、既存のmihomo設定に追加するプロキシグループの抜粋です。サブスクリプション内にすでにあるproxy-providerを参照しており、単独でインポートできる完全な設定ではありません。テストグループは300秒ごとに確認します。手動選択グループも残しておくと、同じノードを使って繰り返し比較できます。

proxy-groups:
  - name: 普段使い・手動選択
    type: select
    use:
      - provider-main

  - name: 遅延テスト候補
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300

provider-mainは、設定内に実在するプロバイダー名に置き換えてください。テストURLは接続確認用であり、実際の用途で使う接続先を示すものではありません。変更前に設定のコピーを保存し、サブスクリプションの更新でローカルの変更が上書きされないようにしてください。プロバイダーとルールの書き方はYAMLマニュアルで確認できます。

ノードを切り替えたら、新しい接続で再テストする

1. 候補のノードを一つ選び、対象のWebサイトを開いて読み込みやダウンロードの状況を記録します。
2. 別の候補に切り替えたら、リクエストを新たに開始します。すでに確立している長時間接続は、元のプロキシ経路を引き続き使う場合があります。
3. 必要な場合は、他のダウンロードや会議を中断しないよう、対象アプリの古い接続だけを閉じます。
4. 同じファイルを近い時間帯に比較し、最高速度だけでなく、途中で止まるかどうかも記録します。

最終チェック：メイン・予備・用途を記録する

比較が終わったら、ネットワーク環境、測定時刻、ノード名、実際の出口地域、倍率、遅延の中央値、タイムアウト回数、用途での結果を一行にまとめて記録します。測定値をすべて長期間保存する必要はありませんが、選んだ理由を残しておけば、サブスクリプションの更新後やネットワークの変化後に見直しやすくなります。

• メインノード：目的のサービスが使え、普段の利用時間帯に安定しており、倍率も日常の通信量に見合っている。
• 予備ノード：できるだけ異なる入口または回線を選びます。名前だけが異なる2つのノードでは、障害時の代替にならない場合があります。
• 用途別ノード：特定の地域やプロトコルが必要な場合だけ使い、すべての通信を経由させる必要はありません。
• 再確認のタイミング：固定回線の変更、クライアントコアの更新、サブスクリプションの変更、またはタイムアウトが続いたときは、同じ条件で改めてテストします。

実用的な確認順は、「目的のサービスが使えるか」→「接続が安定しているか」→「倍率を許容できるか」→「遅延と実効速度が用途に合うか」です。4つの観点を分けて確認すれば、「最低遅延」を何度も選び直すより、今のネットワークに合ったノードを見つけやすくなります。