Clashのプロキシグループを解説：url-test・fallback・load-balanceの違いと選び方

3種類のプロキシグループ：まずは選択基準を確認

普段のブラウジングで低遅延のノードを自動選択するなら url-test、メイン回線を優先し、障害時だけ予備回線に切り替えるなら fallback、複数ノードに接続を振り分けるなら load-balance を使います。いずれも proxy-groups の一種ですが、選択基準は異なります。クライアントに「自動」と表示されているかどうかだけで判断しないでください。

プロキシグループが決めるのは、どのアウトバウンドを使うかです。アプリの通信を自動的にClashへ流す機能ではありません。通信の取り込みはシステムプロキシまたはTUNが担い、ルールモードでは rules によって接続を該当するプロキシグループへ振り分けます。ルールの最終的な転送先が DIRECT の場合、グループの速度テスト設定を変更しても接続経路は変わりません。

url-test：遅延を基準に経路を選択し、toleranceで切り替えを抑制

url-test は候補ノードからテスト用URLへリクエストを送り、その結果をもとにノードを自動選択します。測定されるのはテスト先へのリクエストにかかる時間であり、ダウンロード速度でも、すべてのWebサイトでの平均的な使い心地でもありません。テスト先への経路が良好でも、動画サービスや開発用リポジトリへの経路も同様に良いとは限りません。

初期設定の目安：300秒間隔、許容幅50ミリ秒

以下はグループ定義の一部であり、設定全体ではありません。例にある「ノード-A」「ノード-B」「ノード-C」は、既存設定の proxies に定義済みで、名前も完全に一致している必要があります。既存の proxy-groups リストに追加してください。トップレベルのキーを重複して作成しないでください。

proxy-groups:
  - name: 低遅延自動選択
    type: url-test
    proxies:
      - ノード-A
      - ノード-B
      - ノード-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: false

• interval: 300：ヘルスチェックの間隔は300秒、つまり5分です。アプリのリクエストタイムアウトではありません。
• tolerance: 50：切り替えの許容幅は50ミリ秒です。候補ノードがわずかに速いだけで頻繁に切り替わるのを防ぎます。遅延の上限ではなく、50ミリ秒を超えるノードを除外する設定でもありません。
• lazy: false：グループが一時的に使われていなくても、定期的にチェックして結果を確認できるようにします。ノード数が多い場合はテストリクエストが増えます。
• url：応答が速く、安定してアクセスできるテスト先を選びます。例に使われるURLは通常HTTP 204を返します。ログインが必要なページ、頻繁にリダイレクトされるページ、ボット対策の認証が発生するページは避けてください。

たとえば、ほかの選択条件が同じで、現在のノードの測定値が120ミリ秒、候補ノードが105ミリ秒の場合、差は15ミリ秒しかないため、許容幅を50ミリ秒に設定していれば通常は切り替わりません。候補が60ミリ秒まで下がれば、切り替える意味が出てきます。これはパラメーターの意味を示す例であり、本サイトでの実測値ではありません。最終的な選択は、実際のコアの状態とログを確認してください。

遅延だけでは判断しにくいタスク

大容量ダウンロード、長時間の動画視聴、リモートデスクトップでは、帯域幅やパケットロス、ジッターも影響します。まず自動選択グループで利用可能なノードを絞り込み、同じ時間帯に同じ接続先で転送速度を比較するとよいでしょう。ログイン時に固定の送信元IPが必要な場合は、ノードを手動で選ぶか、主系・予備系の順序を明確にしたグループが適しています。

fallback：リスト順に利用可能なノードを選択

fallback で重視されるのは優先順位です。リストの先頭からヘルスチェックに合格したノードを使い、先行ノードが利用できない場合にのみ、次の利用可能なノードへ切り替えます。そのため、メイン回線を先頭に、予備回線をその後に並べてください。

proxy-groups:
  - name: メイン回線の障害時切り替え
    type: fallback
    proxies:
      - ノード-A
      - ノード-B
      - ノード-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false

ノード-Aの測定遅延が180ミリ秒、ノード-Bが75ミリ秒だとします。Aが正常な限り、グループは引き続きAを優先します。ここに tolerance を追加しても、遅延を基準に経路を選ぶグループにはなりません。「速いノードを使いたい」場合は、url-test を使ってください。

復旧と障害検知の範囲

• メイン回線が復旧して正常と判定されると、その後の経路選択では再びメイン回線が優先されます。障害の検知と復旧は、チェックとコアの動作に依存するため、即時に完了するとは限りません。
• グループの切り替えが主に影響するのは、新しく確立する接続です。確立済みのTCP接続は新しいノードへ移行せず、元の接続が切れた後、通常はアプリ側で再接続が必要になります。
• テスト先にアクセスできることが示すのは、そのチェックが成功したという点だけです。業務で使うWebサイトにだけアクセスできない場合でも、メイン回線は正常と判定されることがあります。その場合は、対象サイトやルールを確認してください。

オンライン会議やリモート端末など継続中のセッションでは、主系・予備系の切り替えは復旧手段であり、通信を途切れさせずに移行する仕組みではありません。導入前にテスト用のメイン回線を一時的に無効にし、新しい接続が予備回線へ切り替わるかを確認した後、メイン回線を戻して優先順位を検証できます。テスト中にDNSとTUNの設定を同時に変更すると、どの層の変更が影響したのか判断しにくくなります。

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

load-balance は利用可能なメンバー間で通信を振り分けます。振り分け方は strategy によって異なります。1つのファイル転送を複数回線に分割して同時に送る、帯域幅の集約機能ではありません。単一のTCP接続は引き続き1つのアウトバウンドを経由します。複数の接続をアプリ側で作成する場合に限り、複数ノードを利用できる可能性があります。

proxy-groups:
  - name: 複数接続の振り分け
    type: load-balance
    proxies:
      - ノード-A
      - ノード-B
      - ノード-C
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: false
    strategy: consistent-hashing

consistent-hashingとround-robin

ラウンドロビンでは、同じWebサイトへの複数の新規接続が異なる出口IPから発信される場合があります。ログイン時の不正検知が厳しいサービス、決済ページ、IPアドレスの固定が必要なAPIでは、この方式をそのまま使うのは避けてください。一貫性ハッシュを使えば変更を抑えられますが、メンバーのヘルスチェック状態やノードリストが変われば、出口が常に固定されるとは限りません。

3つのノードが同じ上流回線のボトルネックを共有している場合、接続を振り分けても利用可能な帯域幅が増えるわけではありません。効果を確認する際は、接続パネルに表示される実際のノード、接続先のスループット、失敗率をあわせて確認してください。3つのメンバーすべてで遅延が測定できたかどうかだけでは判断できません。

自動グループをルールに組み込む：手動選択の入口も残す

3種類の自動選択グループを同時に用意し、select グループから使用する方式を選べます。日常のブラウジング、主系・予備系、複数接続の用途を切り替えるたびにルールを編集する必要はありません。以下の設定例は前述の3つのグループ定義に追加して使うもので、単体では完全な設定として読み込めません。

proxy-groups:
  - name: プロキシ出口
    type: select
    proxies:
      - 低遅延自動選択
      - メイン回線の障害時切り替え
      - 複数接続の振り分け
      - ノード-A
      - DIRECT

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

ここでの MATCH は、フォールバックルールからプロキシグループを参照する方法を示す例にすぎず、国内外の通信を振り分ける設定一式ではありません。既存のサブスクリプションには、通常、LANや中国本土のサイト、ルールセットのルールも含まれます。既存の振り分け設定は維持し、プロキシが必要なルールの転送先だけを「プロキシ出口」に変更してください。ルールは上から順に照合されるため、条件が広すぎるルールを上のほうに置くと、後続のルールが適用されなくなります。

1. 現在使える設定をバックアップし、3つの自動グループとメンバー名がすべてコアに認識されることを確認します。
2. クライアントのプロキシまたはプロキシグループ画面で、「プロキシ出口」の選択先を「低遅延自動選択」などに設定します。名称やメニューの場所は、使用するクライアントによって異なります。
3. ルールモードにしてテストサイトへアクセスし、接続の詳細画面で適用されたルール、プロキシチェーン、最終的なノードを確認します。
4. 別のプロキシグループに切り替え、新しい接続を作成して検証します。既存の接続は元のノードを使い続ける場合があるため、ページを一度更新しただけで判断しないでください。

アプリの通信がプロキシを経由しているか先に確認する場合は、システムプロキシの設定手順に沿って通信の取り込み方法を確認し、その後遅延テストの手順でグループの状態を調べてください。ルールの適用状況を確認する代わりに、全般モードへ切り替えるのは避けてください。

よくある設定ミス：間隔、メンバーの参照元、サブスクリプションによる上書き

intervalをミリ秒で指定してしまう

interval: 300000 は300000秒を意味し、5分ではありません。5分ごとにチェックする場合は 300 と指定します。「反応を速くする」ために 1 に設定するのもおすすめできません。ノード数が多いほどリクエストの負荷が増え、チェック頻度を上げてもノード自体の混雑は解消できません。

ノード名だけを記述し、設定に該当するメンバーがない

proxies で参照するのは、既存のノードまたはプロキシグループの名前であり、サブスクリプションURLではありません。大文字・小文字、空白、記号まで一致させる必要があります。グループ同士が循環参照する設定もできません。たとえば「プロキシ出口」に「低遅延自動選択」を含め、その「低遅延自動選択」に「プロキシ出口」を含める設定は避けてください。

ノードが proxy-providers から提供されている場合は、定義済みのプロバイダーを use で参照できます。例：use: [サブスクリプションノード]。「サブスクリプションノード」は、既存プロバイダーのキー名である必要があります。プロバイダーの health-check とグループ内のチェックは異なる設定レイヤーです。グループのチェック間隔を変更しても、すべてのプロバイダーのチェックが連動して変わるとは限りません。

サブスクリプションを更新するとカスタムグループが消える

リモートサブスクリプションから生成されたファイルを直接編集すると、次回の更新時に変更が上書きされることがあります。クライアントが提供する上書き、マージ、拡張設定の仕組みを優先して使ってください。設定方法はクライアントごとに異なります。保存後に設定を検証し、サブスクリプションをもう一度更新して、グループ定義、ルールの参照、手動選択用のノードが残っていることを確認してください。

選び方のまとめ：用途に合わせて自動化の度合いを決める

• 普段のWeb閲覧や一般的なプロキシ利用：url-test、300秒間隔、許容幅50ミリ秒から始め、頻繁に切り替わらないか確認します。
• メイン回線と予備回線を固定：fallback を使い、メインノードをリストの先頭に配置して、切断時と復旧時の動作を実際に確認します。
• 複数の接続先や複数接続を使うタスク：load-balance を検討し、まず一貫性ハッシュを使います。そのうえで、用途がラウンドロビンを許容できるか判断してください。
• アカウントのセッションや固定の出口が必要な場合：select に特定ノードを手動選択する入口を残します。必要に応じて、対象ドメインを固定のプロキシグループに振り分けてください。

プロキシグループの目的は、用途に合った経路選択を行うことであり、あらゆる場面で測定値の最低遅延を追求することではありません。元に戻せる設定を残し、一度に変更するパラメーターは1つに絞って、新しい接続の出口を確認すれば、設定の変更と使い心地の変化を結び付けて判断できます。