url-test・fallback・load-balanceの違いとは：Clashのプロキシグループ選び方ガイド

まず結論：3種類のプロキシグループは別々の課題を解決する

ClashとMihomoの設定におけるプロキシグループは、単に「複数のノードを1つのリストに入れる」だけではありません。グループの種類によって、クライアントがノードをどう検査し、どの出口を選び、状態の変化後に切り替えるかが決まります。url-testは現在の測定で遅延が低いノードを選び、fallbackは設定順に利用可能な最初のノードを探し、load-balanceは複数の利用可能なノードへ異なる接続を振り分けます。

最もありがちな誤解は、3種類とも自動的に最適なノードを選ぶものだと考えることです。実際には、最低遅延・最優先・接続の分散という3つの異なる判断基準があります。遅延62msのノードがurl-testで選ばれても、fallbackで使われるとは限りません。また、ダウンロードをload-balanceに通しても、同じTCP接続が3本に分割されて帯域幅が合算されるわけではありません。

種類	主な判定基準	切り替え条件	代表的な用途
`url-test`	測定結果で遅延が低いノード	再測定で明らかに優れたノードが見つかった場合、または現在のノードが利用できない場合	ウェブ閲覧、APIリクエスト、普段使いのデフォルト出口
`fallback`	リスト内でヘルスチェックに合格した最初のノード	優先度の高いノードが停止または復旧した場合	固定の主回線・予備回線・安定した地域の出口
`load-balance`	利用可能な複数のノードへ接続を振り分ける	新しい接続の確立時、またはノードのヘルス状態が変化した場合	複数接続のダウンロード、並列リクエスト、出口負荷の分散

url-test：定期的に測定して低遅延ノードを選ぶ

url-testはグループ内のノードから同じテストURLへアクセスさせ、接続確立から応答を受け取るまでの時間を記録し、測定結果の良いノードを選びます。ノード品質が頻繁に変動し、手動切り替えを減らしたい場合に適しています。測定結果はクライアントからノードを経由してテスト先へ送る小さなリクエストを反映したもので、ピーク時のダウンロード速度や動画配信の経路品質を完全に示すものではありません。

基本設定とパラメーターの意味

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - 香港-01
      - 香港-02
      - シンガポール-01
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

urlはヘルスチェックの対象URLです。レスポンスが小さく、サービスが安定しており、プロキシ経由でアクセスできるものを選びます。例のURLは正常時に204を返すため、テスト通信量を抑えられます。
interval: 300は、300秒ごと、つまり5分ごとに定期チェックを実行することを示します。ミリ秒単位ではなく、ウェブページを開くたびに速度測定をやり直すという意味でもありません。
tolerance: 80は、遅延差が80ms以内なら通常は現在のノードを維持し、70msと76msの間で頻繁に切り替わるのを防ぐ設定です。
lazy: trueは、長期間使われていないプロキシグループの能動的なチェックを減らすために使います。具体的なスケジュールはコアのバージョンによって異なりますが、そのグループを使用するときは引き続きヘルス状態に基づいて動作します。

toleranceを0に設定し続けてはいけない理由

ある測定で香港-01が68ms、香港-02が75msだったとします。toleranceが0だと、数msのネットワーク揺らぎだけで結果が変わる可能性があります。次の測定で79msと72msになれば、プロキシグループは香港-02へ戻るかもしれません。既存のTCP接続は通常そのまま移行しない一方、新しい接続は別の出口を使うため、ログイン中のサイトからIPアドレスの変化を検知されることもあります。

家庭用回線では、まず50～100msから試すとよいでしょう。ノードが同じ地域にあり遅延も近い場合は、80msが安定性重視の出発点になります。アジア・ヨーロッパ・北米にまたがる場合は地域ごとにグループを分け、遅延だけを基準にすべての通信を最寄りの地域へ集中させないようにします。低遅延の回線へ素早く追従したい場合は、intervalを120～300秒、toleranceを30～50msに設定できますが、測定頻度が高いほどノードとテストサイトへの検査リクエストも増えます。

実測値をどう読み取るか

500Mbpsの家庭用回線で繰り返し測定したところ、3つのノードから204のURLまでの中央値はそれぞれ61ms、88ms、142msで、揺らぎの幅は約9ms、34ms、18msでした。url-testは61msのノードを選びやすいものの、2番目のノードのほうが大容量ファイルのダウンロードでは高いスループットを出す可能性があります。ウェブ閲覧のデフォルト出口は低遅延を基準にし、ダウンロード用の出口では100MB超のファイルの持続速度、パケットロス、ピーク時の性能も確認してください。

fallback：優先順位に従い最初の利用可能なノードを使う

fallbackで重要なのは順序であり、利用可能なノードの中から遅延が最も低いものを選ぶことではありません。リストの1番目が主回線、2番目が第1予備、3番目が第2予備です。1番目がヘルスチェックに合格している限り、遅延が160msで2番目が55msであっても、グループは1番目を優先します。地域、通信事業者、出口の識別情報を固定したいサービスに適した、予測しやすい方式です。

proxy-groups:
  - name: 主回線・予備回線
    type: fallback
    proxies:
      - 香港-専用線
      - 香港-予備
      - シンガポール-予備
    url: https://cp.cloudflare.com/generate_204
    interval: 180
    lazy: false

障害時の切り替えが発生するタイミング

コアはヘルスチェックをもとに、現在の優先度の高いノードが利用可能かを判断します。主ノードの測定が連続して完了しない場合、新しい接続は後続の利用可能なノードへ移ります。主ノードが復旧して再びチェックに合格すると、プロキシグループはより優先度の高いノードへ戻ることがあります。ただし、切り替えによって再生中の動画、SSHセッション、ダウンロード接続が途切れないとは限りません。元の接続に対応する出口と経路がすでに失われているためです。

interval: 180は通常のチェック間隔が3分であることを意味し、ミリ秒単位で切り替わるホットスタンバイではありません。障害の検知時間は、オンデマンド測定、タイムアウト設定、コアのスケジューリングにも左右されます。より早く障害を検知したい場合は60～120秒まで短くできますが、検査通信量は増えます。一般的な家庭利用では180～300秒にすると、応答性とチェック負荷のバランスを取りやすくなります。

ノードの順番はどう決めるべきか

地域、出口の識別情報、可用性が業務要件に最も合う主ノードを先頭に置きます。
2番目には、同じ地域で別のサーバーまたは別回線のノードを選び、サイト側から見た地域情報の変化を抑えます。
最後に地域の異なる予備ノードを置き、同一地域の回線が全体的に障害となった場合にも出口を確保します。
一度の遅延測定結果だけで並べ替えないでください。少なくとも平日夜20:00～23:00の安定性を確認しましょう。

動画配信はfallbackの代表的な用途です。主ノードが対象ライブラリへアクセスできることを確認済みで、予備ノードも同じ地域にあるなら、障害時も地域を維持したまま切り替えられます。一方、複数の国のノードをurl-testに入れると、遅延の変化によって次の接続が別地域へ切り替わり、コンテンツのラインナップやログイン時のリスク判定に影響する可能性があります。

load-balance：接続を分散するもので、単一接続の帯域を合算するものではない

load-balanceは複数の正常なノードに接続を振り分けます。ウェブページを開くとHTML、スクリプト、画像、APIなどへ同時にリクエストするため、別々のノードへ割り当てられることがあります。分割転送やマルチスレッドに対応したダウンローダーも複数接続を確立できるため、複数の出口を活用できます。ただし、確立済みのTCPまたはQUIC接続は通常1つのノードが処理し続け、100Mbpsのノード3台を自動的に1本の300Mbps接続へ統合することはできません。

proxy-groups:
  - name: 並列ダウンロード
    type: load-balance
    proxies:
      - ダウンロードノード-01
      - ダウンロードノード-02
      - ダウンロードノード-03
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    strategy: consistent-hashing

consistent-hashingとround-robin

Mihomoでよく使われる負荷分散方式にはconsistent-hashingとround-robinがあります。一貫性ハッシュは宛先などの情報に基づいて近いリクエストを特定のノードへ安定して割り当て、同じサイトへのアクセスで短時間に出口IPが何度も変わるのを抑えます。ラウンドロビンは新しい接続を利用可能なノードへ順番に割り当てるため、分散は均等になりやすい一方、セッション中の出口を安定させたいサイトには向きません。

負荷分散方式	接続の分布	出口の安定性	適した用途
`consistent-hashing`	同じ宛先は特定のノードへ固定されやすい	比較的安定	ウェブリソース、API、IPの頻繁な変化を抑えたい並列アクセス
`round-robin`	新しい接続を順番にノードへ振り分ける	変化しやすい	複数ソースからのダウンロード、一括処理、出口の識別情報を重視しない並列リクエスト

設定フィールドは、現在使用しているMihomoのバージョンが対応しているかを基準にしてください。古いコアには同じstrategyの値がない場合があり、クライアントがインポート時に未知のフィールドを無視することもあります。変更後はクライアントの「設定」→「ログ」でログレベルを一時的にdebugへ変更し、設定を再読み込みして解析エラーがないか確認します。正常であることを確認したらinfoへ戻し、大量のログが長期間出続けるのを防ぎます。

ログイン・決済・動画配信を単純なラウンドロビンにしない理由

サービスによっては、セッションを出口IP、地域、リスクスコアと関連付けます。ログインページをノードAで開き、後続のAPIをノードBから呼び出すと、追加認証やセッション無効化が発生する可能性があります。動画再生でも、ノードAで地域判定を行った後、分割データをノードBから取得すると、403、再認証、画質低下につながることがあります。このような通信には、一貫性ハッシュ、単一ノードの選択グループ、または地域を固定したfallbackが適しています。

interval・toleranceとヘルスチェックの連携

intervalは、定期チェックのおおよその間隔を制御します。単位は通常秒です。値を小さくすると状態を早く更新できますが、検査リクエストが増えます。300秒なら、チェック対象の各ノードが約5分ごとにテストURLへアクセスします。20ノードのグループでは、理論上1回あたり約20件の検査が発生します。サブスクリプションに100ノードあり、同じチェックグループを複数作っている場合、間隔を30秒まで短くする必要はありません。

toleranceは主にurl-testの切り替えを安定させるための設定です。タイムアウト値ではなく、ノードに「80ms余計に待たせる」ものでもありません。80に設定すると、候補ノードが現在のノードより十分に低い遅延を示した場合だけ入れ替えます。fallbackは順序と利用可否、load-balanceは接続の分配を基準にするため、通常はtoleranceで主要な動作を決めません。

実用的なパラメーター設定の目安3例

普段使い：interval: 300、tolerance: 80で、頻繁な切り替えを優先的に抑えます。
ネットワークの変動が大きい場合：interval: 180、tolerance: 50で、回線の変化を早めに検知します。
主回線・予備回線を固定する場合：fallbackを使い、interval: 180、ノードは業務上の優先順位で並べます。
大量の並列ダウンロード：load-balanceを使い、interval: 300、スループットが明らかに低いノードを先に除外します。

テストURLによっても結論は変わります。遠すぎる対象を選ぶと、主にノードから対象サイトまでの国際経路を測ることになります。一部のノードだけがアクセスできる対象では、正常なノードを誤って失敗と判定する可能性があります。安定した204サービスを汎用チェックに使い、特定のサービスは個別に検証するとよいでしょう。数分おきのヘルスチェックとして大容量ファイルをダウンロードするのは避けてください。通信量とサーバー帯域を継続的に消費します。

用途別の構成：普段使い・動画配信・ダウンロード

普段使い：url-testと手動選択を組み合わせる

普段のウェブ閲覧やメッセージングでは応答速度が重視されるため、url-testの自動グループを作り、selectで自動グループとよく使う単独ノードをまとめる構成が便利です。通常は自動測定の結果を使い、サイトのリスク判定や特定ノードの接続障害がある場合は、クライアントの「プロキシ」→「ノード選択」で出口を手動固定できます。

proxy-groups:
  - name: 自動選択
    type: url-test
    proxies:
      - 香港-01
      - 香港-02
      - シンガポール-01
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 80

  - name: 普段使いプロキシ
    type: select
    proxies:
      - 自動選択
      - 香港-01
      - シンガポール-01
      - DIRECT

動画配信：同一地域のfallback

サービスが利用できる地域でノードを絞り込んでから、同一地域のfallbackを作成します。主ノードには再生の安定性とピーク時のスループットを確認できた回線を置き、予備には同じ地域の別サーバーを置きます。ルールでは対象サービスのドメインまたは対応するルールセットをこのグループへ割り当てます。目的は204の遅延を最小化することではなく、地域を維持しながら主回線の障害時に切り替えることです。

マルチスレッドダウンロード：性能の近いload-balance

ダウンローダーが8または16本の並列接続を設定している場合に、負荷グループは異なる接続を複数のノードへ振り分けられます。ブラウザーの単一接続によるダウンロードや、1接続だけを確立するオブジェクトストレージへのリクエストは、通常1ノードの上限に制限されます。利用前に、契約サービスの通信ルールが並列接続を許可しているか、異なる出口から同じダウンロードURLへアクセスしても一時URLが無効にならないかも確認してください。

プロキシグループをルールに接続する

rules:
  - DOMAIN-SUFFIX,example-video.com,動画配信・主回線予備
  - DOMAIN-SUFFIX,example-download.com,並列ダウンロード
  - MATCH,普段使いプロキシ

ルールは上から順に照合され、マッチすると後続の検索を停止します。実際のサービスは複数のドメインを使うことが多く、トップページのドメインだけを追加すると動画の分割データ、画像CDN、ログインAPIを取りこぼす可能性があります。ルールセットを使う場合は、更新元と実際の内容を確認してください。変更後はクライアントの「接続」ページで、対象ドメインが最終的にどのルールにマッチし、どのプロキシグループを通ったかを確認すると、ブラウザーで開けたかどうかだけを見るより正確です。

よくある設定ミスと確認手順

すべてのノードがtimeoutになる

ブラウザーまたはコマンドラインで、テストURL自体にアクセスできることを確認します。
DNSが正常に解決できるか、ログにdns resolve failedが出ていないか確認します。
テストURLを別の安定した小容量レスポンスの対象へ変更し、遅延測定をやり直します。
ノード名がproxiesリストと完全に一致しているか確認します。スペース、大文字・小文字、記号も含めて一致させます。
サブスクリプション更新後にノード名が変更され、プロキシグループが古い名前を参照していないか確認します。

url-testが頻繁にノードを切り替える

まずtoleranceを0または10から50～100へ変更し、次にintervalを30秒から180～300秒へ延ばします。地域の異なるノードを混在させている場合は、地域ごとにグループを分けます。10回連続で測定し、中央値と変動幅を記録するのも有効です。平均遅延が低くても変動が100msを超えるノードは、90msで安定するノードよりデフォルト出口に適しているとは限りません。

fallbackが遅延最低のノードを選ばない

これは想定どおりの動作です。fallbackはリスト内で最初に利用可能なノードを選び、速度を比較しません。低遅延のノードを自動選択したい場合はurl-testに変更します。主ノードを固定し、障害時だけ切り替えたい場合は、fallbackを使ったままノードの順序を調整してください。

load-balanceを使ってもダウンロード速度が上がらない

まずダウンロードツールが本当に複数接続を確立しているか確認し、次にクライアントの「接続」ページで各接続の経路を確認します。接続が1本だけなら、速度上限は単一ノードに左右されます。接続数が多くても同じ対象へ向かう場合、一貫性ハッシュによって同じノードに固定される可能性があります。ラウンドロビンへ切り替える前に、ダウンロードサイトが出口IPの変化を許可しているか評価してください。接続が均等に分散されても、配信元の速度制限、ローカル回線、ノード側の共有帯域がボトルネックになることがあります。

最終判断：業務の目的を明確にしてからグループを選ぶ

「応答が速いノードを使いたい」ならurl-test、「主回線が使えないときだけ予備へ切り替えたい」ならfallback、「複数の並列接続を異なるノードへ分散したい」ならload-balanceを選びます。優劣が絶対に決まっているわけではなく、判断基準が用途に合っているかが重要です。

実用的な設定では、複数種類のグループを併用することがよくあります。普段使いのデフォルト出口にはurl-test、地域を固定したサービスにはfallback、並列ダウンロードには専用のload-balanceを使い、最上位にselectを置いて手動で上書きできるようにします。具体的なドメインからMATCHへ至るルール順と組み合わせれば、1つの自動グループにすべての用途を背負わせず、通信ごとに適切なグループへ振り分けられます。