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

目的に合わせて選ぶ：低遅延・優先順位固定・接続分散

url-test は利用可能なノードの中から測定遅延を基準に選択します。fallback は設定順で最初に利用可能なノードを選び、load-balance は指定した方式で複数の接続を振り分けます。いずれもヘルスチェックに対応しますが、「ノードが利用可能か確認すること」と「接続先を決めること」は別です。自動でチェックするからといって、すべてが最速ノードを選ぶわけではありません。

種類	選択基準	適した用途	主な制約
`url-test`	URLへの測定遅延と切り替え許容幅	日常のウェブ閲覧で、応答の速いノードを自動選択	測定遅延はダウンロード速度を示すものではない
`fallback`	候補の順序と利用可能な状態	メイン回線を固定し、障害時に予備回線へ切り替える	後ろにある低遅延ノードが優先されるわけではない
`load-balance`	ハッシュやラウンドロビンなどの振り分け方式	複数の接続を別々のノードに振り分ける	単一接続の帯域を複数ノード分まとめることはできない

たとえば、3つのノードの測定結果が HK-A は 90ms、HK-B は 65ms、JP-A は 130ms だったとします。自動速度測定グループは、切り替え条件を満たせば HK-B を選ぶ傾向があります。HK-A、HK-B、JP-A の順に設定したフェイルオーバーグループは、HK-A が正常ならそのまま使います。負荷分散グループでは、宛先によって異なるノードを経由することがあります。数値は選択の仕組みを説明するための例であり、実測値や速度を保証するものではありません。

url-testの書き方：toleranceで小さな遅延変動による切り替えを抑える

url-test は候補ノード経由で指定したURLにアクセスし、応答時間を選択基準にします。ノードのサーバーに対してICMP pingを1回実行する仕組みではありません。結果はノードとのハンドシェイク、出口回線、接続先サイト、コネクションの再利用などに左右されます。そのため、測定先には安定してアクセスでき、実際の通信先を反映したURLを選ぶのがおすすめです。

proxy-groups:
  - name: 自動速度測定
    type: url-test
    proxies:
      - HK-A
      - HK-B
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

3つのパラメーターは単位に注意

interval: 300：測定間隔は300秒、つまり5分です。300ミリ秒ではありません。
tolerance: 50：切り替え許容幅は50ミリ秒です。小さな遅延変動による切り替えを抑えるための値で、リクエストのタイムアウトではありません。
lazy: true：遅延測定を有効にします。グループが使われていない間は、定期的な測定が停止する場合があります。アプリのリクエストごとに事前測定するという意味ではありません。

現在のノードが約90ms、別のノードが約65msで、差が25msだとします。許容幅を50msに設定している場合、すぐに後者へ切り替わるとは限りません。別のノードが約30msまで下がれば、切り替え条件を満たしやすくなります。実際の選択は、現在のノードが有効か、測定結果が更新されているかにも左右されます。現在のノードが利用できない場合に、許容幅を理由に障害中のノードを使い続けるわけではありません。

日常利用では、まず測定間隔300秒、許容幅50msから試してみましょう。間隔を5秒に縮めても、測定リクエストやモバイル回線の起動、サーバー負荷が増えるだけになりがちです。許容幅を0にすると、数ミリ秒の差で後続の接続先が頻繁に変わることがあります。セッションの安定性が必要なら、画面上の数値を最小化するより、不要な切り替えを抑えることを優先してください。

fallbackの書き方：ノードの順序が優先順位

fallback の基本は「最速のノードを使う」ことではなく、「上から順に見て、最初に正常なノードを使う」ことです。メイン回線が正常なら、予備回線のほうが低遅延でも優先されません。地域や出口を固定したい場合や、回線の費用に優先順位がある場合に適しています。

proxy-groups:
  - name: メイン・予備回線
    type: fallback
    proxies:
      - HK-A
      - HK-B
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

HK-A、HK-Bがどちらも正常：HK-Aを優先します。
ヘルスチェックでHK-Aが利用不可、HK-Bが利用可能と判定：以降はHK-Bを使用します。
次のチェックでHK-Aの復旧を確認：グループは再びHK-Aを優先します。

ここでいう「復旧」はヘルスチェックの結果を基準にします。チェック間隔が300秒だからといって、すべての障害が1秒以内に切り替わるわけでも、必ず300秒ちょうど待つわけでもありません。手動テスト、クライアントの動作、コアの実装によって状態の更新タイミングは変わります。進行中のTCPセッションが予備サーバーへ自動で移行することもありません。切断されたダウンロード、SSH、動画の接続は、アプリ側で再接続が必要です。

load-balanceの書き方：接続を分散し、単一接続の帯域は合算しない

load-balance は、複数の正常なノードに接続を振り分けます。パケットを1つずつ順番に送る仕組みでも、100Mbpsの回線3本を自動で合算して300Mbpsのトンネルにする仕組みでもありません。1つのTCP接続は選ばれたノードを通って通信します。アプリが複数の接続を確立した場合に、複数ノードで通信を分担できることがあります。

proxy-groups:
  - name: 接続分散
    type: load-balance
    proxies:
      - HK-A
      - HK-B
      - JP-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

consistent-hashingとround-robinの選び方

consistent-hashing：宛先情報を使って一貫性ハッシュで振り分け、同じ宛先が同じ出口を使うようにします。実際に使われるハッシュキーは、コアの実装やドメイン名を利用できるかどうかによって異なります。すべてのアカウントセッションが永久に同じノードへ固定されるわけではありません。
round-robin：接続を順番に振り分けます。複数接続の分散効果を確認したい場合に利用できますが、同じウェブサイトへの接続でも異なる出口を経由することがあります。

ラウンドロビンを使う場合は、サンプルの最後の行を strategy: round-robin に変更するだけで済みます。グループ全体を書き直す必要はありません。「ダウンロードを1つ実行して速くなったか」だけで負荷分散の動作を判断しないでください。クライアントの接続一覧で、複数の宛先や新しい接続が実際にどのプロキシ経路を通ったか確認するほうが確実です。

一貫性ハッシュを使っても、1つのウェブページがログイン、画像、API、認証コードなど複数のドメインに同時にアクセスすることがあります。これらが同じノードに割り当てられる保証はありません。地域制限、アカウントの安全性、接続元IPの一致が重要なサービスでは、地域をまたぐ負荷分散をそのまま使うのは避けてください。ノード構成やヘルスチェックの状態が変わると、既存の割り当てが変わる場合もあります。

ネストしたselectグループ：手動切り替えとルール用の出口を確保

自動グループをすべての通信の入口にする必要はありません。外側の select で利用モードを選び、内側のグループで自動速度測定、メイン・予備の切り替え、接続分散をそれぞれ担当する構成が管理しやすくなります。測定に問題が起きても、グループの種類をその場で変更せず、クライアント画面から特定のノードに切り替えられます。

以下は、先ほどの3つの個別サンプルを置き換えられる統合例です。候補名はすべて、既存のノードまたは定義済みのプロキシグループとして解決できる必要があります。「プロキシ出口」をその子グループの候補にすると循環参照になるため、設定しないでください。

proxy-groups:
  - name: プロキシ出口
    type: select
    proxies:
      - 自動速度測定
      - メイン・予備回線
      - 接続分散
      - HK-A
      - HK-B
      - JP-A

  - name: 自動速度測定
    type: url-test
    proxies: [HK-A, HK-B, JP-A]
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: メイン・予備回線
    type: fallback
    proxies: [HK-A, HK-B, JP-A]
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

  - name: 接続分散
    type: load-balance
    proxies: [HK-A, HK-B, JP-A]
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

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

ノードを proxy-providers から読み込む場合、対応するグループでは use を使って既存のproviderを指定できます。provider名をノードとして proxies に書かないでください。また、providerの health-check も確認しましょう。providerのノードをヘルスチェックするには、該当provider側で正しく設定する必要があります。グループに url を記述しただけで、すべての接続元ノードが想定どおり測定されるとは限りません。

サブスクリプションの更新で、直接編集した設定が上書きされる場合があります。変更前にバックアップを取り、クライアントがローカル上書き、設定のマージ、一時編集のどれに対応しているか確認してください。ここで扱うのはコアのYAML構造です。クライアントによって「設定」メニューが同じとは限りません。基本的なインポート手順ははじめにを、ルールとDNSの関係は設定の応用をご覧ください。

適用後は4段階で確認。「グループは切り替わるのに通信先が変わらない」を防ぐ

設定が正常に読み込まれたか確認します。再読み込み後、まずエラーログを確認してください。ノード名の大文字・小文字、インデントの誤り、未対応のポリシータイプ、トップレベルキーの重複などが原因で、新しい設定が反映されていない場合があります。画面に古いグループが表示されている場合は、先に読み込みエラーを解消してください。
モードとルールの適用先を確認します。Proxies で外側のグループが現在どれを選択しているか確認し、Rules で対象ルールを、Logs または接続の詳細で最終的な通信経路を確認します。rules による振り分けが行われるのはルールモードの場合です。グローバルモードでは、特定のドメイン向けに設定した入口を経由しないことがあります。
テストを実行して結果を記録します。グループのテストを手動で実行し、日時、URL、ノードの遅延、最終的に選択されたノードを記録してください。前後の結果を比べるときは同じ測定先を使い、異なる接続先の遅延を同じ指標として比較しないようにします。
新しい接続で再確認します。グループの切り替え後も、既存の接続は元のノードを使い続けることがあります。新しいコマンドラインリクエストを実行するか、テストに使ったアプリの接続を終了してから再試行し、プロキシ経路を確認してください。ページを更新した後の体感速度だけで判断しないでください。

curlでブラウザーのコネクション再利用の影響を除外する

ローカルのHTTPまたはmixedプロキシが 127.0.0.1:7890 で待ち受けている場合は、次のコマンドを実行できます。ポート番号はクライアントの現在の設定に合わせてください。7890がSOCKS専用ポートの場合、HTTPプロキシの指定をそのまま使うことはできません。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 --head https://example.com/

Windows PowerShellでは、コマンドの先頭を curl.exe にすると、一部環境でのコマンドエイリアスの違いを避けられます。このリクエストは、前述のexample.comのルール例に対応しており、ログと併せて「プロキシ出口」を通っているか確認できます。ただし、確認できるのはその宛先へのリクエスト経路と応答だけです。すべてのウェブサイト、UDP通信、TUN経由の通信が正常とは限りません。

TUNを有効にすると、仮想ネットワークインターフェースが接続を処理する場合がありますが、最終的にどのプロキシグループを使うかは動作モードとルールによって決まります。TUNを有効にしても fallback が速度測定グループに変わることはなく、load-balance で単一接続の帯域が自動的に合算されることもありません。

よくある問題：パラメーターを変える前に測定結果を確認

速度測定がすべてtimeoutになるのに、一部のサイトは開ける

多くの場合、「測定用URLにアクセスできない」ことと「すべての通信先にアクセスできない」ことが区別されていません。まず測定先のDNS、TLS、ノードの出口からのアクセス状況を確認し、小さな応答を確実に返すHTTPS URLに変更して比較してください。ログインが必要なサイト、リダイレクト認証があるサイト、アクセス制限のあるサイトのトップページを、常用のヘルスチェック先にしないでください。

url-testが古いノードから切り替わらない

まず、グループが使用中か、遅延測定の設定が更新に影響していないか、遅延差が tolerance を超えているか確認してください。現在の接続がすでに確立済みかどうかも確認します。画面上で別のノードが10ms速く表示されていても、許容幅が50msなら設定の異常ではありません。測定結果が更新済みで、差が十分に大きいにもかかわらず、新しい接続が想定どおりにならない場合に、コアのバージョンやグループの参照関係を確認してください。

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

これは順序を優先する正常な動作です。メインノードの障害時に予備ノードから最速の回線を選びたい場合は、主・予備グループの予備側に url-test グループを入れ、実際の接続でネスト後の選択を確認してください。ネストすると状態の判定が複雑になります。回線が2～3本なら、まずはフラットな構成にしたほうが問題を特定しやすくなります。

負荷分散後にサイトで何度もログインを求められる

まず、そのサイトだけを固定ノードまたは手動選択グループに振り分け、新しいセッションが安定するか確認してください。ラウンドロビンを一貫性ハッシュに変えるだけでは解決しない場合があります。サイトが複数のドメインを使って地域やIPアドレスをまとめて確認することがあるためです。セッションの問題を解決してから、そのサービスの接続を分散する必要があるか検討しましょう。

使い分けの基本：日常の閲覧には適切な許容幅を設定した url-test、メイン回線の固定には fallback、複数接続を分散する必要が明確な場合にのみ load-balance を使います。これらの外側に select を置き、ルールの適用先、ヘルスチェック、新しい接続のログを確認すれば、測定間隔を何度も変更するより原因を把握しやすくなります。