Clashのプロキシグループ選び方：url-test・fallback・load-balanceの設定と使い分け

3種類のプロキシグループ：遅延・優先順位・接続の振り分け

Clashのプロキシグループは「ルールに一致した通信を、どの出口から接続するか」を決めます。ルールが通信をグループに振り分け、グループが候補ノードから出口を選びます。プロキシグループを自動測定にしても、ドメインルールは変更されず、もともと DIRECT で接続する通信がプロキシ経由になることもありません。

url-test は測定遅延の低い出口を自動選択する場合に、fallback は主回線と予備回線の順序を固定したい場合に、load-balance は複数の出口に接続を振り分けたい場合に適しています。性能の優劣で選ぶのではなく、遅延、出口の安定性、複数回線の活用要件に応じて使い分けます。

url-test：toleranceで切り替え頻度を調整

url-test は候補ノード経由で指定したURLにアクセスし、測定結果をもとに出口を選択します。ICMP pingや帯域測定ではありません。測定時間はプロキシ接続、接続先サイトの応答、ネットワーク状況に左右されるため、候補ノードの比較には同じ測定URLを使ってください。

基本設定とパラメーターの単位

以下は設定の一部であり、完全なサブスクリプションではありません。現在の設定にある proxies で「香港-01」「香港-02」「日本-01」という3つのノードが定義済みだとします。適用時は実際に登録されているノード名に置き換えてください。トップレベルの proxy-groups を新たに作らず、既存のリストに項目を追加してください。

proxy-groups:
  - name: 低遅延自動選択
    type: url-test
    proxies:
      - 香港-01
      - 香港-02
      - 日本-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

• url：ヘルスチェックに使うHTTPまたはHTTPSのURLです。ここでは応答サイズの小さい測定用エンドポイントを指定しています。ログインが必要なサービスページは使用しないでください。
• interval: 300：測定間隔は300秒、つまり5分です。300ミリ秒ではありません。
• tolerance: 50：切り替え幅は50ミリ秒です。候補ノード間のわずかな差で頻繁に切り替わるのを抑えます。
• lazy: false：グループが使われていない間も定期測定を続けるため、動作を確認・比較しやすくなります。その分、測定リクエストは増加します。

toleranceは遅延の上限ではない

仮の数値で説明します。現在のノードの遅延が180ミリ秒、別のノードが155ミリ秒なら、差はわずか25ミリ秒です。toleranceを50ミリ秒に設定している場合、毎回後者に切り替わるとは限りません。別のノードが100ミリ秒まで下がり、差が大きくなれば、切り替え条件を満たしやすくなります。実際の選択は、その回の測定結果とノードの接続状態にも左右されます。

tolerance は「遅延が50ミリ秒を超えると使えない」という意味ではなく、回線の遅延が常に一定値以下になる保証でもありません。普段使いでは、まず測定間隔を300秒、toleranceを50ミリ秒にして様子を見てください。出口が頻繁に変わる場合は、測定間隔を数秒に縮めるのではなく、まずノードの品質と測定先を確認し、それからtoleranceを大きくすることを検討します。

fallback：リスト順で主回線と予備回線を指定

fallback は、リストの先頭から順に、ヘルスチェックで利用可能と判定されたノードを使います。全ノードから最も遅延の低いものを探す方式ではありません。2番目のノードが80ミリ秒、1番目が160ミリ秒でも、1番目が利用可能と判定されている限り、主回線として優先されます。

proxy-groups:
  - name: 主回線・予備回線
    type: fallback
    proxies:
      - 香港-01
      - 日本-01
      - 香港-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

ここでは「香港-01」が優先ノード、「日本-01」が第1予備、「香港-02」が第2予備です。利用地域を固定する必要がある場合は、条件に合うノードだけを登録してください。異なる地域のノードを予備に含めると可用性が高まる一方、サービス提供地域、表示言語、ログイン時の不正利用検知の状態が変わる可能性があります。

障害時の切り替えはセッションの引き継ぎではない

• 検出には時間がかかります：間隔を300秒にしても、障害発生後すぐに切り替わるとは限りません。検出までの時間は測定のタイミング、タイムアウト、接続が開始されるタイミングにも左右されます。
• 主ノードに戻る場合があります：リストの先頭にあるノードが復旧すると、以後の接続が再びそのノードを使うことがあります。予備ノードに固定されるわけではありません。
• 確立済みの接続は引き継がれません：使用中のノードに障害が起きると、転送中の接続が切断され、アプリ側で再接続が必要になる場合があります。プロキシグループにTCPセッションを移行する機能はありません。

リモート管理や長時間のアップロードなど、出口を固定したい処理には、手動の select または順序を明確にした fallback が適しています。ただし、出口の変更を一切許容できない処理では、自動切り替えに頼らず、アプリ側の再接続、レジューム、セッション復旧機能も利用してください。

load-balance：接続を振り分ける方式。1接続の帯域は合算されない

load-balance は複数の出口を使って接続を振り分けます。1つのTCP接続を分割して2つのノードに流す機能ではないため、3回線を登録しても、1つの接続で行うダウンロードが自動的に3倍速くなるわけではありません。複数のタスクや接続先へのアクセスで効果があるかどうかは、振り分け方式、各回線の容量、接続先の制限によって異なります。

proxy-groups:
  - name: 複数回線に振り分け
    type: load-balance
    proxies:
      - 香港-01
      - 香港-02
      - 日本-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

consistent-hashingとround-robinの違い

一貫性ハッシュでは通常、接続先ドメインの主な部分が振り分けに使われ、接続先がIPアドレスの場合はそのアドレス情報が使われます。詳細は使用するコアの実装に従います。アカウントに関連するすべてのドメインが同じ出口になる保証はありません。ログイン、決済、APIの各ドメインが別々の出口に割り当てられることがあり、ノードリストの変更で割り当ても変わる場合があります。

順番に振り分けたい場合は、例の設定を strategy: round-robin に変更します。ラウンドロビンを「リクエストごとに均等配分する方式」と考えないでください。複数のHTTPリクエストが同じTCP接続やQUIC接続を再利用する場合があり、接続単位の振り分けはリクエスト単位の振り分けとは異なります。決済やアカウント管理などには出口の固定が適しており、複数回線を使うためだけに負荷分散を強制するのは避けてください。

ルールへの組み込み：通信を自動プロキシグループに流す

プロキシグループを定義するだけでは不十分です。ルールが以前のグループを参照したままでは、新しいグループに該当する通信は流れません。以下では手動選択グループを入口として、3種類の自動グループと直接接続を残し、クライアント上で動作を比較できる構成にします。

proxy-groups:
  - name: プロキシ入口
    type: select
    proxies:
      - 低遅延自動選択
      - 主回線・予備回線
      - 複数回線に振り分け
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,プロキシ入口
  - MATCH,プロキシ入口

ここでは入口グループとルールだけを示しています。前述の自動グループ定義と組み合わせてください。example.com はルールのマッチ例として使う予約済みのサンプルドメインで、実際のサービスには使用しません。MATCH は、それ以前のルールに一致しなかった通信を受け取ります。本番設定では既存のLAN、DIRECT、各サービス向けルールを残し、最後にフォールバックルールを置いてください。この簡略化した例で振り分け設定全体を置き換えないでください。

1. まずクライアントの設定編集画面またはオーバーライド機能で設定を統合し、YAMLのインデントを確認します。リスト項目にはスペースを使い、Tabは使わないでください。
2. 設定を再読み込みし、3つの自動グループと「プロキシ入口」が表示されること、また「プロキシが存在しない」やプロキシグループの循環参照エラーがないことを確認します。
3. プロキシグループ画面で「プロキシ入口」を展開し、以前の手動ノードのままにせず、テストする自動グループを選びます。
4. 新しい接続を開始し、接続一覧で適用されたルールとプロキシチェーンを確認して、想定した出口が使われているか調べます。

測定の誤差：遅延・DNS・TUNの注意点

測定は正常でも、サービスに接続できない場合

測定URLに接続できたことから分かるのは、その回線から測定先へのリクエストが成功したということだけです。すべてのサイトにアクセスできるとは限りません。出口の地域、接続先によるブロック、証明書の問題、DNSの名前解決エラーなどが原因で、サービスを利用できないことがあります。まず入口を単一ノードに固定して対象サービスを再試行し、接続ログを確認してください。自動グループのアルゴリズムに問題があるとすぐに判断するのは避けましょう。

HTTPSの測定には、接続確立やTLS通信にかかる時間が含まれる場合があります。mihomoではトップレベルの unified-delay を使うと、プロキシごとのハンドシェイクの違いが遅延比較に与える影響を抑えられます。これはプロキシグループ内の項目ではありません。測定結果を比較するときは設定、測定URL、テストするネットワークを統一してください。異なる条件で得た数値をそのまま順位付けしないでください。

TUNを有効にしてもプロキシグループの選択方式は変わらない

システムプロキシまたはTUNが通信をコアに取り込み、ルールが転送先のグループを決め、プロキシグループが出口を選びます。TUNを有効にしても、fallback が自動的に最低遅延のノードを選ぶわけではなく、load-balance に帯域を合算する機能が加わることもありません。アプリの通信がコアの接続一覧に表示されない場合は、tolerance を変更する前に通信の取り込み経路を確認してください。

Fake-IPを使用すると、コアはアドレスとの対応付けを通じてドメインの情報を保持できますが、プロキシグループのヘルスチェックの代わりにはなりません。ノードサーバーの指定にドメイン名を使う場合は、その名前解決経路も利用できる必要があります。プロキシ接続を確立するためのDNS問い合わせが、そのプロキシ自体に依存する構成は避けてください。DNS障害が原因で自動グループの全ノードがタイムアウトすることもあるため、DNSログも確認して原因を特定します。

パラメーターの設定：控えめな構成から検証

初回の設定では、まず interval: 300 を共通で使い、動作確認中は lazy: false にします。動作を確認した後、端末のバッテリー持続時間やノード数に応じて調整してください。グループに12ノードあり、1回の測定で各ノードを少なくとも1回測定すると仮定すると、5分ごとの測定は1時間あたり約144回です。実際のリクエスト数は追加測定、再試行、手動測定によって変わるため、通信量の請求額として扱うことはできません。

• 低遅延を優先：url-test を選び、まずtoleranceを50ミリ秒に設定して、新しい接続の出口が頻繁に変わりすぎないか確認します。
• 主回線を優先：fallback を選び、優先して使いたいノードを先頭に置いて、予備ノードの地域と用途も確認します。
• 複数回線を活用：load-balance を選び、まず一貫性ハッシュを試します。ラウンドロビンは出口が変わっても問題のない用途に限って使用してください。
• セッションの固定を優先：select の手動入口を残し、ログイン、決済、長時間の処理には安定したノードを指定します。

検証では一度に変更する項目を1つにしてください。まずノードと測定URLを固定し、次にグループの種類を変え、最後に測定間隔とtoleranceを調整します。測定を少なくとも2周期分行い、新しい接続、長時間のダウンロード、実際のサービスページをそれぞれテストしてください。1回の測定で最小の数値を選ぶより、選択結果、サービスの成功率、接続の安定性を確認するほうが、現在のネットワークに合った設定かどうかを判断できます。