Clash ポリシーグループの url-test と fallback：自動遅延テストとフェイルオーバーの使い分け

1. ポリシーグループがルールとノードの中間にいる理由

Clash の設定はざっくり、proxies（個々のサーバ）→proxy-groups（それらを束ねた名前付きグループ）→rules（ドメインや IP をどのグループへ送るか）、という流れで評価されます。ルールが MATCH,PROXY のように書かれているとき、その PROXY は実は「単一ノード」ではなく、ポリシーグループの名前であることがほとんどです。クライアントのパネルで「香港」「日本」「自動選択」と切り替えているのは、多くの場合このグループの中身を変えているか、グループ自体のタイプによって出口が決まっています。

select タイプはユーザーが手で選ぶだけですが、url-test と fallback はコアが定期的にヘルスチェックに近い計測をして、内部で選択を更新する点が共通しています。ここを混同すると、「自動選速にしたのに IP が変わりすぎる」「バックアップ用のはずなのに遅延でどんどん切り替わる」といった体感のずれが生まれます。まずは型を押さえることが重要です。

購読 URL の取り込み手順そのものは、当サイトの サブスクリプション導入ガイドで扱っています。本稿では、すでにプロファイルが読み込めている前提で、proxy-groups の編集に焦点を当てます。

2. url-test：遅延テストで「いま最速」のノードを選ぶ

url-test は、指定したテスト URL への到達に要する遅延をノードごとに測り、しきい値を満たすなかで「いま一番小さい」ものを選ぶタイプです。代表的なテスト先は https://www.gstatic.com/generate_204 のような HTTP 204 を返す軽量エンドポイントで、購読提供者が推奨している URL があればそれに合わせるとよいです。interval（秒）で計測の間隔を決め、tolerance（ミリ秒、実装依存）を入れているプロファイルもあります。これは「今の選択がまだ十分速いなら、わずかに速い別ノードに頻繁に乗り換えない」ためのクッションです。

重要なのは、url-test の目的は「常に最速を追う」ことに近いという点です。ネットワーク状況やサーバ側の混雑で遅延が入れ替われば、選ばれるノードも変わります。一般の Web 閲覧や動画視聴で「とにかく体感を速くしたい」用途には向いていますが、同じサービスに対して「出口 IP をできるだけ固定したい」という用途とは相性が悪い場合があります。後述の fallback や、手動の select と組み合わせる理由がここにあります。

mihomo / Meta 系では追加のキー（例: 遅延の取り扱いや lazy 的な挙動）がバージョンで変わることがあるため、使っているコアのドキュメントを一度確認するのが安全です。本稿の例は一般的な Clash 系の書き方に沿った最小構成です。

3. fallback：リスト順で「生きている最初の」ノードを使う

fallback は、proxies 配列に書いた順番を優先順位とみなし、上から順に「使えるか」を試し、最初に成功したノードを使い続けるタイプです。ヘルスチェックに失敗したり、遅延が閾値を超えたりしたときに、次の候補へ自動で切り替わるイメージで理解するとよいです。ここでいう「成功／失敗」は、やはり url へのテスト結果に基づくことが多く、interval でテストの頻度が決まります。

つまり fallback は、「遅延が最も小さいものを常に選ぶ」わけではありません。主ノード（リストの先頭）が健全な限りそこに留まり、障害や明らかな不調が検知されたときだけ備援へ移る、という設計に合います。そのため、同一会話や同一ログインセッションで出口 IP を変えたくないサービス（例: 特定の AI サービスで頻繁な IP 変更がリスクになるケース）では、専用の fallback グループを作り、候補を少数に絞る、という運用がよく説明されます。実際のドメインルール付きの例は、ChatGPT 向けのルール記事で別途扱っています。

注意点として、fallback も「絶対に IP が変わらない」わけではありません。主ノードが落ちたあと、別のノードに切り替われば出口は変わります。あくまで「遅延競争で毎回ノードが入れ替わる」url-test より、平常時は固定に近い挙動になりやすい、という位置づけです。

4. 一言でいうとどう違うか（対比表）

検索意図として多い「自動で遅延の少ないノードを使いたい」は url-test、「主が死んだら予備へ」は fallback、とまず覚えてください。細かい数値はプロファイルとコア実装に依存しますが、目的の違いは次の表のとおりです。

ルール全体の流れ（ドメイン別にどのポリシーへ送るか）は、ルールルーティングの解説ページと一緒に読むと、グループ名と RULE-SET の書き方が頭の中でつながります。

5. 設定例（proxy-groups の YAML）

下記は説明用の抜粋です。実際のプロファイルでは、proxies 側で定義したノード名と綴りを完全一致させる必要があります。名前は購読提供者が付けたものをそのまま使うのが安全です。

proxy-groups:
  # Manual selection (often used as dashboard entry)
  - name: 🔰 手動選択
    type: select
    proxies:
      - 🚀 自動遅延テスト
      - 🛡️ フェイルオーバー
      - 香港 A
      - 日本 B
      - DIRECT

  # url-test: pick lowest latency among candidates
  - name: 🚀 自動遅延テスト
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 香港 A
      - 日本 B
      - シンガポール C

  # fallback: try in order, stay on first healthy
  - name: 🛡️ フェイルオーバー
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 60
    proxies:
      - US メイン
      - US 予備
      - 香港 A

tolerance は実装によって省略または意味が異なる場合があります。購読が巨大でノードが数十ある場合、url-test の対象を地域ごとに分けたグループに分割すると、パネルでの選択が分かりやすくなります。また fallback のリストは、本当に「主」と「予備」にしたい順番を上から並べることが最重要です。

6. ルール側でグループ名を参照する

ルールの最右列には、DIRECT や REJECT のほか、ポリシーグループの名前を書きます。例として、海外サイトをまとめて 🚀 自動遅延テスト に送りたいなら、次のような行になります（実際の購読では RULE-SET やプロバイダ名が既に決まっているため、衝突しないよう注意してください）。

rules:
  - DOMAIN-SUFFIX,google.com,🚀 自動遅延テスト
  - GEOIP,CN,DIRECT
  - MATCH,🔰 手動選択

MATCH は最後の「落ちどころ」です。ここを select グループにしておけば、ダッシュボードで一括の出口を切り替えやすくなります。特定のドメインだけ fallback に送りたい場合は、そのドメイン用のルール行をより上に置き、他のトラフィックとは別グループに分けるのが定石です。

7. 使い分けの実例

一般的なブラウジングやアプリの通信では、メインの出口を url-test にしておくと、混雑や線路の変化に追従しやすくなります。一方で、「ログイン状態やリスク検知に敏感なサービス」では、自動でノードが入れ替わると不利なことがあります。そうしたサービス用に別の fallback グループを用意し、候補ノードを数個に限定する、という分け方がよく取られます。

また、ゲームやリアルタイム通信では、遅延の絶対値だけでなく「安定して同じ経路か」も重要になります。url-test の interval が短すぎると、わずかな変動でノードが切り替わり、体感が不安定になることがあります。逆に長すぎると、実際に遅くなっても切り替わるまで時間がかかります。自分の回線と用途に合わせて間隔を調整するのが現実的です。

Windows で TUN を使う場合など、プロセス単位のルールと組み合わせると、ゲームだけ別ポリシー、などの細かい制御ができます。関連する話題は Clash TUN と UWP の記事も参照してください。いずれにせよ、ポリシーグループの型（url-test / fallback）を取り違えないことが、設定の意図どおりに動くための第一歩です。

8. うまくいかないときのチェック

テスト URL がブロックされていると、全ノードが不合格扱いになり、期待と違うフォールバック動作をすることがあります。企業ネットワークや国によっては特定のドメインへのアクセスが制限されるため、購読提供者の推奨 URL や、自環境で通る別の 204 エンドポイントへの変更を検討してください。

ノード名の不一致は典型的な設定ミスです。proxies にある名前と proxy-groups の参照が一字ずつ一致しているか確認します。コメント行や全角スペースの混入にも注意してください。

ルールの順序も忘れがちです。より具体的なルールを上に、広い MATCH を下に配置する、という基本は、ポリシーグループを増やしたあとも同じです。意図せず別のグループに流れているときは、ログ機能（クライアント依存）でどのルールに当たったかを追うと早いです。

最後に、本稿は一般的なネットワーク設定の説明であり、特定のプロバイダやサービスの利用を推奨するものではありません。利用規約や法令に従い、自己責任で運用してください。

9. まとめ

Clash の url-test は遅延テストに基づいて最適なノードを選び直すのに対し、fallback はリストの優先順位に沿って使える最初のノードに留まり、障害時にだけ次へ進む、という役割の違いがあります。「自動で速いところへ」と「主が死んだら予備へ」は似て非なるので、まず目的をはっきりさせてから型を選ぶと設定がブレません。

購読の取り込みからルールの考え方までをあわせて押さえたい場合は、前述のガイドと ルールルーティングを参照し、クライアントのログで実際の命中を確認しながら微調整していくと安心です。Clash 系クライアントはコアや GUI の更新が続くため、リリースノートと合わせて自分のプロファイルを定期的に見直す習慣もおすすめです。

まずは動作の安定したビルドから環境に合わせて試し、ポリシーグループとルールを少しずつ整えていくのがよいでしょう。PC やモバイル向けのパッケージは、 → 無料で Clash をダウンロードし、快適な接続体験を試す から入手できます。