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

自動プロキシグループ3種：遅延・優先順位・接続数で経路を選ぶ

proxy-groupsで定義するのは、出口の選択方法です。プロキシサーバー自体を定義するものではありません。ノードは通常、proxiesまたはproxy-providersから取得します。ルールがプロキシグループに一致すると、そのグループが使用する出口を選びます。グループ名を設定に追加しても、ルールから参照されていなければ実際の通信経路は変わりません。

まず、クライアントが実際に使用しているコアとバージョンを確認してください。ClashのGUIクライアントは操作画面であり、設定項目を解析するのはClashオリジナルコア、またはその後継として開発されたClash Meta系のmihomoです。以下の設定例はmihomoを対象としています。旧バージョンのコアでは拡張項目や負荷分散アルゴリズムに対応していない場合があるため、起動ログと該当バージョンのドキュメントを確認してください。

種類	選択基準	適した用途	主な制約
`url-test`	遅延の測定と切り替え許容幅	応答の速い出口を自動で選びたい	測定遅延はダウンロード速度を示すものではない
`fallback`	リストの順序とノードの状態	通常は主回線を使い、障害時に予備回線へ切り替える	リスト後方のノードのほうが速くても選ばれるとは限らない
`load-balance`	アルゴリズムで新しい接続を振り分ける	複数の利用可能な出口に接続を分散する	複数ノードの帯域を1つの接続に合算することはできない

url-test：intervalとtoleranceの設定方法

url-testは、候補ノード経由で指定したurlにアクセスし、測定結果をもとに出口を選びます。測定されるのはプロキシ経路と接続先の応答に影響されるリクエスト時間です。ICMP pingとは異なり、動画サイトやファイルサーバー全体の性能を測定するものでもありません。

まず3つの項目と単位を確認

url：ヘルスチェックの送信先です。通常は、応答が小さく安定していて、候補ノードからアクセスできるHTTPSのURLを指定します。例として、204を返すヘルスチェック用エンドポイントがあります。
interval: 300：定期チェックの間隔です。単位は秒で、約5分ごとにチェックします。300ミリ秒でも、接続タイムアウト値でもありません。
tolerance: 50：切り替えの許容幅です。単位はミリ秒。わずかな遅延の変動による頻繁な切り替えを抑えるために使います。パケットロス率でも、許容できる最大遅延でもありません。

たとえば、現在のノードの直近の測定値が105 ms、別のノードが80 msで、差が25 msだったとします。許容幅を50 msに設定している場合、この程度の差だけですぐに切り替わるとは限りません。現在のノードが155 msまで遅くなり、もう一方が80 msのままなら、差は75 msとなり、切り替わる可能性が高まります。これは許容幅の動作を説明する計算例であり、当サイトでの実測値ではありません。最終的な選択は、その時点のコアのヘルスチェック状態や実装にも左右されます。

チェック間隔は障害復旧時間の保証ではない

intervalを300から60に変更するとチェック頻度は上がりますが、障害発生から60秒以内にすべての通信が復旧する保証にはなりません。チェック自体にも時間がかかり、既存の接続がタイムアウトを待つ場合もあります。候補ノードが多いほど定期的なリクエストも増えます。日常利用ではまず300秒から始め、ログを確認しながら調整してください。

mihomoのlazyは、使用されていないプロキシグループの定期チェック動作に影響します。調査時には明示的にfalseを設定すると、「グループが使われていないため継続的にチェックされない」という影響を避けやすくなります。ノードをproviderから取得している場合は、provider側のhealth-check設定も別途確認してください。providerのチェックとグループ単位の測定は、同じタイマーではありません。

fallback：リストの優先順位で利用可能な出口を選ぶ

fallbackは候補リストの先頭から、利用可能なノードを選びます。リストが「ノード-A」「ノード-B」の順なら、Aのヘルスチェックが正常な限り、Aが180 ms、Bが60 msでもAが使われると考えてください。遅延の小さいノードを優先したい場合は、チェック間隔を変更するのではなくurl-testを選びます。

普段使う主回線をproxiesの先頭に置き、予備回線をその後に並べます。
すべての候補ノードからアクセスできるチェック先を使い、接続先サイトの制限をノード障害と誤判定しないようにします。
設定を再読み込みし、プロキシ画面でグループ内の順序を確認してから、手動でチェックを実行します。
主ノード側のサービスを一時的に停止し、新しい接続が予備ノードに切り替わるか確認します。テスト後はサービスを再開してください。

主ノードが再び利用可能と判定されると、優先順位に従ってリスト先頭のノードが選ばれやすくなります。「主回線を優先し、障害時は予備回線を使う」用途に適していますが、すでに確立されたTCP接続が移行するわけではありません。短いWebリクエストは通常、新しい接続で再試行されますが、ダウンロード、SSH、動画などの長時間接続ではアプリ側で再試行が必要になる場合があります。

load-balance：接続を振り分ける。帯域は合算しない

load-balanceは、利用可能な候補出口の間で接続をアルゴリズムに従って振り分けます。mihomoではstrategyでアルゴリズムを指定できます。ここではconsistent-hashingを使用します。ログイン、決済、セッション維持が必要なサービスでは、均等な振り分けより出口の安定性が重要です。まずはコンシステントハッシュを使うか、対象ドメインを固定ノードに割り当てるとよいでしょう。

strategyの値	用途	確認ポイント
`consistent-hashing`	接続先に関する情報をもとに、比較的安定した経路を割り当てる	同じサービスは同じ出口を使いやすいが、ノード変更時に割り当てが変わることがある
`round-robin`	新しい接続を順番に振り分ける	同じサイトへの複数の接続が別々の出口を通る場合がある

ハッシュに使う情報、ドメインの扱い、追加アルゴリズムの対応状況は、コアの実装によって異なります。「コンシステントハッシュ」を使っても、グローバルIPが永久に固定されるわけではありません。ノードの追加・削除、設定の再読み込み、候補リストの変更によって割り当てが変わる場合があります。固定出口が必須のサービスには、手動選択グループを指定する専用ルールを設定するほうが確実です。

たとえば、ブラウザーが10本の接続を同時に確立すると、ラウンドロビン方式では別々のノードに振り分けられる場合があります。一方、確立済みのTCP接続が通る出口は1つです。HTTP/2やHTTP/3では接続が再利用されることもあるため、ページを再読み込みしても新しい割り当てが発生するとは限りません。負荷分散を検証する際は、同じIP確認ページを繰り返し更新するのではなく、接続ログに表示されるルールの経路と実際のノードを確認してください。

YAML設定例：3種類のグループを並べ、外側から手動選択

以下は、mihomoで構成を検証するための完全な設定例です。共通の入口としてselectグループを用意し、内部で低遅延、主系・予備系、負荷分散を切り替えられます。2つのノードにはドキュメント用アドレス192.0.2.10と192.0.2.11を使用しているため、実際のプロキシには接続できません。利用する前に、ノード定義全体をサービス提供元から指定されたプロトコル、アドレス、ポート、認証情報に置き換えてください。

config.yaml · mihomo構成例

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: ノード-A
    type: ss
    server: 192.0.2.10
    port: 8388
    cipher: aes-128-gcm
    password: "example-only-change-before-use"
  - name: ノード-B
    type: ss
    server: 192.0.2.11
    port: 8388
    cipher: aes-128-gcm
    password: "example-only-change-before-use"

proxy-groups:
  - name: 出口選択
    type: select
    proxies:
      - 自動・低遅延
      - 主系・予備系の切り替え
      - 接続の負荷分散
      - ノード-A
      - ノード-B
      - DIRECT

  - name: 自動・低遅延
    type: url-test
    proxies:
      - ノード-A
      - ノード-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

  - name: 主系・予備系の切り替え
    type: fallback
    proxies:
      - ノード-A
      - ノード-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

  - name: 接続の負荷分散
    type: load-balance
    proxies:
      - ノード-A
      - ノード-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,出口選択

ルールは上から順に照合されます。この例ではexample.comとそのサブドメインを直接接続し、それ以外の通信を「出口選択」に渡します。これはルールの例であり、日本国内・海外を網羅する振り分け設定ではありません。mixed-port: 7890はHTTPとSOCKSの混合ポートです。システムプロキシを設定するかどうかは、クライアントまたはOSの設定によって決まります。

サブスクリプションproviderを使う場合の変更方法

既存の設定に「サブスクリプションノード」という名前のproxy-providersが定義されている場合は、静的な候補を記述した箇所を以下のグループ設定に置き換えられます。useはprovider名を参照し、proxiesはノード名またはプロキシグループ名を参照します。両者は別の名前空間です。この例は既存のprovider定義を前提としているため、単独では完全な設定として実行できません。

proxy-groupsの設定例 · 既存providerを参照

proxy-groups:
  - name: 自動・低遅延
    type: url-test
    use:
      - サブスクリプションノード
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

リモートサブスクリプションの更新で上書きされる一時設定を直接編集しないでください。クライアントにオーバーライド、マージ、拡張設定の機能がある場合は、その機能を使ってカスタムグループを保存します。具体的な設定場所は、使用中のクライアントのバージョンで確認してください。変更後にサブスクリプションを更新し、グループとルールが残っていることを確認すれば、設定が正しく維持されているか判断できます。

入れ子構成：地域ごとに遅延を測定し、地域間は主系・予備系で切り替え

より細かく構成するには、地域ごとに独立したurl-testグループを作り、外側のfallbackから地域ごとのグループを優先順位順に参照します。たとえば「メイン地域の測定」にはメイン地域のノードだけを、「予備地域の測定」には予備地域のノードだけを登録し、外側のリストではメイン地域を先にします。これにより、地域内では遅延を考慮しつつ、地域間ではサービス上の優先順位を維持できます。

外側のグループから参照できるのは、すでに定義されているグループ名だけです。自分自身を候補に含めたり、AがBを参照し、BがAを参照する循環構造を作ったりしないでください。
外側のグループが参照するのは、内側のグループが現在選択している経路です。内側の全ノードを展開して、外側が改めて比較するとは限りません。
内側と外側にはそれぞれチェック間隔があり、復旧までに複数回の更新が必要になる場合があります。まず単一のグループで動作を確認してから、2層目を追加してください。
ログイン状態に敏感なサービスは、固定ノードまたはselectグループに個別に割り当てられます。大容量ダウンロードと同じ負荷分散設定を使う必要はありません。

日常的なWeb閲覧で自動選択したいだけなら、例の「外側select＋内側url-test」で十分なことがほとんどです。入れ子が深くなるほど接続ログの調査が難しくなるため、地域、料金、主系・予備系の優先順位に明確な違いがある場合に限って階層を増やしてください。

よくある設定ミスと確認方法

症状	まず確認する項目	対処方法
低遅延グループが切り替わらない	現在の遅延差、許容幅、直近の測定時刻	手動でチェックを実行し、そのグループにルールが適用されているか確認する
主系・予備系グループが遅いノードを使い続ける	リストの順序とノードの状態	これはリスト順を優先する動作です。遅延を優先する場合はurl-testに変更してください
すべてのノードが同時にタイムアウトする	チェック先、端末のDNS、システム時刻	まず単一ノードから同じチェック先に接続できるか確認し、グループの種類を変えるだけで済ませない
設定エラーに「プロキシが見つからない」と表示される	グループ名、ノード名、provider名、インデント	参照先の名前を一字ずつ確認し、YAMLではTabではなくスペースを使う
切り替え後も既存のダウンロードに問題がある	既存の接続が再利用されていないか	対象サービスの接続を再確立し、必要であれば該当する接続ログだけを閉じる
サブスクリプション更新後にカスタムグループが消える	編集したのは元の設定か、一時設定か	クライアントが対応する永続化可能なオーバーライド機能で保存する

4つの手順で実際の動作を確認

まず設定を検証：クライアントの設定チェック機能を使います。mihomoを直接実行する場合は、mihomo -t -f config.yamlを実行してください。検証に通っても、ノードの認証情報やネットワークが使えるとは限りません。
次に設定を再読み込み：設定画面で変更した設定を有効にし、ログに未対応の項目、重複した名前、存在しない参照先が報告されていないか確認します。既存の設定に統合する場合、同じ階層にproxy-groupsやrulesのキーを重複して作成しないでください。
ルールの経路を確認：Ruleモードで新しいリクエストを発生させ、接続画面で適用されたルール、外側のグループ、内側のグループ、最終的なノードを確認します。GlobalモードやDirectモードでは、今回検証するルールが適用されない場合があります。
最後に実際のサービスで確認：Webサイトへのアクセス、対象サービスへのログイン、実際のダウンロードをそれぞれ確認します。テスト時刻、出口ノード、測定遅延を記録してから、300秒の間隔や50 msの許容幅を調整してください。

選び方は、次の3つの質問で整理できます。低遅延の経路を自動で選びたいならurl-test、主回線を優先しつつ障害時の予備を用意したいならfallback、複数の出口に新しい接続を振り分けたいならload-balanceを選びます。要件を決めてから設定すれば、すべての方式を多重に組み合わせるより検証や保守が簡単です。