Clash Meta の url-test と fallback：lazy・tolerance で自動選局と故障切替を組み立てる

まず押さえる三つの概念

ポリシーグループは、ルール側からはひとつの名前（例：PROXY）として参照され、内側で実際に使うプロキシ候補と選び方のルールを束ねます。select はユーザーまたは UI が指定した一つを使い続け、url-test は定期的に url へ小さな HTTP リクエストを投げ、成功したノードの遅延を比較して勝者を選びます。fallback はリストの先頭から順に生存確認し、最初に通ったノードを使うイメージに近く、速度順位をつけるのではなく優先順位付きの冗長化です。

どちらの型でも「候補」には単一のプロキシだけでなく、別のポリシーグループ名を入れ子にできます。たとえば地域ごとの select を並べ、ひとつ上の url-test で地域代表同士を比べる、といった合成が可能です。購読で降ってくる名前と衝突しないよう、接頭辞をそろえた自前グループを作ってからルールの MATCH より手前で参照させると保守しやすくなります。

• url-test：遅延が小さいほうへ「乗り換え」やすい（ただし tolerance で抑制可能）。
• fallback：上から順に「生きている最初の一本」へ寄せる。主用途はバックアップ鎖。
• lazy：true にすると、ノードが選ばれた瞬間まで積極的に全体を測り回さない動きになり、起動直後のプローブ負荷を抑えやすいです。

url-test の主なフィールド

代表的なキーは次のとおりです（実装バージョンによって省略形や既定値は読み替えが必要な場合があります）。url はヘルスチェック先です。Google や Cloudflare の生成ページがよく使われますが、自宅 ISP と相性の悪い経路では常にタイムアウトになり、全ノードが不合格に見えることがあります。可能なら自分がよく使うサイト系と同程度の地域・TLS 振る舞いになる URL を選ぶか、購読提供者が推奨するテスト先に合わせます。

interval はテスト周期（秒）です。短いほど変化に追随しやすい反面、バックグラウンドの接続が忙しくなり、かつ RTT が数 ms 単位で入れ替わるノードでは勝者が頻繁に入れ替わる（フラップ）原因にもなります。ブラウジング全般なら十数秒〜数十秒、長めの動画や大きなダウンロードを同一グループで流すなら、もう少し長くする・別グループに分ける、といった調整が現実的です。すでに別記事でも触れているとおり、ストリーミングやソーシャル系では短い interval がセッション途中の切り替えを誘発しやすい点に留意してください。

tolerance は「新しい勝者の RTT が、現在の勝者よりこれだけ以上良くなければ乗り換えない」ためのヒステリシスです。ゼロに近いとわずかな差で切り替わり、大きいと今のノードが多少悪くても維持しやすくなります。VoIP や WebSocket、IDE の長い TLS セッションでは、乗り換え自体が再接続を伴うので、tolerance と interval を同時に締めすぎないのがコツです。

fallback の動きと使い所

fallback グループでは、候補リストの上から順に可用性が評価され、最初に healthy とみなされたノードが選ばれます。下位のノードは「上位が死んだときの保険」なので、欲しい優先順位通りに並べることが重要です。商用の安定ノードを上に、実験用や混雑しやすい出口を下に、あるいは帯域の広いデータセンターを上に、遅延だけは良いが不安定な候補を下にする、といった運用がよく行われます。

障害の偽陽性を減らすには、url 側がブロックリストに乗る、レート制限で 429 を返す、といったテスト先側の事情も疑います。ログで「候補ノードそのものよりテスト GET が失敗している」パターンが続く場合は、URL の置き換えや interval の伸長を検討してください。

段階的に YAML を足す

最初に proxies 配列が購読から入っている前提で、(1) ベースとなる select か素のプロキシ名を確認し、(2) 遅延勝負用の url-test を追加し、(3) 必要なら上位に fallback を載せて「url-test グループ本体・別出口・DIRECT」などの順で切り替える、という順が理解しやすいです。ルールでは最終的にひとつのグループ名（例：🔰 自動選択）だけを指すようにしておくと、アプリの UI でも追いやすくなります。

# Illustrative proxy-groups — replace proxy names with your subscription
proxy-groups:
  - name: "AUTO-BEST"
    type: url-test
    proxies:
      - NODE-A
      - NODE-B
      - NODE-C
    url: "https://www.gstatic.com/generate_204"
    interval: 30
    tolerance: 50
    lazy: false

  - name: "AUTO-FAILOVER"
    type: fallback
    proxies:
      - AUTO-BEST
      - NODE-SPARE
      - DIRECT
    url: "https://www.gstatic.com/generate_204"
    interval: 30

上の例では、まず url-test で三つのノードの中から遅延優位なものを選び、その結果を fallback の第一候補にしています。スペアが死に、さらに全体がダメなら最終的に DIRECT へ落とす、という二段の安全弁です。自宅回線で国外直結が無意味な場合は DIRECT の代わりに別の固定プロキシや reject を検討してください。実運用では購読更新で名前が変わるため、UI での名前と YAML の完全一致にも注意します。

ヘルスチェック URL を選ぶときの観点

「204 が返る軽い URL」は遅延測定には向きますが、実トラフィックと相関が弱いこともあります。たとえば測定では速いが、動画 CDN や銀行 API では別経路になることがあります。可能なら、利用シーンに合わせて別の url-test グループを用途別に分けるほうが、結果の解釈がブレにくいです。仕事用ブラウザはビジネス系の安定出口、エンタメは冗長性重視の fallback、開発用 CLI はフラップしにくい長め interval、といった分け方が一例です。

観点	補足
応答が軽いか	ヘルスチェック自体が帯域を食みすぎない。タイムアウト値との兼ね合いも。
ブロックされにくいか	データセンター出口から 403・451 になり続ける URL は不適切。
HTTPS / SNI	多くのクライアントは TLS ハンドシェイクを伴う URL を想定しています。

フラップ（頻繁な切替）への対処

症状としては、ブラウザの読み込みが一定時間ごとに一瞬切れる、チャットの WebSocket が頻繁に再接続する、大型ファイルの取得が途中からやり直しになる、などが挙げられます。まずログでポリシー名とノード名が短周期で交替していないか確認します。そのうえで (1) tolerance を上げる、(2) interval を伸ばす、(3) 候補数を減らして品質の揃ったプールにする、(4) そもそも用途別にグループを分ける、の順で試すと原因切り分けがしやすいです。

ルールプロバイダで遠隔ルールを重ねている場合は、意図しない MATCH が別グループへ流れていないかも合わせて確認してください。ルールセットの更新間隔や配置は 「ルールプロバイダの path と更新間隔」 に整理されています。

反映後に確認したいチェックリスト

まとめ

url-test は「速いところへ寄せる」、fallback は「決めた優先順で生きているところへ寄せる」という役割の差を押さえると、設定の意図がブレずに済みます。lazy と tolerance は、パフォーマンスログがきれいな数字になることより体感の切断少なさを優先するときの調整ノブです。購読ノードが多い環境ほど、グループを用途で分けて命名規則を揃えるほうが長期運用では楽になります。

Clash を無料ダウンロードして、快適な接続を体験する