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

1. まず確認：最小遅延・優先順位・接続の振り分け

3種類のプロキシグループはいずれも複数のプロキシノードを登録できますが、用途はそれぞれ異なります。url-testはプローブで計測した遅延をもとに自動選択し、fallbackはリスト順に利用可能なノードを選択します。load-balanceは振り分けアルゴリズムに従い、複数の利用可能なノードへ接続を割り当てます。選ぶ前に、自動で最適なノードを選びたいのか、主系・予備系を切り替えたいのか、接続を分散したいのかを決めましょう。

種類	選択基準	用途	注意点
`url-test`	ヘルスチェックで計測した遅延	日常的なブラウジング、低遅延ノードの自動選択	プローブの応答が速くても、ダウンロード帯域が大きいとは限らない
`fallback`	ノードの並び順と利用可能な状態	メイン回線を固定し、障害時に予備回線へ切り替える	予備ノードのほうが速くても、自動的には切り替わらない
`load-balance`	接続の振り分け方式と利用可能な状態	複数ノードで宛先や接続を分散する	1つの接続の帯域が合算されるわけではない

この記事の設定例は、mihomoカーネルを使用するクライアントを前提としています。旧バージョンのClashや各種フォークでは、拡張フィールド、特に負荷分散アルゴリズムへの対応状況が異なる場合があります。クライアントの「バージョン情報」またはカーネル情報でカーネル名を確認し、設定を保存したら読み込み結果も確認してください。クライアント名だけで互換性を判断しないようにしましょう。

2. url-test：プローブ遅延で選択し、toleranceで頻繁な切り替えを抑える

url-testは、出口を固定する必要のない日常的な通信に適しています。カーネルが候補ノードごとにテストURLへアクセスして結果を記録し、利用可能かどうか、遅延、切り替えの許容差をもとに接続先を選びます。測定するのは特定のHTTPリクエストにかかった時間であり、ICMP pingや継続的なダウンロード速度ではありません。

基本設定：300秒間隔でプローブ、許容差は50ミリ秒

以下の設定例は既存の設定に追加して使います。例にある「香港 01」「香港 02」「日本 01」は、proxiesに登録済みで、ノード名と完全に一致している必要があります。サブスクリプションのノードプールを使う場合のuseの設定例は後述します。

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

interval: 300：定期プローブの間隔は300秒、つまり5分です。300ミリ秒ではありません。
tolerance: 50：切り替えの許容差は50ミリ秒です。遅延がわずかに変動しただけでノードが頻繁に切り替わるのを防ぎます。
lazy: false：遅延プローブを無効にし、使用中でないグループも定期的にヘルスチェックを更新します。その分、プローブのリクエスト数は増えます。

たとえば、現在のノードの計測遅延が110ミリ秒、別のノードが95ミリ秒なら、差はわずか15ミリ秒です。許容差を50ミリ秒に設定した場合、この差だけで必ず切り替わるとは限りません。候補ノードが45ミリ秒なら改善幅は65ミリ秒となり、切り替えの条件を満たしやすくなります。ここでの数値はパラメーターを説明するための例で、実際の回線計測値ではありません。結果はプローブのタイミング、現在のノードの状態、カーネルの実装にも左右されます。

遅延が最小なのに、動画が止まるのはなぜ？

小さなプローブリクエストの結果は、混雑時の通信速度を示すものではありません。テストURLへの応答が速いノードでも、動画サービス側で速度が制限されていたり、接続先までの経路が混雑していたりすることがあります。その場合は、実際の利用状況と接続ログをあわせて確認しましょう。帯域を増やすためにintervalを300から5に変更し、頻繁な速度測定に頼るのは適切ではありません。

低遅延ノードが2つの地域間で頻繁に切り替わると、ログイン先のサイトから見た出口も変わる可能性があります。toleranceを適度に大きくするか、同じ地域のノードを専用グループにまとめるとよいでしょう。出口を長期間固定する必要がある場合は、手動選択または明示的な主系・予備系の構成が適しています。

3. fallback：ノードの順序で主系・予備系を設定

fallbackではリストの順序が重要です。先頭の利用可能なノードが最優先で使われ、利用できない場合にのみ次の候補が試されます。ヘルスチェックでメインノードの復旧が確認されると、その後の選択で優先順位の高いノードに戻ることがあります。そのため、一度予備に切り替わったら戻らない、という動作ではありません。

proxy-groups:
  - name: 主系・予備系回線
    type: fallback
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 60
    lazy: false

この例では、「香港 01」の遅延が180ミリ秒、「香港 02」が60ミリ秒でも、前者が利用可能と判定されていれば「香港 01」が優先されます。そのため、遅くても安定している回線を先頭に置くのは有効な主系・予備系の設定であり、速度測定の不具合ではありません。

切り替えにかかる時間は常に60秒とは限らない

interval: 60で指定するのは定期プローブの間隔であり、障害からの復旧時間を保証するものではありません。2回のプローブの間に障害が発生した場合、次のチェックまで待つことがあり、1回のチェック自体にも時間がかかります。接続失敗をきっかけに実行される追加チェックや関連パラメーターの挙動も、カーネルのバージョンや設定によって異なります。

業務で優先して使うノードを先頭に置き、速度測定の結果だけを見てリストの順序を変更しないでください。
主系と予備系では、できるだけ同じ障害点を共有しない回線を選びましょう。共通の上流回線で障害が起きると、すべての候補が同時に利用できなくなる可能性があります。
メインノードに障害が発生すると、既存のTCP接続が切断され、アプリ側で再接続が必要になる場合があります。プロキシグループが既存の接続を別ノードへ移すことはありません。

4. load-balance：接続を振り分ける。1つの接続の速度は合算されない

load-balanceは利用可能な候補から接続先を選びますが、1つのTCP接続を複数のプロキシノードに分割するわけではありません。シングルスレッドのダウンロードは通常、1つの出口で処理されます。複数接続を使うダウンロードでは異なるノードが使われる場合もありますが、ダウンローダー、サーバー、コネクションの再利用、振り分けアルゴリズムにも左右されるため、合計速度が何倍にもなるとは限りません。

consistent-hashing：同じ宛先に同じ出口を割り当てやすくする

proxy-groups:
  - name: 複数回線で分散
    type: load-balance
    proxies:
      - 香港 01
      - 香港 02
      - 日本 01
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

consistent-hashingは宛先アドレスをもとに一貫性ハッシュで振り分け、同じ宛先にはできるだけ同じノードを割り当てます。利用可能なノードの構成が変わると、割り当ても変わる場合があります。異なる宛先へのアクセスを分散する用途に適していますが、ブラウザー全体の出口が常に1つに固定されるわけではありません。同じページでも、ログイン、画像、APIなど複数のドメインに接続する場合があります。

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

上の例のstrategyをround-robinに変更すると、接続をラウンドロビン方式で振り分けます。ラウンドロビンはデータ量を均等に分ける方式ではなく、残りの通信量に応じて自動調整するものでもありません。長時間続くダウンロード接続と、すぐに終了するWebページの接続では、通信量に大きな差が出ることがあります。

ログイン、決済、または出口の変化に敏感なサービスには、固定ノードまたは専用の安定したプロキシグループを優先してください。既存のHTTP/2長時間接続では多数のリクエストが処理されることがあるため、ページを何度か再読み込みしただけでラウンドロビンが機能していないと判断することもできません。接続一覧で新しく作成された接続の実際のノードを確認しましょう。

5. interval・toleranceとノードプール：設定時の注意点

項目	意味	設定の目安
`url`	ヘルスチェック用のHTTPテストURL	安定していて応答データの小さいURLを選び、グループ間の比較では同じURLを使う
`interval`	プローブ間隔（秒）	日常利用では300秒から始め、主系・予備系の要件に応じて短くする
`tolerance`	`url-test`の切り替え許容差（ミリ秒）	50ミリ秒から試す。主系・予備系の優先順位を決める設定ではない
`lazy`	グループが未使用の間、定期プローブを行わないかどうか	予備グループの状態を継続的に更新する場合は、明示的にfalseを設定する
`strategy`	`load-balance`の振り分けアルゴリズム	一貫性ハッシュまたはラウンドロビンを明示的に選び、速度測定の許容差と混同しない

proxiesとuseを混同しない

proxiesにはノードまたは別のプロキシグループの名前を指定します。useにはproxy-providersで定義したノードプロバイダーを指定します。既存の設定に「サブスクリプションノードプール」というプロバイダーが定義されている場合、自動グループから次のように利用できます。

proxy-groups:
  - name: サブスクリプション自動選択
    type: url-test
    use:
      - サブスクリプションノードプール
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

これは単独で動作する完全な設定ではありません。「サブスクリプションノードプール」が実際に定義されていることが前提です。プロバイダーのintervalはノード情報の更新間隔、プロバイダー内のhealth-check.intervalはヘルスチェックの間隔、グループ内のintervalはプロキシグループのプローブ間隔を指定します。同じ名前のフィールドでも階層が異なり、相互に置き換えることはできません。

ノード数によっても負荷は変わります。候補が30個あるグループで、300秒ごとに全候補を1回ずつプローブすると、1時間あたりのプローブリクエストは約360回です。実際の回数は遅延プローブの動作や追加チェックなどにも左右されます。間隔を30秒に短縮するとリクエスト数は大幅に増えますが、普段の使い勝手が改善するとは限りません。

6. ルールとクライアントを設定する：まずグループ、次に通信を確認

プロキシグループを作成したら、ルールから参照するか、上位の手動選択グループに追加する必要があります。以下の組み合わせで3種類の動作を比較できます。既存設定に統合する場合は、各グループを同じproxy-groupsリストに追加してください。YAMLの最上位に同じキーを複数回記述しないようにしましょう。

proxy-groups:
  - name: プロキシ出口
    type: select
    proxies:
      - 低遅延自動選択
      - 主系・予備系回線
      - 複数回線で分散
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,プロキシ出口
  - MATCH,プロキシ出口

この設定例は、前述の3つの自動グループがすでに定義されていることを前提としています。グループ間の参照関係を示すもので、日本国内と海外を振り分けるルールではありません。最後のMATCHは、それ以前のルールに一致しなかったリクエストを「プロキシ出口」に渡します。既存のルールは実際の用途に合わせて残し、テストのために元の直接接続ルールをすべて上書きしないでください。

設定をバックアップする。まず現在の設定をエクスポートしてください。リモートのサブスクリプションを更新すると直接編集した内容が上書きされる場合があります。変更を保持するには、クライアントが対応する上書き、マージ、または拡張設定機能を利用してください。
設定を読み込む。ログに不明なグループ名やノード名、YAMLのインデントエラーが表示されていないか確認します。インデントにはスペースを使い、タブは使用しないでください。
ルールモードに切り替える。クライアントが「ルール」モードになっていることを確認してください。「グローバル」モードでは、ルール一覧を使って通信の振り分けを検証できません。
上位グループを選択する。「プロキシ」画面で「プロキシ出口」を開き、3種類の自動グループをそれぞれ選んでから、クライアントの「速度テスト」または「遅延テスト」を実行します。ボタン名はクライアントによって異なります。
接続を確認する。「接続」画面を開き、リクエストに適用されたルール、プロキシグループの経路、最終的なノードを確認してください。手動の速度テストはその時点でのテストであり、定期ヘルスチェックの動作を一通り確認するものではありません。

主系・予備系を検証するには、設定をバックアップしたうえでテスト用設定から優先ノードを一時的に外し、再読み込み後に次の候補へ切り替わるか確認します。出口の切り替えを検証する際は、新しい通信を開始してください。ブラウザーが接続プール内の既存接続を再利用するのを避けられます。TUNモードで通信を取り込めない場合は、トラブルシューティングガイドも参照し、まず通信が実際にカーネルを通っていることを確認してください。

7. 利用シーンに合わせて選ぶ

日常のブラウジングや一般的なアプリ：まずはurl-testを選び、間隔300秒・許容差50ミリ秒を調整の出発点にして、実際の変動に応じて設定を見直します。
優先して使う回線が決まっている：fallbackを選び、候補の順序を慎重に設定します。予備回線の遅延が低くても、優先順位は変わりません。
複数の回線で異なるアクセスを分散する：load-balanceを選び、まずconsistent-hashingを検討します。ラウンドロビンが必要な場合に限り、round-robinを使いましょう。
アカウントの出口を安定させたい：手動選択グループとドメインルールを個別に設定し、頻繁に切り替わる自動グループに該当する通信を混在させないでください。

最終的には、「実際のリクエストにどのルールが適用され、どのノードが使われたか」を確認することが重要です。遅延の数値、グループ名に「自動」とあること、システムプロキシのオン・オフだけでは確認の代わりになりません。まず少数の候補で動作を検証し、その後ノードプールを広げると、プローブ間隔、DNS、TUN設定を一度に変更するより問題を特定しやすくなります。