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

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

Clashのプロキシグループは複数のアウトバウンドから接続先を選び、ルールは接続をどのプロキシグループに送るかを決めます。この2つは設定の役割が異なります。自動グループの設定が正しくても、ルールが接続を DIRECT に振り分けている場合、その接続ではグループ内のノードは使われません。この記事ではmihomo（旧Clash Meta）の設定構文を基準に説明します。ほかのコアや古いバージョンでは対応するパラメーターが異なる場合があるため、編集前にクライアントの「バージョン情報」またはコア情報で、実際に使われているコアを確認してください。

まず用途に合わせて種類を選びます。低遅延を優先するなら url-test、メイン回線が使える間は常にメイン回線を使うなら fallback、複数のアウトバウンドに接続を振り分けるなら load-balance が適しています。いずれも疎通状況を確認できますが、その結果を選択に反映する方法が異なります。

種類	選択基準	用途	主な注意点
`url-test`	候補のアウトバウンドからテスト先への遅延を比較し、許容差を考慮して選択する。	普段のブラウジング、同じ地域のノードから自動選択。	テスト時の遅延が低くても、大容量ファイルのダウンロードが速いとは限らない。
`fallback`	リスト順に、最初に利用可能なアウトバウンドを選択する。	メイン・バックアップ回線、特定の地域を優先する場合。	優先ノードが遅くなっても利用可能な状態なら、通常は別のノードに切り替わらない。
`load-balance`	指定した分散アルゴリズムに従い、利用可能なアウトバウンドに接続を振り分ける。	複数のタスクを同時に実行する場合や、接続負荷を分散したい場合。	1本のTCP接続を複数回線に分割し、帯域を合算する機能ではない。

url-testの設定例：自動選択と切り替えの許容差

以下の例では、現在の設定の proxies またはプロキシプロバイダーに「香港-01」「香港-02」「日本-01」という名前のノードが登録済みであることを前提とします。これらはノード定義ではなく、既存ノードの参照名です。実際に設定するときは、設定内に存在する名前に置き換えてください。すでに proxy-groups がある場合は、リスト項目を既存の設定に追加し、同じ名前のトップレベルキーを重複して作成しないでください。

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

intervalとtoleranceの役割

interval: 300：定期テストの間隔は300秒、つまり5分です。300ミリ秒ではありません。
tolerance: 50：切り替えの許容差は50ミリ秒です。わずかな遅延の変動による頻繁な切り替えを抑えるための値で、プローブのタイムアウト時間や遅延の上限ではありません。
lazy: true：遅延検査を有効にします。グループが使用されていない間は、定期テストを省略できます。手動テストや初回使用時の動作は、クライアントやコアの実装にも左右されます。
url：疎通状況と遅延のテスト先です。安定していて応答データが小さく、実際に利用するネットワーク経路を反映できるURLを選びましょう。

たとえば、現在のノードのテスト遅延が110ミリ秒、別のノードが95ミリ秒で、差が15ミリ秒しかないとします。許容差を50ミリ秒に設定している場合、常に最小値のノードへ切り替わるとは限りません。許容差は遅延の揺れを抑えるためのもので、決まったタイミングで切り替わることを保証するものではありません。現在のノードが利用できなくなった場合も、コアはこの2つの遅延値だけで判断できるわけではありません。

これらの数値はパラメーターを説明するための例であり、実回線の測定結果ではありません。テスト先のTLSハンドシェイク、ネットワークの混雑、サーバーの応答、接続の再利用状況によって測定値は変わります。Webページの表示が速くてもダウンロードが遅い場合は、スループットやパケットロス、夜間の混雑も確認してください。問題の切り分けをせずに tolerance を0に設定し続けるのは避けましょう。

fallbackの設定例：メイン回線とバックアップ回線の順序

fallback が重視するのは「リストの中でどの回線が先に利用可能か」であり、「どの回線が最速か」ではありません。メイン回線が使える場合、バックアップ回線の測定値が低くても、通常はメイン回線を使い続けます。地域や料金、出口の優先順位が決まっている場合に適しています。

proxy-groups:
  - メイン・バックアップ回線
    type: fallback
    proxies:
      - 香港-01
      - 香港-02
      - 日本-01
    url: https://www.gstatic.com/generate_204
    interval: 120
    lazy: true

この順番では、香港-01が最優先、香港-02が第2優先、日本-01が最後のバックアップです。1つ目のノードでテストに失敗し、2つ目が正常なら、グループは2つ目を選択します。その後のテストで1つ目が再び利用可能になれば、再度1つ目が優先されます。

自動フェイルオーバーでも接続はシームレスに移行しない

間隔を120秒に設定しても、どのような障害でも120秒以内に復旧するとは限りません。検知のタイミング、プローブにかかる時間、アプリ側の再試行も関係します。
テスト先に接続できても、業務で使うWebサイトにアクセスできるとは限りません。地域制限、対象サイトによるブロック、特定サイト向けのルーティング異常は、テストで検知できないことがあります。
プロキシグループの切り替えが主に影響するのは、新しく確立する接続です。ダウンロードや動画再生、WebSocketなど、すでに確立済みの接続が別の回線へ自動的に移行することはありません。

load-balanceの設定例：接続を分散し、1接続の帯域は合算しない

load-balance は複数の接続を同時に使うタスクに適しています。以下では consistent-hashing を使い、候補の構成が安定している場合、同じ接続先ができるだけ同じ出口に割り当てられるようにします。同じWebサイトへのアクセスで出口が頻繁に変わるのを抑えるのに役立ちますが、IPアドレスが常に固定されることを保証するものではありません。

proxy-groups:
  - 接続を分散
    type: load-balance
    proxies:
      - 香港-01
      - 香港-02
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true
    strategy: consistent-hashing

分散アルゴリズムの選び方

consistent-hashing：接続先の情報に基づいて、一貫性ハッシュで振り分けます。接続先のドメインが認識できるか、候補ノードが変わったかによって、割り当て結果も変わります。
round-robin：接続を順番に振り分けます。動作は分かりやすいものの、接続数が同程度でも通信量が同程度になるとは限らず、各回線が同じバイト数を処理する保証もありません。

たとえば、あるプログラムがダウンロード用の接続を8本同時に確立すると、負荷分散によって各接続が別々のノードに割り当てられることがあります。一方、サーバーが1接続しか許可しない場合、スループットは選ばれた回線1本分のままです。また、ブラウザーはHTTP/2を使い、1本の接続で複数のリクエストを再利用することがあります。ページに多くのリソースが含まれていても、すべてのノードが均等に使われるとは限りません。

ネットバンキングやアカウント管理など、特定の地域からのアクセスが必要なサービスでは、固定ノードまたは地域を固定したプロキシグループを優先してください。一貫性ハッシュを使っていても、ノードの停止や候補リストの変更、接続先ドメインの変化によって出口が変わる可能性があります。認証が関わるサービスでは、「負荷分散」のためだけに候補地域を広げるのは避けましょう。

プロキシグループの組み合わせ：用途別に手動選択を残す

普段の設定では、3種類の自動グループを1つの select グループにまとめられます。通常は自動選択を使い、優先順位を固定したいときはメイン・バックアップ回線を選び、複数の接続を使うタスクでは接続分散を選びます。以下の設定例は、既存の proxy-groups リストに追加してください。rules はフォールバックルールを示す独立した例にすぎないため、既存のルール一式を置き換える目的でそのまま使わないでください。

proxy-groups:
  - ネットワーク出口
    type: select
    proxies:
      - 自動選択
      - メイン・バックアップ回線
      - 接続を分散
      - 香港-01

rules:
  - MATCH,ネットワーク出口

上記の MATCH は、ここまでのルールに一致しなかった接続をすべて処理します。LAN内や中国本土のサイト、業務専用のルールを残す場合は、これらの具体的なルールを前に置いてください。ルールは通常、上から順に照合されます。フォールバックルールを先頭に置いても、後続の振り分けルールは適用されません。

プロキシグループの参照名は正確に一致させ、循環参照も避けてください。たとえば「ネットワーク出口」から「自動選択」を参照する場合、「自動選択」から「ネットワーク出口」を参照してはいけません。最初の切り分けでは、手動選択グループの下に自動グループを1つ置く構成がおすすめです。階層が深くなると、速度テストの経路や最終的な出口が分かりにくくなります。

サブスクリプション更新後も設定変更を維持する方法

まず現在の設定をバックアップし、ノード名、グループ名、関連するルールを記録します。
クライアントにオーバーライド、マージ、拡張設定の機能があるか確認してください。サブスクリプションから生成されたファイルを直接編集すると、次回の更新で変更が上書きされることがあります。
proxy-providers を使う場合は、クライアントの対応状況に応じて use でプロバイダーを参照できます。プロバイダー名をノード名と取り違えて proxies に記述しないでください。
サブスクリプションを更新したら、ノード名や候補リストの変更を確認してから、設定チェックと手動テストを行います。

自動プロキシグループが動作しない場合の確認手順

まず設定が正常に読み込まれていることを確認し、その後、接続の実際の経路を追跡してください。DNS、TUN、グループの種類、テスト先を同時に変更するのは避けましょう。一度に1項目だけ変更すれば、どの設定が影響したのか判断しやすくなります。

手順1：YAML構文と参照先を確認する

インデントにはスペースを使い、タブは使わないでください。リスト項目の前には - を付け、同じファイル内でトップレベルの proxy-groups を重複させないようにします。mihomoのコマンドライン版がローカルにインストールされている場合は、次のコマンドで設定をテストできます。コマンド内のファイル名は、現在のディレクトリにある config.yaml を指しており、サブスクリプションのファイル名を変更する必要はありません。

mihomo -t -f config.yaml

特定のプロキシやプロキシグループが見つからないと表示された場合は、まず名前の参照を修正してください。構文チェックに通っても、設定を解析できたというだけで、リモートノードに接続できることやテスト先が正常であることまでは確認できません。

手順2：トラフィックが目的のグループに届いているか確認する

クライアントの接続一覧で対象ドメインを探し、適用されたルール、プロキシグループの経路、最終的に選ばれたノードを確認します。システムプロキシが適用されるのは、その設定を参照するアプリに限られます。TUNは仮想ネットワークインターフェースを通じて対象のトラフィックを処理します。どちらも fallback の優先順位アルゴリズムは変えません。アプリの通信がコアを経由していない場合、プロキシグループのパラメーターを調整しても、そのアプリの出口は変わりません。

設定に mixed-port: 7890 がある場合は、次のコマンドを使ってローカルプロキシ経由でWebページにアクセスできます。ここでの 7890 はポート番号の例なので、実際の設定と一致させてください。外部向けのコントロールポートと混同しないようにしましょう。

curl -x http://127.0.0.1:7890 -I https://example.com

手順3：速度テストの異常とサービス接続の異常を切り分ける

すべてのノードがタイムアウトする：すべての回線が同時に使えなくなったと決めつけず、まずローカルネットワーク、ノードの認証情報、テスト先への接続を確認します。
自動グループで遅延が表示されてもWebサイトに接続できない：対象サイトのDNS、適用されたルール、接続ログを確認し、問題がそのサイトだけで発生しているかを調べます。
数分おきに切り替わる：まず同じテスト先を使い続け、url-test の許容差を適度に増やします。たとえば20ミリ秒から50ミリ秒に変更し、その後のテスト結果を確認します。
切り替えても既存のタスクに変化がない：新しい接続で再試行してください。必要な場合は該当する接続だけを閉じ、進行中のタスクをすべて中断するのは避けましょう。

選び方はシンプルです。遅延を優先するなら url-test、リスト順を優先するなら fallback、接続を分散するなら load-balance を選びます。ルールでトラフィックの入口を明確にし、手動で選べる出口も残しておくと、自動グループを何層も重ねるより管理しやすくなります。構文全体はサイト内のプロトコルリファレンスで確認できます。初めて設定する場合は、インストール・設定ガイドもご覧ください。