1. まず通信経路を確認し、4つの指標を比較する
Clashのノードは、遅延の小さい順に並べるだけでは選べません。遅延は応答速度、倍率はデータ通信量の消費、地域は出口の位置、プロトコルはクライアントとの互換性や通信方式に関わります。4項目を確認したうえで、実際の用途で安定性を試しましょう。
始める前に、サブスクリプションをインポートして設定を有効にします。デスクトップクライアントでは通常、「プロキシ」画面でプロキシグループを選び、「接続」画面でリクエストに適用されたルールと出口を確認できます。メニュー名はクライアントによって異なります。初期設定がまだの場合は、サブスクリプションのインポート方法を先に確認してください。
- 「プロキシ」画面で対象サイトに使われるプロキシグループを見つけ、現在の選択内容を控えます。
- テスト中は手動選択に切り替え、自動遅延測定グループによって途中でノードが変わらないようにします。
- 開いているページを閉じるか、関連する既存の接続を終了してからリクエストをやり直します。確立済みの接続は、ノードを選び直してもすぐには切り替わらないことがあります。
- 「接続」画面で、対象のリクエストが
DIRECTや別のプロキシグループではなく、選択したノードを経由していることを確認します。
2. 遅延の見方：数値が小さくてもダウンロードが速いとは限らない
クライアントが測定するのはテスト用リクエストであり、すべての通信ではない
Clash系クライアントのノード速度テストでは、指定したURLへリクエストを送り、ノード経由でそのアドレスにアクセスするまでの時間を測る方法が一般的です。単純なICMP pingとは異なります。テストURLや接続の再利用、DNS、コアの実装、測定時のノード負荷などが結果に影響します。比較する際は、同じテスト先と同じ方法を使ってください。
たとえばAノードが45 ms、Bノードが90 msでも、分かるのは今回のテスト先への応答がAのほうが速かったということだけです。Aの帯域が混雑していれば、大きなファイルのダウンロードはBより遅くなることもあります。テスト用サイトに正常に接続できても、動画サイトやゲームサーバーへの接続が正常とは限りません。
テストを繰り返し、一時的な低遅延と安定した低遅延を見分ける
- まずは少数に絞る：地域の条件に合うノードを3つ選び、それぞれ5回、約10秒間隔で測定します。サブスクリプション全体を何度も連続測定するのは避けてください。
- ばらつきを確認する：例Aは42、45、43、280、46 ms、例Bは78、81、79、83、80 msです。Aは通常時の応答が速いものの、大きな遅延が一度発生しているため、さらに様子を見る必要があります。
- タイムアウトも記録する：5回中2回タイムアウトするなら、最小値が一度出たことよりも気にかけるべきです。テスト先やローカルネットワークが原因の可能性もあるため、別の利用可能なテスト先でも確認してください。
- 夜間にも測定する：日中と20:00～23:00では混雑状況が異なることがあります。長期利用するノードは、実際に使う時間帯にもテストしましょう。
数値は測定結果の例であり、このサイトによる実測ランキングではありません。Web閲覧では応答速度と失敗率、動画やダウンロードでは持続的なスループット、音声通話やゲームではジッター、パケットロス、UDPが実際に使えるかを重視します。
3. 倍率の見方：通信量を計算して、コストに見合うか判断する
ノード名にある 0.5x、1x、2x は、通常、サービス提供者が定めるデータ通信量の換算倍率です。Clashのプロトコル項目でも、通信速度の倍率でもありません。「2倍」と書かれていても、帯域が2倍になるわけではありません。クライアントは一般にノード名を表示するだけで、サーバー側の通信量計算には関与しません。
| ノード名の倍率表記 | 通信量の例 | 倍率適用後の換算量 | 確認するポイント |
|---|---|---|---|
| 0.5x | 10 GB | 5 GB | 利用時間や地域の制限、別途設定された速度制限の有無 |
| 1x | 10 GB | 10 GB | アップロードとダウンロードの両方が計上されるか |
| 2x | 10 GB | 20 GB | 追加コストに見合う回線や出口が得られるか |
上の表では、「課金対象の総通信量 × 倍率」を消費量として計算しています。実際の計算方法はサービスの説明とアカウントの使用量表示で確認してください。クライアントの通信量、通信事業者の通信量、アカウント上の消費量は、集計範囲や単位の違いによって一致しないことがあります。倍率の記載がないノードを、1xだと決めつけないでください。
名前から性能を推測せず、月間の通信量をもとに選ぶ
たとえば、月の動画通信量が約60 GBの場合、2xのノードでは課金対象の通信量が約120 GBになります。同じ計算方法なら、0.5xでは約30 GBです。低倍率のノードで動画を安定して再生できるなら、名前に「専用回線」とあるだけで高倍率のノードに切り替える必要はありません。一方、低倍率でも頻繁にバッファリングするなら、リアルタイム会議には向きません。
速度テストでもデータ通信が発生します。100 Mbpsで30秒間ダウンロードを続けた場合、プロトコルのオーバーヘッドを除いても、理論上は約375 MBの通信量になります。通信量に上限があるプランでは、まず短時間のテストで候補を絞り、少数のノードだけを継続的に検証してください。
4. 地域の見方：入口の場所と実際の出口を区別する
ノード名にある「香港」「日本」「アメリカ」は、通常、想定される出口の地域を表しますが、名前の付け方は提供者によって異なります。中継サーバーを経由して別の地域からインターネットへ接続する回線もあります。設定にある server のアドレスが入口を示しているだけの場合もあります。入口が近くても、出口が近いとは限りません。
国旗だけで判断せず、用途に合わせて出口を確認する
- 一般的なWeb閲覧：まず距離や経路の条件がよい地域を選び、夜間の応答速度と接続成功率を比べます。地理的な距離だけでなく、通信事業者間の接続や遠回りの経路も影響します。
- 地域限定コンテンツ：利用するサービスが認識する地域の出口を使い、サービスの利用規約を守ってください。IPアドレス検索サイトに表示された地域が、すべてのプラットフォームで同じように判定されるとは限りません。
- 仕事用アカウント：安定した出口を優先し、短時間に複数の地域から何度もログインするのは避けます。ノードの再接続後にIPアドレスが変わるかは、別途確認してください。同じ名前のノードでも、固定IPとは限りません。
- ゲーム：ゲームサーバーの地域と実際の通信経路を基準にします。プロキシの入口まで20 msでも、ゲームサーバーまで20 msとは限りません。
出口を確認するには、「接続」画面でIPアドレス確認のリクエストが選択したノードを実際に通っていることを確かめてから、検索結果を確認します。その後、目的のサービスにも直接アクセスして確かめてください。ルールによってサイトごとに出口が異なることがあるため、1つの確認サイトの結果だけですべてのアプリの経路を判断することはできません。
5. プロトコルの選び方：まず互換性を確認し、次に通信状況を比較する
サブスクリプションで使われているプロトコルは、現在のコアが対応している必要があります。オリジナル版ClashとClash Meta（現在は一般にmihomoと呼ばれます）では、対応プロトコルが異なります。クライアントの画面上の名称が似ていても、使っているコアは異なる場合があります。クライアントの「バージョン情報」やコア情報の画面で、実際のコア名とバージョンを確認し、該当コアのドキュメントを参照してください。画面のアプリだけを更新しても、コアが切り替わるとは限りません。
| プロトコル | 選ぶ際に確認すること | 名称だけでは判断できないこと |
|---|---|---|
| Shadowsocks | 暗号化方式が対応しているか、サーバーとノードの設定でUDPが許可されているか | プロトコル名だけで遅延が最も小さいとは判断できない |
| VMess / Trojan | 通信方式、TLS、関連パラメーターがすべて一致しているか | TLSを使っていても、高速であることや混雑の影響を受けないことが保証されるわけではない |
| VLESS | そのプロトコルと使用する通信方式に対応したコアが必要 | サブスクリプションをインポートできても、拡張パラメーターがすべて有効とは限らない |
| Hysteria2 / TUIC | 対応するコアを使い、ローカルネットワークと回線の両方でUDPが通ることを確認する | QUICベースでも、あらゆるネットワークで速くなるとは限らない |
現在のWi-FiでUDPが制限されている場合、UDP通信に依存するノードは接続に失敗しても、TCP通信の候補ノードなら使えることがあります。一方、パケットロスが多い環境では、特定のプロトコルや実装がよりよい結果を出すこともあります。同じネットワークで近い時間帯に比較し、プロトコル名だけで回線の品質を決めつけないでください。
ゲームに必要なのは、UDPが最後まで通る通信経路
ノード経由でゲームをプレイできるかどうかは、アプリの通信がプロキシに取り込まれているか、コアとノードが必要なUDP転送に対応しているか、サーバー側で利用できるか、ルールが正しい出口を選んでいるかによって決まります。一般的なシステムHTTPプロキシでは、ゲームのUDP通信をすべて取り込めないことがあります。必要な場合に限り、クライアントが対応するTUNモードを検討してください。
TUNは端末内の通信を取り込む方式であり、ノードのプロトコルではありません。有効にしても遅延が自動的に改善するわけではありません。有効化後もルーティング、DNS、接続記録を確認してください。会社のネットワーク、別のVPN、仮想ネットワークアダプターとの競合が起きることもあります。トラブルシューティングでは一度に1つの設定だけを変更し、元に戻せる方法を確保してください。
6. Web閲覧・動画・ゲームの用途別にテストする
まず地域とコアの互換性を確認して対象外のノードを除き、倍率で許容できるコストの候補に絞ってから、遅延と実際の用途で比較します。数十個の名前から最小の数値を選ぶより、同じ条件で再現しやすく、ネットワークを変えた後の再テストもしやすくなります。
| 用途 | 優先する指標 | テスト方法 |
|---|---|---|
| Webサイト・ドキュメント | 応答が安定していること、リクエストの失敗が少ないこと | 同じ3つのよく使うサイトで、初回読み込みと再読み込みの結果を記録する |
| 動画再生 | 持続的なスループット、バッファリング、通信量の倍率 | 同じ動画と画質に固定して5分間再生し、バッファリングの回数とバッファ量の変化を確認する |
| 音声通話・会議 | ジッター、パケットロス、接続の継続性 | アプリの通話統計を10分間確認し、ノードの速度テスト結果だけで判断しない |
| オンラインゲーム | ゲームサーバーへの実際の遅延、パケットロス、UDPの経路 | 同じサーバー地域を選び、トレーニングやランクに影響しないモードで10分間プレイして、ゲーム内の数値を記録する |
そのまま実践できるノード選びの手順
- 候補を3つ残します。たとえば、同じ地域の1xノードを2つと0.5xノードを1つ選び、すべて現在のコアで読み込めることを確認します。
- 同じテストURLを使って各ノードを5回測定し、代表的な遅延、最大値、タイムアウト回数を記録します。
- 同じネットワークで実際の用途をテストします。バックグラウンドの影響を避けるため、システム更新やほかの大容量ダウンロードは一時停止してください。
- 日時、ネットワークの種類、ノード名、倍率、出口の地域、用途別の結果を記録します。サブスクリプションURLやノードのキーは記録しないでください。
- メインで使うノードを1つ選び、別回線の予備ノードも1つ確保します。夜間に再テストしてから、長期利用するノードを決めましょう。
たとえば、Aノードは45 msでも、5分間の動画再生で3回バッファリングが発生し、Bノードは85 msでもバッファリングがなく、どちらも1xなら、動画にはまずBを選ぶのが適しています。これは判断の一例で、固定の基準値ではありません。リアルタイム通信では、アプリ内の遅延やパケットロスも確認してください。
7. よくある質問：自動選択・タイムアウト・切り替え後の確認
自動選択なら、常に最速のノードを選べますか？
url-testプロキシグループは通常、指定したテストURLへの遅延を基準に自動選択します。動画のスループット、地域ごとの利用可否、倍率によるコストを直接測定するものではありません。異なる地域や倍率のノードを同じグループに混在させると、用途に合わないノードが選ばれることがあります。条件に合うノードを同じグループにまとめてから、自動テストを利用しましょう。グループの構成方法はプロキシグループの使い方を確認してください。
ノードがタイムアウトと表示されたら、必ず使えなくなっていますか？
必ずしもそうではありません。テスト先に接続できない、DNSに問題がある、ローカルネットワークで制限されている、一時的に混雑しているなどの理由でタイムアウトすることがあります。まず別の候補ノードと、別の利用可能なテスト先で確認し、「ログ」に名前解決の失敗、ハンドシェイクの失敗、接続タイムアウトなどが記録されていないか調べてください。トラブルシューティングの手順は接続チェックの手順を参照してください。
ノードを切り替えても、速度や地域が変わらないのはなぜですか？
まず正しいプロキシグループを選んでいることを確認し、対象の接続を張り直してください。ブラウザーの持続接続、アプリの接続プール、バックグラウンドのダウンロードは、切り替え前の出口を使い続けることがあります。必要に応じてアプリの関連接続を終了して再起動し、「接続」画面でノードとルールを確認します。クライアントの通信量表示が変わったかどうかだけで、切り替えの成否を判断しないでください。