Clashのプロキシグループを徹底解説：url-test・fallback・load-balanceの選び方

Clashの設定では、プロキシグループはルールと個々のプロキシノードの間に位置します。ルールが接続のトラフィック種別を判定し、プロキシグループが最終的に使用するノードを決めます。プロキシグループを単なる「ノード用フォルダー」と考えると、判断を誤りかねません。グループの種類によって選択条件、ヘルスチェックの方法、障害時の処理順序が異なり、名前が似ていても動作は同じではありません。

url-test、fallback、load-balanceはいずれも複数のプロキシを参照できますが、用途はそれぞれ異なります。url-testはテスト結果が良好なノードを選び、fallbackは設定した優先順位に従って予備回線へ切り替え、load-balanceは複数の利用可能なノードへ接続を振り分けます。選択する際は、クライアント画面のレイテンシだけで判断せず、通常時の遅延を抑えたいのか、出口の優先順位を維持したいのか、同時接続を分散したいのかを明確にしてください。

ルーティングルールにおけるプロキシグループの位置

リクエストがClashまたはMihomoに入ると、通常は最初にDNSとインバウンド処理を経てから、設定内のルールに上から順に照合されます。ルールの転送先には、特定のノードまたはプロキシグループを指定できます。実際の設定では、ルールからグループ名を参照するのが一般的です。たとえば、開発サービスは「Web自動選択」、業務システムは「業務用フェイルオーバー」、大量の独立したダウンロード処理は「接続分散」へ振り分けます。

プロキシグループが処理するのは、ルールによってそのグループへ送られた接続だけです。速度テスト用グループを複数作成しても、ルールの最終的な転送先がDIRECTなら、その接続は直接接続されます。最終的にMATCHへ一致して別のグループに入った場合も、先に定義した速度テスト用グループは使われません。「ノードは使えるのに通信が経由しない」という問題を調べる際は、ノード一覧だけでなく、ルールの一致履歴と現在のプロキシグループ選択を併せて確認してください。

自動グループと手動selectグループの関係

selectは一般的な手動選択グループで、その選択肢に自動グループを追加できます。通常は自動選択を利用しつつ、接続先サイトが特定の出口を制限している場合だけ固定ノードへ一時的に切り替えられます。自動グループをほかのグループから参照することも可能ですが、入れ子が深すぎるとトラブル調査が難しくなります。グループ名には「Web自動選択」「業務用フェイルオーバー」「ダウンロード分散」のように用途が分かる名前を付け、「グループ1」「グループ2」だけで済ませないことをおすすめします。

url-test：テスト結果に基づく自動選択

url-testでは、カーネルがグループ内のプロキシ候補に対して指定URLへの接続テストを行い、その結果が良好なノードを選択します。Web閲覧、コードホスティング、ソフトウェア更新など、高遅延の回線を自動的に避けたい日常的な通信に向いています。ここでいう「良好」とは、主にテストリクエストの応答時間と到達可能性を基準にした評価です。帯域幅、パケットロス、混雑時間帯の安定性まで総合的に評価するものではありません。

テスト用URLには、安定していてレスポンスボディが小さく、成功ステータスが明確に返るものを選びます。空のレスポンスを返すHTTPエンドポイントがよく使われるのは、テスト通信量を抑えるためです。特定のネットワーク環境でテスト先がリダイレクト、帯域制限、個別最適化の対象になると、測定順位が実際の通信状況とずれる可能性があります。テスト先を変更する際は、すべての候補回線から同じ条件でアクセスできることを確認してください。

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

intervalは定期テストの間隔を表し、通常は秒単位で指定します。短すぎるとリクエスト数が増え、わずかなネットワーク変動でも選択結果が変わりやすくなります。長すぎる場合は、ノードの障害後に状態更新が遅れることがあります。一般的な端末では、十数秒ごとよりも数分ごとの実行が安定しやすいでしょう。適切な値は、ノード数と端末性能も踏まえて決めてください。

toleranceは、切り替えに許容値を設けるための設定です。現在のノードと候補ノードの差が許容値を超えない場合、現状を維持することで頻繁な切り替えを減らせます。たとえば現在の測定値が125ミリ秒、別のノードが90ミリ秒で、許容値を50ミリ秒に設定している場合、この差では切り替わりません。差が継続的に拡大してしきい値を超えたときに、自動グループが選択を更新する理由が生じます。カーネルやクライアントのバージョンにより設定項目の表示が多少異なるため、実際に使用しているMihomoまたはClashカーネルのドキュメントを確認してください。

lazyを有効にすると、通常はグループが実際に使用されるタイミングを優先してヘルスチェックが行われ、未使用グループの定期テストを減らせます。地域別グループが多数ある一方、普段使うのは一部だけという設定に適しています。障害を素早く検出する必要がある重要な接続を担うグループでは、検出の遅れとバックグラウンドテストの負荷を比較して判断してください。

fallback：優先順位に従うメイン・予備回線

fallbackの基本動作は「最速を選ぶ」ことではなく、「リスト内で最初に利用可能な項目を選ぶ」ことです。先頭に近いノードほど優先順位が高く、ヘルスチェックで利用可能と判定されている限り、そのノードを使い続けます。現在の優先ノードが失敗した場合にのみ、後続の利用可能なノードを探します。出口IP、地域、回線の安定性が数ミリ秒の遅延差より重要な用途に適しています。

たとえば業務サービスで特定地域の出口を継続して使う必要がある場合、メインノードを先頭、同じ地域の予備ノードを2番目、別地域の緊急用ノードを最後に配置します。予備ノードのテスト遅延が小さくても、利用可能なメインノードより優先されることはありません。出口の変化を抑えられる一方、メインノードが「接続はできるものの使い勝手が悪い」状態でも、自動では切り替わらない場合があります。

proxy-groups:
  - name: 業務用フェイルオーバー
    type: fallback
    proxies:
      - メイン回線
      - 同一地域の予備回線
      - 別地域の緊急回線
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

「利用可能」かどうかはヘルスチェックで決まり、ヘルスチェックが確認できるのは指定されたエンドポイントだけです。テスト用URLにはアクセスできても、特定の業務ドメインへ接続できないノードをfallbackが維持することもあります。この場合は、対象ドメインが正しいルールに一致しているかを確認し、次にDNS解決、接続先サイト側の制限、特定プロトコルへの回線対応状況を調べます。テスト間隔を短くするだけでは、テスト先と実際の接続先が異なる問題は解決できません。

メイン回線が復旧すると、グループはリスト上位のノードへ戻る場合があります。回線が利用可能と利用不能を繰り返すと、切り戻しが頻発します。安定したテスト先を選ぶ、チェック間隔を適切に延ばす、不安定なノードを最優先に置くべきか見直す、という3つの方向から軽減できます。現在利用できている出口を手動操作まで維持したい場合は、自動フェイルオーバーよりも手動のselectグループが適しています。

誤ったフェイルオーバーの主な原因

• リスト順が想定する優先順位と逆で、低優先の回線が先頭に置かれている。
• 実際の接続先にはアクセスできる一方、ヘルスチェック先へ到達できず、ノードが利用不能と早期判定されている。
• 購読の更新でノード名が変わり、静的グループからの参照が無効になったか、別のノードを指している。
• ルールが対象のfallbackグループに入っておらず、確認された出口が別グループまたは最終フォールバックルールのものになっている。
• クライアント画面に古い状態がキャッシュされ、カーネルの実際の選択と表示更新が同期していない。接続履歴での確認が必要。

load-balance：複数ノードへの接続分散

load-balanceは、複数の独立した接続を対象とします。カーネルが負荷分散方式に従い、グループ内で利用可能なノードを接続ごとに選択します。複数ノードの帯域を束ねて1本の太い回線にする機能ではなく、1本のTCP接続のパケットを複数の出口へ無作為に分割するものでもありません。単一接続によるファイルダウンロードは、通常1つのノードで処理されます。複数接続のダウンロード、多数の同時リクエスト、複数端末からの同時アクセスでは、分散効果を確認しやすくなります。

Mihomoで一般的な負荷分散方式には、consistent-hashingとround-robinがあります。コンシステントハッシュは、同じ接続先を継続して同一ノードへ割り当てる傾向があり、短時間に同じサイトの出口が何度も変わるのを抑えられます。ラウンドロビンは、利用可能なノードを接続ごとに順番に選ぶため、より直接的に分散できますが、同じサービスへの複数接続が異なる出口を使う場合があります。

proxy-groups:
  - name: ダウンロード分散
    type: load-balance
    proxies:
      - ノード-A
      - ノード-B
      - ノード-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

ログイン状態に敏感で出口IPを検証するサービスでは、一般にコンシステントハッシュのほうがラウンドロビンより安定します。サイトによってはログインセッション、セキュリティ判定、地域別コンテンツを出口IPと関連付けています。ページ内リソースとAPIリクエストが別々のノードを通ると、再認証、地域の変化、セッション切れが発生する可能性があります。コンシステントハッシュを使用しても、ドメインが異なるリソースは別ノードへ割り当てられる場合があります。そのため、金融サービス、企業アカウントへのログイン、固定出口が必要な通信には、固定ノードまたはfallbackが適しています。

ラウンドロビンは、出口の変化を許容できる大量の独立した接続に適しています。たとえば、複数パッケージのダウンロード、分散した公開リソースへのリクエスト、LAN内の複数端末が生成する大量の非機密接続などです。総スループットが向上するかどうかは、ローカル回線の帯域、接続先サーバーの制限、ノード上流の容量、同時接続方式にも左右されます。ボトルネックが家庭のインターネット回線や接続先サーバーにある場合、ノード数を増やしてもその上限は超えられません。

購読ノードとヘルスチェックの連携

購読からノードを取得する場合、一般的にはproxy-providersでリモートプロバイダーを管理し、複数のプロキシグループからuseで同じプロバイダーを参照します。これにより、購読の更新後は各グループへノード名を個別にコピーしなくても、新しいノードを対応する動的グループに追加できます。プロバイダーの更新間隔とヘルスチェックの間隔は別の設定です。前者はノード一覧を取得するタイミング、後者は既存ノードの状態を確認するタイミングを決めます。

proxy-providers:
  provider-main:
    type: http
    url: https://example.com/clash-provider.yaml
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

proxy-groups:
  - name: 購読ノード自動選択
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

プロバイダー側のヘルスチェックとプロキシグループ側のテストが同時に設定されている場合があります。多数のノードを設定する際は、重複テストによる通信量と端末負荷に注意してください。特にモバイル端末、性能の低いルーター、ノード数の多い購読では影響が目立ちます。チェック間隔を統一する、オンデマンドチェックを有効にする、実際に選択へ関わるグループだけで必要なテストを行う、といった調整が有効です。テストを減らすことは、すべてのチェックを無効にすることではありません。障害検出の要件に合わせて頻度を設定することが重要です。

購読の更新によって、ノード名、並び順、ラベルが変わることもあります。filterで地域を絞り込む場合は、正規表現がテスト用ノードを誤って含めていないか、名前の形式が変わったノードを除外していないか確認してください。fallbackがプロバイダーのノードを動的に参照する場合、プロバイダーから返される順序も優先順位に影響する可能性があります。順序を固定する必要があるメイン・予備回線では、ノードを明示的に列挙するほうが管理しやすい一方、ノード名が変わった際には設定も更新する必要があります。

用途に合わせたプロキシグループの選び方

Web閲覧と一般的なアプリ

まずurl-testを検討し、適度なテスト間隔と許容値を設定したうえで、手動選択できる経路も残します。機能の近い複数ノードから、日常利用に適したものを自動選択できます。ノード間で地域が大きく異なる場合は、地域ごとに自動グループを作り、上位のselectで地域を選択すると、自動テストによって要件外の地域へ出口が切り替わるのを防げます。

固定地域、業務システム、リモートアクセス

まずfallbackを検討し、出口の要件に最も合う回線を先頭、その後ろに同じ地域の予備回線を配置します。サービスが出口IPを厳密に固定している場合は、固定ノードまたは手動グループのほうが適していることがあります。自動フェイルオーバーは障害時の継続性を高めますが、出口の変化自体が接続先サービスのセキュリティ確認を引き起こす場合もあります。

同時ダウンロードと複数端末での共有

load-balanceを検討し、出口の一貫性に関する要件に応じてコンシステントハッシュまたはラウンドロビンを選びます。ログイン、決済、企業アカウント認証などの機密性が高い接続をラウンドロビングループへ混在させないでください。より安全なのは、ルールを使ってダウンロード用ドメイン、更新サービス、特定端末の通信だけを負荷分散グループへ送り、その他の通信には安定した出口を使う構成です。

TUNモードでの選択

TUNモードを有効にするとカーネルが処理できる通信範囲は広がりますが、3種類のプロキシグループの基本的な選択ロジックは変わりません。TUNへ入った接続もルールに照合されてから、対応するプロキシグループへ送られます。TUNの有効化後にアクセス結果が変わった場合は、システムルート、DNSハイジャックまたはリダイレクト設定、ルールの一致状況、プロキシグループの設定を個別に確認し、すべての問題を自動速度テストのせいにしないようにしてください。

頻繁な切り替えと誤ったフェイルオーバーの確認手順

1. ルールの一致先を確認します。クライアントの接続履歴で対象ドメインを見つけ、実際にどのプロキシグループへ入っているか確認してください。ルールの転送先が誤っている場合、ヘルスチェックを調整しても通信経路は変わりません。
2. グループの種類と目的が一致しているか確認します。メイン・予備の順序が必要なのにurl-testを使ったり、出口を固定したいのにラウンドロビンを使ったりすると、設定ロジック上は正常でも意図と異なる結果になります。
3. テスト先を確認します。テスト用URLがすべてのノードで安定して成功ステータスを返すことを確かめ、地域制限、リダイレクト、サーバー側の帯域制限が判定に影響しないようにします。
4. 間隔と許容値を確認します。url-testの選択が頻繁に変わる場合は、まず許容値を大きくします。障害検出が遅い場合はチェック間隔を見直し、最初から極端に短い間隔へ設定しないでください。
5. ノードの並び順を確認します。fallbackは先頭から利用可能な項目を選ぶため、本当に優先したい回線を最初に配置する必要があります。
6. 購読の更新結果を確認します。ノード名、フィルタールール、プロバイダーの状態を確認し、グループ内の候補が想定と異なる状態を防ぎます。
7. ホーム画面の数値だけでなく、実際の接続を確認します。遅延パネルに表示されるのはテスト結果です。各サービスが最終的に使用したノードは、接続ログで確認できます。

プロキシグループ選びで重要なのは、「速度による選択」「メイン・予備の優先順位」「接続の分散」を分けて考えることです。url-testは機能の近いノードからの自動選択、fallbackは明確な回線優先順位の維持、load-balanceは複数の独立した接続の振り分けに適しています。設定後は、1回の遅延テストだけで判断せず、実際に利用するサービスでルールの一致先、ノードの選択、出口の安定性を確認してください。