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

切り替え方式を選んでからproxy-groupsを設定

応答の速いノードを自動で選ぶならurl-test、メイン回線を優先し、使えないときだけ予備回線に切り替えるならfallback、複数のノードに接続を振り分けるならload-balanceを使います。いずれもヘルスチェックに対応していますが、「自動」でもノードの選び方はそれぞれ異なります。

クライアントはサブスクリプションの読み込みやプロキシグループの表示、設定の有効化を担い、選択処理を実行するのはコアです。ClashとClash Meta（現mihomo）は基本的な項目が似ていますが、拡張項目や対応する方式は異なる場合があります。この記事の例はmihomoを対象としています。保存前にクライアントのコア情報や起動ログで使用中のコアを確認し、設定チェックで項目を検証してください。

種類	選択基準	主な用途	主な制約
`url-test`	テストURLへの応答時間と切り替え許容値で判定	普段のWeb閲覧、低遅延回線の自動選択	テストの遅延はダウンロード帯域を示すものではない
`fallback`	リスト順に、正常な候補から最初のノードを選択	メイン・予備回線の切り替え、普段使う出口地域の維持	障害の検知タイミングはチェック間隔に左右される
`load-balance`	振り分け方式に従って正常な候補を選択	複数の接続先や接続を分散して利用	単一接続の帯域は合算されない

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

url-testは候補ノード経由で同じテスト先にアクセスし、ヘルスチェックの結果をもとに応答の速いノードを選びます。表示される数値は、プロキシ経由でテストサービスにアクセスしたときの所要時間です。プロキシサーバーへのICMP pingの値でも、テストファイルのダウンロード速度でもありません。

最小構成とパラメーターの単位

proxy-groups:
  - name: 低遅延自動選択
    type: url-test
    proxies:
      - 香港・普段使い
      - 日本・予備
      - シンガポール・予備
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

url：ヘルスチェックの接続先です。例のURLは通常、HTTP 204を返します。応答が小さく安定しており、候補ノード経由でアクセスできるHTTPS URLを選んでください。
interval: 300：チェック間隔は300秒、つまり5分です。300ミリ秒ではありません。
tolerance: 50：切り替えの許容値は50ミリ秒です。遅延差がわずかなだけで出口が頻繁に切り替わるのを防ぎます。
lazy: true：遅延チェックを有効にします。使用していないグループの定期テストを減らせますが、初回使用時や手動測定時、コアのスケジュールによってチェックが実行される場合があります。

許容値は遅延の固定上限ではない

あるテストで現在のノードが120ms、別のノードが95msなら、差はわずか25msです。許容値を50msに設定している場合、この程度の差だけでは通常切り替わりません。別のノードが60msまで速くなり、差が60msに広がれば切り替え条件を満たす可能性があります。これはパラメーターの説明用に仮定した数値で、当サイトの実測値ではありません。実際の選択はヘルス状態やコアの実装にも左右されます。

toleranceを「50msを超えたノードは使わない」という意味に捉えないでください。これは切り替え時の遅延差を示す値で、全ノードに50msの合格基準を設定するものではありません。地域をまたいだ切り替えが頻繁に起きる場合は、チェック間隔を5秒に短縮するのではなく、まず許容値を20msから50msに上げて様子を見てください。

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

fallbackで重視するのは順序であり、遅延の低さではありません。リストの先頭にある正常なノードを優先し、使えなくなった場合にのみ次の正常なノードを選びます。メインノードが正常に戻ると、通常は再び優先されます。

proxy-groups:
  - メイン・予備切り替え
    type: fallback
    proxies:
      - 香港・普段使い
      - 日本・予備
      - シンガポール・予備
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: false

この例では「日本・予備」が70ms、「香港・普段使い」が150msでも、香港のノードが正常であればメイン・予備グループは香港を優先します。そのため、地域を固定したいノードや通信コストを抑えやすいノードを先に置き、地域の異なる予備ノードを後ろに並べてください。

障害時の切り替えで通信が途切れなくなるわけではない

定期チェックの合間には、状態の反映に遅れが生じることがあります。間隔を300秒に設定しても、障害が発生した瞬間に検知できるわけではなく、復旧時間が保証されるわけでもありません。
グループの切り替えが主に影響するのは、その後に開始する新しい接続です。既存のTCP接続のサーバー側セッションを別の出口へそのまま移すことはできません。動画、SSH、ダウンロードなどは再接続が必要になる場合があります。
ここでいうfallbackは、各リクエストが失敗するたびに同じリクエストを別ノードで即座に再試行する、アプリケーション層のリトライ機能ではありません。
lazy: falseにすると、使用していないグループも定期的にチェックされ、状態が更新されやすくなります。その分、テストリクエストが増え、モバイル端末がスリープから復帰する回数も増える可能性があります。

利用するサービスの地域を固定したい場合は、メインと予備の候補をできるだけ同じ出口地域にしてください。テスト先に接続できるのは、そのチェックリクエストが成功したことを示すだけです。すべてのサービスのドメインにアクセスできることや、2つのノードで同じコンテンツを利用できることは保証されません。

load-balance：接続を分散し、単一接続の速度は合算しない

load-balanceは正常な候補ノード間で接続を振り分けます。回線を束ねる機能ではなく、1つのTCPダウンロード接続を3つに分けて3ノードへ同時に流すこともありません。複数の独立した接続や接続先を分散できる点がメリットで、1回のダウンロード速度がノード数に応じて上がるわけではありません。

proxy-groups:
  - 複数出口への振り分け
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - 香港・普段使い
      - 日本・予備
      - シンガポール・予備
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: true

consistent-hashingとround-robinの選び方

方式	動作	注意点
`consistent-hashing`	接続先の情報をもとに一貫性ハッシュを行い、同じ接続先が同じ出口を使いやすくする	候補やヘルス状態が変わると、一部の接続先の割り当てが変わる場合がある
`round-robin`	ラウンドロビン方式で新しい接続を候補ノードに割り当てる	同じサービスへの接続でも、接続ごとに異なる出口IPになる場合がある

普段のWeb閲覧には、まずconsistent-hashingを試せます。同じ接続先の出口が頻繁に変わるのを抑えやすくなりますが、アカウント単位でセッションを固定する機能ではありません。1つのサービスが複数のドメインに接続することもあり、候補ノードが使えなくなれば割り当てが変わる場合もあります。ログインや決済、接続元IPを固定したい管理画面には、ルールを設定して手動選択グループか、安定したメイン・予備グループを使ってください。

ラウンドロビンが分配するのは接続であり、データ量ではありません。3つのノードに接続が振り分けられても、特定の接続でダウンロードが続けば、通信量に大きな偏りが出ることがあります。この基本例には重み付け設定はありません。ノードの通信料金が0.5倍、1倍、2倍でも、負荷分散が料金をコストの重みとして自動認識することはありません。

設定例：手動選択を残し、ルールの出口をプロキシグループに指定

以下の例では、3種類の自動グループを1つのselectグループにまとめています。設定を有効にしたら、クライアントのプロキシグループ画面で「プロキシ出口」を選び、低遅延自動選択、メイン・予備切り替え、複数出口への振り分け、またはノードの直接指定を選べます。切り分け時に自動方式を迂回し、個別のノードが正常か確認できます。

proxy-groups:
  - name: プロキシ出口
    type: select
    proxies:
      - 低遅延自動選択
      - メイン・予備切り替え
      - 複数出口への振り分け
      - 香港・普段使い
      - 日本・予備
      - シンガポール・予備

  - name: 低遅延自動選択
    type: url-test
    proxies:
      - 香港・普段使い
      - 日本・予備
      - シンガポール・予備
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - メイン・予備切り替え
    type: fallback
    proxies:
      - 香港・普段使い
      - 日本・予備
      - シンガポール・予備
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: false

  - 複数出口への振り分け
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - 香港・普段使い
      - 日本・予備
      - シンガポール・予備
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    lazy: true

rules:
  - MATCH,プロキシ出口

最後のMATCHは、ルールとグループ名の関係を示すためのものです。実際の設定では、既存のLAN向け、DIRECT、用途別の振り分けルールを残し、フォールバックルールは末尾に置いてください。この1行ですべてのルールを置き換えると、本来DIRECTにすべき通信までプロキシ出口に流れてしまいます。

proxy-providersを使うサブスクリプションではuseを使う

既存の proxy-providers からノードを取得する場合、グループ内にノード名を一つずつ記述する必要はありません。設定で 回線サブスクリプション というプロバイダー名を定義している場合は、次のように指定できます。

proxy-groups:
  - name: プロバイダー自動選択
    type: url-test
    use:
      - 回線サブスクリプション
    url: https://cp.cloudflare.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

useで参照するのはプロバイダー名、proxiesで参照するのはノード名またはグループ名です。互いに置き換えて使うことはできません。プロバイダーの更新間隔はノード一覧を取得するタイミング、ヘルスチェック間隔は接続状態をテストするタイミングを決めます。チェック間隔を60秒にしても、サブスクリプションの一覧が60秒ごとに更新されるわけではありません。

プロバイダー側にもhealth-checkを設定できる場合があります。グループとプロバイダーのチェックはコアがスケジュールするため、2つの間隔を単純に足して障害時の切り替え時間を計算することはできません。設定を保守するときは、定期チェックを担当する箇所を明確にし、複数のプロバイダーやプロキシグループで短すぎる間隔を設定して、不要なリクエストが増えないようにしてください。

動作確認とトラブル対処：実際の出口を確かめてからテスト設定を調整

まずYAMLとノード参照を確認

現在動作している設定をバックアップします。サブスクリプション更新で上書きされる一時ファイルを直接編集せず、永続化できるオーバーライド機能や設定のマージ機能でプロキシグループを変更してください。
インデントにはスペースを使い、Tabは使わないでください。グループ名は重複させず、ルール内の名前とグループ名を完全に一致させます。グループ同士が循環参照にならないようにしてください。
コマンドライン版のコアがPATHに通っている場合は、mihomo -t -f ./config.yamlを実行して設定を確認します。相対パスは実際のファイル位置に合わせてください。
設定を再読み込みし、ヘルスチェックを手動で一度実行してから、プロキシグループの候補状態を確認します。設定チェックに通っても、ノードへの接続が成功するとは限りません。

明示的にプロキシを指定して新しい接続を確認

現在の設定でHTTPまたは混合プロキシポートが実際に7890の場合は、次のコマンドでテストできます。このポート番号は動作確認用の例で、すべてのクライアント共通の値ではありません。ポート設定または設定ファイルのmixed-portを先に確認してください。

curl -I --proxy http://127.0.0.1:7890 --max-time 15 https://cp.cloudflare.com/generate_204

プロキシを明示的に指定すれば、コマンドの実行結果はターミナルがシステムプロキシを読み込んでいるかどうかに左右されません。HTTP 204が返れば、このテスト経路が使えることを確認できます。さらにクライアントの接続ログで、適用されたルール、プロキシグループ、実際に使われたノードを確認してください。サービスが使えるか判断するには、実際の接続先への新しい接続も試してください。テストURLへの接続成功だけでは判断できません。

よくある症状と対処の順番

すべてのノードがタイムアウトする：まず、正常に使えると分かっているノードを手動で選びます。サービスにはアクセスできるのにテストだけ失敗する場合は、テスト用ドメインやDNS、URLへの到達性を確認してください。すぐにすべてのノードを削除しないでください。
url-testでノードが頻繁に切り替わる：まずテスト先が安定しているか確認し、そのうえで許容値を大きくします。間隔を300秒から10秒に短縮すると、一時的な変動が反映されやすくなり、消費電力も増える可能性があります。
fallbackが最速ノードを選ばない：正常なノードをリスト順に選ぶ仕様どおりの動作です。遅延を比較したい場合はurl-testに切り替えてください。速度順を再現するために予備ノードの順番を調整する方式ではありません。
load-balanceで通信量が均等にならない：長時間続く接続が少数に限られていないか、複数のリクエストが同じ接続先に集中していないか確認してください。一貫性ハッシュでもラウンドロビンでも、各ノードのデータ量が均等になるとは限りません。
グループは切り替わったのに、ページには以前の出口が表示される：まず新しい接続を開始してください。ブラウザーの接続再利用、ダウンロード、長時間接続では、以前のノードが引き続き使われる場合があります。接続を切ると処理が中断されるため、問題のないタイミングで行ってください。
サブスクリプション更新後に設定が消えた：カスタム設定をクライアント対応の永続化オーバーライド機能へ移し、マージ後の最終設定を確認してください。エディター内の断片だけを確認しても不十分です。