狙いと前提
Clash Verge Rev で購読を読み込んだあと、「フェイルバック」「自動フェイルオーバー」などの名前の策略グループ実体が type: fallback の proxy-groups になっている構成は珍しくありません。コンセプトは 分流ルールの深掘りで触れたとおりリスト順を守りつつ可用性だけを自動で確保するタイプであり、いま問題にしたいのは「どの順でバックアップするか」を決めたうえでの健全性チェック設計です。mihomo が解釈する チェック URL と待ち時間・interval・tolerance・lazy を、GUI と YAML、さらにはPatch（覆い書き）だけに絞って一度まとめるのが本稿です。なお自動で「一番速い」ノードへ寄せたい用途は別物なので、その調整パラメータだけを読みたい場合は連載のうち url-test 専門の記事へ譲ります。Windows 版の総合ガイドは Verge Rev 活用ガイドを参照してください。
チェック一覧のレイテンシ表示とグループ本体の計測先が異なるとき、画面上だけ妙に騒がしく見えるので、YAML 上で当該 proxy-groups エントリーに注目してください。すべての項目が万人向けというより、提供者のサーバ状態と自宅回線の変動に依存する総合問題であることも理解したうえで、まずグループ単体のレバーから静かに寄せていきます。
fallback がやっていること（url-test との分水嶺）
fallback 型は、proxies: に並べた候補を上から順に見て、健全と判断できた最初のメンバーを使います。速さのランキングで毎回入れ替えるのではなく、先頭側を優先したいときの自動バックアップ列です。親グループ経由でも名前はフラットなので、「ここだけ保守契約優先」「ここだけ安価列を並べる」など、運用ポリシーを順番に刻むとチームでも説明しやすくなります。url-test は同一の健全性チェック機構を組み込みつつ選択軸が「遅延比較」へ寄る点が対照的で、両者は混同すると設計レビューで揉めやすいため、構成表に一行メモしておく価値があります。
したがって tolerance や interval が効くシーンも「最速狩り」のノイズではなく、健全・不健全の判定のゆらぎと切り替えの頻度の話に寄ります。実トラフィックが UDP であってチェックが小さめ HTTP であれば相関が薄い問題は fallback でも同様で、その場合は select への退避や別記事にある TUN と DNS の線を検討する必要があります。
proxies: 列とずれないか確認してください。DIRECT を末尾の保険に置くのか最優先で直させるのかによって、リストの読みがまったく変わります。
健全性チェック URL とタイムアウト
チェック URL は、メンバー全員から到達すべき共通のヘルスプローブ先です。環境により url キーだけで済む構成と、名前がテンプレートから写って見づらい場合があるので、アクティブなマージ結果をエディタで開いて文字列ごと確認します。視聴するCDN と地理的にも論理的にも離れ過ぎた参照先だと、「チェックだけ生きているのに本体は詰まる」乖離が出ます。とはいえ著作権ポリシーや規約への配慮、および短時間だけ 403 が返って計測が荒れるサイトは避けます。社内許可リストに載る軽量応答へ寄せられるなら運用も楽になります。timeout（または環境により相当する待ち時間の指定）は、チェック単発が何秒経ったら諦めるかに直結します。短すぎると一瞬の輻輳で次候補へ落ち、長すぎると障害検知がのろく感じられます。まずはやや長めに置き、コアログでタイムアウトとTLS失敗の比率を眺めてから詰めるのが安全です。
interval と tolerance の段階調整
interval は健全性の再評価周期です。短いほど障害からの復帰は速い反面、チェック起因のイベントが増え、不安定な URL を選んでいるとリスト全体が順送りで荒れることにもつながります。長いほど落ち着きますが、「いま上位が死んでいるのに気づくまで」を伸ばしたことになります。入口となるメインの fallback グループは慎重に決め、奥の細いグループだけ長周期にして負荷を逃がすという階層設計が現実的です。tolerance は、健全とみなすゆらぎの幅を広げて、軽い遅延差や測定ブレだけで順送りしないための調整になります。url-test の記事でも述べているとおり、計測先がブレる場合は数値いじりだけでは収束しません。順序は (1) url と timeout、(2) interval、(3) tolerance と覚えておくと手戻りが減ります。
lazy の捉え方
lazy: true にすると、アイドル気味なグループに対して先回りの健全性チェックを抑える方向になり、ノートPCや細いLTE経由などでは省電力と帯域節約につながることがあります。一方で、そのグループに初めてトラフィックが乗った瞬間まで選定準備が遅れる体感が増えるので、ユーザーがログインやライブ開始直後に敏感なワークロードを流すときはfalse も視野です。親の fallback と子のチェック済みグループで役割分担し、すべてを同じ lazy 既定にそろえる必要はありません。
Verge Rev で YAML／Patch に反映する
単体 YAML を直接いじれば proxy-groups ブロックへ interval・tolerance・lazy・url・timeout を足しますが、購読の再取得が上書きする運用ではローカルの差分が消えるのがよくある罠です。Clash Verge Rev では Patch や統合レイヤーを使って、離れたソースへ触れず同一キーを載せられるようにしてください。画面上の名前は開発ラインで差が出やすいので、「最終的にコアに渡るYAMLに項目が載ったか」をプレビューやログで確認するのが鉄則です。変更後はダッシュボードに加え、短時間だけ計測失敗が連続しないかコアログをウォッチし、前述の活用ガイドのログ節と突き合わせます。
# Example fallback proxy-group block (YAML). Names and timeouts are illustrative.
proxy-groups:
- name: "EDGE-FAILOVER"
type: fallback
proxies:
- "paid-primary"
- "paid-secondary"
- "DIRECT"
url: "https://www.gstatic.com/generate_204"
interval: 90
timeout: 5000
tolerance: 50
lazy: falsefallback が向かないとき
コンテンツの最適経路が時間帯で入れ替わるだけで順番には意味がない場合、fallback のまま並べ替えだけ弄っても満足しにくいです。そのときは親を select にして手動運用へ戻すか、速度追随が必要なら url-test へ切り替え、ルール側は 分流記事の親子グループ設計へ寄せてください。またオンラインゲームのようなUDP 主体では健全性チェックと実運用がすれ違いやすく、音声チャットだけ別経路になりたいケースでは UDP と TUNの整理が先になります。
よくある質問
並び順を変えると体感はすぐ変わるか
はい。fallback の中心は並び順なので、先頭だけ差し替えてもログの流れ方が読み換わります。サブスク更新で順序が毎回流動する構成なら、Patch 側で並びを強制固定するか、自分用の上流グループを挟んで名前参照を統一すると事故が減ります。
順送りが早すぎて疲れる
まず timeout と url を疑い、次に interval を長くし、最後に tolerance でブレ耐性を足します。tolerance だけ極端にいじっても計測先が不安定なら収束しません。
url-test と併用のコツは
典型は親を select、子へ url-test と fallback を並列に置き、運用単位で切り替えるパターンです。名前を抽象的にしすぎるとルール改修時に検索できなくなるので、用途が分かる接尾辞を自分で足すと楽です。
まとめ
Clash Verge Rev と mihomo の環境では、fallback 型 proxy-groups が優先順付きフェイルオーバーであることを押さえたうえで、健全性チェック URL・timeout・interval・tolerance・lazy を束ねて一度固めると運用説明もログ追跡も楽になります。速度自動が主役なら url-test、順番と可用性が主役なら fallback、という住み分けを明文化しておくと、GUI の覆い書きやサブスク更新のたびに迷いが減ります。
一部の商用プロキシワンストップGUIは自動経路評価の内部がブラックボックスで、チェック間隔やしきい値を自分の環境に合わせてYAML単位で固定しづらい製品もあります。更新頻度が低く、アフィリエイト中心のクローズドクライアントでは、問題が出ても再現手順や設定差分が残りにくいです。Clash エコシステムのように開いた設定ファイルとコミュニティ検証へ寄せるほうが、フェイルバック調整という地味だが効く仕事にも長くつき合えることが多く、透明性だけでなくトラブル時の自分自身の心理的負担も下がりやすいでしょう。