Clashのプロキシグループ選び方｜url-test・fallback・load-balanceの設定と使い分け

自動プロキシグループ3種類：まず選択基準を決める

Clashのプロキシグループは新しいプロキシサーバーではなく、既存のノードを選択するための設定レイヤーです。ルールがリクエストの振り分け先となるグループを決め、そのグループが使用するノードを選びます。自動グループを設定しただけで、すべての通信がそこを通るわけではありません。ルールまたは上位の選択グループから参照された場合に限り、該当するリクエストに自動選択が適用されます。

3種類ともヘルスチェックと組み合わせられますが、選択基準はそれぞれ異なります。url-testは応答遅延、fallbackは優先順位、load-balanceは接続の振り分けを重視します。普段のブラウジングなら前者2つを優先し、複数の出口に接続を振り分ける必要がある場合に限ってロードバランシングを検討しましょう。

グループの種類	選択基準	向いている用途	主な注意点
url-test	応答遅延と切り替え許容幅	同種のノードから遅延の小さい出口を自動選択	低遅延でもダウンロードが速いとは限らない
fallback	リスト内で最初に正常と判定されたノード	主回線を優先し、障害時に予備回線へ切り替え	予備回線のほうが速くても自動では選ばれない
load-balance	ハッシュやラウンドロビンなどの振り分け方式	複数の接続を別々の利用可能なノードへ振り分け	1つの接続の帯域幅は合算されない

url・interval・lazy：ヘルスチェックの動作

urlはチェック先であり、サブスクリプションURLではない

urlにはヘルスチェックでアクセスするURLを指定します。コアは候補ノードを経由してHTTPリクエストを送り、成功したかどうかと所要時間を記録します。サブスクリプションのダウンロードURLでも、大容量ファイルを使った速度測定用URLでもありません。例ではよく使われる軽量なチェック先としてhttps://www.gstatic.com/generate_204を使用していますが、適切かどうかは回線と接続先のネットワークによります。

公平に比較するため、同じグループでは同一のチェック先を使いましょう。チェック先への接続が速くても、動画サイトや業務システムへの接続が速いとは限りません。逆に、チェック先のドメインが制限されていると、利用可能な回線でも異常と判定されることがあります。問題を調べる際は、「チェックに失敗した」のか「実際のサービスに接続できない」のかを分けて確認してください。

intervalの単位は秒（ミリ秒ではない）

interval: 300は、300秒、つまり5分間隔でチェックを行う設定です。各リクエストのタイムアウト時間ではなく、障害が必ず300秒以内にすべてのアプリで検知されるという意味でもありません。遅延チェックの設定、実行タイミング、チェックにかかる時間、既存の接続状態によって実際の動作は変わります。

普段のブラウジングでは、まず300秒に設定し、しばらく様子を見てから調整してください。
主回線の障害をより早く検知したい場合は、チェック回数が増えることを考慮したうえで60秒を検討できます。
ノードが20個あり、60秒ごとに全件をチェックすると、理論上は1時間あたり約1,200回のチェックが発生します。300秒ごとなら約240回です。実際の回数は遅延チェックなどの仕組みによって変わります。

lazyは未使用グループの定期チェックを制御する

この項目に対応するコアでは、lazy: trueにすると未使用のプロキシグループのチェック負荷を抑えられます。lazy: falseでは、未使用のグループも定期的にチェックします。予備グループが選択されていない間も、直近のヘルスチェック結果を保ちたい場合は遅延チェックを無効にできますが、ノードや自動グループが多い場合は負荷の増加に注意してください。一度失敗した通信を自動で再試行する機能ではありません。

url-test：遅延の小さいノードを自動選択し、toleranceで切り替えを調整

url-testは候補ノードをチェックし、その結果に基づいてノードを自動選択します。用途が近く、出口が変わっても問題ない場面、たとえば同じ地域の一般的なブラウジング用回線に適しています。候補ノード間で地域、アカウントのリスク判定、利用できるサービスが大きく異なる場合は、遅延だけで比較しても適切な選択にならないことがあります。

proxy-groups:
  - name: 低遅延自動選択
    type: url-test
    proxies:
      - 香港回線 A
      - 香港回線 B
      - 日本回線 A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

ここに記載した3つのノード名は、設定内のproxiesに存在し、表記が完全に一致している必要があります。これはプロキシグループ部分だけの例で、サーバーアドレス、認証情報、完全なルールは含まれていません。単体で接続可能なサブスクリプションとしては使えません。

toleranceの単位はミリ秒

tolerance: 50は切り替えの許容幅を50ミリ秒に設定し、わずかな遅延の変動による頻繁なノード切り替えを抑えます。たとえば現在のノードが120ミリ秒、別のノードが100ミリ秒なら、差はわずか20ミリ秒なので、通常はその差だけを理由に切り替える必要はありません。別のノードが60ミリ秒まで下がり、60ミリ秒の改善が見られれば、切り替え条件を満たす可能性があります。数値は説明用の例であり、本サイトで計測した結果ではありません。

許容幅は遅延の上限でも、障害と判定するしきい値でもありません。50と設定しても、遅延が50ミリ秒を超えるノードがすべて除外されるわけではありません。現在のノードが利用できない場合、大きな許容幅を設定してもそのノードを維持できるとは限りません。比較の詳細や初回選択時の動作は、使用しているコアの実装を確認してください。

切り替えが頻繁に起きる：まずノードが繰り返しタイムアウトしていないか確認し、そのうえで許容幅を少し広げることを検討します。
速度測定は速いのにダウンロードが遅い：実際の用途に合わせて別途テストし、スループット、パケットロス、回線の混雑を確認します。
アカウントで接続地域が固定されている：候補ノードを該当地域に絞るか、手動選択に切り替え、異なる地域のノードを混在させないようにします。

fallback：主回線を優先し、障害時に予備へ切り替える

fallbackはproxiesリストの順に利用可能なノードを探します。先頭のノードが正常なら、後続ノードの遅延がより小さくても優先されません。「主回線の出口を安定して使い、予備回線は障害時だけ使う」用途に向いており、「常に最速の回線を選ぶ」方式ではありません。

proxy-groups:
  - name: 主回線・予備回線
    type: fallback
    proxies:
      - 香港回線 A
      - 日本回線 A
      - シンガポール回線 A
    url: https://www.gstatic.com/generate_204
    interval: 60
    lazy: false

この順序では、まず香港回線 Aを使用し、ヘルスチェックに失敗した場合に日本回線 Aを検討します。先頭2つがどちらも利用できなければ、シンガポール回線 Aを使用します。その後のチェックで優先順位の高いノードの復旧が確認されると、新しい接続は再び優先順位の高い利用可能なノードを使います。そのため、主ノードの復旧と障害が繰り返されると、出口が頻繁に切り替わることがあります。

障害時の切り替えで既存の接続が移行するわけではない

動画の再生、SSHセッション、大容量ファイルのダウンロードなどでは、通常すでに接続が確立されています。プロキシグループでノードを切り替えても、既存のTCP接続を別のサーバーへシームレスに移すことはできません。古い接続は切断される可能性があり、アプリ側で再接続が必要です。新しい接続から切り替え後のノードが使われます。音声・ビデオ通話やリモート端末では、予備回線によって復旧までの時間を短縮できますが、通信が途切れないことを保証するものではありません。

load-balance：接続を振り分ける機能であり、帯域幅の合算ではない

load-balanceは利用可能なノード間で通信を振り分けます。複数の接続を別々の出口に分散できるのが主な利点であり、1つのダウンロード接続で2回線分の速度が得られるわけではありません。アプリが並列ダウンロードに対応していても、効果はサーバーの制限、振り分け方式、回線速度、アプリの動作によって異なります。

proxy-groups:
  - name: 複数回線の振り分け
    type: load-balance
    proxies:
      - 香港回線 A
      - 香港回線 B
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

consistent-hashing：同じ種類の宛先で出口を安定させる

mihomoのconsistent-hashingは通常、宛先ドメインの登録可能ドメイン部分を使って一貫性ハッシュを行います。ドメイン名が利用できない場合は、宛先IPが使われることがあります。同じ宛先を同じノードに割り当てやすくする方式ですが、「アカウントごとに出口が永久に固定される」わけではありません。利用可能なノードの変化、宛先ドメインの変更、その他の振り分け条件の変化によって結果が変わることがあります。

1つのWebページでも、ログイン、API、画像、静的ファイルなど、複数のドメインへアクセスすることがよくあります。そのため、「同じWebサイトを開く」からといって、すべてのリクエストが同じ出口を通るとは限りません。ログインセッション、決済、地域に依存するサービスでは、関連ドメインのルールを固定ノードまたは管理された専用グループに割り当てる方法がより確実です。

round-robin：新しい接続を順番に振り分ける

この方式に対応するコアでは、strategyをround-robinにすると、利用可能な候補へ新しい接続を順番に割り当てます。パケットごとに交互に送信する方式ではなく、転送データ量が均等になる保証もありません。1つの接続で2 GB、別の接続で2 KBを転送することもあるため、接続数が近くても通信量が均等とは限りません。

旧バージョンのClashコアでは、strategyの対応範囲が異なる場合があります。mihomoのすべての戦略値を、開発終了したクライアントにそのままコピーしないでください。項目が認識されない、または想定と異なる動作をする場合は、まずコアの名前とバージョンを確認し、該当するドキュメントを参照してください。画面上で設定を保存できたことだけで、項目が有効になったと判断しないでください。

自動グループをルールに組み込む：selectグループから参照する

proxy-groupsを追加しただけでは、既存のルールは自動で置き換わりません。上位に手動選択用のselectグループを作り、3種類の自動グループを選択肢に追加して、プロキシを使うルールからそのグループを参照する方法が便利です。毎回ルールを書き換えなくても、画面から方式を切り替えられます。

proxy-groups:
  - name: プロキシ入口
    type: select
    proxies:
      - 低遅延自動選択
      - 主回線・予備回線
      - 複数回線の振り分け
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,プロキシ入口
  - MATCH,DIRECT

これも設定の一部分なので、前述の自動グループと同じ設定ファイルにまとめてください。example.comはルール構文の説明用ドメインであり、速度測定用サイトではありません。このルールはexample.comとそのサブドメインだけを「プロキシ入口」に割り当て、残りのリクエストは最後のMATCH,DIRECTで直接接続します。この例を普段の通信全体に適用できる完全な振り分けルールと誤解しないでください。

元のサブスクリプション設定を残したまま、テスト用コピーにプロキシグループを追加してください。サブスクリプション更新で変更が失われるのを防げます。
すべてのノード名、プロキシグループ名、ルールからの参照を確認してください。大文字・小文字、空白、日本語を含む文字列も完全に一致させる必要があります。
設定全体で、トップレベルのproxy-groupsとrulesはそれぞれ1つだけにしてください。リスト項目を既存のリストに追加し、トップレベルのキーを重複して貼り付けないでください。
Clash for WindowsのProfilesでテスト用設定を選び、次にProxiesでRuleモードにして、「プロキシ入口」を展開し、テストする自動グループを選択します。
Globalモードでは通信がグローバル設定に従うため、既存ルールからの参照先は適用されません。Directモードでも、自動グループによる普段のルール振り分けは確認できません。

変更を長期間維持するには、利用中のクライアントが対応するオーバーライド、Mixin、設定マージ機能を使い、最終的に生成された実行設定を確認してください。クライアントによって配列を置き換えるか結合するかが異なるため、数行追加するだけでサブスクリプション内のすべてのグループが維持されるとは限りません。

自動プロキシグループが動作しない場合：4つの手順で確認

手順1：設定がコアに読み込まれているか確認する

Logsを確認し、YAMLの解析エラー、ノードが見つからないエラー、未対応の戦略値がないか調べます。YAMLのインデントにはスペースを使い、Tabは使わないでください。proxies内の各リスト項目の位置を揃えます。ノード名にコロンと空白などの特殊な組み合わせが含まれる場合は、名前全体を引用符で囲むと安全です。

手順2：ノードとチェック先を分けてテストする

まずノードを1つ手動で選択し、実際の接続先にアクセスしてから、グループ内の遅延テストを実行します。特定のチェック先だけに失敗する場合は、すべてのノードをすぐに削除せず、そのURLへの到達性とHTTPS接続を確認してください。ノード自体に接続できない場合、toleranceの調整や負荷分散方式の変更では、認証、サーバー、ネットワークの問題は解決できません。

手順3：リクエストが実際に使ったルールを確認する

Connectionsで新しいリクエストのルールとプロキシチェーンを確認し、目的のグループを通っているか確かめます。より上位の直接接続ルールに一致している場合や、アプリがクライアントを経由していない場合、自動グループは機能しません。ブラウザーではプロキシが使えるのに他のアプリでは使えない場合は、システムプロキシ、アプリ固有のプロキシ設定、TUNの対象範囲も確認してください。プロキシグループだけでは、通信をクライアントへ取り込む設定の代わりになりません。

手順4：新しい接続で変更を確認する

グループを切り替えるかチェックの完了を待ってから、新しいリクエストを発行してください。古い接続を見続けないようにします。fallbackのテストでは、管理された環境で主ノードを一時的に接続不能にし、チェック時刻、最初に失敗した時刻、復旧時刻を記録します。url-testでは複数回の遅延結果を記録し、1回の測定だけで比較しないでください。load-balanceでは、既存の接続を再利用する可能性があるページを1つ更新するだけでなく、複数の接続でプロキシチェーンを確認します。

普段のブラウジング：同じ地域のノードにurl-testを組み合わせ、まず300秒間隔・50ミリ秒の許容幅から試します。
主回線を固定：fallbackを使い、用途の優先順位に沿って並べ、主回線の復旧後の動作も確認します。
複数接続を使う作業：出口の変化が許容できることを確認してからload-balanceを使い、ハッシュとラウンドロビンをそれぞれ検証します。
セッションの安定性が重要：ノードを固定するか専用の選択グループを使い、出口の安定性を遅延の自動比較だけに任せないようにします。

プロキシグループ選びで重要なのは、どれが「高機能」かではなく、遅延、主回線・予備回線の優先順位、接続の振り分けのうち何を改善したいかです。まず候補ノードを絞り、チェック設定を調整してから実際の用途で検証しましょう。チェック間隔を短くし続けるより効果的です。