Clashのプロキシグループ設定ガイド｜url-test・fallback・load-balance

用途に合ったプロキシグループを選ぶ

手動でノードを選ぶなら select、遅延の小さいノードを自動選択するなら url-test、特定ノードを優先し、障害時だけ予備に切り替えるなら fallback、複数ノードに接続を振り分けるなら load-balance を使います。それぞれ目的が異なるため、「自動」という名前だけで選ばないようにしましょう。

プロキシグループは、ノードや別のプロキシグループをまとめたものです。ルールが接続を振り分けるグループを決め、そのグループが実際の出口を選びます。たとえば MATCH,出口選択 は、前のルールに一致しなかった接続を「出口選択」に渡します。これは速度測定のコマンドではなく、すべてのルールを自動的にこのグループへ切り替えるものでもありません。

種類	選択基準	向いている用途	注意点
`select`	ユーザーが手動で選択	接続先の地域を固定したい、手動でトラブルを切り分けたい	通常の手動選択では、ノードに障害が起きても自動で切り替わらない
`url-test`	測定結果と遅延差	日常的に遅延の小さい出口を自動選択したい	測定遅延はダウンロード速度を示すものではない
`fallback`	リストの順序と利用可能な状態	メイン回線と予備回線を使い分ける	予備回線のほうが速くても、選ばれるとは限らない
`load-balance`	振り分けアルゴリズムと利用可能な状態	異なる接続を複数の出口に分散する	1つのダウンロード接続の帯域幅が合算されるわけではない

設定前にカーネルとノード名を確認

クライアントは画面を提供し、設定を実行するのはカーネルです。ボタンの見た目が似ていても、クライアントによって搭載カーネルは異なる場合があります。まずクライアントの「バージョン情報」やカーネル情報で、Clash互換カーネルとmihomoのどちらを使っているか確認し、該当バージョンの設定仕様を参照してください。以下では一般的なClashのプロキシグループ項目を使い、負荷分散の例ではmihomo対応の consistent-hashing を指定します。

現在の設定ファイルと、クライアントが個別に保存しているオーバーライド設定をバックアップします。オーバーライドとは、サブスクリプションの元設定に項目を追加・変更する仕組みです。
既存の proxies に利用可能なノードがあることを確認し、名前を完全な形でコピーします。空白・大文字小文字・記号も一致させてください。
ノードが proxy-providers から提供される場合は、グループ内の use で該当プロバイダーを参照します。プロバイダー名をノードとして proxies に記述しないでください。
クライアントのローカル設定またはオーバーライド設定の場所を確認します。サブスクリプションからダウンロードしたファイルを直接編集すると、次回更新時に上書きされることがあります。

select：入口を1つにまとめて手動で切り替える

select 自体は遅延を比較しません。候補を画面に表示し、ユーザーが選択します。候補には実際のノードだけでなく、自動測定グループやフェイルオーバーグループなど、別のグループも指定できます。そのため、外側に手動選択、内側に自動選択を置く構成が実用的です。

proxy-groups:
  - name: 出口選択
    type: select
    proxies:
      - 自動測定
      - フェイルオーバー
      - 接続分散
      - 香港メイン
      - 日本予備
      - シンガポール予備

このコードは後述する3つのサブグループを参照します。実際に使うときは、4つのグループの項目を1つのトップレベル proxy-groups にまとめてください。1つのYAMLファイルに同じトップレベルキーを何度も追加してはいけません。重複キーは解析エラーの原因になったり、先に記述した設定が後の設定で上書きされたりすることがあります。

初回読み込み時は通常リストの先頭が使われますが、クライアントが前回の選択を復元する場合もあります。リストの順序を変更した後は、プロキシグループ画面で現在の選択を確認してください。トラブルの切り分けでは、実際のノードを一時的に選び、サブグループの入れ子による影響を除外できます。

url-test：自動測定とtoleranceの役割

url-test は候補ノードから指定したテストURLへ接続し、測定結果に基づいて出口を選びます。比較するのはテストURLへのリクエスト時間であり、すべてのWebサイトでの総合的な性能ではありません。テストURLへの応答が速いノードでも、動画サイトやゲームサーバー、大容量ファイルのダウンロードでは性能が伸びないことがあります。

  - name: 自動測定
    type: url-test
    proxies:
      - 香港メイン
      - 日本予備
      - シンガポール予備
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

intervalは秒、toleranceはミリ秒

interval: 300：測定間隔を300秒（5分）に設定します。300ミリ秒ごとにノードを切り替える設定ではありません。
tolerance: 50：自動選択に50ミリ秒の切り替え幅を設け、ノード間の遅延差がわずかな場合に頻繁に切り替わるのを防ぎます。
lazy: false：グループが最近使われたかどうかにかかわらず、定期測定を行います。アイドル時の通信が増えるため、スマートフォンでは必要に応じて true に変更してください。

切り替え幅を仮の数値で見てみましょう。現在のノードが120ミリ秒、別のノードが100ミリ秒なら差は20ミリ秒です。toleranceを50ミリ秒に設定している場合、通常は現在のノードが維持されます。別のノードが60ミリ秒まで下がり、差が60ミリ秒になると、切り替わる可能性があります。これは仕組みを示す例であり、実回線の測定値や性能を保証するものではありません。実際の選択は、測定の成否や過去の状態、カーネルの実装にも左右されます。

toleranceはタイムアウト時間ではありません。現在のノードの測定に失敗したとき、「さらに50ミリ秒待ってから切り替える」という意味ではありません。スマートフォンでは、まずintervalを300秒、toleranceを50ミリ秒にして様子を見るとよいでしょう。間隔を5秒まで短くすると測定回数は大幅に増えますが、通信の安定性が保証されるわけではありません。

fallback：優先順位に沿って障害時に切り替える

fallback はリストの順に利用可能なノードを探します。最速のノードを常に選ぶのではなく、優先回線を維持するのが目的です。以下の設定では、まず「香港メイン」を試し、利用不可と判定された場合にのみ「日本予備」、さらにその次に「シンガポール予備」を検討します。

  - name: フェイルオーバー
    type: fallback
    proxies:
      - 香港メイン
      - 日本予備
      - シンガポール予備
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

メイン回線の測定遅延が180ミリ秒、予備回線が80ミリ秒だとしても、メイン回線が利用可能と判定されている間は通常そちらを使います。後続の測定でメイン回線の復旧が確認されると、グループは再びメイン回線を優先します。そのため、接続先の地域を固定したい場合や、ログイン環境の変化に敏感なサービスを使う場合は、遅延の最小化を追求するよりフェイルオーバーのほうが管理しやすいことがあります。

また、「テストURLに接続できた」ことが示すのは、その測定に成功したという点だけです。テストURLに接続できても、目的のサービスに接続できないノードが利用可能と判定される場合があります。その場合は測定間隔を短くするのではなく、対象サービスの地域制限、DNS解決、ルールの一致状況を確認してください。

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

load-balance はアルゴリズムに従って、異なる接続を候補ノードに振り分けます。以下では consistent-hashing（コンシステントハッシュ）を使い、接続先の情報をもとに、同じ種類の宛先ができるだけ安定した出口を使うようにします。mihomoでは通常、接続先ドメインの登録可能な親ドメインなどをもとに振り分けます。詳細は実際に使用するカーネルのバージョンを確認してください。

  - name: 接続分散
    type: load-balance
    proxies:
      - 香港メイン
      - 日本予備
      - シンガポール予備
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

よく使われる別の方式に round-robin（ラウンドロビン）があります。新しい接続の出口を順番に選ぶ方式で、確立済みの接続をデータの送信ごとに別のノードへ切り替えるものではありません。ログイン状態を保ちたいWebサイトでは、複数の接続が異なる地域の出口から送信されると追加認証が求められることがあります。すべての通信に一律で適用するのは避けましょう。

1つのファイルを1本のTCP接続でダウンロードする場合、グループ内にノードが3つあっても速度が自動的に3倍になるわけではありません。
複数の独立したダウンロードや異なる宛先への接続は、別々のノードに振り分けられる可能性があります。ただし、転送データ量が均等になるとは限りません。
複数のノードが最終的に同じ帯域制限のある上位回線を共有している場合、接続を分散してもその回線のボトルネックは解消できません。
UDPを正常に利用できるかは、実際のノードのプロトコルやサーバーの機能、通信の取り込み方式にも左右されます。グループの種類だけでは判断できません。

ルールからプロキシグループを利用する

プロキシグループを定義しただけでは不十分で、接続を振り分けるルールも必要です。以下は既存のルール体系における配置を説明するための2つの例です。ドメインの example.com は振り分け例であり、特定のサービスに必要な設定を示すものではありません。

rules:
  - DOMAIN-SUFFIX,example.com,フェイルオーバー
  - MATCH,出口選択

ルールは上から順に評価され、一致すると通常は以降のルールを調べません。個別ドメインのルールは最後の MATCH より前に置いてください。既存の設定にルールセット、LANへの直接接続、地域別の振り分けが含まれている場合は残し、変更が必要な振り分け先だけを調整します。グループを試すためにルール全体を上の2行だけに縮めないでください。

クライアントがルールモードで動作していることも確認してください。グローバルモードでは全体設定が使われ、ダイレクトモードでは前述のルールによるプロキシ出口の選択が行われません。AndroidでVpnServiceを使って通信を取り込む場合も、デスクトップでTUNを有効にする場合も、4種類のグループの基本的な経路選択は変わりません。TUNは通信を取り込む方式であり、5つ目の速度測定アルゴリズムではありません。

設定の読み込み・検証とトラブルシューティング

まず構文を確認。 YAMLのインデントにはスペースを使い、タブは使いません。4つのグループを同じ proxy-groups リスト内に記述し、グループ名が重複していないことを確認します。
設定を再読み込み。 クライアントの設定画面で変更後の設定を有効にし、ノードが見つからない、グループ参照が無効、非対応の項目があるといったエラーが表示されないか確認してください。
手動で一度テスト。 プロキシグループ画面から遅延測定を実行し、3つのノードそれぞれに結果が出るか確認します。画面に表示されているのがグループの測定結果か、サブスクリプションプロバイダー側の別のヘルスチェック結果かにも注意してください。
ルールの一致先を確認。接続ログを開き、接続先ドメイン、一致したルール、最終的に使われたノードを確認します。「出口選択」が選ばれていることだけでは、実際にどのサブグループのノードが使われたかは分かりません。
元に戻せる方法で障害をテスト。テスト用の設定から一時的にメイン回線を外し、再読み込みして新しい接続を作り、予備回線が動作するか確認します。テスト後は元の設定に戻してください。障害を再現するために本番サーバー側の設定を変更しないでください。

設定を更新するとプロキシグループが元に戻る

まず、サブスクリプションの更新でローカルの変更が上書きされていないか確認します。独自のプロキシ設定は、クライアントが対応するオーバーライド機能やマージ機能に追加し、その方式が追記・置換・スクリプト処理のどれか確認してください。同名グループの扱いはクライアントによって異なります。「保存しました」という表示だけで正しい設定になったと判断せず、実際に動作している設定を確認しましょう。

遅延は正常なのにWebページを開けない

まず select で利用可能と分かっているノードを固定し、接続ログを確認してください。対象ドメインが誤って直接接続に振り分けられている場合、プロキシグループの測定設定を変更しても解決しません。テストURLには接続できるのにサービスが使えない場合は、DNS、サービスの地域制限、プロトコルへの対応状況を調べてください。Wi-Fiとモバイル回線を切り替えた後は、改めて測定しましょう。以前の結果が新しいネットワークの状態を示すとは限りません。

複数グループの同時測定でスマートフォンの電池消費が増える

3つの自動グループにそれぞれ3ノードを設定し、各グループが300秒間隔で個別に測定すると、1回あたり最大9回の測定が発生する可能性があります。プロバイダー独自のヘルスチェックが追加で実行される場合もあります。これはリクエスト回数の単純な計算であり、カーネル側のスケジューリングや処理の再利用もあるため、電池消費量を直接見積もれるわけではありません。スマートフォンでは主な自動選択方式を1つに絞り、使っていないグループは lazy: true を検討し、プロバイダーのヘルスチェック間隔も過度に短くしないのが一般的です。

普段使いの構成はシンプルに始められます。外側の select で手動選択を残し、内側には url-test か fallback のどちらか1つだけを置きます。複数ノードに接続を振り分ける必要が出てから、負荷分散グループを追加しましょう。まずルールとノードが使えることを確認してから測定項目を調整すると、複数の方式を一度に重ねるより問題を特定しやすくなります。