Clash URL-Test／Fallback：遅延テストとフェイルオーバー

1 なぜ今 url-test と fallback か

リモート購読をインポートすると、数十個のプロキシが一気に proxies に並びます。初期のテンプレートはしばしば type: select のグループだけで、ユーザーがダッシュボードで都度切り替える前提です。日常利用では「とりあえず遅延の低いもの」「メインが不通のときだけ予備」という機械的な判断を自動化したい場面が多く、その用途に合うのが url-test と fallback です。前者は一覧の中から定期的な HTTP ベースの遅延測定で最適とみなしたノードを選び直し、後者はリストの上から順にヘルスチェックし、生きている最初のノードを固定します。どちらも proxy-groups に宣言する戦略グループの一種であり、Mihomo（Clash.Meta）を含む現行の Clash 互換コアで広く使われます。

なお DNS ブロックの dns.fallback や fallback-filter は、名前解決のフォールバック列であり、本稿のプロキシ側 type: fallback とは役割が異なります。混同しやすいので、DNS まわりは別稿の DoH／FakeIP 解説に任せ、ここではトラフィックのアウトバウンド選択だけを扱います。購読 URL の取り込みや SS／V2Ray から YAML への変換がまだの場合は、購読変換ガイドで土台を整えてから読み進めると理解が早いです。

2 URL-Test 型：遅延が最小のノードへ自動で張り替える

type: url-test は、グループに列挙した各プロキシに対して、指定した url へ HTTP リクエストを送り、往復遅延を測定します。一定間隔ごとに再測定し、最も速いと判断したノードを現在の選択として使います。ここで重要なのが tolerance（許容差）です。新しい候補が現選択より速くても、その差が tolerance ミリ秒以内なら張り替えない、という挙動により、境界付近での頻繁な切り替え（フラッピング）を抑えられます。混雑した Wi-Fi 下では遅延が数ミリ秒単位で揺れるため、ゼロに近い値にすると不安定になりがちです。実務では 30〜80ms 程度から試し、様子を見て調整するのが無難です。

interval は再テストの周期（秒）です。短くすると追従は速い反面、バッテリー消費やログノイズが増えます。長くすると最適ノードへの収束が遅れます。モバイルと常時電源のデスクトップでは好みが分かれるので、クライアントのプリセットをそのまま信じず、自分の回線に合わせて触る価値があります。lazy: true を付けると、そのグループが実際にルールで使われるまで積極的に測らない、という意味合いで待機電力を抑えられます。初回接続直後だけ遅い、という体感が出る場合は lazy: false に戻して比較してください。

url は「軽くて安定した HTTP エンドポイント」が定番です。コミュニティでは http://www.gstatic.com/generate_204 のような 204 応答を返す URL がよく使われますが、地域やプロバイダーによっては到達性が異なるため、自環境で curl などから到達確認してから固定するのが安全です。HTTPS のテスト URL を使う構成もありますが、TLS ハンドシェイク込みの遅延が乗る点を理解しておいてください。

YAML

proxy-groups:
  - name: "AUTO-BEST"
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies:
      - hk-01
      - hk-02
      - jp-01
      - us-west-01

名前の一致： proxies にある実ノード名と一字一句合わせる必要があります。購読マージ後にリネームされた場合は、グループ側も同じ名前に更新してください。proxy-providers 由来の名前も同様です。

3 Fallback 型：優先順位どおりに「生きている先」を探す

type: fallback は、リストの上から順に見ていき、ヘルスチェックに通った最初のプロキシを使います。遅延の絶対値で並べ替えるのではなく、「優先度」をYAMLの並び順で表現するのがポイントです。たとえば契約上メインのデータセンター、混雑時だけ使う予備、最後の手段として直結の DIRECT、といった階層をそのまま配列に書けます。メインがタイムアウトや TLS エラーで落ちたときにだけ自動で次へ滑り込む、というユーザー期待に素直に合うタイプです。

ヘルスチェックの間隔や URL は url-test と同様に interval と url で指定します（実装により省略可能な場合もありますが、明示しておくと挙動が読みやすい）。proxies の最後に DIRECT を置くと、すべてのアウトバウンドが不通でも国内向けの通信だけは抜ける、という逃げ道を作れます。ただし「プロキシが全部死んでいるのに気づかず直結する」ことになるので、プライバシー要件の高い用途では最終手段を REJECT にする、別の通知を併用する、など運用側の判断が必要です。

url-test が「常に最速を追う」一方で、fallback は「書いた順番を尊重する」ため、ビジネス用途で「必ずこのエンドポイントを第一希望にしたい」場合は fallback の方が制御しやすいです。逆に、遅延だけが問題で優先度は一定なら url-test の方が向きます。両方を組み合わせ、外側をセレクタで切り替える構成もよく見られます。

YAML

proxy-groups:
  - name: "FAILOVER-CHAIN"
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - primary-ss
      - backup-trojan
      - spare-vmess
      - DIRECT

4 ルールとセレクタへ載せる

どちらのグループも、宣言した name がそのままルールのターゲットになります。例として GEOIP,CN,DIRECT のあとに国外向けをまとめるなら MATCH,AUTO-BEST のように書き、ダッシュボードでは最上位に「プロキシモード用の select」を置き、その選択肢に AUTO-BEST と FAILOVER-CHAIN、個別ノードを並べると運用が柔らかくなります。ルールは上から評価されるので、細かいドメイン例外を先に書き、最後に広い MATCH を置く、という一般的な Clash の作法は変わりません。

ストリーミングや広告ブロックなど、ルールセットを外部から引く場合はACL4SSR 系の解説のように rule-providers と組み合わせます。戦略グループの名前を一貫させておくと、GUI クライアントのプロファイルを切り替えてもルールの向き先が追いやすいです。ネストしたグループ（url-test のメンバーに別の select を入れる等）も可能ですが、デバッグが難しくなるので、まずはフラットに近い構成から始めることをおすすめします。

5 よくある落とし穴

テスト URL が自分から見えない： 企業プロキシや国フィルタの内側では、定番の gstatic に届かないことがあります。その場合は到達できる軽量 HTTP に差し替えないと、全ノードが不健康扱いになります。
tolerance と体感のギャップ： url-test は「測定 URL への RTT」を見ています。ゲームの ping や動画 CDN までの経路とは一致しません。体感が悪いときはセレクタで別グループに切るか、ノード集合を見直してください。
interval を極端に短くしすぎ： 負荷とログが増え、一部のプロバイダー側でレート制限に触れる報告もあります。意味のある範囲に留めましょう。
IPv6 だけ通る／通らない： ipv6: true/false やノードの IP スタックと相性が出ると、ヘルスは成功でも実トラフィックが別経路になることがあります。切り分け時はクライアントの IPv6 設定も確認します。
クライアントの古いコア： 機能名は似ていても挙動差があるため、可能なら Mihomo 系の現行ビルドに揃え、ダッシュボードのログで実際にどのノードが選ばれたかを追跡すると安心です。

セキュリティと規約： 本稿の例は教育目的です。利用規約・当地の法規・職場ポリシーを遵守し、信頼できる購読元からのみ設定を取得してください。テスト URL への過剰アクセスは避け、間隔と対象を適切に保ってください。

6 まとめ

url-test は遅延測定に基づく自動最適化、fallback は明示した優先順位に基づくフェイルオーバー、という役割分担を押さえれば、購読後の「運用まわり」の設定はだいぶ楽になります。tolerance・interval・lazy とテスト url の四つを環境に合わせて整えるのが成功の鍵で、一度うまく動いた値をメモしておくと再セットアップが速いです。ルール側ではグループ名を一貫させ、セレクタで手動オーバーライドできる余地を残しておくと、トラブル時の切り分けもしやすくなります。

GUI クライアントではこれらの YAML を直接編集しなくても、同等のプリセットが選べる場合があります。それでも中身を読めると、ダッシュボードの表示と実際の挙動のズレを自分で説明できるようになります。グラフィカルに購読管理と遅延表示をまとめたい場合は、ダウンロードページで紹介しているビルドのうち、自 OS に合うものを選ぶと、同じ proxy-groups 概念を画面越しに操作しやすいです。

総じて、Clash 互換スタックはルールと DNS、そして戦略グループの三層で体験が決まります。本稿の url-test／fallback を足すと、サブスク直後の「とりあえずつながる」から一歩進み、回線状況に追従する構成へ近づけます。

→ 無料で Clash をダウンロードし、設定の自由度を確かめる

Clash の URL-Test と Fallback を書き分ける：
遅延テストで自動選別、障害時は次のノードへ