ノードの遅延：まず接続可否を確認し、次に速度を比較
遅延が小さくてもダウンロードが速いとは限らず、タイムアウトしてもノードが完全に使えないとは限りません。Clashクライアントの「速度測定」は、多くの場合、小規模なHTTPリクエストを使ったテストです。継続的なダウンロード速度を測るものではありません。リクエストを完了できないノードの切り分けや、自動選択プロキシグループの判断材料にはなりますが、動画やダウンロード、オンライン会議での使い勝手は、持続速度や安定性、実際の接続先も確認する必要があります。
たとえば、あるノードが80 ms、別のノードが180 msと表示されても、前者が大容量ファイルのダウンロードに向いているとは限りません。前者は応答が速くても帯域が狭く、後者は接続開始に少し時間がかかる一方で、大量のデータを安定して転送できることがあります。数値は状況を説明するための例であり、当サイトでの実測値ではありません。
単位の取り違えにも注意が必要です。100 Mbpsを理論上換算すると12.5 MB/sですが、実際のダウンロード速度はプロトコルのオーバーヘッド、サーバー側の速度制限、回線の状態にも左右されます。ノード一覧の100 msを、ダウンロード速度のランクとして見ることはできません。
url-testの仕組み：1回のHTTPプローブにかかる時間を測定
url-testはプロキシグループの種類のひとつです。コアは候補となるプロキシ経由で指定されたテストURLにアクセスし、所要時間を記録してノードを選びます。クライアントの手動遅延テストも、コアの制御APIから同様のテストを実行することがよくあります。ただし、テストボタンとプロキシグループではURLやタイムアウトが異なる場合があり、表示される数値が一致するとは限りません。
テストで行われる処理
- テストURLを読み込み、測定対象のプロキシまたはプロキシグループを決めます。
- プロキシサーバーへの接続を確立し、プロキシプロトコルに必要な接続処理を行います。
- プロキシ経由で接続先にアクセスします。HTTPSの場合は接続先とのTLSネゴシエーションも行います。
- HTTPプローブを送信し、コアが定める計測時間内に応答を受け取ります。
コアのバージョンによって、接続の再利用、計測開始のタイミング、リクエストの実装が異なる場合があります。このテストをICMP pingと同一視することも、単一のネットワーク往復時間として厳密に扱うこともできません。より正確には、その時点でプロキシ経由の小規模なHTTPプローブが完了するまでの時間であり、接続やハンドシェイク、応答待ちなどが含まれます。
帯域幅を測定できない理由
一般的なgenerate_204のURLが返すレスポンスは非常に小さく、204はレスポンス本文がないことを示します。十分な量のデータを継続して転送しないため、数十秒間負荷をかけたときのスループットは分かりません。応答が速くても、そのテスト経路がその時点で素早く応答したことを示すだけで、大容量ファイルの転送時に速度制限がないことの証明にはなりません。
このテストは、通常、実際の業務ルールに従ってサイトへアクセスする場合とも異なります。指定したプロキシを使ったプローブだけでは、ブラウザーのリクエストが同じノードを経由したとは確認できません。実際の経路を確かめるには、クライアントの接続ログや適用ルール、最終的なプロキシチェーンを確認してください。
テストURLで順位が変わる
テスト結果は「ローカル環境からプロキシの入口まで」と「プロキシの出口からテストサイトまで」の両方に左右されます。テストサイトの場所やCDNの利用状況、接続先ドメインの名前解決によっても結果は変わります。あるノードからテストサイトには速く接続できても、利用したいサービスのサーバーには遅いことがあります。
| テストURL | 確認できること | 注意点 |
|---|---|---|
https://www.gstatic.com/generate_204 |
小規模なHTTPSリクエストを完了できるか | その接続先への経路を示すだけで、すべてのサイトでの結果を示すものではありません |
https://cp.cloudflare.com/generate_204 |
別の接続先への応答状況 | エッジノードの場所が異なると、順位も変わることがあります |
| 実際に利用するページやファイル | 対象サービスでの実際の使い勝手 | ログイン、リダイレクト、キャッシュ、速度制限が結果に影響します |
HTTPとHTTPSの結果を混同しない
HTTPテストでは通常、接続先とのTLSネゴシエーションがないため、数値が低くなることがあります。ただし、分かるのはHTTPプローブの結果だけです。HTTPSは普段の暗号化されたWebアクセスに近く、証明書やシステム時刻の問題が表面化することもあります。ノードを比較するときはURL、プロトコル、タイムアウトをそろえ、HTTPとHTTPSの結果をそのまま順位付けしないでください。
- レスポンスが小さく、長期的に安定し、ログイン不要なURLを選びましょう。
- すべてのノードがタイムアウトする場合は、別のテストURLでも確認してください。
- アクセス制限の厳しい業務用APIに、多数のノードから自動テストを集中させないでください。
- 変更前に元のURLを記録し、URL変更後にネットワークが急に改善・悪化したと誤解しないようにしましょう。
自動選択の設定：intervalとtoleranceの役割
以下はinclude-allに対応するmihomoコア向けのプロキシグループ設定例で、完全なサブスクリプション設定ではありません。完全な設定に含まれるプロキシノードとプロキシプロバイダーから、候補を取り込みます。事前に実際のプロキシ設定が必要です。従来のClashや古いコアではこのフィールドに対応していない場合があります。使用するコアのドキュメントを確認し、既存のオブジェクトをproxiesまたはuseで明示的に指定してください。
proxy-groups:
- name: 自動選択
type: url-test
include-all: true
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 50
lazy: true
- name: プロキシ出口
type: select
proxies:
- 自動選択
- DIRECT自動選択とプロキシ出口はどちらもこの設定例で定義されていますが、すべての通信が自動的にこのグループを経由するわけではありません。完全な設定のルールから、該当するプロキシグループを参照する必要があります。サブスクリプションの既存ルール構成を保ち、対象の通信がどのグループに向いているか確認してから変更してください。テストのためにルール全体をグローバルプロキシへ切り替えないでください。
| 設定項目 | 設定例 | 役割 |
|---|---|---|
interval |
300 | 定期テストの間隔（単位：秒）。リクエストのタイムアウトではありません |
tolerance |
50 | 切り替え許容値（単位：ミリ秒）。わずかな差による切り替えを抑えます |
lazy |
true | グループが使われていない間は定期テストを省略できます。常に最新の結果があるとは限りません |
toleranceは「50 ms未満なら使用可能」という意味でも、すべての測定値に一律50 msを加算する設定でもありません。自動選択でノードを切り替えるかどうかの判定に影響します。たとえば、現在のノードが約130 ms、別のノードが約110 msの場合、20 msの改善では切り替わらないことがあります。実際の動作はコアの実装やノードの利用状況にも左右されます。
タイムアウト設定：5000 msは待ち時間の上限であり、速度の基準ではない
タイムアウトは、指定時間内にプローブが完了しなかったことを示します。タイムアウトを5000 msに設定した場合、待つ時間は最大で約5秒です。10000 msに延ばすと、遅いリクエストの結果が返ることはありますが、ノードの帯域幅が増えるわけではありません。また、timeoutを任意のプロキシグループに追加しないでください。そのフィールドが対応しているか、どこに記述するかは、使用するコアの設定ドキュメントで確認してください。
制御APIでタイムアウト関連の値を確認する
Clash形式の制御APIに対応するコアでは、通常、プロキシの遅延を測定するAPIが用意されています。以下のコマンドはローカル環境での診断用です。制御APIが127.0.0.1:9090で有効になっており、この例では認証が不要であることを前提としています。測定対象は組み込みのDIRECTで、直接接続の基準を確認するためのものです。サブスクリプションのノードではありません。
curl --get "http://127.0.0.1:9090/proxies/DIRECT/delay" \
--data-urlencode "url=https://www.gstatic.com/generate_204" \
--data-urlencode "timeout=5000"成功すると、{"delay":186}のような結果が返り、今回の測定値が186 msであることを示します。これは形式を示す例です。特定のノードをテストする場合は、パス内のDIRECTを実際のプロキシ名に置き換え、名前をURLパス用にエンコードしてください。日本語や空白、スラッシュをそのまま連結することはできません。
APIでsecretを設定している場合、リクエストには対応するBearer認証ヘッダーが必要です。権限がない場合に返る401は、ノードのタイムアウトではありません。テストのために制御APIをインターネットへ公開しないでください。ポート9090は固定ではないため、クライアントで現在有効な設定を確認してください。
すべてタイムアウトする場合の確認手順
- コアが実行中で、サブスクリプションのノードが読み込まれているか確認してください。古い一覧が表示されているだけではないことも確認します。
- 別のテストURLでも試してください。1つのURLだけ失敗する場合は、まず接続先に到達できるかを確認します。
- ログでDNS、接続拒否、TLS、タイムアウトに関する情報を確認し、どの段階で失敗したかを切り分けます。
- システムの日付と時刻が正しいか確認し、HTTPS証明書の時刻に関する問題を除外します。
- 同じタイムアウト設定で異なる2つのノードを測定し、必要であれば直接接続の基準値とも比較します。
実際の通信速度を調べる：ノードと接続先を固定して繰り返し測定
2つのノードを比較するには、まず自動選択を手動で候補ノードに固定するか、既存の手動選択グループを使います。テスト中に出口を頻繁に切り替えると、結果の原因を特定しにくくなります。ブラウザーによる接続の再利用、サーバー側のキャッシュ、バックグラウンドのダウンロードも比較に影響します。
再現性のあるテスト手順
- 条件を固定：同じ端末と同じWi-Fiまたは有線ネットワークを使用し、ほかの大容量通信を一時停止します。
- 経路を確認：接続ログで対象ドメイン、適用ルール、最終ノードを確認します。ダウンロードが実際にはDIRECT経由になっていないか注意してください。
- 小規模なリクエストを繰り返す：ノードごとに5回測定し、最小値だけでなくすべての数値を記録します。
- 継続的な転送を確認：アクセスが許可されている同じ大容量ファイルを使い、30～60秒間測定します。開始直後の瞬間速度と安定した速度を分けて見ます。
- 時間を変えて再測定：たとえば10:00と21:00にそれぞれ測定し、夜間にスループットが低下したり、タイムアウトが増えたりしないか記録します。
5回の遅延が82、85、87、91、680 msだったとすると、中央値は87 msですが、最後の大きな変動にも注意が必要です。数値は計算方法を示す例で、実測レポートではありません。少数回のHTTPテストで失敗した割合を、そのまま「ネットワークのパケットロス率」と呼ぶことはできません。DNS、TLS、接続先サイト、接続タイムアウトが原因の可能性もあります。
遅延は小さいのにダウンロードが遅い場合に確認すること
- プロキシ出口の混雑：小さなリクエストにはすぐ応答できても、ピーク時は大容量通信で帯域を取り合うことがあります。
- 接続先サーバーの速度制限：ファイル配信サイトやCDNによって、同じ出口でも異なる制限が適用される場合があります。
- ローカルのWi-Fi：電波が不安定だと再送が発生し、継続的な転送速度が低下します。有線接続との比較も有効です。
- プロトコルと端末の負荷：暗号化処理やCPU使用率、クライアントのリソース制限がスループットに影響することがあります。
- 経路の違い：速度測定ボタンと実際の通信で異なるノードを使っている、またはアプリがシステムプロキシに従っていない可能性があります。
特に最後のケースはよくあります。ブラウザーでプロキシを使えていても、すべてのアプリが同じ経路を通るとは限りません。システムプロキシに従わないプログラムでは、アプリ内のプロキシ設定やTUNによる転送が必要な場合があります。TUNは通信をコアに取り込む方法を変えるもので、出口の帯域幅を増やすものではありません。基本設定はシステムプロキシの設定手順、用語の違いは用語クイックガイドをご覧ください。
ノード選びの結論：ミリ秒の数値だけでなく用途で判断
Web閲覧では応答の安定性と接続先への到達性、大容量ファイルのダウンロードでは持続スループット、動画では読み込み速度や再生中の途切れに注目します。音声会議やリアルタイム通信では、ジッターや切断、使用するUDP経路も確認が必要です。HTTP遅延テストだけではUDP転送の可否は分からず、アプリ内のネットワーク診断の代わりにもなりません。
- 日常のWeb閲覧：安定したノードを1つ選ぶか、適切な許容値を設定した自動選択グループを使います。
- 大容量ファイルのダウンロード：実際のダウンロード速度を比べ、開始後はできるだけ出口を固定します。
- 特定のサイトで問題がある：まず適用ルールを確認し、そのサイトへの実際の接続状況を比較します。
- 夜間に遅くなる：同じ条件で再測定し、午前中に記録した遅延だけで判断しないでください。
記録する項目は、測定時刻、テストURL、タイムアウト、最終ノード、繰り返し測定した遅延、継続ダウンロード速度です。情報をそろえることで、テスト先の問題か、ノード経路の問題か、ローカル設定の問題かを切り分けられます。クライアントを変更する場合は、まずクライアント比較を確認し、プラットフォームに合ったものを選びましょう。遅延の数値を小さくするためだけに、何度も再インストールする必要はありません。