1. 用途に合うノードを絞ってから遅延を比較

Clashに表示されるノードは、通常、リモートのプロキシサーバーへ接続するための設定一式です。接続できるからといって、すべての用途に向いているとは限りません。遅延が低くても、ダウンロードが速いとは限りません。まず用途を決めましょう。普段のWeb閲覧では応答速度、動画視聴では安定した通信速度と地域制限への対応、オンライン会議では遅延の揺れやパケットロス、UDP通信を確認します。

「利用するサービスに接続できる → 出口地域が条件に合う → 倍率を許容できる → 混雑時間帯も安定している → 遅延が低い」の順に絞り込むのがおすすめです。まず必須条件を満たさないノードを除外し、残った候補を比較しましょう。最小の遅延値だけで選ぶより確実です。

項目 確認すること これだけでは判断できないこと
遅延 同じテストURLで複数回測定し、ばらつきやタイムアウトを確認する 帯域幅の上限、すべてのサイトでの通信速度
倍率 プランの説明と利用量画面に記載された実際の課金ルール 回線が必ず速い、または安定していること
地域 利用するサービスが判定する出口IPの地域 ノード名と物理サーバーの所在地が完全に一致すること
プロトコル クライアントのコアが対応しているか、UDPの利用可否、現在のネットワークでの動作 特定のプロトコルがあらゆるネットワークで最速であること

2. 遅延テストは最小値だけでなく複数回の結果を見る

HTTP遅延はICMP pingとは異なる

Clash系クライアントでは、小さなHTTPまたはHTTPSのURLにアクセスしてプロキシの応答を確認し、結果をミリ秒で表示するのが一般的です。サーバーにICMP pingを送る単純な測定ではありません。計測時間に含まれる処理は、コアの実装、接続の再利用、プロトコルのハンドシェイク、テスト先などによって異なります。主に、プロキシ経由で指定URLにアクセスした際の応答を示します。

同じノードでも、アクセス先によって出口経路やCDNが異なることがあります。テストURLへの応答が速くても、動画サイト、コードホスティングサービス、オンライン会議が同じように快適とは限りません。また、測定用URLだけが利用できない場合もあります。すべてのノードがタイムアウトするときは、サブスクリプションをすぐ削除せず、まず測定先に問題がないか確認してください。

条件をそろえて5回測定する

  1. 同じ端末、同じネットワーク、同じテストURLを使います。ダウンロード、クラウドストレージの同期など、帯域を使う処理は一時停止してください。
  2. 候補を3つ選び、それぞれ5回測定します。測定の間隔は約10秒とし、ミリ秒単位の結果とタイムアウトの回数を記録します。
  3. まず中央値とばらつきを比較します。さらに、現地時間の20:00～23:00など、普段使う時間帯にも測定してください。
  4. 実際の用途でも確認しましょう。Webページを何度か開き、動画は数分間再生してバッファリングを確認し、会議では音声の途切れやパケットロスをチェックします。

たとえば、仮の測定結果がA：45、48、220、タイムアウト、190 ms、B：80、82、79、85、81 msだったとします。最小値はAのほうが低い一方、Bは5回の結果がより安定しています。Web閲覧や会議のような応答性が求められる用途では、Bを優先して検証する価値があります。数値は比較方法を示す例であり、実際の回線を測定した結果ではありません。

遅延・通信速度・ジッターは別々に見る

遅延が40 msのノードでも使える帯域が小さいことがあり、150 msのノードでも大容量ファイルを安定して転送できる場合があります。ダウンロード速度は、サーバーの負荷、ネットワーク間の混雑、接続先の速度制限、利用中の回線などに左右されます。速度測定では通信量を消費します。まず小規模なテストで候補を絞り、残った少数のノードで持続速度を確認しましょう。すべてのノードで大容量ファイルを使った測定を行う必要はありません。

3. 通信量倍率はサービス提供元の課金ルールで確認

「0.5倍」「1倍」「2倍」は、通常、サブスクリプション提供元が設定する課金上の倍率で、Clashコア共通の課金項目ではありません。ノード名に倍率が書かれていても、それは表示上の文字列にすぎず、名前を変更しても課金方法は変わりません。実際の消費量は提供元のルールと利用量画面で確認してください。アップロードとダウンロードの合算、時間帯による倍率、専用の通信量枠があるかも確認しましょう。

課金対象の通信量 = 課金対象の転送量 × ノード倍率

例：ダウンロード8 GB、アップロード2 GB、送受信の合計で課金される場合
0.5倍：10 GB × 0.5 = 5 GB
1倍：  10 GB × 1   = 10 GB
2倍：  10 GB × 2   = 20 GB

上記は単純化した計算例です。集計期間や単位換算、プロトコルのオーバーヘッドにより、クライアント側の統計とサービス提供元の利用量画面が完全には一致しないことがあります。少量の通信を一度試しただけで課金ミスと判断しないでください。画面の数値を記録し、通信量を管理しながら一定量のデータを転送したあと、利用量の更新を待って比較しましょう。

  • Web閲覧・メッセージアプリ：通信量は比較的少ないため、応答性と安定性を優先できます。
  • OSイメージ・大容量アップデート：プロキシが必要かを確認してから、倍率の低いノードの持続速度を比較します。
  • 長時間の動画視聴：1日の視聴量を通信量の予算に含め、1回の再生がスムーズかどうかだけで判断しないようにしましょう。

倍率が高い理由は、サービス提供元が特別な回線として設定しているための場合もあれば、単に料金プランの違いの場合もあります。通信速度や安定性を保証する技術的な指標ではありません。長期利用するなら、同じ時間帯での実際の通信状況と消費量を記録して、コストに見合うか判断しましょう。

4. 出口地域は利用するサービスの判定で確認

ノード名の「香港」「日本」「米国」などは、通常、想定される出口地域を示しますが、名前だけでは実際の地域を確認できません。中継地点と最終的な出口が別の地域にあることもあり、IPアドレスのデータベース更新が遅れている場合もあります。確認すべきなのは、利用するサービスにどの出口IPが見えており、そのIPがどの地域として判定されているかです。

地域が合っていてもサービスを利用できるとは限らない

動画配信など地域制限のあるサービスでは、IPアドレスの地域だけでなく、データセンターか住宅回線か、アカウントの地域、支払い情報、不正利用対策の判定なども確認されることがあります。ログインページが開けても、すべてのコンテンツを再生できるとは限りません。番組を1つ再生できても、ライブラリ全体を利用できるとは限りません。「地域制限の解除」は、具体的なサービス、コンテンツ、テストした時間を明確にして確認しましょう。ノードのラベルだけでは判断できません。

  1. 利用するサービスに対応したプロキシグループでノードを選び、開いているページを閉じるか既存の接続を終了してから再アクセスします。
  2. クライアントの接続ログを確認し、サービスへの通信が想定したルールとノードを通っているか調べます。
  3. 出口IPの地域を確認し、対象サービスでコンテンツを再生するなど、実際の操作を試します。
  4. 結果が想定と異なる場合は、アカウントの地域、アプリの位置情報権限、IPv6の通信経路、関連ドメインがプロキシを経由せず接続されていないかを確認します。

DNSの問い合わせ先の地域と、最終的な出口地域は別のものです。DNSサーバーを変更しても、プロキシの出口が自動的に別の国へ変わるわけではありません。一部の通信が直接接続になっている、またはIPv6が想定した経路を迂回している場合は、ノードの地域を調べる前に通信の取り込みとルール振り分けを修正してください。関連する設定項目はドキュメントをご覧ください。

5. プロトコルの種類はコアの対応状況と通信環境で判断

Shadowsocks、Trojan、VMess、VLESS、Hysteria2、TUICは、それぞれ異なるプロトコルまたはプロトコル体系です。決まった速度ランクがあるわけではありません。実際の通信性能は、プロトコルの設定、トランスポート層、サーバーの実装、ネットワークの混雑、ローカルネットワークの制限などによって変わります。同じプロトコルでも、サーバーを変えたときの差のほうが、プロトコルを変更したときより大きいことがあります。

  • Shadowsocks：暗号化方式とコアの対応範囲を確認します。追加プラグインを使うノードでは、クライアントがそのプラグインに対応しているかも確認してください。
  • Trojan：TLSを使う構成が一般的です。サーバーアドレス、ポート、認証情報、TLS設定を一致させる必要があります。
  • VMess / VLESS：プロトコル名だけでなく、トランスポート方式やTLSなどの設定も確認します。WebSocketとgRPCなどの設定は、互いに置き換えられません。
  • Hysteria2 / TUIC：QUICをベースとしており、UDP通信が必要です。ネットワークでUDPが制限されていると接続できない場合があります。他のTCPノードが使えるからといって、設定が正しいとは限りません。

Clashはクライアントのエコシステムで広く使われる呼称ですが、実際に対応するプロトコルは実行中のコアとバージョンによって異なります。オリジナルのClashとClash Meta（現在のmihomo）では、対応範囲が異なります。インポート時に「サポートされていないプロキシタイプ」と表示された場合は、YAMLのtypeを別の値に書き換えるのではなく、まずコアの対応状況を確認してください。名前を変えてもサーバーのプロトコルは変換されません。

6. url-test：条件を満たすノードから低遅延のものを自動選択

地域、倍率、用途に合ったサービスが使えることを確認してから、url-testで候補内の遅延を比較します。地域、コスト、利用条件が異なるノードをすべて同じ自動選択グループに入れるのは避けましょう。最も遅延が低いノードが、現在の用途に合うとは限りません。

以下はmihomo向けの例です。既存設定のproxiesに、HK-01とHK-02という名前のノードがあり、どちらも同じ用途で検証済みであることを前提としています。名前は参照関係を示すための例です。実際に使う場合は、既存ノード名と完全に一致させてください。

proxy-groups:
  - name: HK-AUTO
    type: url-test
    proxies:
      - HK-01
      - HK-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
  • interval: 300：測定間隔は300秒です。300ミリ秒ではありません。
  • tolerance: 50：切り替えの許容差を50ミリ秒に設定し、わずかな遅延差による頻繁な切り替えを抑えます。
  • lazy: true：遅延測定を有効にします。グループが使われていない間も、設定間隔で常に測定し続けるという意味ではありません。
  • url：応答の安定した小さなテストURLを指定します。例のURLは通常HTTP 204を返しますが、現在のネットワークとノードからアクセスできることを確認してください。

これは完全な設定ではありません。グループの項目は既存のproxy-groupsリストに追加してください。同じYAMLの最上位にこのキーを重複して追加してはいけません。ノードがproxy-providers由来の場合は、プロバイダーの構成に合わせてuseと適切なフィルター条件を使います。上記の静的ノード参照をそのままプロバイダー設定の代わりにできるとは限りません。

7. fallback：利用可能な予備ノードを順番に使う

fallbackとurl-testは目的が異なります。前者は候補の順に利用可能なノードを選び、後者は測定した遅延を比較します。通常は優先ノードを固定し、測定に失敗した場合に予備へ切り替えたいときはfallbackを使えます。実際のすべての通信障害に対し、ただちに切り替わることを保証するものではありません。

proxy-groups:
  - name: HK-FAILOVER
    type: fallback
    proxies:
      - HK-01
      - HK-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

  - name: PROXY
    type: select
    proxies:
      - HK-AUTO
      - HK-FAILOVER
      - HK-01
      - HK-02

この設定例は前のセクションと同じproxy-groupsリストに追加します。HK-AUTOはすでに存在している必要があります。続いて、プロキシを使うルールからPROXYを参照し、クライアントで自動選択グループ、予備グループ、または個別ノードを選択します。同じ名前のプロキシグループがすでにある場合は、同名の項目を新たに作らず、既存の項目を編集してください。

たとえば、次のルールはgithub.comとそのサブドメインへの通信をPROXYに振り分けます。このルールは、対象の通信に先に一致する広範なルールや、最後のMATCHルールより前に置いてください。例を使うために既存のルールをすべて上書きしないようにしましょう。

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  # 既存のルールは残し、最後の MATCH は末尾に置く

優先ノードから測定用URLには接続できても、動画サービスでエラーが起きる場合、fallbackは優先ノードを使い続けることがあります。これは測定先と実際のサービスが異なるために起こります。ノードの切り替えが影響するのは主に新しい接続です。ダウンロード中の通信、動画再生、長時間接続が自動的に移行するとは限らないため、アプリ側で再接続が必要になる場合があります。

8. 日常的なノード選びのチェックリスト

  1. 通信経路を確認：対象アプリの通信がシステムプロキシまたはTUNを経由し、接続ログで想定したルールに一致していることを確認します。
  2. 必須条件を確認：必要な地域で対象サービスを利用できること、UDPなど必要な機能が実際に使えることを確認します。
  3. コストを確認：ノード名だけで判断せず、サービス提供元の画面で倍率、アップロードの課金、残りの通信量を確認します。
  4. 安定性を比較：条件をそろえて5回測定し、普段使う時間帯にもばらつき、タイムアウト、持続速度を確認します。
  5. 候補グループを作成：用途が同じノードを自動選択グループにまとめ、検証済みのノードを手動で選べるよう残しておきます。
  6. 変更を保存：設定をバックアップし、設定チェックを実行してからログを確認します。サブスクリプションを更新した後は、カスタムグループが上書きされていないか確認してください。

ノード選びで大切なのは、常に最小となる遅延値を探すことではありません。用途に合った条件が明確で、コストを管理でき、検証結果を再現できる候補をいくつか確保しましょう。回線の状態は時間帯やネットワークによって変化します。問題が起きたら、まず通信の取り込み、ルール、測定先、利用するサービスのどこに原因があるかを切り分けてから、ノードの変更を判断してください。