Clashのプロキシグループ設定：url-test・fallback・load-balanceの選び方と自動切り替え

3種類の自動プロキシグループ：選び方の基本

Clashの自動プロキシグループが選ぶのは「新しい接続をどのノードに割り当てるか」であり、Webサイトへの振り分けルールを自動で書き換えるものではありません。ルールが接続をプロキシグループに割り当て、そのグループが独自のロジックでノードを選択します。ルールモードで特定のドメインがすでに DIRECT に一致している場合、自動グループのチェック間隔を変えても、そのドメインの通信経路は変わりません。

どの方式もヘルスチェックを利用できますが、結果の使い方は異なります。url-testは遅延を比較し、fallbackは優先順に並べたノードの利用可否を判定し、load-balanceは利用可能なメンバーに接続を振り分けます。ここでは主にmihomoカーネルの設定仕様を説明します。旧バージョンのClashカーネルやクライアントによっては、一部の項目に対応していない場合があります。アプリ名だけで判断せず、実際に動作しているカーネルを確認してください。

方式	選択基準	適した用途	主な注意点
`url-test`	遅延を測定し、切り替え幅を調整	普段のブラウジングで応答の速い回線を自動選択	テスト結果がすべてのサイトでの使い心地を示すわけではない
`fallback`	設定順で最初に利用可能なメンバー	メイン回線を優先し、障害時に予備回線へ切り替え	メイン回線の復旧後、自動で戻る場合がある
`load-balance`	ハッシュまたはラウンドロビンで振り分け	複数の独立した接続を複数回線に分散	接続ごとに出口が異なる場合があり、単一接続の帯域は合算されない

url-test：遅延で選び、toleranceで頻繁な切り替えを抑える

url-testは候補ノードから指定したテストURLにアクセスし、その結果をもとにノードを選択します。ここで測定する遅延はICMP Pingでもダウンロード速度でもありません。プロキシ経由でテスト先にアクセスするまでの時間であり、ノードへの接続、テスト先の応答、回線の状態などに左右されます。

普段使い向けの基本設定

以下の設定例は、設定ファイルのトップレベルにあるproxy-groupsの下に追加します。例では香港-A、香港-B、日本-Aがproxiesに登録済みとしています。実際に使う際は、メンバー名を登録済みのノード名と完全に一致させてください。これはプロキシグループの設定例であり、サーバー認証情報を含む完全なサブスクリプションではありません。

proxy-groups:
  - name: 普段使い自動
    type: url-test
    proxies:
      - 香港-A
      - 香港-B
      - 日本-A
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

interval: 300：チェック間隔は300秒、つまり5分です。300ミリ秒ではありません。
tolerance: 50：切り替えのしきい値は50ミリ秒です。わずかな遅延差でノードが頻繁に切り替わるのを防ぎます。
lazy: true：遅延チェックを有効にします。使用されていないグループは、アクティブなグループと同じ頻度でチェックされ続けるわけではありません。設定した間隔でバックグラウンドチェックが常に行われるとは限りません。
url：すべての候補ノードから正常にアクセスできる、負荷の軽いURLを指定します。例ではHTTP 204を返すURLがよく使われます。

数値で見るtoleranceの仕組み

現在のノードAの測定値が110ミリ秒、ノードBが90ミリ秒で、差がわずか20ミリ秒だとします。toleranceを50ミリ秒に設定している場合、この程度の差だけですぐにBへ切り替わるとは限りません。Aが180ミリ秒に悪化し、Bが90ミリ秒のままなら、差は90ミリ秒となり、より速いノードに切り替える条件を満たします。実際に切り替わるタイミングは、チェックと選択のタイミングによります。数値は仕組みを説明するための例であり、本サイトでの実測値ではありません。

toleranceは追加の待ち時間でも、ノード障害を判定するタイムアウト値でもありません。0にすると小さな遅延変化にも反応しやすくなりますが、Webページの表示が速くなるとは限りません。普段使いではまず50ミリ秒から試し、切り替えが頻繁に起きるかを見て、必要に応じて100ミリ秒に調整してください。

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

fallbackはリストの先頭から、最初に利用可能なメンバーを選びます。先頭のメンバーがヘルスチェックで利用可能と判定されている限り、2番目のメンバーの遅延がより小さくても、そちらに切り替わることはありません。「指定した出口を優先し、使えないときだけ回線を切り替える」用途に適しており、「常に最速のノードを探す」方式ではありません。

proxy-groups:
  - name: メイン・予備回線
    type: fallback
    proxies:
      - 香港-A
      - 日本-A
      - 香港-B
    url: https://www.gstatic.com/generate_204
    interval: 120
    lazy: true

障害発生時と復旧時の選択

3つのメンバーがすべて利用可能な場合、選択リストの先頭にある香港-Aが選ばれます。
香港-Aのチェックに失敗し、日本-Aが利用可能な場合、以降の接続には日本-Aが使われます。
その後のチェックで香港-Aの復旧が確認されると、優先順位が再び適用され、新しい接続は香港-Aに戻る場合があります。

つまりfallbackは、予備回線に切り替えた後ずっとそこに留まる、固定型のメイン・予備方式ではありません。メイン回線の状態が利用可能と不可用の間で頻繁に変わると、切り戻しが起こることがあります。特定の回線を固定して使いたい場合は、手動選択のselectグループのほうが分かりやすいでしょう。

チェック間隔を120秒に設定しても、障害から必ず120秒以内に復旧するわけではありません。実際の所要時間は、障害が起きた箇所、チェックのタイムアウト、遅延チェックの設定、アプリの再試行などにも左右されます。メイン回線がひどく混雑していてもテスト先にアクセスできる場合、fallbackはその回線を使い続けることがあります。「遅い」と「利用できない」は別の状態です。

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

load-balanceは利用可能なノード間で接続を振り分けます。複数のタスクを並行して実行する用途には向いていますが、通常のTCPダウンロード1本を3つの回線に分割するわけではありません。各ノードの速度が10 MB/sでも、この方式を有効にするだけで単一接続のダウンロード速度が30 MB/sになることはありません。

consistent-hashingとround-robinの違い

consistent-hashing：接続先に関する情報を使って一貫性ハッシュで振り分け、同じ接続先には同じメンバーが選ばれやすくなります。同一の接続先で出口の変化を抑えたい場合に適していますが、利用可能なノードの構成が変わると、割り当ても変わることがあります。
round-robin：利用可能なメンバーを順番に選び、新しい接続を分散しやすくします。リアルタイムの帯域幅、CPU負荷、残りの通信量に応じて振り分ける方式ではありません。

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

ラウンドロビンを使うには、現在のカーネルがこの方式に対応していることを確認したうえで、上記のstrategyをround-robinに変更します。振り分けの単位は接続であり、Webページ上のクリックごとでも、HTTP/2接続内のリクエストごとでもありません。ブラウザーが長時間接続を再利用する場合、ページから多くのリクエストが送信されても、使われるノードは少数にとどまることがあります。

interval、テストURL、ノード提供元の役割

自動プロキシグループのチェック通信は候補ノードを経由します。ノードが30個あり、間隔を30秒に設定して、グループが常にアクティブで毎回すべてのノードをチェックすると仮定した場合、1時間あたりのチェック回数は約30 × 120 = 3600回です。300秒間隔なら約360回になります。実際の回数は遅延チェックの設定、提供元、カーネルのスケジュール動作によって異なります。チェック間隔を短くすればよいとは限らず、負荷も考慮が必要です。

設定項目	単位・用途	設定の目安
グループ内の`interval`	ヘルスチェックの間隔（秒）	普段使いは300秒、メイン・予備構成では120秒から試す
`tolerance`	url-testの切り替えしきい値（ミリ秒）	50ミリ秒。汎用のタイムアウト設定ではない
`lazy`	遅延チェックを有効にするか	まずは`true`から
`strategy`	load-balanceの振り分け方式	まずは`consistent-hashing`を使用

サブスクリプション更新とヘルスチェックを区別する

proxy-providersを使う場合、通常、提供元設定の外側にあるintervalはリモートのノードリストを更新する間隔を指定します。health-check.intervalはノードのヘルスチェック間隔です。プロキシグループの同名フィールドとは別の設定です。サブスクリプションの更新間隔を60秒にしても、毎分の速度測定が自動的に行われるわけではありません。

useでプロバイダーを読み込む場合は、プロバイダー側のヘルスチェック設定も確認してください。プロキシグループにテストURLを指定しただけで、プロバイダーの全メンバーが想定どおりにチェックされるとは限りません。複数の箇所でむやみに高頻度チェックを設定するのも避けてください。まず少数のノードを直接指定して動作を確認し、その後プロバイダーを追加して、更新ログとヘルスチェックの状態を個別に確認することをおすすめします。

テストURLは到達可能で、比較に適したものを選ぶ

一部のノードが接続するネットワークでテストURLがブロックされていると、そのノードは利用不可と判定されても、ほかのサイトには正常にアクセスできる場合があります。逆に、テストURLにアクセスできても、すべてのサービスが利用できるとは限りません。グループ全体がタイムアウトする場合は、まず正常動作が分かっているノードから同じURLへアクセスし、テスト先の障害、DNSエラー、TLSハンドシェイクの失敗を切り分けてから、ノードの問題かどうかを判断してください。

設定の適用と確認：新しい接続が対象グループに入るか確かめる

3種類の自動グループを同時に有効にする必要はありません。同じ設定で比較したい場合は、先ほどの3つの定義を1つのproxy-groupsリストにまとめ、手動選択用の入口を追加します。YAMLのトップレベルに同名のproxy-groupsキーを複数書かないでください。既存の設定が上書きされたり、解析エラーが発生したりするおそれがあります。

  - name: プロキシ入口
    type: select
    proxies:
      - 普段使い自動
      - メイン・予備回線
      - 複数回線の分散
      - 香港-A

上記の設定例は同じリスト内に追加し、ほかのグループと同じインデントにしてください。既存のルールでプロキシを使う対象には、プロキシ入口を指定します。たとえばexample.comとそのサブドメインをプロキシ経由にする場合は、関連する広範なルールより前に次のルールを追加します。これは対象を指定するルールの例であり、すべての通信をプロキシ経由に変更するものではありません。

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

このルールはマッチ条件を説明する例です。最後の行はそれ以外の通信を直接接続にするため、サブスクリプションに含まれる分割ルール全体を置き換える用途には使えません。ルールは上から順に評価されるため、前方にある既存ルールがテスト通信に一致することもあります。

設定を保存して確認します。カーネルに、未対応の方式、グループ名の重複、存在しないノードに関するエラーが出ていないことを確認してください。サブスクリプション管理ツールの更新で直接編集した内容が上書きされる場合があります。継続して設定を変更する場合は、クライアントが提供する上書き設定またはマージ機能を使ってください。
現在の通信制御方式を維持します。まずは動作しているシステムプロキシまたはTUNの設定をそのまま使い、DNSやポート、プロキシグループを同時に変更しないでください。3種類の方式はいずれも、TUNを必須としません。
入口から対象グループを選択します。まず普段使い自動を選び、チェックを1回実行して候補ノードの遅延と現在の選択を記録します。次にメイン・予備グループに切り替え、選択順を比較します。
新しい接続で動作を確認します。接続パネルで一致したルール、プロキシの経路、最終的に選択されたノードを確認します。すでに開いているWebページは接続を再利用している場合があります。必要に応じてページとその接続を閉じてから、再度アクセスしてください。
影響を抑えて障害時の動作を確認します。ローカルのテスト用設定で一時的にメインノードを外すか、利用できないことが分かっているメンバーを使い、その後のチェックと新しい接続を確認します。高頻度チェックや、業務ネットワークを切断する方法で検証しないでください。

よくある症状と確認ポイント

url-testで2つのノード間を頻繁に行き来する：遅延差がtoleranceに近いか、テストURLの応答が不安定でないか、チェック間隔が短すぎないかを確認します。まず1つの設定だけ変更し、しばらく様子を見てください。
fallbackが最も遅延の小さいノードを選ばない：優先順位に基づく正常な動作です。遅延を優先する場合は、intervalをさらに短くするのではなく、url-testを使ってください。
load-balanceが1つのノードしか使わないように見える：一貫性ハッシュを使っているか、常に同じ接続先にアクセスしているか、アプリが長時間接続を1本だけ確立していないかを確認します。
グループを切り替えても出口IPが変わらない：IP確認サイトへの通信が対象グループに割り当てられているかを確認し、接続を再確立してください。複数のノードが同じパブリック出口を共有している可能性もあります。
すべてのノードがタイムアウトになる：同じテストURL、ノードの状態、システム時刻、ログを確認してください。クライアントのパネルから手動で行う速度測定は、自動グループと異なるテストURLやパラメーターを使う場合があります。

用途別の選び方：遅延重視・メイン／予備・回線分散

普段のブラウジングでは、まずurl-test + interval 300 + tolerance 50を試します。特定の地域や回線を優先する場合は、順番を指定したfallbackを使います。複数の独立したタスクで接続を分散したい場合はload-balanceを検討し、まず一貫性ハッシュを使ってサービスとの相性を確認してください。

自動プロキシグループはノード選択、ルールは接続先の振り分け、システムプロキシとTUNは通信の取り込みを担います。この3つを分けて確認すると、カーネルやDNS、自動グループを同時に変更するより、問題を特定しやすくなります。対応フィールドや通信制御の範囲については、サイトの技術リファレンスをご覧ください。インポートと基本的な接続を先に確認する場合は、使い方ガイドに沿って順番に確認できます。