Clashのプロキシグループ設定を徹底解説：url-test・fallback・load-balanceの違い

まずはプロキシグループの役割を整理

Clashまたはmihomoでサブスクリプションを読み込むと、通常は複数のプロキシノードが登録されます。プロキシグループはノードとルールによる振り分けの間に位置します。ルールが接続先のグループを指定し、そのグループが実際に使うノードを決定します。手動選択グループではユーザーがノードを指定し、自動プロキシグループでは遅延、接続状態、振り分けアルゴリズムに基づいて継続的に選択します。

url-test、fallback、load-balanceはいずれもグループ内のノードをヘルスチェックしますが、選択の目的はそれぞれ異なります。単に「どれも自動でノードを選ぶ」と考えると、設定を誤りやすくなります。たとえば、予備回線に安定した主回線・予備回線の優先順が必要なのに、低遅延優先の設定にしてしまうケースです。ダウンロードで接続を分散したい場合も、ロードバランシングによって単一接続の帯域まで合算されるわけではありません。

プロキシグループの種類	主な目的	選択方法	適した用途
`url-test`	アクセス遅延を抑える	正常なノードから計測結果が最も良いものを選択	Web閲覧、検索、インタラクティブなアプリ
`fallback`	回線の可用性を維持	リスト順に最初の正常なノードを使用	主回線と予備回線、リモートワーク
`load-balance`	複数の接続に分散	コンシステントハッシュまたはラウンドロビンで振り分け	複数接続のダウンロード、並列リクエスト、一括処理

url-test：応答遅延を基準にノードを選択

url-testはグループ内の各ノードから指定したテストURLへアクセスし、応答時間を記録して、利用可能なノードからより高速なものを選びます。Web閲覧、インスタントメッセージ、リモートターミナルなど、操作時の遅延に敏感な通信に適しています。計測された68 ms、115 ms、240 msといった値はテストリクエストの往復時間であり、ダウンロード速度でも、ノードの実効帯域幅を直接示す値でもありません。

そのまま使える基本設定

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

rules:
  - DOMAIN-SUFFIX,example.com,自動選択
  - MATCH,自動選択

この設定では300秒ごとにヘルスチェックを行い、テストURLが正常なら空のレスポンスが返ります。tolerance: 80は、現在のノードと候補ノードの遅延差が80ミリ秒を大きく超えない限り、頻繁な切り替えを避けるための設定です。現在92 ms、新しい結果が54 msなら差は38 msなので、すぐに切り替えず現在のノードを維持するほうが安定しやすいでしょう。一方、新しいノードが55 msで現在のノードが190 msまで悪化した場合は、切り替える意味が大きくなります。

安定性を高めるパラメータ設定

url：テストURLには、レスポンスが小さく、安定して予測可能なものを指定します。計測先自体に帯域制限や地域ブロックがあると、すべてのノードが異常と誤判定される可能性があります。
interval：単位は秒です。通常利用では300秒から始め、ネットワークの変化が多い場合は120秒まで短くできます。固定回線の家庭環境なら600秒でも問題ありません。
tolerance：単位はミリ秒です。0にすると小さな遅延変動まで選択に影響し、遅延が近いノード間を頻繁に行き来しやすくなります。一般的には50～150ミリ秒が目安です。
lazy：有効にすると、実際に使用されていないプロキシグループで不要な能動テストを減らせます。予備グループを継続的に監視したい場合は、コアの動作と実際の用途に応じて無効化を検討してください。
proxies：ノード名は設定内の定義と完全に一致させる必要があります。空白、地域記号、数字を含む名前は引用符で囲むのがおすすめです。

遅延が最も低くても、体感が最良とは限りません。あるノードは48 msでも、夜間の実効帯域が8 Mbpsしかないかもしれません。別のノードは86 msでも、120 Mbpsを安定して出せる場合があります。Webページの表示には前者、大容量ファイルのダウンロードには後者が向くこともあります。つまり、url-testは遅延を基準に選ぶ機能であり、総合性能のスコアリングではありません。

fallback：優先順位を保って可用性を確保

fallbackもヘルスチェックを行いますが、正常なノードの中から最低遅延のものを探すわけではありません。proxiesのリスト順に確認し、前方にあり、現在利用できるノードを優先します。1番目が使用できなくなった場合にのみ2番目へ切り替え、1番目が復旧してチェックを通過すると、優先回線へ戻ることがあります。

「主回線を優先し、予備回線で補う」という明確な要件に適した動作です。たとえば社内業務で特定地域の出口を固定したい場合、主ノードを先頭に置きます。主ノードへの接続に失敗したときだけ、同じ地域の予備ノードへ切り替えます。予備ノードの遅延が30 ms低くても、主ノードを自動で奪うことはありません。

主回線・予備回線のYAML例

proxy-groups:
  - name: "業務回線"
    type: fallback
    proxies:
      - "シンガポール 専用線"
      - "シンガポール 予備"
      - "日本 予備"
    url: "http://www.gstatic.com/generate_204"
    interval: 180
    lazy: false

rules:
  - DOMAIN-SUFFIX,corp.example,業務回線
  - DOMAIN-SUFFIX,meeting.example,業務回線

この並び順が優先順位になります。まず「シンガポール専用線」を使い、利用できない場合は「シンガポール予備」へ切り替え、両方とも失敗した場合にだけ「日本予備」を使います。interval: 180は、およそ3分ごとに再チェックする設定です。障害が2回のチェックの間に発生すると、確立中の接続ではタイムアウトが先に起きる場合があります。そのため、復旧時間を重視する業務では間隔を長くしすぎないでください。

fallbackが適さないケース

常に現在の最低遅延ノードを選びたい場合は、url-testを使用します。
複数のノードで大量の独立した接続を同時に処理したい場合は、load-balanceを検討します。
複数ノードに明確な優先順位がなく、名前の並びだけが異なる場合、fallbackは速度を自動比較しません。
出口IPを固定したいログインセッションを、地域の異なる予備ノードへ安易に切り替えないでください。障害発生後に出口地域が変わる可能性があります。

load-balance：複数の接続を異なるノードへ振り分け

load-balanceの目的は、グループ内の複数の正常なノードで接続を分担することであり、唯一の「最速ノード」を選ぶことではありません。大量の独立したリソースを含むWebページ、分割ダウンロード、並列APIリクエスト、一括処理に適しています。接続の振り分け方法はstrategyで決まり、mihomoではconsistent-hashingとround-robinがよく使われます。

コンシステントハッシュの設定

proxy-groups:
  - name: "並列振り分け"
    type: load-balance
    strategy: consistent-hashing
    proxies:
      - "香港 01"
      - "香港 02"
      - "香港 03"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    lazy: true

rules:
  - DOMAIN-SUFFIX,download.example,並列振り分け
  - DOMAIN-SUFFIX,static.example,並列振り分け

consistent-hashingは対象情報をもとに安定したマッピングを行い、ノード構成に大きな変化がなければ同じ対象を同じプロキシへ割り当てやすくします。同一サイトへの複数リクエストで出口IPが頻繁に変わるのを抑えられるため、ログイン状態、CDNリソース、出口の一貫性がある程度求められる用途に適しています。

ラウンドロビンの設定

proxy-groups:
  - name: "ラウンドロビンノード"
    type: load-balance
    strategy: round-robin
    proxies:
      - "日本 01"
      - "日本 02"
      - "日本 03"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    lazy: true

round-robinは新しい接続を正常なノードへ順番に割り当て、接続数を分かりやすく分散します。出口の変更が許容される並列処理に適しています。同じWebサイトがIPの変化に敏感な場合、ログイン、CAPTCHA、セッション検証で問題が起きる可能性があります。その場合はコンシステントハッシュを優先するか、単一ノードのグループを使用してください。

ヘルスチェックのパラメータとノードの取得元

3種類のプロキシグループはいずれもヘルスチェックに依存します。テスト結果がタイムアウトや負数になっても、すぐにサブスクリプション内の全ノードが無効だと判断しないでください。まずテストURLにアクセスできるか、システム時刻が正しいか、DNSで対象ドメインを解決できるかを確認し、ローカルファイアウォールがコアプロセスを遮断していないかも調べます。特定のネットワークでテストURLが不安定なら、小さなレスポンスを返す別のHTTPSまたはHTTP URLに変更して結果を比較してください。

現象	優先して確認する項目	推奨する操作
すべてのノードで同時にタイムアウトする	テストURL、DNS、ローカルネットワーク	ブラウザでテストURLへ直接アクセスし、コアのログを確認する
1つのノードだけ継続的にタイムアウトする	ノードのパラメータ、サーバーの状態	そのノードを手動で選択し、実際の接続をテストする
url-testが頻繁に切り替わる	`tolerance`が小さすぎる	80 msまたは100 msから調整する
fallbackが最低遅延ノードを選ばない	ノードの並び順	業務の優先順位に合わせて並べ替えるか、url-testに変更する
ロードバランシング後にログインできない	出口IPが頻繁に変わる	コンシステントハッシュまたは単一ノードグループに変更する

サブスクリプションのノードが多い場合はプロキシプロバイダーを使う

サブスクリプションでノードが動的に更新される場合、proxiesへ1つずつ記述するのは管理が困難です。mihomoではproxy-providersでサブスクリプションの取得元を定義し、プロキシグループからuseでプロバイダーを参照できます。更新後、条件に合うノードが対応するプロキシグループに追加されます。

proxy-providers:
  main-subscription:
    type: http
    url: "https://subscription.example/profile.yaml"
    path: "./providers/main.yaml"
    interval: 21600
    health-check:
      enable: true
      url: "http://www.gstatic.com/generate_204"
      interval: 300

proxy-groups:
  - name: "香港自動"
    type: url-test
    use:
      - main-subscription
    filter: "(?i)香港|港|HK"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

filterでは正規表現を使ってノード名を絞り込みます。この例では、名前に「香港」「港」「HK」のいずれかを含むノードを残します。(?i)は英字の大文字・小文字を区別しない指定です。サブスクリプションによって「Hong Kong」「HKG」や地域の旗アイコンなど命名方法が異なるため、実際に使う前にノード一覧を確認し、実際の名前に合わせて式を調整してください。

プロバイダー層とプロキシグループ層の両方でヘルスチェックが実行される場合があります。前者はノードの利用可能状態を管理し、後者はプロキシグループ内の選択を行います。ノードが100個を超える場合、複数のチェック間隔をすべて30秒にすると探測リクエストが増えます。通常の設定では300秒、サブスクリプションの更新間隔は21600秒、つまり6時間が目安です。

Clash Nyanpasuで設定を適用する

まず、現在実行しているコアが設定内のプロキシグループの種類とパラメータに対応していることを確認します。Clash Nyanpasuでは「設定」→「Clashコア」と進むと、コアの種類とバージョンを確認できます。mihomoコアを使用している場合は、ログ冒頭で実際に読み込まれたバージョンを確認してください。この記事の例はmihomoで一般的な構文を使用しています。古いClash派生版では、一部のロードバランシング方式やプロバイダーのフィルタパラメータを認識できない場合があります。

「設定」ページを開き、現在有効になっているサブスクリプション設定を探します。
設定の編集画面を開き、トップレベルにあるproxy-groupsセクションを見つけます。
新しいプロキシグループをproxy-groupsに追加します。各階層で同じスペース幅のインデントを使用し、Tabは使わないでください。
rulesで処理対象のドメイン、ルールセット、またはフォールバックルールを新しいグループ名へ向けます。
設定を保存して再読み込みし、「ログ」を開いてYAMLの解析エラーやプロキシノードが見つからないというメッセージがないか確認します。
プロキシグループ画面で遅延テストを1回実行し、ノードの状態と自動選択の結果が想定どおりか確認します。

3種類のプロキシグループを組み合わせる

複雑な設定で、種類を1つだけ選ぶ必要はありません。地域ごとにurl-testグループを作り、その地域グループを手動選択用に使うこともできます。重要な業務にはfallback、大量ダウンロードにはload-balanceを設定する方法もあります。プロキシグループを入れ子にする場合は目的を明確にし、循環参照を避けてください。

proxy-groups:
  - name: "香港低遅延"
    type: url-test
    proxies:
      - "香港 01"
      - "香港 02"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "日本低遅延"
    type: url-test
    proxies:
      - "日本 01"
      - "日本 02"
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "重要業務"
    type: fallback
    proxies:
      - "香港低遅延"
      - "日本低遅延"
    url: "http://www.gstatic.com/generate_204"
    interval: 180

  - name: "ノード選択"
    type: select
    proxies:
      - "香港低遅延"
      - "日本低遅延"
      - "重要業務"
      - DIRECT

この構成では、まず各地域内で低遅延のノードを選び、その後「重要業務」を香港優先、日本予備の順で動作させます。最外層の「ノード選択」は手動操作の入口として残します。香港のノード全体が利用できない場合にだけ、fallbackが日本グループへ切り替えます。香港グループ内で1つのノードだけに問題がある場合は、内部のurl-testが別の香港ノードへの切り替えを先に試みます。

よくある設定ミスとトラブルシューティングの順序

グループ名またはノード名が一致していない

YAMLの名前は完全な文字列として照合されます。「香港 01」と「香港01」は異なる名前で、全角スペースと半角スペースの違いでも参照に失敗することがあります。ログにproxy not foundのようなメッセージが出たら、手入力せずノードの元の名前をコピーしてください。

インデントは正しいが階層が間違っている

proxy-groups、proxy-providers、rulesはいずれもトップレベルのフィールドです。プロキシグループをproxiesノードの内部に入れると、見た目が整っていても正しく読み込めません。リスト項目の前に2つのスペースを置くのは一般的な書き方にすぎず、本当に重要なのは同じ階層のインデントを統一することです。

速度テストは正常なのに、実際のWebサイトへアクセスできない

まずプロキシグループをグローバルモードまたは手動ノードに切り替えてテストし、ルールの問題かノードの問題かを切り分けます。手動ノードではアクセスでき、ルールモードで失敗する場合はルールの順序を確認してください。Clashのルールは上から順に照合されるため、先に記述されたDOMAIN、DOMAIN-SUFFIX、ルールセット、GEOIPによって別のプロキシグループへ送られている可能性があります。

TUNモードの結果がシステムプロキシと異なる

システムプロキシが制御するのは、システムのプロキシ設定に従うアプリだけです。TUNモードでは仮想ネットワークインターフェースを通じて、より広範な通信を取り込みます。TUNへ切り替えると、ターミナル、ゲーム、単独のアップデーターなどもClashを経由し始め、プロキシグループの負荷が変化することがあります。トラブルシューティングでは現在のモード、DNS設定、対象プロセスを記録し、通信入口の変化をプロキシグループの障害と取り違えないようにしてください。

サブスクリプションを変更すると設定が上書きされる

リモートサブスクリプションから生成された設定を直接編集すると、次回の更新時に元の内容へ戻る可能性があります。長期的に使うカスタム設定は、クライアントが対応する上書き、マージ、スクリプト処理の仕組みに入れてください。変更前にローカル設定をコピーしてテストし、プロキシグループ、ルール参照、プロバイダーのフィルタが正常に読み込まれることを確認してから、継続的に管理できる方法へ移行します。

選び方の結論：名前ではなく目的で決める

Web閲覧、検索、リモート操作にはurl-testを優先し、toleranceを50～150 msに設定して揺れを抑えます。
主回線を必ず優先し、障害時だけ予備回線へ切り替えるならfallbackを使います。ノードの並び順がそのまま業務上の優先順位になります。
大量の独立した接続を複数ノードへ分散したい場合はload-balanceを使います。ログイン状態が重要なら、コンシステントハッシュを優先してください。
単一接続の速度が遅い場合、ロードバランシングによる帯域の合算に頼らず、ノードの容量、プロトコルのオーバーヘッド、ローカルネットワーク、対象サーバーの速度制限をそれぞれ確認してください。
どの自動グループを使う場合でも、ルールの送信先、ヘルスチェックURL、コアの互換性、サブスクリプション更新後のノード名をあわせて確認してください。

実際の設定は、3ノードと300秒のチェック間隔を指定したシンプルなグループから始め、1日の遅延、切り替え回数、ログを確認しながら少しずつ調整します。最低遅延を求めるのか、可用性を優先するのか、並列接続を分散したいのかを明確にすれば、3種類のプロキシグループから適切なものを選べます。