Clashのプロキシグループ比較：url-test・fallback・load-balanceの選び方

プロキシグループ、ノード、プロキシルールを整理する

Clashとmihomoコアを採用したClash Verge Revでは、プロキシノードをプロキシグループにまとめ、ルールによって各接続をどのグループへ渡すかを決めます。プロキシグループは新しいプロキシサーバーではなく、ノード本来のプロトコル、通信方式、出口地域を変更するものでもありません。グループ内のメンバーから、今回の接続に使うものをどう選ぶかを担います。

たとえば、動画配信サイトのドメインを「ストリーミング」グループへ、業務用ドメインを「安定回線」グループへ、それ以外の通信を「デフォルトプロキシ」グループへ振り分けられます。各グループでは異なる種類を使えます。url-testはテスト結果をもとに遅延の短い利用可能なメンバーを選び、fallbackは設定順に最初の利用可能なメンバーを使い、load-balanceは複数の利用可能なメンバーへ接続を振り分けます。

したがって、3種類の違いを「どれが速いか」だけで説明することはできません。選ぶ際は、少なくとも次の4点を確認しましょう。

メンバーの選択基準：遅延、固定された優先順位、振り分けアルゴリズムのどれで選ぶか。
障害発生時の動作：再測定するのか、順番を後ろへ移すのか、それとも残りのメンバーへ振り分け続けるのか。
出口の一貫性：同じ宛先や同じセッションで、できるだけ同じ出口アドレスを維持する必要があるか。
デバイスへの負荷：定期的なテストは少量ながら通信リクエスト、バッテリー、バックグラウンドリソースを消費するため、特にモバイル端末では間隔を適切に設定する必要があります。

ヘルスチェックで確認していること

自動プロキシグループは通常、設定されたテストURLへアクセスし、指定した間隔で可用性や遅延の結果を更新します。一般的なテストURLはごく小さなHTTPレスポンスを返し、DNS、TCP、TLS、プロキシ経路を使ったリクエストが完了するかを判定します。この結果は基本的な接続性を示しますが、すべてのウェブサイトでの実際のダウンロード速度と同じではありません。

テスト先の位置、ノードから対象サイトまでの経路、短時間の混雑、通信事業者のネットワークが結果に影響します。テストURLへの遅延が最も短いノードでも、別地域のサービスへ最速でアクセスできるとは限りません。特定のサービスに地域や安定性の条件がある場合は、まず用途に合うノードを絞り、その少数の中で自動プロキシグループを使う方が適切です。

url-test：テスト遅延で利用可能なメンバーを選ぶ

url-testはグループ内のメンバーに接続テストを実行し、利用可能なメンバーからテスト遅延の短いものを選びます。メンバーの機能や出口地域が近く、主に応答速度を重視する場面に適しています。たとえば同じ地域に複数の一般回線がある場合、url-testで基本的な候補選びを自動化し、頻繁な手動切り替えを減らせます。

一般的な設定例は次のとおりです。利用できるフィールドはコアのバージョンによって異なるため、読み込む前に現在のmihomo設定ドキュメントとクライアントログを確認してください。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - ノード-A
      - ノード-B
      - ノード-C
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

intervalはテスト間隔を表し、通常は秒単位です。間隔が短すぎるとバックグラウンドのテスト頻度が上がりますが、体感が改善するとは限りません。長すぎると回線状態の変化をすぐに検知できない場合があります。常時稼働するデスクトップではネットワークの変動に応じて数分に設定し、モバイル端末ではやや長めにするとよいでしょう。

toleranceは、遅延差が小さいときの頻繁な切り替えを抑えるために使います。現在のメンバーが95ミリ秒、別のメンバーが80ミリ秒だったとしても、差が小さいなら、すぐに切り替えず現在のメンバーを維持する方が安定することがあります。許容値は低ければよいわけではありません。ゼロにすると、わずかな測定揺らぎで選択先が何度も変わる可能性があります。

lazyを有効にすると、コアはプロキシグループが実際に使われるまでテストを実行しない場合があり、長期間使わないグループのバックグラウンドリクエストを減らせます。ただし、遅延チェックの発動条件やキャッシュ動作はコアの実装に依存するため、判断する際はログとクライアントに表示される最終テスト時刻を確認してください。

url-testの適用範囲と注意点

ウェブ閲覧、コードリポジトリへのアクセス、応答速度を重視する日常的な接続に適しています。
同じ地域、同じ用途、近い品質のノード群に適しています。機能が大きく異なる出口を混在させ、遅延だけで選ぶ用途には向きません。
テスト遅延は帯域幅を直接示すものではありません。大容量ファイルのダウンロード速度は、出口帯域、サーバー側の速度制限、長時間の混雑に大きく左右されます。
選択先が変わると、新しい接続で別の出口アドレスが使われる可能性があります。出口の一貫性が重要なログインセッションでは注意が必要です。

fallback：順番に最初の利用可能なメンバーを使う

fallbackの核心は、遅延の比較ではなく優先順位です。コアはグループ内のメンバーが利用可能かを確認し、リストの先頭に近い利用可能なメンバーを優先します。第一候補が利用できない場合にのみ後続メンバーを使い、第一候補が復旧すると、その後の新しい接続は通常、優先順位の高いメンバーへ戻ります。

proxy-groups:
  - name: 安定回線
    type: fallback
    proxies:
      - メイン回線
      - 予備回線-1
      - 予備回線-2
    url: http://www.gstatic.com/generate_204
    interval: 300
    lazy: true

この仕組みは、回線に明確な優先順位がある場合に特に適しています。たとえば、出口地域が固定され、対象サービスとの互換性があり、長期的に安定したメイン回線を用意し、障害時だけ予備回線を使う構成です。予備回線のテスト遅延が一時的に短くても、利用可能なメイン回線をfallbackが飛び越えて選ぶことはありません。

「利用可能」の意味はテストURLと合わせて考える必要があります。テスト成功が証明するのは、そのノードからテスト先へアクセスできることだけで、すべての対象サービスへの接続を保証するものではありません。メイン回線が接続性テストに正常応答していても、業務ドメインが経路、地域、サーバー側のポリシーの影響を受けていれば、プロキシグループはメイン回線を利用可能と判断し続けることがあります。この場合は、単にチェック間隔を短くするのではなく、業務ルールを調整し、プロキシグループを分割するか、より実態に近いテスト先を使ってください。

fallbackが適する用途

リモートワーク、特定地域向けのサービス、ホームゲートウェイ、長時間稼働する端末では、「第一候補を維持し、障害時だけ後続へ移る」動作が重視されます。これはfallbackの順序に基づく動作と一致します。設定時は、長期的に使いたいメンバーを先頭に置き、予備メンバーにも同等のサービス利用能力があることを確認してください。

リスト順に明確な意味がなく、すべてのメンバーを自由に入れ替えられるなら、url-testの方が日常的な自動選択に適しています。逆に、ユーザーが現在のノードを手動で決めたい場合はselectタイプを使い、fallbackが一時的な手動選択を記憶すると期待しないでください。

load-balance：複数の利用可能なメンバーへ接続を振り分ける

load-balanceは、唯一の「最速ノード」を選ぶことを主目的とせず、グループ内の複数の利用可能なメンバーへ接続を振り分けます。大量の独立したリクエスト、並列ダウンロード、多数の端末で共有するゲートウェイに適していますが、確立済みの1本の接続に複数ノードの帯域を合算するものではありません。

proxy-groups:
  - name: 並列振り分け
    type: load-balance
    proxies:
      - ノード-A
      - ノード-B
      - ノード-C
    url: http://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

一般的なconsistent-hashingは、宛先情報をもとに一貫したマッピングを行い、メンバーリストが安定している間は同じ、または近い宛先が同じメンバーを使うようにします。これにより、同一サイトへの連続リクエストで出口が頻繁に変わるのを抑えられます。メンバー障害やリスト変更があれば一部のマッピングは変わるため、永続的に出口を固定する仕組みではありません。

round-robinは、新しい接続を順番に振り分ける方式に近いものです。各メンバーにより均等に接続機会を与えられますが、同じアプリが複数のドメインへアクセスしたり複数の接続を確立したりすると、異なる出口アドレスになることがあります。利用できるstrategyの値はClashの派生版やmihomoのバージョンによって変わるため、使用前に現在のコアのドキュメントを確認してください。他の実装のフィールドをそのまま設定へコピーしてはいけません。

負荷分散は1本の接続を束ねる機能ではない

ブラウザーで1つのファイルをダウンロードする際、サーバーが1本の接続だけを確立するなら、その接続は通常1つのメンバーだけを通ります。ダウンローダー、ブラウザー、アプリが複数の独立した接続を確立し、それらが異なるメンバーへ振り分けられた場合に限り、全体のスループットが複数回線を活用できる可能性があります。最終的な速度は、ローカルネットワークの上限、ノードの速度制限、対象サーバー、プロトコルの動作にも左右されます。

負荷分散では出口の一貫性にも注意が必要です。短時間に送信元アドレスが頻繁に変わると異常と判定するサイトがあり、ログイン状態、認証コードの要求頻度、地域別コンテンツに影響する場合もあります。そのようなサービスはルールでドメインをfallback、url-test、固定したselectグループへ振り分け、静的リソースやソフトウェア更新などの並列リクエストを負荷分散グループへ渡すとよいでしょう。

UDP通信でも、セッションのマッピングとノードの対応状況を確認する必要があります。音声通話、ゲーム、QUIC接続は経路の変化に敏感なため、「均等化」だけを目的に関連通信の出口を頻繁に変えるべきではありません。設定後は実際のアプリでパケットロス、遅延の揺らぎ、再接続の状況を確認し、ヘルスチェックの数値だけで判断しないでください。

デバイスと用途に合わせてプロキシグループを選ぶ

デスクトップでの日常利用：まずurl-testを検討

Windows、macOS、Linuxのデスクトップでは、ウェブ閲覧、コードのダウンロード、メッセージングを同時に行うことが一般的です。ノードが同じ地域にあり、アクセス性能も近いなら、url-testを使い、適切な許容値を設定して揺らぎを抑えるとよいでしょう。特定地域の固定や安定した出口が必要なドメインは、ルールで専用のfallbackまたは手動選択グループへ振り分けます。

リモートワークと固定業務：まずfallbackを検討

企業システム、リモートデスクトップ、管理画面、長時間ログインするサービスでは、予測しやすい動作が重視されます。要件に最も合う回線を先頭に置き、実際の信頼性に基づいて予備メンバーを並べる方が、単純にミリ秒単位の遅延で並べるより適切です。予備メンバーについても、対象サービス、DNS解決、UDP対応を事前に確認し、メイン回線の障害後に互換性がないと気づく事態を避けてください。

ホームゲートウェイと多数の端末：load-balanceは慎重に使う

ルーターや透過型ゲートウェイで複数の端末を同時に処理する場合、接続数が多いため、負荷分散による振り分け効果が出やすくなります。出口の一貫性が重要なサービスはルールで別グループに分け、システム更新、静的リソース、一般的な並列リクエストをload-balanceへ渡す構成がおすすめです。ゲートウェイのハードウェア性能に余裕がない場合は、ヘルスチェック、TUN転送、大量のコネクショントラッキングによるリソース使用量も確認してください。

モバイル端末：テスト間隔を延ばし、メンバーを絞る

ノートパソコンやモバイル端末は、Wi-Fi、テザリング、モバイルデータ通信の間を切り替えて使います。ネットワーク環境そのものが変わるため、テスト結果が無効になりやすく、過度に頻繁なヘルスチェックは有効とは限りません。自動グループのメンバー数を減らし、間隔を延ばし、適切な遅延チェックの遅延実行を有効にするとよいでしょう。プロキシをたまにしか使わない端末では、複雑な自動プロキシグループより手動選択グループの方が分かりやすい場合もあります。

TUNモードでもプロキシグループの意味は変わらない

TUNモードは、システムプロキシ設定に従わない一部のプログラムを含め、より多くのシステム通信を引き受けます。ただし、url-testを負荷分散に変えたり、fallbackのメンバー順を変更したりするものではありません。通信がmihomoに入った後も、ルールに従ってプロキシグループへ振り分けられ、グループがメンバーを選択します。

TUNを有効にすると対象となる接続範囲が広がり、DNS、LAN通信、UDPアプリもコアに入る可能性があるため、プロキシグループの設定問題がより明確に現れます。トラブルシューティングでは、「通信がTUNに取り込まれているか」「どのプロキシグループにルールが一致したか」「プロキシグループが最終的にどのメンバーを選んだか」の3段階を分けて確認してください。

プロキシグループが期待どおり切り替わらない場合の確認手順

実際に稼働している設定を確認する。
サブスクリプション更新後に新しいプロキシグループが生成されたり、設定の上書きによってグループ名、メンバー、テストパラメータが変わったりすることがあります。まずClash Verge Revの設定画面で現在有効な設定を確認し、実行中のプロキシグループの内容と照合してください。
ルールの一致結果を確認する。
接続が目的のプロキシグループに入っていなければ、グループ内のアルゴリズムを変更しても効果はありません。接続画面またはログ画面を開き、ドメイン、宛先アドレス、ルール種別、最終的に一致したプロキシグループ名を確認してください。
ヘルステストの状態を確認する。
各メンバーの最終テスト時刻、遅延、利用可能状態を確認します。すべてタイムアウトする場合は、テストURL、DNS、ノード本体、ローカルネットワークを確認してください。一部のメンバーだけが失敗する場合は、その回線を個別に検証します。
名前とインデントを確認する。
YAMLはインデントに敏感です。proxies内の名前も、ノード名または他のプロキシグループ名と正確に一致していなければなりません。名前に特殊文字が含まれる場合は引用符で囲み、解析時の曖昧さを避けてください。
新しい接続で再テストする。
テスト対象アプリの既存セッションを終了するか、接続が終わるのを待ってから再アクセスしてください。画面上のプロキシグループの状態を更新するだけでは、確立済みの接続をすべて直ちに移行できません。
DNS障害とプロキシ障害を切り分ける。
ドメインを解決できない場合、プロキシグループが接続可能な宛先をまだ取得できていない可能性があります。まずDNSログ、nameserver設定、リダイレクト設定を確認してから、ノード選択の異常を判断してください。IPアドレスなら接続できるのにドメインだけ失敗する場合は、先に名前解決経路を調べるのが適切です。

3種類のプロキシグループの要点

低遅延のメンバーを自動選択したい：url-testを使い、許容値で頻繁な切り替えを抑えます。
メイン回線と順序付きの予備回線を固定したい：fallbackを使い、実際の業務上の優先順位でメンバーを並べます。
大量の独立した接続を複数のメンバーへ分散したい：load-balanceを使い、出口の一貫性にも対応します。
ユーザーがノードを明示的に指定したい：selectを使い、自動プロキシグループで手動操作を再現しようとしないでください。

実際の設定では複数の方式を組み合わせられます。最上位のプロキシグループで手動選択を提供し、その内部に自動テストグループ、フェイルオーバーグループ、負荷分散グループを配置します。ルールでは用途が明確なグループ名だけを参照し、グループ内のメンバーは同じ種類に揃えます。テストURLと間隔はデバイスや業務に合わせて調整してください。これによりClash Verge Revで状態を確認しやすくなり、障害時にも原因がルール、ヘルスチェック、ノード本体のどこにあるかを素早く特定できます。

Clashプロキシグループ比較：url-test・fallback・load-balanceの選び方