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

Clashの設定におけるプロキシグループは、各接続を最終的にどのノードへ渡すかを決めます。ルールはトラフィックをグループへ振り分けるだけで、グループ内の type がノードの選択方法を決定します。手動グループの select はユーザーがノードを指定し、自動グループはヘルスチェック、並び順、または分配アルゴリズムに基づいて選択します。

url-test、fallback、load-balanceはいずれもヘルスチェックを利用しますが、目的はまったく異なります。前者は低い測定遅延、2つ目は固定された優先順位と障害時の切り替え、3つ目は新しい接続の分散を重視します。種類を誤ると、設定エラーではなく、頻繁な切り替え、接続元の変化、または予備ノードが想定どおり引き継がないといった問題が起こりがちです。

3種類の自動プロキシグループの違い

種類を判断するときは、まず次のどれを重視するかを考えます。「応答の速いノードを選ぶ」「業務上の優先順位に沿って切り替える」「複数ノードで新しい接続を分担する」のいずれかです。これらはそれぞれ url-test、fallback、load-balance に対応します。

種類	選択基準	主な用途	接続先の特徴
`url-test`	ヘルスチェックの遅延と許容差	日常的に低遅延ノードを自動選択	一定期間、現在の優先ノードを集中的に利用
`fallback`	設定順と利用可能な状態	主回線を優先し、予備回線へ切り替え	リストの先頭にある利用可能なメンバーを優先
`load-balance`	負荷分散方式	複数ノードへ新しい接続を分散	接続ごとに異なる接続先になる可能性がある

ヘルスチェックは業務接続を継続的に占有して速度測定するものではない

自動グループは interval で指定した秒数ごとにテスト URLへアクセスし、メンバーの利用可否と応答時間を記録します。たとえば interval: 300 なら通常の周期は300秒、つまり5分です。周期が短すぎるとノードやローカルネットワークへの測定リクエストが増え、長すぎると回線の復旧や障害の発見が遅れます。

テスト URLには通常、返される内容が小さく応答が安定したアドレスを選びます。たとえば https://www.gstatic.com/generate_204 です。このアドレス自体が接続元のネットワークで制限されていると、すべてのノードが同時に失敗と判定される可能性があります。その場合は、すぐに全ノードが停止したと判断せず、安定して応答する軽量なアドレスへ変更してください。

url-test：測定遅延で自動的に最適なノードを選択

url-test はグループ内のメンバーを定期的にテストし、測定遅延の低い利用可能なノードを選択します。Web閲覧、インスタントメッセージ、コードホスティングなど、応答時間を重視する日常的な通信に適しています。選択はプロキシグループ単位で行われるため、リクエストごとに再測定するわけではありません。

proxy-groups:
  - name: 自動最適化
    type: url-test
    proxies:
      - 香港-01
      - 香港-02
      - 日本-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

tolerance：数ミリ秒の差による切り替えを抑える

tolerance の単位はミリ秒です。上の例では 50 に設定しており、新しい測定結果との差が許容範囲を超えた場合に切り替える価値があると判断します。細かな選択の挙動は使用するコアの実装に左右されます。主な目的は、遅延が近い2つのノードが何度も優先候補を入れ替えるのを防ぐことです。

たとえばノードAの実測値が82 ms、ノードBが106 msで、差が24 msだとします。許容差が50 msなら、1回の測定の揺らぎだけで切り替える必要はありません。ノードAが178 msまで悪化し、ノードBが103 msのままなら差は75 msに広がるため、再選択する意味が大きくなります。家庭のWi-Fiで遅延の変動が大きい場合は50～100 msから始め、安定した有線ネットワークでは20～50 msを目安にできます。

lazy：通信があるときだけチェックを維持

lazy: true は使用頻度の低いプロキシグループに適しています。グループに長時間接続がない場合、コアは不要な定期テストを減らし、再び対象トラフィックが発生するとチェックを再開できます。予備回線の状態をすばやく把握したい重要な業務グループでは、使用する mihomo のバージョンとクライアントの挙動を確認したうえで有効化を判断してください。

url-testが適するケース・適さないケース

用途が似ており、料金プランと回線品質が近い複数のノードに適しています。
高遅延ノードを自動的に避けたい一方、固定の接続先アドレスを必要としない場合に適しています。
同じ地域または同じ接続先アドレスを長期間維持する必要があるログインセッションには適していません。
1回の204テストだけで動画向け帯域を判断する用途には適していません。遅延測定は継続的なスループット測定の代わりにならないためです。

fallback：順番に確認し、最初の利用可能なノードを使う

fallback の要点は、遅延が最も低いノードではなく、先に並び、現在利用できるノードを選ぶことです。リストの最初のメンバーが主回線となり、主回線のヘルスチェックに失敗した場合に限って後続の予備メンバーを試します。主回線が復旧してチェックを通過すると、通常は再び前方のメンバーへ戻ります。

proxy-groups:
  - name: 業務回線
    type: fallback
    proxies:
      - 企業専用線
      - 香港予備
      - 日本予備
    url: https://www.gstatic.com/generate_204
    interval: 180
    lazy: false

この設定は明確な業務上の優先順位を表しています。まず「企業専用線」を使い、利用できない場合は「香港予備」へ切り替え、両方とも利用できない場合に「日本予備」を使います。日本ノードの実測値が45 ms、企業専用線が92 msであっても、企業専用線が利用可能である限り、優先順位は変わりません。

「利用可能」とは、テスト URLへのアクセスが完了することだけを意味する

ノードから204テストアドレスへアクセスできても、ルールに対応する業務ドメインへ確実にアクセスできるとは限りません。ヘルスチェックには成功しても、特定のサービスへ正常に接続できない回線もあります。その場合は業務グループのテスト先を実際の対象に近いアドレスへ変更できますが、ログインが必要なページ、何度もリダイレクトするページ、大容量ファイルを返すページは避けてください。

障害切り替えによって、確立済みのTCP接続が別のノードへシームレスに移行することもありません。主回線が切断されると、既存のダウンロード、SSH、WebSocket接続は通常中断されます。アプリが再接続した後の新しい接続から、予備メンバーが使用されます。長時間接続を使う業務では、アプリ自身の再試行機能も確認してください。

fallbackの代表的な用途

主回線を固定：主ノードに安定した接続先や特定地域があり、他のノードは障害時の切り替えだけを担う場合。
コストを優先：通信容量に余裕のある回線を優先し、高額または容量制限のある回線を後ろに置く場合。
地域に順序を付ける：まず香港リージョンを使い、すべて利用できない場合に日本またはシンガポールへ切り替える場合。
リモート接続：リモート開発や管理パネルなど、数十ミリ秒の遅延差より接続先の継続性を重視する業務。

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

load-balance は複数の利用可能なメンバーへ接続を分配します。ただし帯域を合算する機能ではありません。1本のTCPダウンロードは通常1つのノードを通るため、100 Mbpsの回線3本を自動的に300 Mbpsの接続へまとめることはできません。大量の独立したリクエスト、複数ドメインへのアクセス、並列タスクに適しています。

proxy-groups:
  - name: 並列分散
    type: load-balance
    proxies:
      - 香港-01
      - 香港-02
      - 香港-03
    url: https://www.gstatic.com/generate_204
    interval: 300
    strategy: consistent-hashing

consistent-hashing：近い接続先を比較的安定して維持

consistent-hashing は接続先に基づいて分配先を計算し、同じまたは近い接続先が同じメンバーへ割り当てられやすくします。完全なラウンドロビンよりも、Webサイトへのログイン、API呼び出し、ある程度の接続先の継続性が必要な場面に適しています。ノード一覧が変わると一部の接続先は再マッピングされる可能性があるため、本当の固定接続先の代わりにはなりません。

round-robin：新しい接続を順番に割り当てる

mihomo が対応する round-robin 方式では、新しい接続を利用可能なメンバーへ順番に割り当てます。グループ内にA、B、Cの3ノードがある場合、連続して確立される接続はA、B、C、Aの順になる可能性があります。1つのWebページでも複数ドメインへ同時接続することが多いため、同じページの読み込み中に複数の接続先アドレスが現れる場合があります。

ラウンドロビンは、並列取得や接続数の分散など、単一の接続先に依存しないタスクに適しています。アカウントログイン、決済、ネットバンキング、またはIPアドレスの変化に敏感なAPIには向きません。サーバー側で短時間の複数接続先を異常と判定する場合は、select、fallback、または割り当てが安定しやすい方式を使用してください。

負荷分散方式	接続の割り当て方法	適した用途	注意点
`consistent-hashing`	接続先に基づいて比較的安定した割り当てを計算	複数サイトへのアクセス、並列APIリクエスト	メンバー変更後も割り当てが変わる可能性がある
`round-robin`	新しい接続を順番に切り替え	独立したタスク、並列ダウンロード	同じアプリで複数の接続先になる可能性がある

複合プロキシグループ：地域内で最適化してから地域間でフォールバック

複雑な設定を1つのグループですべて解決する必要はありません。プロキシグループは別のグループを参照できるため、まず地域ごとに url-test を作成し、上位の fallback で地域の優先順位を決めると分かりやすくなります。同一地域では低遅延ノードを選びつつ、その地域全体が利用できない場合は別地域へ切り替えられます。

proxy-groups:
  - name: 香港自動
    type: url-test
    proxies:
      - 香港-01
      - 香港-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 日本自動
    type: url-test
    proxies:
      - 日本-01
      - 日本-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: デフォルト接続先
    type: fallback
    proxies:
      - 香港自動
      - 日本自動
    url: https://www.gstatic.com/generate_204
    interval: 180

rules:
  - DOMAIN-SUFFIX,example.net,デフォルト接続先
  - MATCH,デフォルト接続先

この構成では、「香港自動」が2つの香港ノードから適切なメンバーを選びます。上位の「デフォルト接続先」は香港グループを優先し、香港グループのチェックに失敗した場合にのみ日本グループを使います。グループ名は大文字・小文字、空白、記号を含めて完全に一致させてください。YAMLのインデントは半角スペース2つに統一し、Tabを混在させないことをおすすめします。

手動グループと自動グループを併用する

実際の設定では、一時的にノードを指定できる select グループも残しておくことが多いでしょう。「自動最適化」「業務回線」「並列分散」と個別ノードを手動グループにまとめ、ルールからその手動グループを参照できます。普段は自動方式を選び、固定の接続先が必要なときは個別ノードへ切り替えます。

proxy-groups:
  - name: ノード選択
    type: select
    proxies:
      - 自動最適化
      - 業務回線
      - 並列分散
      - 香港-01

この構成は、すべてのルールから下位の自動グループを直接参照するより保守しやすくなります。クライアント画面では「ノード選択」だけを操作し、下位グループにはテストと障害判定を任せられます。設定を変更したら、クライアントで「設定」→「再読み込み」を実行し、プロキシグループ名が存在しない、YAMLの解析に失敗した、ノード参照が不正といったエラーがログにないか確認してください。

ルールモード、システムプロキシ、TUNモードとの関係

プロキシグループは接続先を選び、ルールはどのグループへ入れるかを決めます。ルールモードでは、接続が上から順に DOMAIN、DOMAIN-SUFFIX、IP-CIDR などのルールと照合され、該当すると指定されたプロキシグループへ進みます。グローバルモードでは通常、通信をまとめてグローバル設定へ渡すため、通常ルールごとに行き先を決めることはありません。

システムプロキシとTUNモードは、どの通信をコアへ入れるかを決めるもので、url-test、fallback、load-balance の基本的な選択ロジックは変えません。ブラウザーがシステムプロキシ経由でClashへ入る場合でも、ゲーム通信がTUN経由でmihomoへ入る場合でも、最終的に同じプロキシグループへ到達すれば、その種類に応じてノードが選択されます。

TUNモードではUDPを追加で確認する

ゲーム、音声通信、一部のHTTP/3通信はUDPを使用します。ノードのプロトコル、サーバー、クライアントのコアが、対応するUDP転送をサポートしている必要があります。TCPのテスト URLに成功しても、UDPが利用できるとは限りません。Webページは正常なのに音声通信やゲームだけ失敗する場合は、接続パネルで通信種別を確認し、ノードのUDP対応、TUN設定、ファイアウォールルールを確認してください。

DNSの結果はルールと接続先に影響する

Fake-IPを有効にすると、DNSモジュールがマッピングアドレスを返し、コアがその対応関係からドメインを復元してルールと照合します。Redir-Hostを有効にした場合は、ドメインの名前解決結果がより直接的に接続へ使われます。プロキシグループ自体がDNSを修復するわけではありません。ドメインの名前解決がタイムアウトすると、3種類の自動グループはいずれも正常な業務接続を確立できない可能性があります。

パラメータの調整方法：安定した設定から始める

自動プロキシグループのパラメータに、すべてのネットワークで通用する正解はありません。家庭用ブロードバンド、モバイルホットスポット、中国と海外を結ぶ専用線、クラウドサーバーでは変動幅が異なります。まず控えめな値を使い、切り替えと失敗の状況を記録してから、問題に応じて調整するのが確実です。

パラメータ	推奨開始値	小さくした場合の影響	大きくした場合の影響
`interval`	180～300秒	変化を早く検知し、測定頻度が上がる	リクエストは減るが、障害の検知が遅くなる
`tolerance`	50 ms	小さな遅延差を重視し、切り替えが増える可能性がある	選択は安定するが、やや遅いノードを維持する可能性がある
`lazy`	通常のグループではtrueに設定可能	継続的なチェックがより積極的になる	アイドル状態のグループでは測定を減らせる

まずテスト URLへ各ノードから安定してアクセスできることを確認し、少なくとも3回連続でチェックしてください。
1回の結果だけでなく、ノードの遅延を記録します。82 ms、91 ms、87 msは近い値ですが、82 msと260 msは明確な差です。
クライアントの接続パネルで実際のプロキシチェーンを確認し、ルールが想定どおりのグループに一致しているか確認します。
調整後は設定を再読み込みし、新しい接続を作成してテストします。既存の接続は、調整前の接続先を使い続ける可能性があります。
グループ全体が失敗した場合は、まずローカルネットワークとテストアドレスを確認し、次にサブスクリプションのノードを確認します。複数のパラメータを同時に変更しないでください。

よくある誤解とトラブルシューティングの手順

誤解1：url-testはすべてのリクエストを最低遅延ノードへ送る

url-testは直近のヘルスチェック結果に基づいて現在の選択を維持し、HTTPリクエストのたびに完全な速度測定を実行するわけではありません。2回のチェック周期の間にノードの遅延が変化すると、現在の判定が一時的に遅れて見えることがあります。これは周期的に測定する方式の正常な特徴です。

誤解2：fallbackは予備リストから最速のノードを選ぶ

fallback はまず並び順を優先します。先頭のメンバーが利用可能であれば、2番目のメンバーのほうが低遅延でも自動的には切り替えません。遅延で選びたい場合は url-test に変更するか、fallback内でurl-testの子グループを参照してください。

誤解3：load-balanceで単一ファイルのダウンロード速度が上がる

通常、1つの接続は1つのノードに割り当てられます。ダウンローダーがファイルを複数の独立した接続に分割し、それらが異なるメンバーへ割り当てられた場合に限り、合計スループットが変化する可能性があります。最終的な速度は、配信元の速度制限、ノードの帯域、回線混雑、分配方式にも左右されます。

決まった順序でトラブルシューティングを行う

クライアントの「設定」ページで、変更したばかりの設定ファイルが読み込まれていることを確認します。
ログを開き、プロキシグループの種類、メンバー名、YAMLのインデントが正しいか確認します。
「プロキシ」または「プロキシグループ」ページで遅延テストを1回実行し、失敗したメンバーを記録します。
「接続」パネルで、対象接続が実際に一致したルールとプロキシチェーンを確認します。
対象アプリを終了して再起動し、古いTCP接続が以前の接続先を再利用していないか切り分けます。
システムプロキシの通信は正常でTUN通信だけ異常な場合は、TUN、DNS、ファイアウォールを確認してください。プロキシグループの種類を何度も変更する必要はありません。

選択の結論：名前ではなく目的で決める

測定遅延の低いノードを自動的に使いたいなら、url-test を選びます。
主回線を優先し、障害時に順番どおり切り替えたいなら、fallback を選びます。
複数ノードへ新しい接続を分散し、接続先の変化を許容できるなら、load-balance を選びます。
手動操作と自動判定を両立したいなら、外側に select を置き、自動グループをメンバーにします。
地域の優先順位が必要なら、まず地域内に url-test を作成し、上位で fallback と組み合わせます。

個人利用の設定は、まず「手動選択＋自動最適化」の2層構成から始めれば十分です。明確な主回線と予備回線がある場合にのみfallbackを追加し、独立した接続が多く接続先の分散を許容できる場合にのみload-balanceを使います。種類が多いほど設定が有効になるわけではありません。グループとルールの役割を明確にすることが、検証とトラブルシューティングを容易にします。