Clashのプロキシグループ徹底解説：url-test・fallback・load-balanceの違い

Clashのルール分流におけるプロキシグループの役割

Clash設定では、プロキシノードが実際の接続を確立し、ルールがトラフィックの種類を判定します。プロキシグループはその中間に位置し、特定のトラフィックを最終的にどのノードへ渡すかを決めます。ルールの送信先には通常、ノード名を直接指定せず、プロキシグループを指定します。たとえば業務ドメインを「業務サービス」、ストリーミングドメインを「メディアサービス」へ振り分け、グループ内の選択ロジックでノードを切り替えます。

url-test、fallback、load-balanceはいずれも自動プロキシグループですが、「自動」だからといって同じ選択をするわけではありません。3つはそれぞれ、低遅延ノードの優先選択、順番に基づく障害切り替え、複数ノードへの接続分散に対応します。ノード一覧だけを見てグループの種類を確認しないと、同じノード構成でもアクセス結果が大きく異なる場合があります。

proxy-groups:
  - name: 業務サービス
    type: url-test
    proxies:
      - ノード-A
      - ノード-B
      - ノード-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

rules:
  - DOMAIN-SUFFIX,example.com,業務サービス
  - MATCH,業務サービス

上記の設定では、ルールは一致した接続を「業務サービス」へ渡すだけです。ノードA、B、Cのどれを使うかを実際に決めるのは、url-testの測定結果と切り替えパラメータです。プロキシグループは追加のネットワークトンネルではなく、ノード自体のプロトコル、暗号化方式、サーバー回線を変更するものでもありません。ノードを整理し、選択を実行する仕組みです。

自動プロキシグループにおけるヘルスチェックの役割

自動グループでは通常、各候補ノードを通じて定期的にテストURLへアクセスします。カーネルはリクエストの成否、応答時間、連続したチェック結果をもとにノードの状態を管理します。テストURLには安定していて応答データが小さく、実際のネットワーク出口に近いものを選びます。204を返すURLは基本的な接続性の測定に適していますが、特定のサービスが主目的なら、長期的に管理できる軽量なURLを使うこともできます。

intervalはチェック間隔を表し、通常は秒単位です。短すぎるとノードや端末への追加リクエストが増え、モバイル回線では接続を頻繁に起こす可能性があります。長すぎると回線障害の発見が遅れます。デスクトップで常時稼働させる場合は、まず300秒前後から様子を見て、回線の変動やノード数に応じて調整するとよいでしょう。

url-test：ヘルスチェックの遅延でノードを選ぶ

url-testはグループ内のノードをテストし、利用可能なノードの中から測定遅延が低いものを優先します。複数のノードが同じような用途で使え、応答速度を重視する場合に適しています。たとえば同じ地域の複数の出口、同じサービスへアクセスできる複数ノード、日常的なWeb閲覧やコードリポジトリへのアクセスなどです。

ここでいう「最も低い遅延」は、ヘルスチェックのリクエストに対するものです。ダウンロード速度が最速という意味ではありません。小さなHTTPリクエストで分かるのは主にハンドシェイク、往復時間、現在の到達性であり、大容量ファイルのスループット、混雑時間帯の輻輳、対象サイトから出口サーバーまでの帯域を完全には反映できません。url-testは「テスト結果から応答の速い正常なノードを選ぶ」仕組みであり、帯域を継続的に競わせる機能ではありません。

toleranceで頻繁な切り替えを抑える

ネットワーク遅延は常に変動します。ノードAが82ミリ秒、ノードBが76ミリ秒だった場合、6ミリ秒の差だけで直ちに切り替えても体感できる改善はほとんどなく、新しい接続の出口だけが変わる可能性があります。toleranceは許容する遅延差を設定する項目です。現在のノードと候補ノードの差がしきい値以内なら、現在の選択を維持します。

- name: 日常低遅延
  type: url-test
  proxies:
    - 香港-01
    - 香港-02
    - シンガポール-01
  url: https://www.gstatic.com/generate_204
  interval: 300
  tolerance: 100
  lazy: true

これらのフィールドに対応するmihomo設定では、lazy: trueを使うことで、プロキシグループが長時間使われていない間のチェック処理を減らせます。グループがトラフィックを処理し始めると、カーネルが仕様に従って状態を更新します。具体的な発動条件はカーネルのバージョンによって変わる可能性があるため、利用前に使用中のバージョンのドキュメントと実行ログを確認してください。

url-testが適する範囲

適しています：候補ノードの用途が同じで、地域の違いがWebサイトの内容やアカウントのリスク判定に影響しない場合。
適しています：Web閲覧やAPIリクエストなど、応答遅延の影響を受けやすい接続。
注意が必要：固定の出口IPを維持しなければならないログイン、決済、リモートワーク、ホワイトリスト登録済みのサービス。
速度だけで判断しない：大容量ファイルのダウンロード、高ビットレートの動画転送、継続的なアップロードは、帯域幅やパケットロスにも左右されます。

業務上、セッション中はできるだけ同じ出口を維持したい場合は、toleranceを大きくする、メンバーを絞る、または自動グループとは別にselectによる手動選択グループを追加します。自動選択の入口を残しながら、必要な時間だけ特定のノードに固定できます。

fallback：ノードの順番で障害を切り替える

fallbackの目的は最速のノードを比較することではなく、設定順に従って最初の正常なノードを使うことです。先頭のノードがヘルスチェックを通過している限り、後ろのノードの遅延がさらに低くても通常は置き換わりません。先頭のノードが利用できなくなったとき、次の利用可能なメンバーを順番に探します。

この動作は、プライマリとバックアップの関係が明確な環境に適しています。たとえば、プライマリノードが固定出口、専用回線、または業務に適した地域を持ち、予備ノードはプライマリ回線の障害時だけ引き継ぐ構成です。url-testと比べてfallbackの判断は予測しやすく、ノードの並びそのものが優先順位リストになります。

- name: オフィス主系・予備系
  type: fallback
  proxies:
    - オフィス主回線
    - オフィス予備回線
    - 緊急用回線
  url: https://www.gstatic.com/generate_204
  interval: 180
  lazy: false

この例では「オフィス主回線」を優先して使います。このノードのヘルスチェックが失敗した場合にだけ、「オフィス予備回線」、続いて「緊急用回線」を試します。主回線が復旧して正常と判定されると、グループが前方のノードへ戻る場合があります。復旧判定と既存接続が直ちに移行するかどうかは分けて考える必要があります。グループの選択が影響するのは後続の接続であり、確立済みのTCPまたはUDPセッションが切断なしに移行できるとは限りません。

遅延の数値よりノードの順番が重要

fallbackを設定するときは、まず業務上の優先順位でノードを並べ、その後に測定結果を考慮します。主回線は長期的に使いたい回線にし、予備回線には同じ重要なアクセス能力を持たせます。予備ノードが主要サービスへアクセスできなければ、ヘルスチェックURLが正常でも本当の引き継ぎはできません。

地域に依存するサービスでは、異なる地域のノードを1つのfallbackグループに無作為に混在させないことをおすすめします。より安全なのは、地域ごとに主系・予備系グループを作り、それを上位の手動選択グループへ渡す方法です。たとえば「日本主系・予備系」には日本ノードだけ、「シンガポール主系・予備系」にはシンガポールノードだけを入れ、最上位で必要な地域を選択します。障害時も自動切り替えによって出口地域が意図せず変わりません。

fallbackに適した典型的なケース

リモートワークサービスで、アクセス許可リストに登録済みの固定出口を優先したい場合。
主回線の品質とコストが明確で、予備回線は障害時のトラフィックだけを担当する場合。
ノード間に、瞬間的な遅延ではなく信頼性による明確な順位がある場合。
基本的な接続性は自動復旧しつつ、選択ロジックを監査・説明しやすく保ちたい場合。

load-balance：新しい接続を複数ノードへ分散する

load-balanceは、グループ内の複数の正常なノードで接続を分担します。1つのノードを恒久的な勝者として選ぶのではなく、負荷分散方式に従って接続ごとの出口を決めます。独立したリクエストが大量に発生し、複数ノードの性能が近く、複数の出口を使っても業務上問題ない環境に適しています。

注意したいのは、Clashの負荷分散は通常、接続または宛先を単位に判断し、1本のTCP接続を複数のプロキシサーバーへ分割するものではない点です。大容量ファイルのダウンロードが1本の接続だけで行われる場合、速度はその接続に選ばれたノードに制限されます。アプリが複数の並列接続を作る場合に限り、複数ノードがそれぞれ一部を担当できます。

- name: 複数ノード分散
  type: load-balance
  proxies:
    - ノード-A
    - ノード-B
    - ノード-C
  url: https://www.gstatic.com/generate_204
  interval: 300
  strategy: consistent-hashing

consistent-hashingとround-robin

mihomoで利用できる具体的な負荷分散方式は、使用中のバージョンを基準に確認してください。一般的なconsistent-hashingは宛先情報に基づいて比較的安定した対応付けを行い、同じ、または関連する宛先を同じノードへ割り当てやすくします。同じサイトへアクセスする際の出口の頻繁な変化を抑えられるため、ページ内に複数のリソースリクエストがあり、サイトが接続元に敏感な場合に適しています。

round-robinは、利用可能なノードを順番に切り替え、新しい接続を異なるメンバーへ分散する方式です。トラフィックを分ける動きは分かりやすい一方、同じWebサイトへの複数接続が異なる出口を使う可能性があります。サイトが送信元IPに基づいてログイン状態を管理したりセキュリティチェックを行ったりすると、再認証、セッション切れ、地域による表示の不一致につながることがあります。

一部のmihomoバージョンには、ほかの方式も用意されています。フィールドや動作は変更される可能性があるため、古いファイルを読み込めたからといって、すべての方式の意味が完全に同じだと考えてはいけません。起動ログの設定警告を確認し、接続詳細から実際に選ばれたノードを確認してください。

負荷分散が適さないすべての業務

アカウントログイン、ネットバンキング、企業向け認証など、安定した出口が必要なサービスでは、固定ノード、select、または宛先を安定して同じノードへ割り当てる方式を優先してください。
ノードの出口地域が異なると、検索結果、メディアカタログ、通貨単位、ページの地域設定が接続ごとに変わる可能性があります。
ノード性能に大きな差がある場合、接続を均等に配分しても帯域が均等になるわけではありません。遅いノードが一部のリクエストを引き延ばします。
モバイル回線で頻繁に切り替わる場合、端末リソースが限られている場合、またはノード数が多すぎる場合、ヘルスチェックと並列接続による負荷が増加します。

url-test・fallback・load-balanceの主な違い

比較項目	url-test	fallback	load-balance
主な目的	測定遅延が低い正常なノードを選ぶ	一覧の前方にある正常なノードを優先して使う	複数の正常なノードで新しい接続を分担する
ノードの順番の役割	通常、主な選択基準ではない	主系・予備系の優先順位を直接示す	負荷分散方式によって異なる
切り替えの理由	遅延差が許容範囲を超えた、または現在のノードが停止した	前方のノードが停止した、またはより高い優先順位のノードが復旧した	新しい接続を方式に従って割り当て、停止したノードを除外する
出口の安定性	中程度。toleranceで切り替えを抑えられる	高い。主ノードが正常な間は優先状態を維持する	ハッシュ方式またはラウンドロビン方式による
よくある用途	Web、API、同一地域での低遅延ノード選択	オフィスの主系・予備系、固定地域での障害切り替え	複数接続のダウンロード、並列リクエストの分散

名前ではなく要件で選ぶ

プロキシグループを選ぶときは、まず3つの質問に答えます。1つ目は、業務で固定地域または固定出口が必要か。2つ目は、ノード障害時に任意の利用可能なノードへ自動切り替えしてよいか。3つ目は、複数ノードで本当に接続を同時に分担する必要があるかです。主出口を維持し、障害時だけ切り替えたいならfallbackが分かりやすく、ノードが同等で応答速度を優先するならurl-testが適しています。リクエスト量が多く、接続が互いに独立していて、接続元の変化を許容できる場合にload-balanceを検討してください。

1つの設定で自動グループを1種類だけ使う必要はありません。実際には階層的に組み合わせられます。下位でfallbackを使って地域ごとの主系・予備系ノードを整理し、中位でurl-testを使って同等の地域グループから応答のよい入口を選び、最上位にselectを置いてユーザーが手動で固定できるようにします。グループの入れ子は業務上の境界を明確にできますが、階層が増えすぎるとトラブル対策が難しくなります。グループ名は用途を正確に表すようにしてください。

proxy-groups:
  - name: 香港主系・予備系
    type: fallback
    proxies:
      - 香港主回線
      - 香港予備回線
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: シンガポール主系・予備系
    type: fallback
    proxies:
      - シンガポール主回線
      - シンガポール予備回線
    url: https://www.gstatic.com/generate_204
    interval: 300

  - name: 自動地域選択
    type: url-test
    proxies:
      - 香港主系・予備系
      - シンガポール主系・予備系
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 120

  - name: 最終選択
    type: select
    proxies:
      - 自動地域選択
      - 香港主系・予備系
      - シンガポール主系・予備系
      - DIRECT

プロキシグループ設定の総合チェック手順

1. カーネル、クライアント、設定フィールドを確認する

Clashオリジナル版、Clash Meta、後継のmihomo系では、機能範囲や対応フィールドが異なります。GUIクライアントによっても、プロキシグループの編集画面は違う場合があります。サブスクリプションに特定のフィールドが含まれていても、現在のカーネルが対応しているとは限りません。設定を読み込んだ後はカーネルの起動ログを確認し、未知のフィールド、プロキシグループの種類の誤り、プロキシ名の参照失敗がないことを確認してください。

クライアントでカーネルを切り替えられる場合は、クライアント名だけで判断せず、実際にどのコアが動作しているかを確認します。サブスクリプション更新時に設定を再生成するクライアントもあり、手動で変更したプロキシグループが上書きされる可能性があります。長期的に使うカスタムルールやポリシーは、クライアントが提供するオーバーライド、拡張設定、設定統合機能で管理するとよいでしょう。

2. プロキシ名とインデントを確認する

YAMLはインデントに依存します。プロキシグループ内のproxiesメンバー名は、プロキシノードまたは他のプロキシグループの名前と完全に一致していなければなりません。日本語、スペース、記号は名前に使えますが、コピー時に余分なスペースが入らないよう注意してください。あるグループが別のグループを参照する場合は、循環参照も避けます。

proxies:
  - name: ノード-A
    type: ss
    server: server.example
    port: 443
    cipher: aes-128-gcm
    password: example-password

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - ノード-A
    url: https://www.gstatic.com/generate_204
    interval: 300

3. アイコンだけでなくヘルスチェックを検証する

クライアントに表示される遅延値は、手動測定の結果の場合もあれば、プロキシグループのヘルスチェックの結果の場合もあります。テストURLと測定時刻は一致しない可能性があります。ノードが利用可能と表示されるのにサイトが開かない場合は、接続ログを確認し、どのルールがどのプロキシグループに一致したか、グループが実際にどのノードを選んだか、失敗がDNS、接続確立、対象サーバーの応答のどの段階で起きたかを確認してください。

すべてのメンバーが同時にタイムアウトする場合は、まず現在のネットワークからテストURLへアクセスできるか、DNSが異常な結果を返していないか、システム時刻が正確か、ノード自体が接続を確立できるかを確認します。すぐにintervalを短くして測定を繰り返してはいけません。テスト頻度を上げても、基本的な接続問題は解決しません。

4. システムプロキシとTUNモードを組み合わせて検証する

プロキシグループは、トラフィックがClashカーネルに入って初めて機能します。システムプロキシが主に扱えるのは、OSのプロキシ設定に従うアプリです。システムプロキシを参照しないプログラム、一部のゲーム、特定のUDPトラフィックは、ルールチェーンに入れるためにTUNモードが必要になる場合があります。ブラウザではノードが期待どおり切り替わるのに、特定のアプリだけが常に直接接続するなら、まずトラフィックが取り込まれているかを確認し、いきなりプロキシグループを変更しないでください。

TUNモードを有効にした後は、DNSモード、ルーティング除外、LANアクセスにも注意します。DNS設定を誤るとドメインルールが期待どおりに一致せず、ルーティング除外によって対象トラフィックがカーネルを迂回することもあります。トラブル対策では、明確なテストドメインを1つ選び、DNS解決、ルール一致、プロキシグループ選択、ノード接続、対象サーバーの応答を順番に確認します。

5. サブスクリプション更新後のノード変更に対処する

サブスクリプション提供元は、ノードの追加、名前の変更、古いノードの削除を行う場合があります。プロキシグループのメンバーを固定名で列挙していると、名前の変更後に参照が無効になります。mihomo設定では、プロキシセットとフィルタールールを使ってサブスクリプションのノードを動的に整理できますが、フィルター式は慎重に設計してください。「残り通信量」や「プラン情報」など、ノードではない項目が自動グループに入るのを防ぐ必要があります。

動的フィルターを使うときは、地域と用途ごとにセットを作り、各グループの範囲を明確にします。たとえば低遅延グループには同じ業務で許容できる地域のノードだけを入れ、主系・予備系グループには本当に引き継ぎ可能な回線だけを入れます。ノード数は多ければよいわけではありません。候補が多すぎるとヘルスチェックの一覧が長くなり、異常ノードの特定も難しくなります。

安定したプロキシグループを作るための実践的なヒント

グループ名で選択ロジックを表現する。「香港主系・予備系」「低遅延自動」「ダウンロード分散」のような名前は、「プロキシグループ1」より接続記録を確認しやすくなります。
速度より業務上の境界を優先する。まず候補ノードが地域、アカウント、プロトコルの条件を満たすことを確認し、その後で遅延を比較したり接続を分散したりします。
自動切り替えに余裕を持たせる。url-testのtoleranceを適切に設定し、小さな遅延変動で出口が頻繁に変わるのを防ぎます。
load-balanceを速度測定の代わりに使わない。load-balanceは接続を分散する機能であり、すべての接続を最速ノードへ送ることは保証しません。
実際の選択結果を定期的に確認する。クライアントの接続画面で、ドメインルール、プロキシグループ、最終的なノードが想定どおりか確認します。
変更後は段階的にテストする。まずノード単体の利用可否、次にヘルスチェック、その後にルールの一致、最後に実際の業務を検証します。

要するに、url-testは「正常な回線のうち、現在最も応答が速いものはどれか」を解決し、fallbackは「主回線の障害後に誰が引き継ぐか」を解決し、load-balanceは「複数の正常なノードで接続をどう分担するか」を解決します。速度、優先順位、接続分散のどれが必要かを先に明確にし、ヘルスチェック、切り替えしきい値、ルールの入口を設定すれば、Clashの自動分流を分かりやすく予測しやすい状態に保てます。