プロキシグループの種類を解説：url-test・fallback・load-balanceの違いと選び方

ルールとプロキシノードをつなぐプロキシグループの役割

プロキシグループ（Proxy Group）は、ルールが指定したポリシーを実際に使うプロキシノードへ振り分けます。たとえば、あるドメインへの接続を「普段使いのプロキシ」に割り当てると、そのグループが手動選択、遅延テスト、フェイルオーバーなどの方式に基づいて出口を決めます。ルールが決めるのは「この接続をどこに渡すか」、プロキシグループが決めるのは「グループ内のどのノードを使うか」です。

この記事では、Clash Verge Revで使用するmihomoコアの設定を例に説明します。画面ではグループの表示や切り替えを行いますが、動作を決めるのは proxy-groups 内の type です。システムプロキシやTUNモードは通信をコアに取り込む方法に関わるもので、select が自動テストグループに変わったり、負荷分散のアルゴリズムが変わったりするわけではありません。

種類	選択基準	主な用途	主な制約
`select`	メンバーを手動で選択	地域や出口を固定したい場合	ほかのメンバーが利用可能でも自動で切り替わらない
`url-test`	遅延の測定と切り替え幅の調整	同じ種類の回線から低遅延のものを自動選択	測定値が低くてもダウンロードが速いとは限らない
`fallback`	メンバーの順序と利用可否	メイン回線の障害時にバックアップへ切り替え	最も遅延が低いノードを選ぶ方式ではない
`load-balance`	指定した接続振り分けアルゴリズム	複数の接続を複数の出口に分散	単一接続の帯域を合算する方式ではない

select：手動で選ぶ出口グループ

select は出口を明確に指定したい場合に適しています。Clash Verge Revの「プロキシ」画面で該当するプロキシグループを開き、ノードまたは子グループを選択します。選択したノードに障害が起きても、ほかのメンバーが使えるという理由だけで手動選択グループが自動で切り替わることはありません。ただし、選択したメンバー自体が自動選択グループなら、その子グループは独自の自動選択を行います。

手動選択グループに自動選択グループを追加する

よくある構成は、最上位に select を置き、その中に「低遅延自動選択」「メイン・バックアップ回線」と個別のノードをまとめる方法です。普段は自動選択グループを使い、地域制限への対応や出口の固定が必要なときはノードを手動で選びます。ルールから参照する入口を変えずに済むため、一時的な回線変更のたびにルール全体を編集する必要がありません。

アカウントへのログイン、決済、管理画面：地域が安定し、出口を明確に指定できるノードを選びます。
通常のWeb閲覧：自動遅延テストの子グループを選ぶと、手動で切り替える手間を減らせます。
障害の切り分け：自動切り替えの影響を避けるため、ノードを1つ固定します。

「ノードを固定」しても「グローバルIPが固定」されるわけではありません。サーバー側で出口が変更されたり、複数の出口が使われたりする場合があります。固定IPが必要な場合は、サービス提供元に回線の仕様を確認してください。クライアントのプロキシグループだけでは保証できません。

url-test：測定遅延を基準にノードを選択し、toleranceで切り替え幅を調整

url-test は候補ノード経由で指定したテストURLにアクセスし、測定結果を記録します。その結果と現在のノードの状態、許容範囲をもとに使用ノードを選択します。地域や用途が近い回線をまとめるのに適しています。異なる地域のノードを混在させると、遅延が低い地域が選ばれ続けても、接続先サイトが求める地域条件に合わないことがあります。

interval・timeout・toleranceの単位

interval: 300：単位は秒。ヘルスチェックの間隔を設定します。この例では5分です。
timeout: 5000：単位はミリ秒。1回の測定に許されるタイムアウトは5秒です。
tolerance: 50：単位はミリ秒。小さな遅延の揺れによる切り替えを抑えます。
lazy: true：遅延チェックを有効にします。グループが使われていない間は、設定間隔どおりに測定されない場合があります。「候補すべてを300秒ごとに必ず測定する」という意味ではありません。

例として、現在のノードが105ms、別のノードが80msの場合、差はわずか25msです。tolerance: 50 なら、この程度の差では通常切り替わりません。一方、現在のノードが180ms、候補が80msなら、差は許容範囲を大きく超えています。ノードが利用できなくなった場合は、利用可能な状態に基づいて再選択されます。toleranceは障害のあるノードを使い続ける設定ではありません。

速度測定の結果だけでは実効速度はわからない

テストURLから返る小さな応答は、主に接続可能かどうかとリクエストの遅延を確認するためのものです。80msのノードが120msのノードより大容量ファイルのダウンロードに適しているとは限りません。帯域、混雑状況、接続先へのルーティング、サーバー負荷によって結果は変わります。また、クライアントに表示される測定遅延をICMP pingの値と同一視しないでください。測定経路や仕組みが異なります。

fallback：リストの順序に従ってメイン回線からバックアップへ切り替え

fallback はメンバーリストの先頭から利用可能なノードを探します。優先ノードが利用可能と判定されている限り、すべてのノードの遅延を比較して最も低いものを選ぶのではなく、そのノードを使います。そのため、メイン回線を先頭に、バックアップ回線をその後に並べます。リストの順序は優先順位を表し、単なるメモの順番ではありません。

たとえば、ノードAが160ms、ノードBが70msでも、Aが利用可能でBより前に並んでいれば、メイン・バックアップグループはAを優先します。Aのヘルスチェックが失敗した場合に、初めて後続の利用可能なメンバーが選ばれます。その後の測定でAの復旧が確認されると、新しい接続は再びAを優先して使います。

フェイルオーバーは既存接続の引き継ぎではない

確立済みのTCP接続は元の経路に紐づいています。プロキシグループがバックアップノードに切り替わっても、既存の接続が切断されずに別の出口へ移ることはありません。Webページは新しいリクエストで復旧する場合がありますが、ダウンロード、リモート端末、通話などは再接続が必要になることがあります。検知までの時間には、チェック間隔、タイムアウト、遅延チェックの設定、障害の発生タイミングが影響します。interval: 300 を「必ず300秒で復旧する」という保証と解釈しないでください。

メイン回線とバックアップ回線は、同じサーバーの別名ではなく、異なる入口やサーバーなど障害発生箇所の異なる回線を選びましょう。
メイン・バックアップグループは「指定した回線を優先する」用途に適しており、「常に最低遅延の回線を選ぶ」用途には向きません。
バックアップ回線が従量課金の場合は、通信量を確認してください。ヘルスチェックでも少量の通信が発生します。

load-balance：複数の接続を振り分ける方式。単一接続の帯域は合算しない

load-balance は、設定した方式に従って接続を候補ノードに振り分けます。1つのTCP接続を分割して2つのノードから転送する機能でも、複数回線を束ねる機能でもありません。単一接続でのダウンロードは通常、選択されたノードの帯域に制限されます。複数の接続を使う通信なら、異なる出口に負荷を分散できる場合があります。

主なstrategyの違い

strategy	主な動作	選ぶ際の注意点
`consistent-hashing`	接続先情報に基づいてコンシステントハッシュで割り当て	同じ接続先は同じ出口になりやすいが、メンバー構成が変わると割り当ても変わる場合がある
`round-robin`	利用可能なメンバーに接続を順番に割り当て	同じWebサイトへの接続でも、異なる出口IPになる場合がある
`sticky-sessions`	送信元と接続先の組み合わせに基づき、一定時間同じ割り当てを維持	mihomoのセッション維持方式であり、出口を永久に固定するものではない

接続先がドメインかIPアドレスか、DNSモードでドメイン情報が保持されるかによって、実際の振り分け結果は変わることがあります。「ブラウザーごとに常に同じノードを使う」とは限りません。アカウント関連のサービスでは、ログイン用ドメイン、静的ファイル用ドメイン、API用ドメインに個別にアクセスするため、コンシステントハッシュを使っても異なる出口に振り分けられる場合があります。

設定例：手動選択の入口と3種類の自動選択グループ

以下は、既存のmihomo設定に追加するプロキシグループとルールの例です。ノードの認証情報を含む完全なサブスクリプションではありません。HK-A、HK-B、SG-A は現在の設定の proxies で定義済みで、名前も完全に一致している必要があります。ノードが proxy-providers から提供される場合は、実際のprovider名を使って use で読み込んでください。provider名をノード名としてリストに入力するだけでは使えません。

proxy-groups:
  - name: 普段使いのプロキシ
    type: select
    proxies:
      - 低遅延自動選択
      - メイン・バックアップ回線
      - 複数接続の振り分け
      - HK-A
      - HK-B
      - SG-A

  - name: 低遅延自動選択
    type: url-test
    proxies:
      - HK-A
      - HK-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    tolerance: 50
    lazy: true

  - name: メイン・バックアップ回線
    type: fallback
    proxies:
      - HK-A
      - SG-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: true

  - name: 複数接続の振り分け
    type: load-balance
    proxies:
      - HK-A
      - HK-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    timeout: 5000
    lazy: true
    strategy: consistent-hashing

rules:
  - DOMAIN-SUFFIX,example.com,普段使いのプロキシ
  - MATCH,普段使いのプロキシ

設定を統合するときに確認する3つのポイント

グループ一覧に追加：新しいグループは既存の proxy-groups に追加してください。同じ階層に同名のキーをもう1つ作らないでください。グループ名は重複しないようにし、子グループ同士が相互参照する構成も避けてください。
既存のルールを維持：例の example.com は動作を示すためのドメインです。既存の設定に直接接続、ブロック、地域別のルールがある場合は残し、フォールバック用の MATCH はルールの末尾に置いてください。ルールは上から順に照合されるため、フォールバックを個別のルールより前に置かないでください。
編集する設定を確認：Clash Verge Revの「設定」画面で、現在有効な設定を確認してください。リモートサブスクリプションの更新で直接編集した内容が上書きされることがあります。継続して変更する場合は、現在のクライアントが対応する設定のマージ機能やスクリプト機能を使い、最終的に適用された設定も確認してください。

上記の3つの自動グループはいずれも lazy: true で、未使用時の測定を減らしたい場合に適しています。バックグラウンドで継続的にチェックする必要がある場合は、false への変更を検討し、ノード数とチェック頻度にも注意してください。たとえば、ノード20個のグループを300秒間隔でチェックすると、1回のチェックで20回の測定が発生します。同じノードを複数のグループから参照する場合は、コアのスケジューリングやproviderのヘルスチェックも含めて、実際の負荷を確認してください。

用途に合わせて選び、実際の振り分け結果を確認する

よくある3つの構成と選び方

Web閲覧や日常業務：最上位を select にし、同じ地域の url-test を初期選択にします。まずはチェック間隔300秒、許容差50msで様子を見て、遅延の変動に応じて調整してください。
メイン回線を優先し、障害時はバックアップへ：fallback を使い、継続して利用したい回線を先頭にします。障害時は再接続を許容し、メイン回線の復旧後にどう動くかも実際に確認してください。
複数の出口を許容できる接続が多い場合：load-balance を検討します。まずはコンシステントハッシュを試し、ラウンドロビンが本当に必要か判断してください。単一のダウンロードを速くする目的で負荷分散に切り替えるのは適切ではありません。

Clash Verge Revでの確認手順

「設定」画面を開き、対象の設定が有効になっていることを確認します。適用時にエラーが出た場合は、「ログ」画面でグループの種類、ノード名、YAMLのインデントに関するエラーを確認してください。設定の読み込みに失敗したままテストを続けないでください。
「プロキシ」画面を開き、「普段使いのプロキシ」でテスト対象の子グループを選びます。ルールによる振り分けを確認する場合は「ルール」モードを使います。「グローバル」モードではグローバル用のポリシー入口が使われるため、個別のルールとは結果が異なる場合があります。
グループの速度テストを実行し、実施時刻、現在のノード、遅延を記録します。ノードの数値が緑色かどうかだけで判断せず、最上位の入口でどのグループが実際に選択されたかを確認してください。
プロキシ経由になることが確実なサイトにアクセスし、「接続」画面でドメインを絞り込み、適用されたルールとプロキシチェーンを確認します。「グループが選択されている」だけでは、そのリクエストがグループを経由した証拠にはなりません。
既存ページの接続を閉じるか、新しいリクエストを開始してから結果を比較します。メイン回線の障害をテストする場合は、復旧可能なテスト環境で一時的にメイン回線を停止し、障害の検知時刻とバックアップ接続の確立時刻を記録してください。

「速度テストは正常なのにサイトを開けない」場合は、測定先と実際の接続先がそれぞれ到達可能かを切り分けます。対象ドメインのDNS解決、ルールの一致、ノードの地域制限、ログのエラーを確認してください。「切り替えたのに出口が変わらない」場合は、既存接続の再利用、ルールによる直接接続、グローバル入口の選択ミス、両ノードが同じグローバルIPを共有していないかを確認します。

プロキシグループ選びで重要なのは自動化の度合いではなく、選択基準が用途に合っているかどうかです。手動制御には select、遅延を基準にした選択には url-test、順序に沿ったメイン・バックアップ切り替えには fallback、複数接続の分散には load-balance を検討してください。ルール、プロキシグループ、ノードの役割を把握しておけば、問題を段階的に切り分けられます。設定項目は設定リファレンスで確認でき、関連用語は用語集をご覧ください。