Clashのノード選び方：レイテンシ測定・通信量倍率・地域とプロトコルの比較

まず実際の通信経路を確認し、その後にノードの数値を比較

Clashのノード一覧に表示されるレイテンシ、地域、倍率は、それぞれ異なる情報です。レイテンシはプローブにかかった時間、地域は通常サービス提供元が示す出口の場所、倍率は契約アカウントから差し引かれる通信量に関係します。これらは相互に置き換えられません。ノードを選ぶ際は、まず接続先に必要な出口を決め、次に利用可能か・安定しているかを確認し、最後に速度と通信量のコストを比較しましょう。

ノードのテストは正常なのにWebページが遅い場合、まずWeb通信がそのノードを経由しているか確認してください。mode: rule では、rules が上から順に適用され、ルールの転送先にはポリシーグループや DIRECT を指定できます。現在のリクエストが使っていないポリシーグループを切り替えても、そのリクエストの経路は変わりません。

1. クライアントの「接続」画面で対象ドメインの接続を探し、適用されたルール、出站経路、ポリシーグループを確認します。
2. 変更しているのが、その接続経路で使われているグループか確認します。名前が似た別のグループではないことにも注意してください。
3. ノードを切り替えたら、接続を再確立します。既存のTCP接続は、選択を切り替えても通常は自動で移行しません。
4. バックグラウンドのダウンロードやクラウドストレージの同期を一時停止してから比較テストを行い、端末側の帯域競合を避けます。

レイテンシ測定：HTTPプローブはダウンロード速度テストとは異なる

クライアントで一般的なレイテンシ測定は、指定したテストURLへプロキシ経由でアクセスし、応答にかかった時間を記録します。プロキシサーバーにICMP pingを送るだけの測定ではありません。ノードへの接続、TLSハンドシェイク、テストサイトの応答、ローカルネットワーク、接続の再利用などが結果に影響することがあります。実装の詳細はコアやクライアントによって異なる場合もあります。

比較する際は、テストURL、ネットワーク、測定時間帯を揃えましょう。あるクライアントで測った80 msと、別のクライアントで測った110 msをそのまま順位付けしても、共通の基準がないため参考になりにくいものです。一度「タイムアウト」と表示されても、その測定が制限時間内に完了しなかったことを示すだけで、すべてのWebサイトにアクセスできないとは限りません。

繰り返し測定して低レイテンシと安定性を見分ける

以下は判定方法を示すための例であり、本サイトで測定した結果ではありません。各ノードを同じネットワーク環境で5回連続して測り、測定間隔は約10秒にします。

Webページの操作では往復時間と失敗率が重視される一方、大容量ファイルのダウンロードでは持続的なスループットが重要です。ノードAが60 msだからといって、ノードCよりダウンロードが速いとは限りません。継続速度は回線容量、共有負荷、サーバー側の速度制限、接続先サイトにも左右されます。プローブ結果のばらつきは厳密な意味でのジッター測定ではなく、これだけで回線全体のパケットロス率を算出することもできません。

ダウンロードと動画は個別に確認する

• 信頼できる同じダウンロード元を使い、約30～60秒間テストします。開始直後のピーク値だけでなく、速度が安定してからの値を確認してください。
• MB/s と Mbps の違いに注意します。理論上、10 MB/sは約80 Mbpsですが、実際にはプロトコルのオーバーヘッドがあります。
• 動画では再生開始までの時間、バッファリングの回数、プレーヤーに表示される接続速度を確認します。一度再生できても、混雑時間帯に安定して使えるとは限りません。
• 速度テスト自体にも通信量が発生します。大容量ファイルをテストする前に、残りの通信量とノードの倍率を確認してください。

通信量倍率：サービス提供元の課金方式を確認

倍率はサブスクリプション提供元が定める課金ルールであり、Clash共通のローカル課金設定ではありません。標準のClashやmihomoには、サービス提供元のアカウントから差し引かれる通信量を変更できる共通のノード ratio フィールドはありません。ノード名に「2×」とあっても目安にすぎず、実際の課金は提供元のノード説明、請求明細、アカウントの利用量記録で確認してください。

一般的な計算方法は「課金対象の実通信量 × ノード倍率」です。アップロードとダウンロードの合計が課金対象だとすると、ダウンロードが8 GB、アップロードが2 GBの場合、基準となる通信量は10 GBです。0.5×、1×、2×のノードを使うと、それぞれ5 GB、10 GB、20 GBが差し引かれる計算になります。ここでは同じ単位で説明していますが、サービスがGBとGiBのどちらを使うか、端数処理、時間帯別の課金があるかは別途確認が必要です。

倍率から使える通信量の目安を計算する

• アカウントの残量が100 GBで、2×のノードを使い続ける場合、同じ計算方式では基準となる通信量の目安は約50 GBです。
• 0.5×だから速度が遅いとは限らず、2×でも帯域が2倍になるわけではありません。倍率が示すのは料金上の関係であり、性能を保証するものではありません。
• 長時間の動画視聴、大容量ファイルのダウンロード、端末のバックアップでは、まず通信量の残りを確認します。短時間のログインや特定地域からのアクセスでは、必要な機能が使えるかを優先しましょう。
• クライアントの累計通信量とサービス提供元の課金量は異なる場合があります。接続の集計範囲、集計期間、プロトコルのオーバーヘッドなどが違えば、差が生じます。

地域の選び方：出口の場所と回線品質を分けて考える

ノードの地域は通常、外部サイトへのアクセスに使われる出口の場所を指し、サブスクリプション内の server アドレスがある物理的な場所とは限りません。入口、中継地点、出口はそれぞれ異なるネットワークにある場合があります。香港、日本、シンガポールなど地理的に近い地域のノードは候補を絞る際の参考になりますが、距離だけでは事業者間のルーティング、夕方以降の混雑、出口の品質までは判断できません。

実際の用途に合わせて条件を絞る

接続先のWebサービスは独自のIPアドレス位置情報データベースを使うことがあり、アカウントの地域、支払い情報、端末の位置なども判定に加える場合があります。あるIP検索サイトで特定の地域と表示されても、すべてのサービスで同じ判定になるとは限りません。対象のサービスで直接確認し、「地域表示が正しい」ことをアクセス権の保証と考えないでください。

プロトコルの選び方：まずコアの対応状況、次に通信品質を確認

プロトコルは接続方式や機能の範囲を決めますが、回線状況を抜きに優劣を比較することはできません。Shadowsocks、Trojan、VMess、VLESS、Hysteria2、TUICなどへの対応は、実際に使用するコアによって異なります。mihomoが対応するプロトコルと従来のClashコアが対応するものは完全には一致しません。クライアントの見た目が似ていても、内蔵コアが同じとは限りません。

インポート後に「unsupported proxy type」などのエラーが出た場合は、測定先URLを何度も変更するのではなく、ノードの type とクライアントが実際に使用しているコアを確認してください。クライアントの変更が必要な場合は、まず選び方ガイドを確認し、次にダウンロードページから対応プラットフォーム用のものを選びます。

UDP、システムプロキシ、TUNの役割の違い

• Hysteria2とTUICはUDPを使って接続します。現在のネットワークでUDPが制限されていると、ハンドシェイクに失敗したり、接続が不安定になったりする場合があります。TCP方式の接続は正常に動作することもあります。
• ノード設定の udp: true は、この項目に対応するタイプでUDP転送を許可します。サーバーやローカルネットワークにUDP機能を追加するものではなく、すべてのプロトコルタイプで使えるわけでもありません。
• 一般的なHTTPシステムプロキシは、プロキシ設定に従うアプリ向けです。ゲームや音声通話のUDP通信もプロキシを経由しているとは限りません。
• TUNは仮想ネットワークインターフェースを使って通信を取り込みますが、ルーティング、ルール、DNS、権限の設定が正しく必要です。TUNを有効にしても、サービス提供元がノードに割り当てた帯域が増えるわけではありません。

同じ回線でも、プロトコルによってハンドシェイク、輻輳制御、リソース消費に差が出る場合があります。一方、回線が異なれば、帯域や負荷の影響のほうが大きいことも少なくありません。プロトコル名の新旧だけで判断せず、現在のネットワークでの接続成功率、実際の用途での動作、端末への負荷を基準に選びましょう。

ポリシーグループ設定：手動選択と自動測定を使い分ける

select は地域や出口を固定したい場合、または手動で比較したい場合に向いています。url-test は指定URLへの測定結果に基づき、候補を自動で選択します。後者はサービス提供元の倍率を考慮せず、動画サービスで指定地域が利用できるかも自動確認しません。用途の異なるノードをすべて同じ自動選択グループに入れると、「測定は速いが、用途の条件を満たさない」結果になることがあります。

以下はmihomoのポリシーグループ設定例であり、完全な設定ではありません。使用前に proxies 内に「香港-A」と「日本-B」という名前が完全一致するノードが必要です。プロキシプロバイダーを使う場合は、実際の構成に合わせて use でプロバイダーを参照してください。ノード名を2つ書くだけでは使えません。

proxy-groups:
  - name: 日常用
    type: select
    proxies:
      - 自動レイテンシ
      - 香港-A
      - 日本-B

  - name: 自動レイテンシ
    type: url-test
    proxies:
      - 香港-A
      - 日本-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

• interval: 300 は測定間隔が300秒という意味で、サブスクリプションの更新間隔ではありません。
• tolerance: 50 は切り替えのしきい値をミリ秒単位で設定し、小さな差による頻繁な切り替えを防ぎます。用途上のレイテンシ上限ではありません。
• lazy: true を設定すると遅延測定が有効になり、グループが使われていない間は定期測定を行わない場合があります。そのため、画面に表示された古い数値をリアルタイムの結果とみなさないでください。
• url はヘルスチェックの対象です。安定してアクセスできるURLを選んでください。対象を変更した後は、変更前後の数値をそのまま比較できません。

ポリシーグループを設定しただけでは不十分です。実際のリクエストで使うには、該当するルールから「日常用」を参照する必要があります。編集前に設定をバックアップし、読み込み後にログと接続画面を確認してください。サブスクリプションの更新で生成ファイルへの直接編集が上書きされることがあります。継続的に変更する場合は、クライアントが提供するオーバーライドやマージ機能を使いましょう。設定方法はクライアントによって異なります。

ノード選びのチェックリスト

1. 要件を確認：対象サイト、必要な地域、UDPへの依存、本月の残り通信量を記録します。
2. 候補を絞る：地域とプロトコルの要件を満たすノードを2～3個選び、倍率とコアの互換性を確認します。
3. 条件を揃えて測定：同じネットワーク、同じURLで各ノードを5回測定し、タイムアウトが繰り返されたり、ばらつきが目立ったりする候補を優先的に除外します。
4. 実際の用途で確認：Webページは接続を再確立し、動画は連続再生、ダウンロードは安定速度を確認し、ゲームはアプリ内レイテンシを確認します。
5. 出口を確認：接続画面でルールとプロキシ経路を確認し、直接接続の結果をノードの性能と取り違えないようにします。
6. 混雑時間帯も確認：普段使う時間帯にもう一度測定し、同じ要件を満たす予備ノードを1つ確保します。

最終的な記録は、ノード名、用途、倍率、連続測定の結果、実際の用途での動作の5項目で十分です。一度だけ記録された最低レイテンシではなく、あとから確認できるこれらの情報を基準に選びましょう。ポート、ルール、DNSの項目を確認する場合は、設定リファレンスもご覧ください。